--------------------------------------------------------------------- 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@redhat.com - 0.5.1-1.FC4.1 - Update to NetworkManager 0.5.1
* Wed Oct 19 2005 Christopher Aillon caillon@redhat.com - 0.5.0-1.FC4.2 - Requires dhcdbd
* Tue Oct 18 2005 Christopher Aillon caillon@redhat.com - 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/$A... ---------------------------------------------------------------------
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 :)
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.
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.
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).
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.
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.
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
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....
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.
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.
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.
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.
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
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
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.
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.
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.
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.
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.
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
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
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
Once upon a time, Dan Williams dcbw@redhat.com 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.).
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.
On Wed, 2006-01-11 at 10:01 -0600, Chris Adams wrote:
Once upon a time, Dan Williams dcbw@redhat.com 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
Once upon a time, Dan Williams dcbw@redhat.com 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.
On Wed, 2006-01-11 at 13:02 -0600, Chris Adams wrote:
Once upon a time, Dan Williams dcbw@redhat.com 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
On 1/11/06, Chris Adams cmadams@hiwaay.net 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
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
On 1/11/06, Dan Williams dcbw@redhat.com 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
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.
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.
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
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.
On 10/20/05, Christopher Aillon caillon@redhat.com 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@redhat.com - 0.5.1-1.FC4.1
- Update to NetworkManager 0.5.1
- Wed Oct 19 2005 Christopher Aillon caillon@redhat.com - 0.5.0-1.FC4.2
- Requires dhcdbd
- Tue Oct 18 2005 Christopher Aillon caillon@redhat.com - 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/$A...
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
Working great here!
On 10/20/05, Christopher Aillon caillon@redhat.com 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