Fedora Core 4 Test Update: NetworkManager-0.5.1-1.FC4.1

[Christopher Aillon]

---------------------------------------------------------------------
Fedora Test Update Notification
FEDORA-2005-1004
2005-10-20
---------------------------------------------------------------------

Product     : Fedora Core 4
Name        : NetworkManager
Version     : 0.5.1                      
Release     : 1.FC4.1                  
Summary     : Network link manager and user applications
Description :
NetworkManager attempts to keep an active network connection available at all
times.  It is intended only for the desktop use-case, and is not intended for
usage on servers.   The point of NetworkManager is to make networking
configuration and setup as painless and automatic as possible.  If using DHCP,
NetworkManager is _intended_ to replace default routes, obtain IP addresses
from a DHCP server, and change nameservers whenever it sees fit.

---------------------------------------------------------------------

* Wed Oct 19 2005 Christopher Aillon <caillon(a)redhat.com&gt; - 0.5.1-1.FC4.1
- Update to NetworkManager 0.5.1

* Wed Oct 19 2005 Christopher Aillon <caillon(a)redhat.com&gt; - 0.5.0-1.FC4.2
- Requires dhcdbd

* Tue Oct 18 2005 Christopher Aillon <caillon(a)redhat.com&gt; - 0.5.0-1.FC4.1
- Update to NetworkManager 0.5.0


---------------------------------------------------------------------
This update can be downloaded from:
  http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/4/

db894029702d5d215183f68f084e6e54  SRPMS/NetworkManager-0.5.1-1.FC4.1.src.rpm
1f7eb735362b3c4c45fe059f8c8068c9  ppc/NetworkManager-0.5.1-1.FC4.1.ppc.rpm
dcbccbf14baebb1502d1d88347c84a03  ppc/NetworkManager-gnome-0.5.1-1.FC4.1.ppc.rpm
f4a21112da9dc690f4c3352c23925120  ppc/NetworkManager-devel-0.5.1-1.FC4.1.ppc.rpm
753bcdfc80d5bdb9fce3ae0b03e4768c  ppc/NetworkManager-glib-0.5.1-1.FC4.1.ppc.rpm
7f7365e9337ad4ec593166c648a34f3c 
ppc/debug/NetworkManager-debuginfo-0.5.1-1.FC4.1.ppc.rpm
c2de140db1531e06bf1a54ea4e22e906  x86_64/NetworkManager-0.5.1-1.FC4.1.x86_64.rpm
56bec14e5a6254a403cdafffb8ccd117  x86_64/NetworkManager-gnome-0.5.1-1.FC4.1.x86_64.rpm
3a3f0c6873b3922da4bff81c6760657f  x86_64/NetworkManager-devel-0.5.1-1.FC4.1.x86_64.rpm
70edd19eb76e7d39ba6ff409486744c5  x86_64/NetworkManager-glib-0.5.1-1.FC4.1.x86_64.rpm
68d72f460849d17b209b3049e2dc3f25 
x86_64/debug/NetworkManager-debuginfo-0.5.1-1.FC4.1.x86_64.rpm
42af9a34dac320f199e8977df1d89bbe  i386/NetworkManager-0.5.1-1.FC4.1.i386.rpm
918e63cac84d79fe4b8ad2981c29110a  i386/NetworkManager-gnome-0.5.1-1.FC4.1.i386.rpm
e7efac816a1ec83cf703ff89404fb377  i386/NetworkManager-devel-0.5.1-1.FC4.1.i386.rpm
c39d7b016047d50a96f9f489365cacf5  i386/NetworkManager-glib-0.5.1-1.FC4.1.i386.rpm
1193e9a00a79555fa7e0897a08e40027 
i386/debug/NetworkManager-debuginfo-0.5.1-1.FC4.1.i386.rpm

This update can also be installed with the Update Agent; you can
launch the Update Agent with the 'up2date' command.  You may 
need to edit your up2date channels configuration.  Within 
/etc/sysconfig/rhn/sources enable the following line: 
yum updates-testing
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/4...
---------------------------------------------------------------------

[David Woodhouse]

On Thu, 2005-10-20 at 09:48 -0400, Christopher Aillon wrote:
>  Product     : Fedora Core 4
>  Name        : NetworkManager
>  Version     : 0.5.1                      
>  Release     : 1.FC4.1                   
Doesn't seem to work here. It asks for the encryption key, sets the key
correctly and the link is working. IPv6 autonegotiation works and
connectivity is working -- I can see traffic on the network with
tcpdump. But there's no DHCP request, so no Legacy IP address, and very
soon it asks me for another encryption key.

NetworkManager: <information>   Activation (eth1) New wireless user key for network
'Baythorne Wavelan' received.
NetworkManager: <information>   Activation (eth1) Stage 1 (Device Prepare)
scheduled...
NetworkManager: <information>   Activation (eth1) Stage 1 (Device Prepare)
started...
NetworkManager: <information>   Activation (eth1) Stage 2 (Device Configure)
scheduled...
NetworkManager: <information>   Activation (eth1) Stage 1 (Device Prepare)
complete.
NetworkManager: <information>   Activation (eth1) Stage 2 (Device Configure)
starting...
NetworkManager: <information>   Activation (eth1/wireless) Stage 2 (Device
Configure) will connect to access point 'Baythorne Wavelan'.
NetworkManager: <information>   Activation (eth1/wireless): access point
'Baythorne Wavelan' is encrypted, and a key exists.  No new key needed.
NetworkManager: <information>   Activation (eth1/wireless): using essid
'Baythorne Wavelan', with Open System authentication.
NetworkManager: <debug info>    [1129889326.890942]  (): Activation (eth1/wireless):
no hardware link to 'Baythorne Wavelan' in Open System mode, trying Shared Key.
NetworkManager: <information>   Activation (eth1/wireless): using essid
'Baythorne Wavelan', with Shared Key authentication.
NetworkManager: <debug info>    [1129889337.502387]  (): Activation (eth1/wireless):
no hardware link to 'Baythorne Wavelan' in Shared Key mode, need correct key?
NetworkManager: <information>   Activation (eth1) New wireless user key requested
for network 'Baythorne Wavelan'.
NetworkManager: <information>   Activation (eth1) Stage 2 (Device Configure)
complete.
NetworkManager: <information>   Activation (eth1) New wireless user key for network
'Baythorne Wavelan' received.

Dhcdbd is installed and running, but doesn't seem to be doing much --
it's just sitting in a select() loop.

While it's claiming that the network is broken and asking me for another
key, I can continue to use IPv6 just fine, and I can even use IPv4 if I
give it an address manually.

On the plus side, this does seem to fix the problem I had with 'ifup
bnep0' not working because dhclient complained that something else was
already listening on the dhcp client socket :)

-- 
dwmw2

[David Woodhouse]

