Re: Network Manager does not find system wide connections

[Dan Williams <dcbw redhat com>]

On Sat, 2009-08-01 at 00:58 +0100, Timothy Murphy wrote:
> Brian Morrison wrote:
> 
> >> I do not believe that it was a good idea to use nm as a standard
> >> software tool in ubuntu.
> > 
> > Works perfectly fine in Fedora....
> 
> You should say, "It works fine for ME in Fedora".
> It is obvious from the Fedora newsgroups that many people
> have serious problems with NM.
> 
> I don't, personally, but I find the complete lack of documentation
> a major drawback with NM.
> The whole point of Linux is that it is not magic;
> you are meant to be able to work out what is going on.

It's pretty simple.  NM takes connection configuration from a few
sources, and applies that to network interfaces based on certain
criteria.  Those criteria are: (a) whether the connection is available,
ie whether the wifi network can be seen or whether there is an ethernet
carrier, or (b) when the user tells NM to do so.

That's it.  Seriously.

Where it gets complex is because people expect it to interact seamlessly
with their normal distribution's config files and mechanisms, and for
finer-grained security so you don't need to be root to do everything.

a) distro config files: we've added interpretation of you distros config
files to NM.  In many cases, those config files operated like bash
scripts with variable subsitution and backtick commands, etc.  So the
mapping isn't always exact, and that's sometimes confusing.  However,
for many people, it's a lot less confusing than learning a completely
new configuration system, and building up new tools to work with that
config system.

For example, /etc/resolv.conf is *not* static, because lots of things
need to update it (vpns, ppp, dhcp, etc).  In Fedora, people were
confused when /etc/resolv.conf was rewritten periodically by NM to
accomodate VPNs or mobile broadband, etc.  Because in reality
resolv.conf cannot be static (yet some people expected that because it
had always worked that way before), they were surprised when this
happened.  Instead, placing the DNS information into the connection
configuration itself, instead of out-of-band in resolv.conf, fixes this
issue.

b) DNS indirection: Debian uses resolvconf to mediate /etc/resolv.conf,
which duplicates a large part of what NM does.  Various bugs and other
issues with resolvconf have led to some frustration when user's blame
NetworkManager for blowing away their /etc/resolv.conf (and of course
don't understand how things work because the interactions are complex).
In it's most simple use-case, NM completely manages /etc/resolv.conf and
we don't have these problems.

c) permissions: much of the time, you don't want to have to become root
just to connect to a different network.  However, most of the older
tools required SUID or sudo or some other privilege escalation
mechanism.  Additionally, making that complete mechanism (executed by
the user) SUID made security vulnerability windows larger.  By using
PolicyKit, we can grant users only the permissions they need, *or* grant
them all permissions if they so desire.  Thus, users can control
networking with only the permissions they need, instead of having to
grant the user access to an entire unix group (debian-style) or using
SUID binaries (console-helper, Fedora style).

These are some of the ways that NM is unfortunately more complex than
previous script-based networking systems.  A combination of user-driven
requirements and security-based goals.

Dan