Date: Tue, 14 May 2019 22:08:24 +0200 From: Polytropon <freebsd@edvax.de> To: Per olof Ljungmark <peo@nethead.se> Cc: freebsd-questions@freebsd.org Subject: Re: rcorder - wait for tap0 Message-ID: <20190514220824.a4779bb2.freebsd@edvax.de> In-Reply-To: <63fe68c5-b85b-7d6d-a438-596ec8041f6b@nethead.se> References: <dc363ae4-d331-efd0-e099-ee01b7eaddb1@nethead.se> <20190514182945.0ced24d4@gumby.homeunix.com> <20190514185340.0159358c@gumby.homeunix.com> <63fe68c5-b85b-7d6d-a438-596ec8041f6b@nethead.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 14 May 2019 21:39:26 +0200, Per olof Ljungmark wrote: > On 2019-05-14 19:53, RW via freebsd-questions wrote: > > On Tue, 14 May 2019 18:29:45 +0100 > > RW wrote: > > > >> On Tue, 14 May 2019 08:49:52 +0200 > >> Per olof Ljungmark wrote: > >> > >>> Despite large amounts of cofee and time I cannot grasp how to make > >>> this happen. > >>> > >>> What I want is > >>> > >>> Boot -> start openvpn/tap0 configured -> start named -> start jails > >>> > >>> Because the jails uses tap0 of course they cannot start before tap0 > >>> is up, but this is what happens in the default configuration. > >>> > >>> Surely this cannot be unique? How did you do it? > >>> > >>> Preferrably without messing with rc.d scripts that gets overwritten > >>> when updated. > >> > >> You need an rc script in /usr/local/etc/rc.d with something like: > >> > >> > >> # PROVIDE: vpnwait > >> # REQUIRE: openvpn > >> # BEFORE: <whatever string the jail rc.d script provides> > > > > now I come to think about it openvpn runs after LOGIN, so either you > > have to put up with the order > > > > named, openvpn, jails > > > > or rewrite the openvpn script. > > > > What I did was to allow DNS to pass directly to one well-known server so > > lookups could happen before openvpn started. > > Thank you for your comments. > > Thing is named dies if tap0 is not up when it starts and as this is a > public named server it needs to be running after boot. > > Rewriting the provided rc scripts, they are part of the port and > requires work when updated. > > So, the conlusion is, fiddle with the ule/rc.d/ and prepare to fix them > after every update? No other way? There is another way, but it doesn't sound much better: You could use /etc/rc.local to implement the exact order in which you need to start the different services, without using their automatic startup (*_enable="YES" in combination with the /etc/rc.d/ and /usr/local/etc/rc.d/ scripts). Again, note that /etc/rc.local is not the _last_ thing executed at startup - other services might be started later. So if you need such a service to run _before_ something else, start it yourself from /etc/rc.local and prevent any further startup tries (or ignore the "service already running" messages). -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190514220824.a4779bb2.freebsd>