On Fri, 2005-10-21 at 11:27 +0100, David Woodhouse wrote:
>  Doesn't seem to work here. It asks for the encryption key, sets
> the key
>  correctly and the link is working. IPv6 autonegotiation works and
>  connectivity is working -- I can see traffic on the network with
>  tcpdump. But there's no DHCP request, so no Legacy IP address, and very
>  soon it asks me for another encryption key. 
Upon rebuilding it to debug, I found that it refused to build unless I
had a newer wireless-tools package installed. That newer wireless-tools
seems to have been sufficient to make it work -- you should probably add
it to the RPM requirements.

However, it's still not particularly user-friendly. I was asked again
for the WEP key and accidentally entered it as a passphrase instead of a
hex key. Then I couldn't work out how to _change_ the WEP key. It was
unable to connect, of course, but it didn't ask me for the key again.

Eventually I was able to enter a new key by killing
'gnome-keyring-daemon'. Not the most user-friendly experience.

Unfortunately I'm also required to enter my password for
gnome-keyring-daemon each time I boot the laptop, before the wireless
network will connect. I'm sure it used to connect as soon as the machine
booted, but now it's waiting for me -- that's a fairly significant
regression, since I'm used to just powering the laptop up and walking
away from it, then logging in over the network.

-- 
dwmw2

[Christopher Aillon]

On 10/21/2005 08:18 AM, David Woodhouse wrote:
>  On Fri, 2005-10-21 at 11:27 +0100, David Woodhouse wrote:
>    
> > Doesn't seem to work here. It asks for the encryption key, sets the key
> > correctly and the link is working. IPv6 autonegotiation works and
> > connectivity is working -- I can see traffic on the network with
> > tcpdump. But there's no DHCP request, so no Legacy IP address, and very
> > soon it asks me for another encryption key.
> >     
>
>  Upon rebuilding it to debug, I found that it refused to build unless I
>  had a newer wireless-tools package installed. That newer wireless-tools
>  seems to have been sufficient to make it work -- you should probably add
>  it to the RPM requirements.
>    
>  cd builds/rpms/NetworkManager/FC-4
>  grep wireless-tools NetworkManager.spec 
NetworkManager.spec:20:Requires:
wireless-tools >= 28-0.pre9
NetworkManager.spec:31:BuildRequires: wireless-tools >= 28-0.pre9
>  
I'm not sure how that is failing for your version.  That is there in the 
spec file... Suggestions as to how to fix are appreciated.

>  However, it's still not particularly user-friendly. I was asked
> again
>  for the WEP key and accidentally entered it as a passphrase instead of a
>  hex key. Then I couldn't work out how to _change_ the WEP key. It was
>  unable to connect, of course, but it didn't ask me for the key again.
>
>  Eventually I was able to enter a new key by killing
>  'gnome-keyring-daemon'. Not the most user-friendly experience.
>
>  Unfortunately I'm also required to enter my password for
>  gnome-keyring-daemon each time I boot the laptop, before the wireless
>  network will connect. I'm sure it used to connect as soon as the machine
>  booted, but now it's waiting for me -- that's a fairly significant
>  regression, since I'm used to just powering the laptop up and walking
>  away from it, then logging in over the network.
>
>     
Before, we used to store the WEP keys in plain text on the disk.  Now we 
use gnome-keyring-manager which encrypts the passwords, and in theory is 
a better experience.  Having to enter your keyring password is a 
"regression" in that sense, I suppose.  There's a bug filed in gnome CVS 
I believe to get the keyring to not require login if the user has "log 
me in to GNOME automatically" enabled.

[David Woodhouse]

On Fri, 2005-10-21 at 09:19 -0400, Christopher Aillon wrote:
>   > cd builds/rpms/NetworkManager/FC-4
>   > grep wireless-tools NetworkManager.spec
>  NetworkManager.spec:20:Requires: wireless-tools >= 28-0.pre9
>  NetworkManager.spec:31:BuildRequires: wireless-tools >= 28-0.pre9
>   >
>  
>  I'm not sure how that is failing for your version.  That is there in the 
>  spec file... Suggestions as to how to fix are appreciated. 
Hm, strange. Yet I can reproduce it on another clean FC4 box...

baythorne /home/dwmw2 # rpm -q wireless-tools
wireless-tools-28-0.pre4.3
baythorne /home/dwmw2 # yum --enablerepo=updates-testing install NetworkManager
Setting up Install Process
Setting up repositories
livna                     100% |=========================|  951 B    00:00
base-local                100% |=========================|  951 B    00:00
updates-testing           100% |=========================|  951 B    00:00
extras                    100% |=========================| 1.1 kB    00:00
updates-released          100% |=========================|  951 B    00:00
emacs-cvs-testing         100% |=========================|  951 B    00:00
base                      100% |=========================|  951 B    00:00
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for NetworkManager to pack into transaction set.
NetworkManager-0.5.1-1.FC 100% |=========================|  18 kB    00:00
---> Package NetworkManager.i386 0:0.5.1-1.FC4.1 set to be updated
--> Running transaction check
--> Processing Dependency: dhcdbd for package: NetworkManager
--> Processing Dependency: caching-nameserver for package: NetworkManager
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for dhcdbd to pack into transaction set.
dhcdbd-1.9-1.FC4.i386.rpm 100% |=========================| 5.2 kB    00:00
---> Package dhcdbd.i386 0:1.9-1.FC4 set to be updated
---> Downloading header for caching-nameserver to pack into transaction set.
caching-nameserver-7.3-3. 100% |=========================| 6.8 kB    00:00
---> Package caching-nameserver.noarch 0:7.3-3 set to be updated
--> Running transaction check

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Installing:
 NetworkManager          i386       0.5.1-1.FC4.1    updates-testing   257 k
Installing for dependencies:
 caching-nameserver      noarch     7.3-3            base-local         22 k
 dhcdbd                  i386       1.9-1.FC4        updates-testing    63 k

Transaction Summary
=============================================================================
Install      3 Package(s)
Update       0 Package(s)
Remove       0 Package(s)
Total download size: 343 k
Is this ok [y/N]: n
Exiting on user Command
Complete!

Seth?
  
>  Before, we used to store the WEP keys in plain text on the disk.  Now
> we 
>  use gnome-keyring-manager which encrypts the passwords, and in theory is 
>  a better experience.  Having to enter your keyring password is a 
>  "regression" in that sense, I suppose.  There's a bug filed in gnome CVS 
>  I believe to get the keyring to not require login if the user has "log 
>  me in to GNOME automatically" enabled. 
The WEP key is stored in plain text on the disk anyway --
in /etc/sysconfig/network-scripts/keys-eth1. It's readable only by root,
and mere users cannot read it. For many situations, that is the most
appropriate behaviour.

