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. >> 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 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature