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

["Kay Sievers" <kay sievers vrfy org>]

On 8/14/07, Michael Biebl <biebl debian org> 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.

Nope, it should be /usr/lib/NetworkManager/. Libexec is mainly a Red
Hat construct that disagrees with LSB:
"Applications may use a single subdirectory under /usr/lib. If an
application uses a subdirectory, all architecture-dependent data
exclusively used by the application must be placed within that
subdirectory."

So no new stuff should use any libexec thing. It's ok though, as long
as the libexec dir is configurable, but it will be a pain for addons
to find out the right place to install stuff.

Thanks,
Kay