Perhaps the dialog box which allows me to enter the WEP key should have
a 'Set this system-wide' checkbox, which would then ask me for the root
password and store it somewhere appropriate instead of in my own
personal settings?

On a separate note, the 'connect with dialup' option is very nice for
_connecting_ but then doesn't actually show that the connection is made,
and doesn't offer me a 'disconnect' option.

Any pointers on adding Bluetooth support? Bluetooth devices are detected
in sysfs as one might expect, the 'scan' procedure is what's implemented
in the 'pand' tool in bluez-utils (search for other hosts, then search
for PAN capability on each host found), and connection involves creating
up a virtual Ethernet device over the Bluetooth and then treating that
as a normal Ethernet device. I can do all that, but interfacing it to NM
looks complex (to me).

-- 
dwmw2

[Christopher Aillon]

On 10/21/2005 09:43 AM, David Woodhouse wrote:
>  On Fri, 2005-10-21 at 09:19 -0400, Christopher Aillon wrote:
>    
> >  > cd builds/rpms/NetworkManager/FC-4
> >  > grep wireless-tools NetworkManager.spec
> > NetworkManager.spec:20:Requires: wireless-tools >= 28-0.pre9
> > NetworkManager.spec:31:BuildRequires: wireless-tools >= 28-0.pre9
> >  >
> >
> > I'm not sure how that is failing for your version.  That is there in the 
> > spec file... Suggestions as to how to fix are appreciated.
> >     
>
>  Hm, strange. Yet I can reproduce it on another clean FC4 box... 
Grah, looks like
Epoch Man strikes again.  The wireless-tools package 
has an Epoch of 1.  So, wireless-tools-1:28-0.pre4 is newer than 
wireless-tools-28-0.pre9.  (Or so I think).  I'll build a new RPM with 
that fixed.

[Justin Conover]

On 10/20/05, Christopher Aillon <caillon(a)redhat.com&gt; wrote:
>  ---------------------------------------------------------------------
>  Fedora Test Update Notification
>  FEDORA-2005-1004
>  2005-10-20
>  ---------------------------------------------------------------------
>
>  Product : Fedora Core 4
>  Name : NetworkManager
>  Version : 0.5.1
>  Release : 1.FC4.1
>  Summary : Network link manager and user applications
>  Description :
>  NetworkManager attempts to keep an active network connection available at
>  all
>  times. It is intended only for the desktop use-case, and is not intended
>  for
>  usage on servers. The point of NetworkManager is to make networking
>  configuration and setup as painless and automatic as possible. If using
>  DHCP,
>  NetworkManager is _intended_ to replace default routes, obtain IP
>  addresses
>  from a DHCP server, and change nameservers whenever it sees fit.
>
>  ---------------------------------------------------------------------
>
>  * Wed Oct 19 2005 Christopher Aillon <caillon(a)redhat.com&gt; - 0.5.1-1.FC4.1
>  - Update to NetworkManager 0.5.1
>
>  * Wed Oct 19 2005 Christopher Aillon <caillon(a)redhat.com&gt; - 0.5.0-1.FC4.2
>  - Requires dhcdbd
>
>  * Tue Oct 18 2005 Christopher Aillon <caillon(a)redhat.com&gt; - 0.5.0-1.FC4.1
>  - Update to NetworkManager 0.5.0
>
>
>  ---------------------------------------------------------------------
>  This update can be downloaded from:
>  http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/4/
>
>  db894029702d5d215183f68f084e6e54 SRPMS/NetworkManager-
>  0.5.1-1.FC4.1.src.rpm
>  1f7eb735362b3c4c45fe059f8c8068c9 ppc/NetworkManager-0.5.1-1.FC4.1.ppc.rpm
>  dcbccbf14baebb1502d1d88347c84a03 ppc/NetworkManager-
>  gnome-0.5.1-1.FC4.1.ppc.rpm
>  f4a21112da9dc690f4c3352c23925120 ppc/NetworkManager-
>  devel-0.5.1-1.FC4.1.ppc.rpm
>  753bcdfc80d5bdb9fce3ae0b03e4768c ppc/NetworkManager-
>  glib-0.5.1-1.FC4.1.ppc.rpm
>  7f7365e9337ad4ec593166c648a34f3c ppc/debug/NetworkManager-
>  debuginfo-0.5.1-1.FC4.1.ppc.rpm
>  c2de140db1531e06bf1a54ea4e22e906 x86_64/NetworkManager-
>  0.5.1-1.FC4.1.x86_64.rpm
>  56bec14e5a6254a403cdafffb8ccd117 x86_64/NetworkManager-
>  gnome-0.5.1-1.FC4.1.x86_64.rpm
>  3a3f0c6873b3922da4bff81c6760657f x86_64/NetworkManager-
>  devel-0.5.1-1.FC4.1.x86_64.rpm
>  70edd19eb76e7d39ba6ff409486744c5 x86_64/NetworkManager-
>  glib-0.5.1-1.FC4.1.x86_64.rpm
>  68d72f460849d17b209b3049e2dc3f25 x86_64/debug/NetworkManager-
>  debuginfo-0.5.1-1.FC4.1.x86_64.rpm
>  42af9a34dac320f199e8977df1d89bbe i386/NetworkManager-
>  0.5.1-1.FC4.1.i386.rpm
>  918e63cac84d79fe4b8ad2981c29110a i386/NetworkManager-
>  gnome-0.5.1-1.FC4.1.i386.rpm
>  e7efac816a1ec83cf703ff89404fb377 i386/NetworkManager-
>  devel-0.5.1-1.FC4.1.i386.rpm
>  c39d7b016047d50a96f9f489365cacf5 i386/NetworkManager-
>  glib-0.5.1-1.FC4.1.i386.rpm
>  1193e9a00a79555fa7e0897a08e40027 i386/debug/NetworkManager-
>  debuginfo-0.5.1-1.FC4.1.i386.rpm
>
>  This update can also be installed with the Update Agent; you can
>  launch the Update Agent with the 'up2date' command. You may
>  need to edit your up2date channels configuration. Within
>  /etc/sysconfig/rhn/sources enable the following line:
>  yum updates-testing
>  http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/4...
>  ---------------------------------------------------------------------
>
>  --
>  fedora-test-list mailing list
>  fedora-test-list(a)redhat.com
>  To unsubscribe:
>  https://www.redhat.com/mailman/listinfo/fedora-test-list
>  

Working great here!

[Peter Robinson]

