rcorder - wait for tap0

[Polytropon]

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, ...