How to bring up ypbind with NM in F9?

[Dan Williams]

On Tue, 2008-04-01 at 10:10 -0600, Orion Poplawski wrote:
> Dan Williams wrote:
> > On Mon, 2008-03-31 at 14:46 -0600, Orion Poplawski wrote:
> >> So, how are we supposed to start ypbind on F9 with NetworkManager?  The 
> >> ypbind init script currently runs before NM startup and so fails to run.
> > 
> > We start HAL at 23, and NM at 24, since I think dbus is at 22.  Whatever
> > the order is, we need to start dbus -> hal -> NM in that order, whenever
> > it's appropriate.
> > 
> > I'll rebuild HAL & NM packages with the right ordering, but what should
> > that ordering be?  Is 23 & 24 sufficient for the cases that people need?
> > What might require network that starts after 'network' (10 IIRC) and
> > when NM would start in this schemed (24)?
> 
> I'm seeing NM start at 99:
> 
> # chkconfig --del NetworkManager
> # chkconfig --add NetworkManager
> # ls -l /etc/rc3.d/S*NetworkManager
> lrwxrwxrwx 1 root root 24 2008-04-01 10:07 /etc/rc3.d/S99NetworkManager 
> -> ../init.d/NetworkManager
> 
> # grep chkconfig S99NetworkManager
> # chkconfig: - 98 02

Yep, the LSB headers force NM to start after HAL, which puts it at 99
since HAL is at 98.

> Another issue I've run into is that NM starts up in the background 
> (right?) so the network may not be available after the init script returns.

Right; services that require network need to block waiting for the
network to come up.  They should really block waiting for the network
_they_ want to come up, instead of just "give me any network, even one I
may not be configured for".  For example, if your Apache install binds
specifically to 5.4.3.2:80, you want your http service to only start if
a device has the 5.4.3.2 address, not just blindly start because NM says
there's a random connection somewhere.

There are some tools that I can have the NM package install, for example
'nm-online', which blocks until NM enters NM_STATE_CONNECTED or times
out after a specified period of time.  You could put that into your
service's startup script and emulate the current blocking behavior of
the network.

I certainly don't want to have the NM startup script block, because
that's just wrong and doesn't reflect where the real problem lies, which
is in startup scripts that are just too dumb for 2008.

Dan