On 10/20/05, Christopher Aillon <caillon(a)redhat.com&gt; wrote:
> ---------------------------------------------------------------------
>  Fedora Test Update Notification
>  FEDORA-2005-1004
>  2005-10-20
>  ---------------------------------------------------------------------
>
>  Product     : Fedora Core 4
>  Name        : NetworkManager
>  Version     : 0.5.1
>  Release     : 1.FC4.1
>  Summary     : Network link manager and user applications
>  Description :
>  NetworkManager attempts to keep an active network connection available at all
>  times.  It is intended only for the desktop use-case, and is not intended for
>  usage on servers.   The point of NetworkManager is to make networking
>  configuration and setup as painless and automatic as possible.  If using DHCP,
>  NetworkManager is _intended_ to replace default routes, obtain IP addresses
>  from a DHCP server, and change nameservers whenever it sees fit.
>
>  --------------------------------------------------------------------- 
Just an update from my perspective. It works great for me most of the
time. The problems that I seem to have are when I'm on the border of
the wireless network boundary.

I also have the network monitor applet and that seems to report about
double the single strength of the NetworkManger applet thingy. Also
being on the boundary of the network everytime the network drops out
for a second or two it has to go through the whole process of
reconnecting and getting an IP etc which is quite annoying as when I
use the wireless without it (just the Network monitor + I suppose the
wireless tools) it will just reconnect and continue on as before.

It also seems to get a bit confused when it drops and reconnects and
seems to loose DNS as  well.

Should I bugzilla these? Or maybe head to the nm mailing list.

Peter

[David Woodhouse]

On Fri, 2005-10-21 at 13:18 +0100, David Woodhouse wrote:
>  Unfortunately I'm also required to enter my password for
>  gnome-keyring-daemon each time I boot the laptop, before the wireless
>  network will connect. I'm sure it used to connect as soon as the
>  machine booted, but now it's waiting for me -- that's a fairly
>  significant regression, since I'm used to just powering the laptop up
>  and walking away from it, then logging in over the network. 
I filed bug #174467 for this in rawhide; I've just noticed that the
package I was testing has made its way into FC4 updates without this
problem being fixed, so I cloned the bug as #176728 for FC4.

WEP keys are _not_ per-user data. They're system-wide.

-- 
dwmw2

[Dan Williams]

On Sat, 2005-12-31 at 02:32 +0000, David Woodhouse wrote:
>  On Fri, 2005-10-21 at 13:18 +0100, David Woodhouse wrote:
>  > Unfortunately I'm also required to enter my password for
>  > gnome-keyring-daemon each time I boot the laptop, before the wireless
>  > network will connect. I'm sure it used to connect as soon as the
>  > machine booted, but now it's waiting for me -- that's a fairly
>  > significant regression, since I'm used to just powering the laptop up
>  > and walking away from it, then logging in over the network.
>  
>  I filed bug #174467 for this in rawhide; I've just noticed that the
>  package I was testing has made its way into FC4 updates without this
>  problem being fixed, so I cloned the bug as #176728 for FC4.
>  
>  WEP keys are _not_ per-user data. They're system-wide. 
Debatable.  I may be authorized to connect to certain networks, and
you're not.  So the network & authorization information is specific to
my user, and shouldn't be available to yours.  This is the same
situation as 802.1x certificates for authentication.  You shouldn't use
my certificate to authenticate to the access server.  Same for WEP keys.

Of course, this is all premised on console-user privileges.  In an
actively multi-user machine, there do need to be system-wide settings
for networking.  But nobody has come up with an acceptable method for
system-wide settings, besides using GConf's default/mandatory settings.
But by default, I argue that such security and authentication
information is first per-user, second system-wide, and only in that
order.  Just like login passwords.

Dan

[David Woodhouse]

On Wed, 2006-01-04 at 13:25 -0500, Dan Williams wrote:
>  Debatable.  I may be authorized to connect to certain networks, and
>  you're not.  So the network & authorization information is specific to
>  my user, and shouldn't be available to yours.   
That doesn't really make much sense in the Linux world -- if the network
is configured and running then all users on the machine _have_ got
access to the it. I think there are some iptables hacks around to
attempt to limit network access to certain users, but we don't ship
them, do we? We certainly don't attempt to use them.

For Windows, perhaps it's different -- one really can consider a Windows
box to be a single-user machine, and it might actually make sense to
consider network connections to be a per-user thing. Even VPNs might
make some sense in the Windows world, but this isn't Windows.

>  This is the same situation as 802.1x certificates for authentication.
>
>  You shouldn't use my certificate to authenticate to the access
>  server.  Same for WEP keys. 
It isn't 'my' WEP key. It is the system's WEP key. You are trying to
impose a policy which doesn't make any sense in this environment.

>  Of course, this is all premised on console-user privileges.  In an
>  actively multi-user machine, there do need to be system-wide settings
>  for networking.  But nobody has come up with an acceptable method for
>  system-wide settings, besides using GConf's default/mandatory
>  settings.
>  But by default, I argue that such security and authentication
>  information is first per-user, second system-wide, and only in that
>  order.  Just like login passwords. 
Not at all like login passwords. Login passwords get you a _session_
from which you can access an individual resources's files, and you can
access certain other shared resources which are available to you.

WEP keys set up a system-wide resource which _any_ user of the system
can then utilise. Networks _aren't_ a per-user resource in practice, and
I'd be surprised if it were particularly common for users to want WEP
keys to be per-user. Certificates might well be a different matter, but
in practice I doubt there are many users who really care about those
being per-user instead of system-wide either.

Network data being stored system wide is by far the more common
arrangement, and as far as I can tell, NetworkManager doesn't seem to
allow that -- I ought to at least have the _option_ of doing so, surely?
Or is this yet another case where GNOME knows better than its idiot
users?

I'd like to reboot my laptop onto a new kernel, but if I do so at the
moment while I'm 20 miles from it, I know it wouldn't manage to
reconnect to the network....

-- 
dwmw2

[Peter Jones]

On Mon, 2006-01-09 at 16:16 +0000, David Woodhouse wrote:
>  On Wed, 2006-01-04 at 13:25 -0500, Dan Williams wrote:
>  > Debatable.  I may be authorized to connect to certain networks, and
>  > you're not.  So the network & authorization information is specific to
>  > my user, and shouldn't be available to yours.  
>  
>  That doesn't really make much sense in the Linux world -- if the network
>  is configured and running then all users on the machine _have_ got
>  access to the it. I think there are some iptables hacks around to
>  attempt to limit network access to certain users, but we don't ship
>  them, do we? We certainly don't attempt to use them. 
We do implement that concept (though not that method) if you consider
xen, don't we?

That may not make sense for WEP right now, but I can certainly see a
world where Xen guests know different WEP keys than other guests, and is
on a different network, whether that's supported in software only or
just hardware.  It wouldn't be very hard to add that into the current
ieee80211 stack, and I suspect it wouldn't be hard to do in similar
software implementations.

Obviously, this doesn't have direct immediate repercussions on NM, but
it is important to keep in mind that such a scenario is possible,
whether or not we intend to support it right now.

