Re: CVS (STABLE_0_3) works for Madwifi/Atheros, but starts too late

[Dan Williams <dcbw redhat com>]

On Thu, 12 May 2005, Derek Atkins wrote:
> Quoting Bill Moss <bmoss CLEMSON EDU>:
> > Starting dbus, hal, and NM early will work in the wired case because a
> > connection is established before nm-applet is run so ntpd will find a
> > connection when it runs later, but this won't work for wireless because
> > a connection will not be made until nm-applet runs after all the init
> > scripts have run. Am I missing something?
> 
> I guess that was my question.  Does NM need the applet in order to select the
> wireless network (and WEP key)?  Or will NM have access to the list of
> preferred networks (and WEP keys) before I login?  I would certainly prefer if
> the list were "global" instead of per-user.

No, the wireless networks are per-user and until you log in to start GConf, they 
are not available to NetworkManager.

> > If ntpd doesn't find a connection when it is run, it becomes brain dead
> > and will not work until restarted. Depending on the order of init
> > scripts is problematic. Network dependent services need some way to be
> > told that a link is available or some way to be started or restarted
> > when a link becomes available.
> 
> Yep, this is indeed my problem.  Currently (well, before I got NM working at
> all) I was logging in as root, setting up my network, re-starting my services
> (like ntpd) that failed during bootup, then logging out and logging in as me.
> I would prefer if NM could do all this during the boot sequence, even with
> wireless.

You might want to investigate using NetworkManagerDispatcher.  You can drop a 
script into /etc/NetworkManager.d that will be executed by 
NetworkManagerDispatcher when connections go up or down.  Then you can kick ntpd 
manually.

> > I am running Head 1.361 under FC4 Test 3 on a T42. All seems very stable
> > including vpnc support.
> 
> I haven't tried vpnc support.  However I do have a problem with vpnc and ncsd
> and selinux:
> 
> audit(1115923917.382:0): avc:  denied  { read write } for  pid=3378
> exe=/usr/sbin/nscd path=socket:[687155] dev=sockfs ino=687155
> scontext=root:system_r:nscd_t tcontext=root:system_r:unconfined_t
> tclass=udp_socket
> audit(1115923917.382:0): avc:  denied  { read write } for  pid=3378
> exe=/usr/sbin/nscd path=/dev/net/tun dev=tmpfs ino=2009
> scontext=root:system_r:nscd_t tcontext=system_u:object_r:tun_tap_device_t
> tclass=chr_file

I've noticed a few of these too, I've spoken with Dan Walsh (an SELinux guy at 
Red Hat) and he's aware that we need more finely tuned policy for 
NetworkManager.

Dan