On Tue, 2007-08-14 at 01:19 +0200, Michael Biebl wrote: > Hi everyone, > > I just tested the latest svn versions of NetworkManager (r2674) and > nm-applet (r113) and it's the first time, that it actually worked for > me! In earlier tests, NM mostly segfaulted right away. > Even my proposed move of nm-vpn-properties to nm-applet was committed, > which is great imho. > So here come my questions/comments: > > 1.) nm-vpn-properties: > Because of the move of nm-vpn-properties, the POTFILES.* have to be > updated to keep "make distcheck" happy. Patches are trivial and > attached. Please apply.
Thanks, committed in r2676 (NM) and r115 (applet). > 2.) dep on dhclient with extended options: > dhcdbd is dead, NM now controls dhclient directly, where it passes the > -x flag to dhclient. This is a Fedora specific patch to support that > that option. > My question now is, if NM can also work with a vanilla dhcp3-client or > if this patch is mandatory. How do other distros than Fedora handle > this, do they all have this patch against dhcp3? I'm somewhat fuzzy on the details, and the patch doesn't spell out exactly what env vars are added to the environment. But at a minimum, NM needs to know the DHCP client state, the DHCP client PID (not the PID of the script, but of the actual client), the dhcp client options, and the interface for which the event occurred. If the normal dhcp3-client can provide those, great, we can drop the req on -x. But I'm not sure it actually does. Currently, anyone who uses NM patches dhcp and adds the hunk to /sbin/dhclient-script (or whatever the script is that their distro uses). Upstream has kindly renounced use of the "-x" option which they recently tried to use. Also, if anyone wants to add compile-time (or CLI switch) support for other DHCP clients I'm quite open to that. The same format should more or less work for other clients as long as they can deliver the information in the same manner, as a D-Bus signal containing a dict of String->Variant/Byte Array elements, containing the options. If other clients don't use the same state values, I'm open to changing those to something more generally applicable. > 3.) binaries in /etc/NetworkManager/callouts/ > NM installs a binary /etc/NetworkManager/callouts/nm-dhcp-client.action. > According to the FHS [1], this is not allowed. nm-dhcp-client.action > should either be a shell script as wrapper around the real > nm-dhcp-client or the callout directory should be moved to another > directory (under /usr/lib e.g.). Sure, should move that then. We'll have more callouts later on, the immediate one coming to mind is avahi-autoipd which finally has a --script option in 0.6.20. Shouldn't this be /usr/libexec though? I thought that's where that sort of thing went. Do you think /usr/libexec/nm-dhcp-client.action would be OK? > 4.) A bug I encountered: > Everytime I restart NetworkManager, the vpn menu entries in nm-applet > are added again and listed multiple times. I just pushed a fix for that in r2675. I need to fix the applet icon state not updating correctly, and the entries need to be sorted alphabetically, but they aren't duplicated any more. > Other than that, the new NM seems to work fine so far. I'm eager to test > the new system wide configuration management and the fixed IP address > support. Rodrigo landed the major bits of interface code and object model, and should now be working on hooking up the new config bits internally in NM so that the new config stuff can actually get used. It may be a bit rocky ahead for wireless for a bit while that settles down. Dan > Cheers, > Michael > > [1] > http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCHOSTSPECIFICSYSTEMCONFIGURATION > _______________________________________________ > NetworkManager-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/networkmanager-list _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