>  For Windows, perhaps it's different -- one really can consider a
> Windows
>  box to be a single-user machine, and it might actually make sense to
>  consider network connections to be a per-user thing. Even VPNs might
>  make some sense in the Windows world, but this isn't Windows. 
VPNs make plenty of sense in Linux.  Let's not characterize the entire
world's usage based on *your* requirements, or those of any single
individual.

>  > This is the same situation as 802.1x certificates for
> authentication. 
>  > You shouldn't use my certificate to authenticate to the access
>  > server.  Same for WEP keys.
>  
>  It isn't 'my' WEP key. It is the system's WEP key. You are trying to
>  impose a policy which doesn't make any sense in this environment. 
It doesn't make sense, but why not?  I think it's because our code
doesn't do it, not because the idea is totally off base.  I think a WEP
key can conceptually make sense as either per-host or per-user, but our
network stack doesn't really support but one of those.

>  Network data being stored system wide is by far the more common
>  arrangement 
*That* I'll agree with.

-- 
  Peter

[Alan Cox]

On Mon, Jan 09, 2006 at 04:16:08PM +0000, David Woodhouse wrote:
>  That doesn't really make much sense in the Linux world -- if the
> network
>  is configured and running then all users on the machine _have_ got
>  access to the it. I think there are some iptables hacks around to 
The administration may see that differently to the physical topology. We
do actually enforce user level management for some network protocols notably
AX.25 where the authorization to use the radio generally is tied to a user
and multiple users effectively appear as different "addresses"

>  It isn't 'my' WEP key. It is the system's WEP key.
> You are trying to
>  impose a policy which doesn't make any sense in this environment. 
What is it they say about being able to see in stereo through a keyhole 8)

There are cases of systems where it is meaningful to deal with authentication
and control of interfaces at a user level. Different users having different
WEP keys is one possible case but more common are things like end users
bluetooth connections not being made available to remote users sharing the
system.

>  WEP keys set up a system-wide resource which _any_ user of the
> system
>  can then utilise. Networks _aren't_ a per-user resource in practice, and 
See example above. They can be. It isnt perhaps the most common situation
but it is a very real one and I've dealt with people who actively wanted to
route some users via different networks or deny them some access and for good
reasons.

[David Woodhouse]

On Mon, 2006-01-09 at 13:27 -0500, Alan Cox wrote:
>  On Mon, Jan 09, 2006 at 04:16:08PM +0000, David Woodhouse wrote:
>  > That doesn't really make much sense in the Linux world -- if the network
>  > is configured and running then all users on the machine _have_ got
>  > access to the it. I think there are some iptables hacks around to
>  
>  The administration may see that differently to the physical topology. We
>  do actually enforce user level management for some network protocols notably
>  AX.25 where the authorization to use the radio generally is tied to a user
>  and multiple users effectively appear as different "addresses" 
I'm sure we'll bear that in mind when NetworkManager starts to support
AX.25.

>  There are cases of systems where it is meaningful to deal with
> authentication
>  and control of interfaces at a user level. Different users having different
>  WEP keys is one possible case but more common are things like end users
>  bluetooth connections not being made available to remote users sharing the
>  system.
>  
>  > WEP keys set up a system-wide resource which _any_ user of the system
>  > can then utilise. Networks _aren't_ a per-user resource in practice, and
>  
>  See example above. They can be. It isnt perhaps the most common situation
>  but it is a very real one and I've dealt with people who actively wanted to
>  route some users via different networks or deny them some access and for good
>  reasons. 
I agree that it's possible, although relatively rare and fairly naïve in
the case of IP networks, for network connections to be considered
'per-user', and hence for WEP keys or WPA certificates to be considered
such too. I have no objection to NetworkManager attempting to
accommodate this strange view of the world in _addition_ to the normal
setup.

What I object to is the fact that it no longer supports the _normal_
form of operation, where the network is a system-wide resource, set up
automatically at boot time. I have to actually log in and enter a
password now in order for my machine to connect to the network, and
that's a serious regression.

-- 
dwmw2

[Dan Williams]

On Tue, 2006-01-10 at 03:40 +0000, David Woodhouse wrote:
>  What I object to is the fact that it no longer supports the _normal_
>  form of operation, where the network is a system-wide resource, set up
>  automatically at boot time. I have to actually log in and enter a
>  password now in order for my machine to connect to the network, and
>  that's a serious regression. 
I've maintained all along that if users and/or administrators wish to
delegate keys to all users of the system, that's quite acceptable.

What's _doesn't_ exist right now is a mechanism to store those keys in a
system-wide location, and to give those keys to NetworkManager on
demand.  Stuff we've tossed around:

1) GConf: either through mandatory/default settings, or a 'nobody'
user's GConf settings, a system-wide org.freedesktop.NetworkManagerInfo
service runs from bootup to shutdown.  When a user-session asks for the
service, the system-level one gives the service up.  It reacquires the
service when the user-level service drops.  It provides
default/system-wide settings to NetworkManager just like the
user-session one does.

2) Text files in /etc like we have now.  Haha.  No way.

3) Some other system-wide configuration framework.  Sure, as long as its
not text files in /etc like we have now.  The nice stuff about GConf and
everything else is that it's -structured- and easily accessed by a sane
API.  I don't want to write text-file parsing tools for every damn thing
that needs system-wide config access.

(1) has to happen anyway for power management too, how do you manage
power if nobody is logged in?  Again, system-wide settings and prefs.
But to keep a consistent architecture and not build different
system-settings parsing crap into every daemon, we have a nicer option
in the dbus-enabled world.

But then again, why can't these daemons that need network on boot start
_not_ needing network on bootup?  Why can't they gracefully fail when
they don't have network, and do whatever they do when the network shows
up?  Yeah, it's new to lots of people that a Linux system just might not
have networking 100% of the time, but that's the reality client-side,
and daemon developers have to suck it up and deal with it.

Dan

[David Woodhouse]

On Mon, 2006-01-09 at 13:23 -0500, Peter Jones wrote:
>  We do implement that concept (though not that method) if you
> consider
>  xen, don't we? 
I suppose you _could_ do it like that, but it's fairly unlikely. Surely
you're far more like to set it up with different routing for the various
Xen hosts just as you would if they were external network hosts, rather
than playing with per-user stuff?

>  > For Windows, perhaps it's different -- one really can
> consider a Windows
>  > box to be a single-user machine, and it might actually make sense to
>  > consider network connections to be a per-user thing. Even VPNs might
>  > make some sense in the Windows world, but this isn't Windows.
>  
>  VPNs make plenty of sense in Linux.  Let's not characterize the entire
>  world's usage based on *your* requirements, or those of any single
>  individual. 
VPNs make sense in Linux in certain cases, of course -- bridging the
public Internet between two or more sets of 'trusted' machines, for
example. Again, where the network is seen as a system-wide resource.

