Network Manager

[javier]

El Viernes, 17 de Febrero de 2006 20:33, Scott James Remnant escribió:
> (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.

Hi

Can this package be used my the knetwork-manager interface jriddell created in 
last distro sprint? i.e. Does this package include the cvs features riddell 
needed to make it work with it's kde frontend? It would be totally awesome if 
this feature worked out of the box for both ubuntu & kubuntu users.

Thanxs
javier