-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steve Langasek wrote: > On Fri, Mar 30, 2007 at 04:02:42AM +0300, Eddy Petrișor wrote: >>> Uh, putting your comments on the process *in-line as shell comments* is very >>> difficult to read; you also show three tests but only show the contents of >>> /etc/network/interfaces in two of them, which I find confusing. It would be >>> a lot clearer if you would summarize your findings. > >> Ok, I added comments/summaries above each test (in fact 4 of them). > > Ok, thanks. > > So it happens that I've just done my first real etch install onto a new > laptop. The desktop is great, but network-manager is /awful/ for my > purposes; not because I don't want a desktop applet managing my connection > -- I in fact do want this -- but because it stores all my wep keys under > lock and key, and as a result my wifi connection isn't brought up until I > log into the GUI. This is doubly-broken for me because I want to be able to > use Kerberos for network-based login *at* the GUI... > > None of this is anything that I think should be RC for etch, though I look > forward to trying to help find a solution better-integrated with ifupdown > for lenny. In the meantime, I'll probably install waproamd for my own use. > >> Summaries are separated between some visible markers. > >>> It is certainly the case that /etc/init.d/networking should have no effect >>> on interfaces that are not marked 'auto'. > >> allow-hotplug ones should be managed, too (according to the README.Debian >> examples) > > Uh, I don't understand what you mean by "too". I was talking about what > *ifupdown* does with interfaces that are not marked 'auto', which is: > nothing. The interface is only managed by /etc/init.d/networking if it's > marked 'auto'; if it's marked allow-hotplug and *not* marked auto, it's > managed via the hotplug system exclusively. > >>> fact that it is possible in the NM applet to *override* the status of an >>> interface sounds to me like a feature, not a bug. > >> That would be ok *if* I would still be able to use the init script to stop >> and start networking from the console. Since X might not start, it might >> not allowing me to maneuver networking from the console until I: > >> 1) remove NM from the system, >> 2) start in X and use NM to start it (which leaves the init script broken >> with >> allow-hotplug, and partly broken with auto) >> 3) add a dummy hook to the interface I want to work with and restart dbus, >> to NM >> does not handle the connection anymore >> 4) modify interfaces to use a static IP > >> All of these are suboptimal, IMHO. > > Well, at this point the problem you're describing is not reproducible for > me. > > I've set up my ethernet interface as: > > # The primary network interface > auto eth0 > allow-hotplug eth0 > iface eth0 inet dhcp
The default install, in my case had no "auto eth0" line, only an "allow-hotplug eth0" line. I tested in a either / or kind of way wrt allow-hotplug/auto. So what I'm trying to say is that, by default, you don't have "auto", so you get the asymmetric behaviour. IMO, this violates the principle of least surprise. > I have manually disabled networking with NM. I have then run Strange, you *had*to* disable it? Wasn't it disabled by default? >> -------------------------------------------------- > >> The first situation starts with NM removed, after a reboot, with >> "allow-hotplug" set in interfaces. > >> After "networking stop", "networking start" has no effect. >> So this whole issue looks like is related both to NM and the >> "allow-hotplug" vs. "auto" option. > >> Sorry for not provifing full information here. > >> -------------------------------------------------- > > So what I understand from this description is that 'allow-hotplug eth0' was > set, and 'auto eth0' was /not/ set, so this behavior of > /etc/init.d/networking is expected. Yes, while this is the default I got after installation... About the "expected", as I said before, I have my reservations. >> Script started on Jo 29 mar 2007 19:57:11 +0300 >> debian:/# ifconfig eth0 >> eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 >> inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 [..] >> debian:/# ps ax | grep dhc >> 1740 ? S<s 0:00 dhclient3 -pf /var/run/dhclient.eth0.pid -lf >> /var/lib/dhcp3/dhclient.eth0.leases eth0 >> 8507 pts/2 R+ 0:00 grep dhc >> debian:/# /etc/init.d/networking stop >> Deconfiguring network interfaces...There is already a pid file >> /var/run/dhclient.eth0.pid with pid 1740 >> killed old client process, removed PID file [..] >> debian:/# ps ax | grep dhc >> 8540 pts/2 S+ 0:00 grep dhc >> debian:/# ifconfig eth0 >> eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 >> BROADCAST MULTICAST MTU:1500 Metric:1 >> debian:/# /etc/init.d/networking start >> Configuring network interfaces...done. >> debian:/# ifconfig eth0 >> eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 >> BROADCAST MULTICAST MTU:1500 Metric:1 >> debian:/# /etc/init.d/networking restart >> Reconfiguring network interfaces...done. >> debian:/# ifconfig eth0 >> eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 >> BROADCAST MULTICAST MTU:1500 Metric:1 > This is all consistent with the ifupdown documentation. > /etc/init.d/networking uses "ifup -a" and "ifdown -a"; when "ifdown -a" is > called it affects *all* interfaces, when "ifup -a" is called it affects > *only* those interfaces that are marked 'auto'. Yes, this is asymmetrical, > but it's asymmetrical for a reason. That reason being? >> -------------------------------------------------- >> This test starts without NM installed and with "auto eth0" in interfaces. >> In this case the init script behaves as expected, stop is stop, start is >> start, restart is restart. >> -------------------------------------------------- > > Right, again as expected. Yes, of course, this is the desired behaviour :-) . >> -------------------------------------------------- >> As soon as NM enters the stage, things become weird, even if auto is kept: > >> The interface is down, (init) start has no effect until the interface is >> stopped >> through the init script. > >> (this continues the test above) > >> -------------------------------------------------- > >> debian:/# # I will try to install NM, too >> debian:/# aptitude install network-manager >> [...] >> Reloading system message bus config...done. >> Restarting network connection manager: NetworkManager. >> Restarting network events dispatcher: NetworkManagerDispatcher. > >> debian:/# ifconfig >> eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 [..] >> lo Link encap:Local Loopback >> inet addr:127.0.0.1 Mask:255.0.0.0 [..] >> debian:/# /etc/init.d/networking start >> Configuring network interfaces...done. >> debian:/# ifconfig >> eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 [..] >> lo Link encap:Local Loopback >> inet addr:127.0.0.1 Mask:255.0.0.0 [..] >> debian:/# /etc/init.d/networking stop >> Deconfiguring network interfaces...There is already a pid file >> /var/run/dhclient.eth0.pid with pid 8818 >> killed old client process, removed PID file >> Internet Systems Consortium DHCP Client V3.0.4 [..] >> done. >> debian:/# ifconfig >> lo Link encap:Local Loopback >> inet addr:127.0.0.1 Mask:255.0.0.0 [..] >> debian:/# /etc/init.d/networking start >> Configuring network interfaces...Internet Systems Consortium DHCP Client >> V3.0.4 [..] >> bound to 10.0.2.15 -- renewal in 38286 seconds. >> done. >> debian:/# ifconfig >> eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 >> inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 [..] >> lo Link encap:Local Loopback >> inet addr:127.0.0.1 Mask:255.0.0.0 [..] >> debian:/# exit > >> Script done on Jo 29 mar 2007 20:34:09 +0300 > > Ok, looks perfectly consistent to me -- you install network-manager, it > takes control of the interface; /etc/init.d/networking doesn't bring it up > because network-manager didn't bring the interface *down* using ifupdown, so > ifup believes the interface is already configured (this is the same thing > that happens if you run 'ifconfig eth0 down'); running stop and then start > again resets this. Ok, I wasn't aware of that behaviour. It definetly *looked* weird. >> -------------------------------------------------- >> NM installed, connection was activated the GNOME applet, the interface has >> "allow-hotplug" >> /etc/init.d/networking stop has no effect. >> This configuration would be the one after the default install, *after* the >> user realises that he has to start the interface via the applet. >> -------------------------------------------------- > > Ah, again, in this case the eth1 interface was not brought up by ifupdown, > but by network-manager; so there's no ifupdown state in > /etc/network/run/ifstate telling ifdown that it needs to act on this > interface. I agree that this is surprising; perhaps network-manager could > be fixed to write to /etc/network/run/ifstate for better integration? Yes, this is part of the issue I am talking about. - -- Regards, EddyP ============================================= "Imagination is more important than knowledge" A.Einstein -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGEk40Y8Chqv3NRNoRAp2jAJ9xhMCu5Uy75T+vB37+zpYKtHP/mwCguFbP yQmBUVa0spWNlLLoa4a0jaQ= =NwWI -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