But that's not what I was referring to -- I was referring to the use of
a VPN from NetworkManager, which is usually done to allow a single user
to access services from a remote point on the public network. That's
something you generally find in the Windows world, where machines are
effectively single-user, rather than in Linux where the network is a
shared resource, and where private access can be achieved in other ways
-- even Evolution can handle accessing IMAP servers over arbitrary
commands like SSH instead of having to be able to connect directly by
TCP to its servers. But we digress. 

>  > > This is the same situation as 802.1x certificates for
> authentication. 
>  > > You shouldn't use my certificate to authenticate to the access
>  > > server.  Same for WEP keys.
>  > 
>  > It isn't 'my' WEP key. It is the system's WEP key. You are trying
> to
>  > impose a policy which doesn't make any sense in this environment.
>  
>  It doesn't make sense, but why not?  
The policy of WEP keys being per-user, which is the policy
NetworkManager is trying to impose, doesn't make any sense in my home
environment because the key is _not_ a per-user thing. In common with
most WEP users, it's a system-wide thing. I don't expect to have to tell
all the other users of my laptop the WEP key in order for them to be
able to use the network.

>   I think it's because our code
>  doesn't do it, not because the idea is totally off base.  I think a WEP
>  key can conceptually make sense as either per-host or per-user, but our
>  network stack doesn't really support but one of those. 
Our network stack doesn't support network devices being per-user. There
are some hacks you can do with iptables, but they're just that -- hacks.

However, you _can_ tell yourself that network connections are a per-user
thing _if_ you have a system which only actually has a single user. Of
course, in that case you might as well have made the setting system-wide
anyway, and satisfied all the users out there with _normal_ setups as
well.

>  > Network data being stored system wide is by far the more common
>  > arrangement
>  
>  *That* I'll agree with. 
Yet NetworkManager doesn't deal with that case.

While we can contrive a case for per-user keys, they aren't actually the
norm. I'm not arguing that NetworkManager shouldn't support per-user
keys, but rather that it should support system-wide keys, because that's
what people actually _use_ in the real world, in general.

-- 
dwmw2

[Alan Cox]

On Tue, Jan 10, 2006 at 03:40:33AM +0000, David Woodhouse wrote:
>  the case of IP networks, for network connections to be considered
>  'per-user', and hence for WEP keys or WPA certificates to be considered
>  such too. I have no objection to NetworkManager attempting to
>  accommodate this strange view of the world in _addition_ to the normal
>  setup. 
You are confusing connections and authorisation. The two are very different.
Another clear example is bluetooth. If you are remotely logged into my
machine and I'm testing bluetooth IP links on my phone I don't want you
using it. More to the point if I'm on bluetooth I don't want daemons using
the link either by default...

>  What I object to is the fact that it no longer supports the _normal_
>  form of operation, where the network is a system-wide resource, set up
>  automatically at boot time. I have to actually log in and enter a
>  password now in order for my machine to connect to the network, and
>  that's a serious regression. 
Its more secure 8)

Most keys belong system wide. The UI certainly needs something along the lines
of "Share this key with other users [ ]"

Alan

[Christopher Aillon]

On 01/09/2006 11:16 AM, David Woodhouse wrote:
>  On Wed, 2006-01-04 at 13:25 -0500, Dan Williams wrote:
>    
> > Debatable.  I may be authorized to connect to certain networks, and
> > you're not.  So the network & authorization information is specific to
> > my user, and shouldn't be available to yours.  
> >     
>
>  That doesn't really make much sense in the Linux world -- if the network
>  is configured and running then all users on the machine _have_ got
>  access to the it. I think there are some iptables hacks around to
>  attempt to limit network access to certain users, but we don't ship
>  them, do we? We certainly don't attempt to use them.
>     
Well, we live in the real world, not the linux world.  For example, on 
my personal, privately owned laptop, I want to access Red Hat's VPN and 
its WEP keys.  I store my keys in the keyring.  It is not unreasonable 
for me to allow my sister, or my girlfriend, or whatnot to use my laptop 
at times.  However, they do not get access to Red Hat's internal 
network.  They have their own unpriveledged user accounts on my laptop.  
I don't see how this is an unreasonable situation in the real world.

[David Woodhouse]

On Tue, 2006-01-10 at 11:59 -0500, Christopher Aillon wrote:
>  Well, we live in the real world, not the linux world.  For example,
> on 
>  my personal, privately owned laptop, I want to access Red Hat's VPN and 
>  its WEP keys.  I store my keys in the keyring.  It is not unreasonable 
>  for me to allow my sister, or my girlfriend, or whatnot to use my laptop 
>  at times.  However, they do not get access to Red Hat's internal 
>  network.  They have their own unpriveledged user accounts on my laptop.  
>  I don't see how this is an unreasonable situation in the real world. 
Yet those people, if they have accounts on your laptop, _can_ access Red
Hat's internal network any time your laptop is connected. Because you
haven't set up iptables to do per-user filtering, have you?

And anyway, I'm not suggesting that you shouldn't support the esoteric
case of people kidding themselves that per-user keys are actually
meaningful. I'm suggesting that you shouldn't _enforce_ that bizarre
view; that you should at least make some allowance for the _normal_
case, which is per-system keys.

-- 
dwmw2

[David Woodhouse]

On Tue, 2006-01-10 at 07:04 -0500, Alan Cox wrote:
>  I have to actually log in and enter a password now in order for my
>  machine to connect to the network, and that's a serious regression.
>  
>  Its more secure 8) 
Not really. A security policy which is over the top is just inviting you
to circumvent it. It's tempting me just to disable WEP altogether,
rather than forcing all users to enter some kind of password _again_
after they've already done so to log in.

And that's beside the point, which is that GNOME applets shouldn't be
dictating security policies -- especially silly ones like 'networks are
per-user', even if you _can_ contrive a couple of situations where that
seems to make sense.

Support the bizarre 'per-user' thing if you really must, but please also
support the common case, which is that stuff like WEP keys are a
system-wide thing.

-- 
dwmw2

[Peter Jones]

On Tue, 2006-01-10 at 17:08 +0000, David Woodhouse wrote:
>  On Tue, 2006-01-10 at 11:59 -0500, Christopher Aillon wrote:
>  > Well, we live in the real world, not the linux world.  For example, on 
>  > my personal, privately owned laptop, I want to access Red Hat's VPN and 
>  > its WEP keys.  I store my keys in the keyring.  It is not unreasonable 
>  > for me to allow my sister, or my girlfriend, or whatnot to use my laptop 
>  > at times.  However, they do not get access to Red Hat's internal 
>  > network.  They have their own unpriveledged user accounts on my laptop.  
>  > I don't see how this is an unreasonable situation in the real world.
>  
>  Yet those people, if they have accounts on your laptop, _can_ access Red
>  Hat's internal network any time your laptop is connected. Because you
>  haven't set up iptables to do per-user filtering, have you? 
The premise here is obviously that he's not connected to the RH network
except when he's logged in as his user, and the other users neither
neither use his account nor access his laptop remotely.

