Re: The logic behind user/system settings

[Dan Williams <dcbw redhat com>]

On Tue, 2010-03-09 at 21:10 +0200, Ozan Çağlayan wrote:
> Hi,
> 
> I'm from the core developer team of a linux distribution called Pardus Linux[0].
> 
> Years ago, when there wasn't even Network-Manager, we developed a network management backend in C/Python that we're still using
> in our distribution but due to lack of time/interest it's getting older and older which risks to not fulfill the current
> desktop user's needs.
> 
> So we're seriously thinking about migrating to Network-Manager as soon as the KDE4 manager/plasmoid gets ready as Pardus comes
> with KDE by default.
> 
> I'm currently experimenting with NM 0.8 and nm-applet. Here are some questions:
> 
> * There's this "Auto ifaceX" default/unremovable connection which is Up'ped by default when NM is launched. Okay, it's
> good to have a default profile which will always try hard to bring the machine online. But as far as I understand, the connections
> that I'm adding from nm-applet are considered as some sort of user-settings so if that specific user which added that connection
> profile never loggs in, should I forcely stick with that automatic dhcp profile? Isn't there something like system-wide connections
> which will take effect when NM is spawned? How can the root user setup a manual connection on his server system which doesn't even have a
> desktop session?

As you've discovered, there are user-specific settings (which are only
available when that user is logged in) and system-wide settings (which
are available to all users *and* before any user has logged in).  The
problem you're hitting is when there aren't any settings at all, like
right after an install.

So NetworkManager creates an internal "Auto XXXX" connection that at
least allows your system to get online if there are any DHCP-configured
ethernet devices on the system.  This is a "system-wide" connection and
should be available at boot and before login.

NM does not switch away from "Auto ifaceX" when you log in, because we
assume that interrupting connectivity is a very bad thing to do.

By default, the connections you add by clicking on APs or such from the
applet menu are user connections.  There is some debate about making
them system connections by default, which is probably the right thing to
do since it's less confusing (except for VPNs perhaps, which tend to be
specific to a user).

What you may not have configured on your install is a system-settings
plugin.  See below.

> * Why does nm-applet's tray icon's left-click menu provides a sub-menu to VPN connections? It's weird. That context menu seems to have
> dynamic content e.g. when I add a connection for eth0, it appears alltogether with Auto eth0; if there are no 802.11 devices, there
> are no content related to 802.11 connections but that "VPN connections" is always there which I think is not at all human-interface
> centric and ergonomic.

There's an open bug to not show the VPN submenu when no VPN plugins are
installed, and there's another open bug to move the VPN connections into
the main menu instead of a submenu.  Simply a lack of time and more
important bugs to handle, but these two should certainly be fixed.  If
you've got a bit of time to look at either of these two I'd happily take
patches for them.

> * What are the plugins (ifcfg-rh for redhat/fedora for example) for?

They translate the distribution's native config file format (ifcfg files
for RH, /e/n/i for Debian/Ubuntu, etc) into system-wide configuration
that NetworkManager can use.  They also provide the distro's configured
persistent hostname (/etc/hostname for Debian, /etc/sysconfig/network
for RH) to NetworkManager.

If your distribution does not have a system settings plugin, you can use
the 'keyfile' plugin which reads/writes connections in a .ini-style
format in /etc/NetworkManager/system-connections.

So in a perfect world, it doesn't matter that much to the user whether
the connection is system or user; they can use nm-connection-editor to
move it between system and user scopes as they need to.  If you want a
connection before login that's available all the time, it should be a
system connection and you can make it so in the connection editor.

The problem with that is that often writing to privileged locations
requires some permissions, so NetworkManager will ensure that the caller
is authenticated via PolicyKit before they can change a connection to be
"system-wide".  That's configurable too, so as a distro maintainer you
could turn that authentication off via the file in the policy/ directory
in the source.

Dan