On Tue, 2007-08-14 at 09:13 +0200, Michael Biebl wrote: > Dan Williams schrieb: > > On Tue, 2007-08-14 at 01:19 +0200, Michael Biebl wrote: > > > >> 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. > > > Thanks for the info. > > In Debian we used to patch dhcdbd (include/dhcdbd.h) and set > #define DHCLIENT_EXTENDED_OPTION_ENVIRONMENT 0 > and it seemed to work fine so far. > > I'll investigate if the same can be done for NM 0.7 . Otherwise i'll try > to convince the dhcp3 maintainer in Debian to include > dhcp-3.0.5-extended-new-option-info.patch from the fedora package. > > > > > >> 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? > > Yep, $libexecdir would be fine for that case.
Fixed in r2682 Dan > > >> 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. > > > > Cool, looking forward to it. > > Cheers, > Michael _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