I think we all agree that WEP keys should at least have the option of
being global.  Let's all stop being didactic, argumentative lunatics
about our reasons why they should have some other mode as well.
-- 
  Peter

[David Woodhouse]

On Tue, 2006-01-10 at 13:26 -0500, Peter Jones wrote:
>  The premise here is obviously that he's not connected to the RH
> network
>  except when he's logged in as his user, and the other users neither
>  neither use his account nor access his laptop remotely. 
We are assuming that these users are not acting maliciously, and that
their accounts have not been compromised. But if we're making that
assumption, then it doesn't actually matter much if they _do_ have
access, does it?

Yes, having the key be per-user in NM does prevent other users from
_deliberately_ (or even accidentally) using it when the 'authorised'
user isn't currently logged in. But the 'per-user' nature of the
connection is just an illusion -- in the case where the other user's
account is compromised by a trojan or an SSH worm, the VPN 'solution'
still allows that infection to propagate through the VPN connection. 

Other methods of connection like SSH don't allow that to happen, because
they really _are_ per-user, while network connectivity in practice is
not.

>  I think we all agree that WEP keys should at least have the option
> of
>  being global.  
Do we? I reported this fault when a NetworkManager package in
updates-testing started asking me for a password, and that package still
went into FC4 updates-released -- and it's still not fixed in rawhide
either.

If we all agree, shall we make bug #174467 a FC5Blocker then?

>   Let's all stop being didactic, argumentative lunatics
>  about our reasons why they should have some other mode as well. 
I assume that's directed at GNOME folks rather than myself, as I've
never said it shouldn't allow a per-user option.

I just questioned the value of the per-user mode in the real world.

Yes, I accept that you can find some weird situations in which it makes
sense, so it should be possible -- but it certainly shouldn't be the
_default_, let alone the _only_ mode available.

-- 
dwmw2

[Alan Cox]

On Tue, Jan 10, 2006 at 07:17:22PM +0000, David Woodhouse wrote:
>  > I think we all agree that WEP keys should at least have the
> option of
>  > being global. 
>  
>  Do we? I reported this fault when a NetworkManager package in
>  updates-testing started asking me for a password, and that package still
>  went into FC4 updates-released -- and it's still not fixed in rawhide
>  either.
>  
>  If we all agree, shall we make bug #174467 a FC5Blocker then? 
Please do. I consider it a blocker for many uses including just about any
server use of wireless networks

[Bill Rugolsky Jr.]

On Tue, Jan 10, 2006 at 02:30:36PM -0500, Alan Cox wrote:
>  On Tue, Jan 10, 2006 at 07:17:22PM +0000, David Woodhouse wrote:
>  > If we all agree, shall we make bug #174467 a FC5Blocker then?
>  
>  Please do. I consider it a blocker for many uses including just about any
>  server use of wireless networks 
 
<rant>
Thank $DEITY that a few folks at Red Hat realize that the wireless
contraption in my pocket might actually *serve* data to an ergonomically
confortable keyboard and screen that I happen to be using.

The rest of the lot should be required to sit through as many presentations
as necessary from Jim Gettys until they understand that LINUX IS NOT WINDOWS!
</rant>
	-Bill

[Dan Williams]

On Tue, 2006-01-10 at 19:17 +0000, David Woodhouse wrote:
>  Do we? I reported this fault when a NetworkManager package in
>  updates-testing started asking me for a password, and that package still
>  went into FC4 updates-released -- and it's still not fixed in rawhide
>  either.
>  
>  If we all agree, shall we make bug #174467 a FC5Blocker then? 
No, I don't really agree.  The correct solution to this is going to take
quite a bit of engineering, coming right on the heels of WPA support
which itself is a major code churn and breaks some wireless drivers
because they don't work with wpa_supplicant.  Do you want to push FC5
out another month or two just for NetworkManager and a use-case that's
of dubious _immediate_ importance?

Yes, we need to have system-wide configuration, nobody disagrees.  We
all just disagree on how immediate the need is.

Dan

[Chris Adams]

Once upon a time, Dan Williams <dcbw(a)redhat.com&gt; said:
>  Yes, we need to have system-wide configuration, nobody disagrees. 
> We
>  all just disagree on how immediate the need is. 
System-wide configuration is much more useful than per-user config.  A
lot of things are broke if the network is only working when someone logs
in (cron jobs like "yum", any type of remote administration, etc.).

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Jesse Keating]

On Wed, 2006-01-11 at 10:01 -0600, Chris Adams wrote:
>  
>  System-wide configuration is much more useful than per-user config.  A
>  lot of things are broke if the network is only working when someone logs
>  in (cron jobs like "yum", any type of remote administration, etc.).  
I've found that a way around this is to have a config in place
in /etc/sysconfig/network-scripts/  by using netconfig or whathaveyou.
This config is used at boot time, and then when I log in as a user
NetworkManager takes over the connection.  Not optimal, but at least
functional for my system.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)

[Dan Williams]

On Wed, 2006-01-11 at 10:01 -0600, Chris Adams wrote:
>  Once upon a time, Dan Williams <dcbw(a)redhat.com&gt; said:
>  > Yes, we need to have system-wide configuration, nobody disagrees.  We
>  > all just disagree on how immediate the need is.
>  
>  System-wide configuration is much more useful than per-user config.  A
>  lot of things are broke if the network is only working when someone logs
>  in (cron jobs like "yum", any type of remote administration, etc.). 
> From your perspective perhaps.  It depends entirely on how you use
> your 
computer.

NetworkManager was written to make wireless & laptop use easier
_immediately_, and server & immobile workstation cases would be dealt
with at a slightly later date.  The current operation of NM is entirely
consistent with a laptop/mobile-user use-case, and I've not heard [m]any
of these users complain.  Laptop & mobile users do not always have
network.  So in the current system, cronjobs have no guarantee of being
run either.  NM doesn't change that.

* The people who want network on boot are, by definition, the people NM
was immediately trying to please. *

But now that the time has come to start building out support for more
use-cases, including the tethered workstation case, these problems need
fixing.  They will be fixed in a consistent, usable, and technically
correct manner.  That is to say, not tomorrow, and probably not by FC5.

Various people are complaining that "NM doesn't work for me, it needs
fixing NOW."  These people are entirely correct in the medium and long
run.  But if it doesn't work for you now, then don't use it.  Or, gently
help it along towards those goals with a minimum necessary level of
complaint.

Dan

[Chris Adams]

Once upon a time, Dan Williams <dcbw(a)redhat.com&gt; said:
>  NetworkManager was written to make wireless & laptop use easier
>  _immediately_, and server & immobile workstation cases would be dealt
>  with at a slightly later date. 
You are assuming that there are no wireless or laptop workstations.
Some people use wireless because it is easier than running a wire, not
because the system is mobile.

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Dan Williams]

