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

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
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.

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]