Re: 2 questions...

[Colin Walters <walters verbum org>]

On Mon, 2005-07-25 at 17:55 -0400, David Zeuthen wrote:
> On Mon, 2005-07-25 at 16:54 -0400, Derek Atkins wrote:
> > no offense intended, but I still disagree with that design choice.  It means you
> > cannot use NM in a situation where you have wireless network and network-based
> > login (e.g. Kerberos/Hesiod, NIS, etc).  In the current design you have to
> > already be logged in in order to start the wireless network, which means you
> > have to have a local account.
> > 
> > IMNSHO it would be much better to store this information globally so that NM can
> > choose from pre-defined networks before the user is logged in.  This certainly
> > works fine for WEP or unprotected networks, and even for shared-key WPA
> > networks.  It might not work as well for interactive 802.1x authentication...
> > 
> > Even Windows will setup the network before the login process, assuming the
> > wireless network was configured a priori!  How could Windows get something
> > right and Linux not?
> 
> I've tried to argue for some time that the right solution here is
> clearly to run nm-applet on top of, and managed by, your login manager,
> e.g. gdm. 

I think this kind of jumping to implementation details.  This may be in
large part the approach we want, but I'd like to look at some of the use
cases and interaction choices that fall out from it.

We already fixed the Kerberos thing, so that's a non-use-case.

The other thing that came up in this thread is the server case.  The way
system administrators configure networking right now is
$EDITOR /etc/blah or possibly some tool like system-config-network.
Your nobody/GConf suggestion basically makes it impossible to configure
server wireless networking by hand with $EDITOR.  You will probably get
a lot of unhappy Unix sysadmins, who tend to live and breathe text files
(as we don't have any better common system).  

For the server case, an alternative to nobody/GConf is to have
"nm-static-info", a little binary which parses distro wireless network
config files (and possibly reads /etc/NetworkManager/wireless.conf or
something), and owns the org.freedesktop.NetworkManagerInfo service on
the bus.  It doesn't link to GTK+ or GConf, and there's no user
interaction expected, it just runs early as part of the server bootup. 
This approach lets Unix admins use $EDITOR and also keeps all the
existing distro tools for server wireless network configuration (like
system-config-network, YaST, etc.) working unchanged.

Possibly we could even have the default NetworkManager init script start
this daemon by default; we need to figure out how to kill it (really,
make it not own NetworkManagerInfo) though when the user logs in.  The
current semantics for D-BUS service names are backwards from what we
want here.

> - the UI will have to be a bit different and it will store keys in the
> user 'nobody' gconf-tree, alternatively use keys from the system-wide
> (or site-wide) default/mandatory gconf-trees.

Wait, am I understanding you correctly and you're saying gdm would gain
a notification area and a wireless networking selector?  Or are you just
talking about implementation details?

The goal in my mind here is to solve the server case.

> Btw, we desperately need this kind of infrastructure in GNOME for
> other
> things such as running gnome-volume-manager, gnome-screensaver,
> gnome-power-manager etc. I proposed this [1] to be part of the GNOME
> session services framework that people at Red Hat been working on; it
> makes a lot of sense to me.

I guess what makes me nervous about this is it seems like part of a big
plan to unify how servers and desktops are configured, and while I think
that's valuable in theory, the current design is a pretty nontrivial
change to how many server system administrators are used to working.

I mean...the server admin experience for configuring wireless manually
would be like:

sudo nobody gconftool-2 -t string /system/networking/wireless/networks/Company/essid blah
sudo nobody gconftool-2 -t string /system/networking/wireless/networks/Company/timestamp ??
sudo nobody gconftool-2 -t string /system/networking/wireless/networks/Company/key secret
...

versus just $EDITOR /etc/blah, which is what admins have to do anyways
for all the stuff they truly care about like Samba and Apache.

The primary value in your proposal seems to be that we share a lot more
code between the desktop/server cases.  But for g-v-m and g-p-m, do you
really want to have the same set of knobs available for desktops and
servers?