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

[Dan Williams <dcbw redhat com>]

On Tue, 2007-08-14 at 01:19 +0200, Michael Biebl wrote:
> Hi everyone,
> 
> I just tested the latest svn versions of NetworkManager (r2674) and
> nm-applet (r113) and it's the first time, that it actually worked for
> me! In earlier tests, NM mostly segfaulted right away.
> Even my proposed move of nm-vpn-properties to nm-applet was committed,
> which is great imho.
> So here come my questions/comments:
> 
> 1.) nm-vpn-properties:
> Because of the move of nm-vpn-properties, the POTFILES.* have to be
> updated to keep "make distcheck" happy. Patches are trivial and
> attached. Please apply.

Thanks, committed in r2676 (NM) and r115 (applet).

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

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

> 4.) A bug I encountered:
> Everytime I restart NetworkManager, the vpn menu entries in nm-applet
> are added again and listed multiple times.

I just pushed a fix for that in r2675.  I need to fix the applet icon
state not updating correctly, and the entries need to be sorted
alphabetically, but they aren't duplicated any more.

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

Dan

> Cheers,
> Michael
> 
> [1]
> http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCHOSTSPECIFICSYSTEMCONFIGURATION
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list