Re: 2 questions...



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. 
> 
> - 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.
> 
> - when someone logs in the nm-applet managed by gdm goes away and is
> replaced with the nm-applet in the user session (this, similar schemes
> for e.g. fast-user-switching).

As we've talked about before, something like this would be completely
acceptable.

Dan




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]