On Wed, 2006-01-11 at 13:02 -0600, Chris Adams wrote:
>  Once upon a time, Dan Williams <dcbw(a)redhat.com&gt; said:
>  > NetworkManager was written to make wireless & laptop use easier
>  > _immediately_, and server & immobile workstation cases would be dealt
>  > with at a slightly later date.
>  
>  You are assuming that there are no wireless or laptop workstations.
>  Some people use wireless because it is easier than running a wire, not
>  because the system is mobile. 
No, I'm not assuming that.  What I'm saying is that these cases aren't
something NM was going to solve immediately.  The immediate target was
_mobile_ users, which wireless workstations are not.

Dan

[Jef Spaleta]

On 1/11/06, Chris Adams <cmadams(a)hiwaay.net&gt; wrote:
>  You are assuming that there are no wireless or laptop workstations.
>  Some people use wireless because it is easier than running a wire, not
>  because the system is mobile. 
I think the point is... wireless situations with something
approximating a consistently available network can use the older
s-c-network mechanism for their usage case. A non-mobile but wireless
workstation or desktop that was expected to do network activity with
noone logged in would fall into this wouldn't it?  For those users the
pre-NM situation still exists?

I think system wide configuration for no-one logged in for all of the
snazzy dbus service related software thats being developed now is
important. But if there is a pre dbus-enabled fallback mechanism
available for systemwide policy in the short-term, I think thats a
livable compromise.

NM like the other dbus related service managers are works in progress,
I really don't think the long term development goals benefit from
waiting for these things to be perfect. Let me be very clear. I think
NM would be 3 billion percent more useful, to me personally, if it had
system wide configs instead of just per-user configs. But I'm willing
to wait for that functionality to mature as long as the more
traditional networking configuration options are still available for
me to use to setup system wide policy.

I think  David Zeuthen makes a persuasive outline of the way forward
concerning system/per-user for whatever dbus-enabled manager you could
dream up in  http://blog.fubar.dk/?p=63 .

If NM is suboptimal for systemwide use in FC5 really doesn't interest
me at all. Even partially functional NM that really only addresses
mobile laptop users is progress... as long as there is a traditional
network configuration mechanism to fallback on.  What interests me is
that there is a plan to address system-wide configs for DBUS managers
of all flavors that can and will be implemented as part of an
achievable development roadmap.



-jef

[Chris Chabot]

The reason you did not hear many people complain might be because for
one its not used by default so not everyone knows of its existence, or
alternatively like me are waiting for the point where they can use it
without to much fuss.

The 'ease' of 'it just works' isn't quite there yet, because it keeps
asking me for passwords to be able to bring the network up, instead of
already letting me get to work when i switch on the notebook.. i have to
wait for it to prompt for passwords and use them to get the wep key and
bring the network up, instead of being ready and connected to the
preferred & available network and letting me do whatever i switched my
notebook on

To be honest i only complain because i WANT to use NM badly and you said
not many people do :-). I love the visual feedback on network strength,
have the pretty clickable applet & would love to just be able to click
the network i want it to use ... without the disadvantages it brings
with it that it has now :-) 

Can't we just use (and store) the keys that
in /etc/sysconfig/networking/profiles/*/keys-* ? :-)

    -- Chris

On Wed, 2006-01-11 at 13:04 -0500, Dan Williams wrote:


>  NetworkManager was written to make wireless & laptop use easier
>  _immediately_, and server & immobile workstation cases would be dealt
>  with at a slightly later date.  The current operation of NM is entirely
>  consistent with a laptop/mobile-user use-case, and I've not heard [m]any
>  of these users complain.  Laptop & mobile users do not always have
>  network.  So in the current system, cronjobs have no guarantee of being
>  run either.  NM doesn't change that.

[Dan Williams]

On Wed, 2006-01-11 at 14:44 -0500, Jeff Spaleta wrote:
>  I think  David Zeuthen makes a persuasive outline of the way forward
>  concerning system/per-user for whatever dbus-enabled manager you could
>  dream up in  http://blog.fubar.dk/?p=63 . 
Yeah, David and I have talked about that extensively, and that's likely
the route that NM would go.

Dan

[Jef Spaleta]

On 1/11/06, Dan Williams <dcbw(a)redhat.com&gt; wrote:
>  Yeah, David and I have talked about that extensively, and that's
> likely
>  the route that NM would go. 
excellent!  The proposal he outlines in that blog post resonates
deeply i think as a solution to the general problem of system wide
configs even with the UI focus is clearly for per-user interaction for
whatever dbus enabled service manager you can dream up.  I'd really
hate to have to fight the same fight over and over again with each
dbus-tricked out service. We solve this "no-one/multiple-people logged
in" policy crap in a general way and everybody wins from now until the
sun blows up.

-jef

[Peter Jones]

On Wed, 2006-01-11 at 13:04 -0500, Dan Williams wrote:

>    The current operation of NM is entirely
>  consistent with a laptop/mobile-user use-case, 
Not true.  If it was, it wouldn't ask me for a passphrase to unlock my
keyring before connecting to a WAP; logging in (even automatically via
gdm) would be sufficient for a key required to authenticate with an AP.

-- 
  Peter

[Dan Williams]

On Thu, 2006-01-12 at 13:20 -0500, Peter Jones wrote:
>  On Wed, 2006-01-11 at 13:04 -0500, Dan Williams wrote:
>  
>  >   The current operation of NM is entirely
>  > consistent with a laptop/mobile-user use-case,
>  
>  Not true.  If it was, it wouldn't ask me for a passphrase to unlock my
>  keyring before connecting to a WAP; logging in (even automatically via
>  gdm) would be sufficient for a key required to authenticate with an AP. 
_NM_ is entirely consistent.  Whatever the Gnome Keyring does is another
story.

Dan

[Peter Jones]

On Thu, 2006-01-12 at 13:30 -0500, Dan Williams wrote:
>  On Thu, 2006-01-12 at 13:20 -0500, Peter Jones wrote:
>  > On Wed, 2006-01-11 at 13:04 -0500, Dan Williams wrote:
>  > 
>  > >   The current operation of NM is entirely
>  > > consistent with a laptop/mobile-user use-case,
>  > 
>  > Not true.  If it was, it wouldn't ask me for a passphrase to unlock my
>  > keyring before connecting to a WAP; logging in (even automatically via
>  > gdm) would be sufficient for a key required to authenticate with an AP.
>  
>  _NM_ is entirely consistent.  Whatever the Gnome Keyring does is another
>  story. 
That's a total cop-out.  NM uses gnome-keyring, which in this case means
it behaves in a way that's inconsistent with that use-case.

-- 
  Peter