Re: Some comments/questions about 0.7 [was: status of 0.7]

[Dan Williams <dcbw redhat com>]

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