Re: How to get NetworkManager connect to known WIFI networks upon BOOT

[Dan Williams <dcbw redhat com>]

On Thu, 2007-11-29 at 15:23 -0500, Tony Espy wrote:
> Dan Williams wrote:
> > On Wed, 2007-11-28 at 23:42 -0600, Igor Chudov wrote:
> >> My Ubuntu 7.10 computer boots up and gets its IP address just fine
> >> when it is on a wired network (via DHCP). 
> >>
> >> It can also connect to wireless networks, however, it requires me to
> >> be logged on to gnome and enter my password. 
> >>
> >> I want to skip all of that and make NetworkManager connect to several
> >> known wifi networks automatically upon boot, even if no one logs on to
> >> this laptop. 
> >>
> >> In Fedora, I wrote a custom  script calling wpa_supplicant with a .conf
> >> file, but I want to integrate NetworkManager better as I like its
> >> reconnection abilities. 
> >>
> >> So. How can I make NM connect to password protected wifi networks upon
> >> boot, without users logging in?
> >>
> >> How can I do it?
> > 
> > It isn't possible with NM 0.6.x.  I've already committed code to trunk
> > (0.7) for the system settings service, which will provide NM connection
> > information before logins, therefore providing this functionality.  I'm
> > currently implementing the 'ifcfg' backend that will work with Fedora
> > and SUSE distros, and I'm going to implement a more flexible format
> > based on key/value pairs (essentially .ini files, really) and maps much
> > better to the NM connection/setting structure.  Somebody from the
> > Debian/Ubuntu community will need to step up and write the plugin for
> > their distro.
> 
> Dan --
> 
> I recently started working at Canonical, working on Ubuntu Mobile.
> We've been having conversations recently re: the NM 0.7 planned system
> settings service and it's applicability to mobile devices.
> 
> A couple of questions for you...
> 
> 1. Does the global settings service use the keyring-daemon to store
> global key / passphrases?

The general answer is "no", for two reasons:

1) the system settings service is designed _not_ to use any UI, and
therefore won't rely any other services to be started.  This means that
all your keys need to be available without user interaction, since it's
a system connection.  This is already the case with most static system
network configuration; the key must be stored somewhere that it can be
accessed without prompting the user.

2) The system settings service uses plugins.  The point of doing this is
so that you can implement whatever backing store for the configuration
and the keys that you want.

The system settings service is _not_ designed to replace the user
settings service.  The user settings service (ie the applets) are
expected to be the main configuration point.  There needs to be really
nice tie-in between the UI applets and the system settings service
though, so that the user can "publish" a connection to the system and
make it available for everyone, and the for the system to use before
login.  The main purpose of the system settings service is to replace
the static configuration that's often used today on servers, in an
attempt to expand the cases in which NM can be used, and providing the
ability to bring connections up before login.

> I'm working on a problem right now with a MID device that doesn't
> require the user to login, therefore there's no keyring setup.  We also
> would like to avoid requiring the user to enter a keyring pw. Someone
> earlier today pointed me at the following gnome-keyring bug:
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=386866
> 
> I'm going to try and implement this as a short-term solution.
> 
> I guess what I'm wondering is whether or not the global settings
> service, if fully implemented on Ubuntu, would alleviate the need to
> create a pw-less keyring as mentioned in this bug.

Yes.

> 2. Could you explain how the 'ifcfg' backend will work?

You probably won't be able to use it for /etc/interfaces at all, since
the ifcfg backend is designed to parse the ifcfg-* files that Fedora and
SUSE use.  You'll need to implement an ubuntu/debian backend that parses
and monitors the /etc/interfaces file instead.  The problem with many of
these current configuration methods is that they don't really work well
with a lot of the device types we're going to add support for; either
distros need to expand those systems, or use some other method.  When we
switch over to NM by default in Fedora 9, I'd like to use the key/value
configuration plugin in addition to the ifcfg plugin, to provide support
for the legacy ifcfg files during a transition period.

Dan