Network Manager

[Scott James Remnant]

(Note: I'm currently changing ISPs, thus the unusual e-mail address
and lack of signature.  Please also Cc me on replies, as I'm not
subscribed to the list and am just reading via the web-interface.)

I've just uploaded a version of NetworkManager that implements the
network-magic specification (http://wiki.ubuntu.com/NetworkMagic).
This e-mail is to serve as both a rationale for the changes that have
been made and to start a discussion about the ultimate destination of
this package.


First off let's outline the requirements we had:

 (a) it should not introduce any major new dependencies, and
especially not introduce any new open ports.

 (b) where possible it uses our existing tools and daemons, especially
the ISC dhcp3 client (dhclient3) instead of a different tool such as
pump.

 (c) it integrates and interoperates well with our existing "ifupdown"
infrastructure.  That allows configuration of interfaces in the
/etc/network/interfaces file either by hand or through the
gnome-system-tools "Networking" dialog.  Interfaces are brought up at
boot time and when the hardware drivers are loaded automatically if
they are marked "auto" in the file.  This system allows configuration
of both static interfaces and DHCP interfaces.

 (d) scripts can be run when network interfaces are brought up and
down, such as ntpdate; and if possible without having to duplicate the
locations for them.

 (e) be reliable and not cause additional complications.


The changes we made for each of the requirements and rationale are as follows:

 (a) Network Manager depends on the ISC bind9 name service daemon and
reconfigures the machine to use the local name server, adjusting the
name server configuration to forward to the appropriate DNS servers.
This not only introduces a major new dependency, one which listens on
network sockets, but also would prevent users from having a different
DNS server on their system.  We've already undertaken a lot of work to
remove any MTA from our system, so introducing something as major as a
DNS server seemed like a backward step.

     Instead we've applied a patch to the libc which causes
/etc/resolv.conf to be reloaded whenever it changes under a running
application.  This takes care of the issue of DNS information changing
during the lifetype of such applications.

    As we've already ensured that /etc/resolv.conf is modified and
replaced correctly by dhclient, there was no need for Network Manager
to try and maintain it itself; a source of several open bugs.  We've
therefore also removed the "named-manager" from n-m entirely.

     Unfortunately the "vpn-manager" had heavy dependencies on the
named-manager, so this had to be removed as well.  VPN support wasn't
a use case we've considered for dapper, where we're concentrating only
on improving existing functionality and not necessarily introducing
new functionality.  Also the VPN support in Network Manager was
largely hidden, and has been vastly changed upstream in CVS anyway.
It's inclusion can be reconsidered for dapper+1.

 (b) this was easy to accomplish, the dhcdbd daemon has been made to
control dhclient and use the same PID and leases files that we use
already.  This daemon responds to the same dbus messages Network
Manager sends.

 (c) The problems here are that ifupdown and Network Manager have
fundamentally different use cases.  ifupdown's goal is to keep all
interfaces up all of the time, where Network Manager's is just to keep
one up at a time.  Typical behaviour with both fighting ends up
something like:

        - udev starts: configures eth0 and starts dhclient3 to manage it
        - dbus (and n-m) starts: deconfigures eth0, leaves dhclient3
running (or kills it)
        - user logs in
        - nm-applet starts: configures eth0 again, and starts dhclient3 again

     This may initially seem merely irritating, but there's a lot of
additional configuration option with the /etc/network/interfaces file
-- such as wireless channels and mode that Network Manager would then
fail to take into account.

     We therefore decided that it would be best if Network Manager
ignored interfaces completely if they were "manually configured" in
/etc/network/interfaces.  This means you need to remove the
configuration for them before you can use NM with them.  While this
has an initial configuration difficulty, the general experience once
configured is nicer.

     This also removes some of the problems with static interface
configuration; as currently Network Manager has no UI for configuring
network interfaces, whether dynamic, static, or otherwise.

     Currently however this patch has resulted in Network Manager
simply not knowing about such interfaces, and it'll claim that no
interfaces are configured when it should at least show the status of
the configured interface and not allow changing of them.  I intend to
improve this if possible before release.

 (d) Network Manager includes a "Dispatcher" dbus service that listens
to messages from the daemon proper and runs scripts in
/etc/NetworkManager/dispatcher.d for those events.  We've modified
this to include additional events (before an interface comes up, and
after it has been taken down), and also changed it such that it
instead causes the scripts in /etc/network/if-*.d to be run instead.

     Thus it interacts reasonably well with the existing scripts there.

 (e) is probably the largest problem.  With the most modern wireless
cards and drivers (which is currently the largest reason for using
it), Network Manager generally works well.

     However with less main-stream drivers, including Atheros cards
(which are a fairly popular 802.11g card) and most USB adapters, our
testing has indicated a wide range of problems.  Some simply fail to
be detected, some fail to scan, some fail to connect, etc.

     Network Manager also seems to behave very poorly if there are
multiple wireless interfaces, and seems to often try to configure the
wrong one.


So that's the requirements, changes and rationale.  Now we can decide
what we want to do with it.  The options are simple:

 (1) leave it in universe for dapper
 (2) move it to main, but only on the archive so people can install it
if they want it and get security support
 (3) move it to main and the ship seed, so that it's available on the
CD for people who want it
 (4) move it to main and install by default in the desktop seed

There's also the option for the LiveCD of having it installed by default there.

My current feeling is that with the above modifications it can be
installed by default, as it needs manual work to activate, but only if
we provide some easy way to make that happen with a clear notice that
it might not work.

I'd probably rather it were in the ship seed, so those who know about
it can install it, and those who don't won't experience any
regressions.  We should probably install by default on the LiveCD.