Re: gnome-networkmanager do not use gnome-keyring to manage network key
sorry, but I cannot find kering- in /tmp dir, any comments? Thanks for the help Dan Williams wrote: On Thu, 2009-08-06 at 09:00 -0700, fireinice wrote: Hi, after I update my debian on laptop from lenny to squeeze(testing) dist, the network-manager stop using gnome-keyring to manage the key of the wireless, we I login to the desktop(I'm using the FVWM as the WM) with the xdm, the Could it be that your session manager doesn't set up the correct environment variables that point any application using the keyring to the keyring daemon? Whatever starts your session and launches the keyring daemon needs to insert these into the environment of all other processes that start: GNOME_KEYRING_SOCKET=/tmp/keyring-5KSAbP/socket GNOME_KEYRING_PID=1392 That sort of thing. Dan nm-applet always requires me to input the actual wireless network password but not the gnome-keyring password, and I can not find the remember password in keyring option, but the vpn plug-in seems work fine with the gnome-keyring package. Before the upgrading the network-manager works fine with the gnome-keyring I installed the gnome-keyring2.26.1-1 network-manager-gnome 0.7.1-1 and all dependence packages The console would log info: ** (nm-applet:1452): WARNING **: security_combo_changed: no active security combo box item. ** (nm-applet:1452): WARNING **: security_combo_changed: no active security combo box item. ** (nm-applet:1452): WARNING **: applet-device-wifi.c.1539 (get_secrets_dialog_response_cb): canceled ** Message: info No keyring secrets found for Auto *wireless-id*/802-11-wireless-security; asking user. any clues? Thanks ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list -- View this message in context: http://www.nabble.com/gnome-networkmanager-do-not-use-gnome-keyring-to-manage-network-key-tp24849397p24878019.html Sent from the Gnome - NetworkManager mailing list archive at Nabble.com. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
ECMP Routing with multiple wireless interfaces
Greetings, Recently I've been searching around for a way to use multiple wireless interfaces on my laptop simultaneously. After some long hours searching the net I came across ECMP ( Equal Cost Multipath Routing ). I'm interested in implementing ECMP into NetworkManager. Instead of a radio button for wireless networks I propose ( if there are multiple wireless interfaces ) that it be a checkbox, and ECMP be used to set a default route that incorporates them. I know that I personally would use this feature on a daily basis, but I'm not sure of others. Let me know what you think, Robert Keizer signature.asc Description: OpenPGP digital signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager does not find system wide connections
Dan Williams wrote: Many packets for debian/ubuntu are designed for the four phases of the ifup/down system of debian for pretty good reasons. It depends; reasons change, and so do implementations. Nothing is set in stone. Ah, I see. debian and ubuntu will change their main concepts just to please network manager... Completely wrong. NetworkManager is *NOT* a Red Hat tool. Novell has contributed immensely to it, as have quite a few others from other distributions. It just happens that I am paid by Red Hat to spend 110% of my time working on NetworkManager. Nobody else has made that commitment. If some other company or person decided to invest time in NetworkManager, then that person or companies goals would also obviously be reflected in the feature set of the final product. So network manager is designed to not fit very well into other distributions? So lets add some cold hard facts to the discussion. What things are people doing in pre-down scripts? * Any kind of logout, e.g. release dynamic dns entries, properly shut down connections that are kept alive during the online state * cleanly shutting down VPN connections and tunnels * network logoffs, e.g. deregistration from firewalls to prevent that someone else uses the user's permissions still bound the IP address * Anything that needs to be done with network interfaces that don't exist anymore after taking them down, e.g. read the counters * Doing jobs that need the network connection to be present, e.g. empty the mail queue * Porperly shutting down daemons with services bound to that particular network interface or internet address Beyond the dispute whether two or four phases should be supported, Network Manager does not pass the required Information to the up/down scripts. See below. What other information do you need? Is there some reason the tools you're running in these phases cannot use D-Bus for network even notifications if they are already running as a service somewhere? If they are not running as a service, then yes, a one-shot script-based approach may be more appropriate. Using dbus to fetch information in such a basic application is a completely wrong way. dbus is not very well documented. When trying to fetch debugging data to find the problem in my cause I could not find a detailed description about how to fetch attributes from dbus, and it would be a nightmare to do it in a shell script (and too slow as well). Documentation is poor and incomplete. requiring each single one of the phase scripts fetch information over dbus is simply very, very bad design. If five scripts need that informations then every single one should fetch data over dbus even if the network manager already has them but does not pass for 'religious reasons'? Under debian/ubuntu there is a standard about which data the phase scripts expect, and not all of these data can be found on dbus. Needed: * The environment variables as set by the ifupdown program * The parameters set by users to use extra functionality provided by the phase scripts. Configured in /etc/network/interfaces for every connection type * Any parameters passed by the DHCP server Expecting the scripts to retrieve details with a given UUID over dbus is error prone and bad design, and it does not make the script run any faster. The UUID is already passed to the scripts, and has been for a long time. As are all the IPv4 details, and the DHCPv4 lease details if any. What version of NM are you using? 0.7.1~rc4.1.cf199a964-0ubuntu2 Tools before NetworkManager didn't work for a more dynamic environment (especially wifi), thus we created NetworkManager. I certainly don't want a pile of shell glued together with duct-tape and chewing-gum, which is what most of the previous networking system were. This is a pretty good approach. But unfortunately it takes much more to write a good program. Besides the fact that network manager's programming style is poor (too complex, lack of docs, comments, and debugging, names of little or no use, difficult and time consuming to read), it suffers from a main problem: Network manager is written like one of those many little tools and gadgets for a desktop and extremely interweaved with the desktop environment and it's complex functionalities. You can write a tool for sticky notes or a timer for your cup of tea in that way, things that are related to the user only, but you cannot write a program that controls the communication interfaces this way. You cannot even precisely describe how nm finds its interfaces and configurations, and where to start debugging if something goes wrong. The way nm is driven over the dbus is one of the most silly methods to drive network interfaces I've ever seen. You can certainly add the functionality to a network managing daemon to inform other
Re: Network Manager does not find system wide connections
On Sat, 08 Aug 2009 21:29:07 +0200 Hadmut Danisch had...@danisch.de wrote: Or in other words: Network Manager is too much like Windows and too little like Unix. It's also not compulsory to use it, so if it gives you so much trouble you can always turn it off and operate your network connections as you want. Maybe there is something fundamentally different about networking in Debian-based distros compared with Fedora, personally I've never used a Debian-based distro so I may be missing the point. On Fedora you simply tell the OS which interfaces you want NM to control and which you don't and it just sorts it out. I can only say that before NM existed my laptop was a pain to configure in the three or four places and environments where I need to use it. Once I started using NM it changes the networking setup without needing any more input from me than to configure the keys. I consider that a major benefit. Now I'll grant that I don't have a fantastically complex networking environment to worry about. If I did, I'd probably need to do something differently. NM is great for dealing with changes between a few different network environments, if you're trying to do something that is difficult to describe in simple terms then it probably hasn't yet reached the state of development necessary to meet your needs. I suspect that will happen before 1.0 is released. -- Brian Morrison I am not young enough to know everything Oscar Wilde ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager does not find system wide connections
2009/8/8 Hadmut Danisch had...@danisch.de Dan Williams wrote: Many packets for debian/ubuntu are designed for the four phases of the ifup/down system of debian for pretty good reasons. It depends; reasons change, and so do implementations. Nothing is set in stone. Ah, I see. debian and ubuntu will change their main concepts just to please network manager... This wasn't what he said, the statement was that it depends and reasons change. The DBus interface wasn't available before and therefore everything had to get information from and happen as a result of the phase scripts. Now that the DBus interface is there the packages that used the previous methods should be revised and it should be decided whether that really is the most appropriate way of doing things. Maybe it is the case that the DBus interface isn't entirely suitable for whatever reason, but that needs to be looked at on a case by case basis and if appropriate something else can be decided upon/added. Completely wrong. NetworkManager is *NOT* a Red Hat tool. Novell has contributed immensely to it, as have quite a few others from other distributions. It just happens that I am paid by Red Hat to spend 110% of my time working on NetworkManager. Nobody else has made that commitment. If some other company or person decided to invest time in NetworkManager, then that person or companies goals would also obviously be reflected in the feature set of the final product. So network manager is designed to not fit very well into other distributions? Again no, network manager wasn't designed to not fit into distribution X, it simply hasn't been adapted to fit into it yet. The way you're saying this it's like NM was designed specifically for redhat and they refuse to change anything to make it fit well with other distributions as well. What was said is that redhat have invested a lot in NM and so of course it is suited well to a redhat environment. If some other distro were to invest heavily (by sending patches for the functionality that was required) then NM would also fit well into that distribution. So lets add some cold hard facts to the discussion. What things are people doing in pre-down scripts? * Any kind of logout, e.g. release dynamic dns entries, properly shut down connections that are kept alive during the online state * cleanly shutting down VPN connections and tunnels * network logoffs, e.g. deregistration from firewalls to prevent that someone else uses the user's permissions still bound the IP address * Anything that needs to be done with network interfaces that don't exist anymore after taking them down, e.g. read the counters * Doing jobs that need the network connection to be present, e.g. empty the mail queue * Porperly shutting down daemons with services bound to that particular network interface or internet address Beyond the dispute whether two or four phases should be supported, Network Manager does not pass the required Information to the up/down scripts. See below. What other information do you need? Is there some reason the tools you're running in these phases cannot use D-Bus for network even notifications if they are already running as a service somewhere? If they are not running as a service, then yes, a one-shot script-based approach may be more appropriate. Using dbus to fetch information in such a basic application is a completely wrong way. dbus is not very well documented. When trying to fetch debugging data to find the problem in my cause I could not find a detailed description about how to fetch attributes from dbus, and it would be a nightmare to do it in a shell script (and too slow as well). Documentation is poor and incomplete. Then documentation should be fixed, not the method itself. DBus is the best approach to do this, it uniffies IPC in unix, which is a *good* thing. requiring each single one of the phase scripts fetch information over dbus is simply very, very bad design. If five scripts need that informations then every single one should fetch data over dbus even if the network manager already has them but does not pass for 'religious reasons'? Under debian/ubuntu there is a standard about which data the phase scripts expect, and not all of these data can be found on dbus. Needed: * The environment variables as set by the ifupdown program * The parameters set by users to use extra functionality provided by the phase scripts. Configured in /etc/network/interfaces for every connection type * Any parameters passed by the DHCP server Expecting the scripts to retrieve details with a given UUID over dbus is error prone and bad design, and it does not make the script run any faster. The UUID is already passed to the scripts, and has been for a long time. As are all the IPv4 details, and the DHCPv4
Re: Network Manager does not find system wide connections
Graham Lyon wrote: Then documentation should be fixed, not the method itself. DBus is the best approach to do this, it uniffies IPC in unix, which is a *good* thing. Network configuration is such an essential and basic function, that it should not depend on IPC. IPC means that several processes must exist, and this is error prone by default. IPC may be an addon, but it should work without IPC. NM is not interweaved with desktop applications. You're confusing the user settings manager with network manager itself. A plain user will store his network settings under Gnome or KDE and such within the Gnome and KDE configuration methods. This depends on desktop applications. Without a desktop network manager will not find any user specific config. And I did not yet see any command line front end. It's actually the best way to get the two levels of configuration that I can think of. Storing network configuration in Gnome or KDE in a way that they are not available if someone uses the other Desktop is a bad idea. Network settings are not desktop settings and thus should not be stored in the Gnome or KDE configuration. It doesn't need a running desktop to be configured, and lots of system relevent applications require DBus (it's not a desktop program). And that's wrong. DBus is not started in single user mode. So NetworkManager could not be used in single user mode. A network configuration that does not work in single user mode is a flaw. Networking must be able to work even in single user mode in a simple terminal with a shell session and must not depend on anything else. Correct me if I'm wrong, but I think it does as long as the daemon is started and the system settings daemon is started. That's one of the problems. Network configuration must not depend on that many daemons. Network configuration must be able to work on its own, even if everything else is absent. Windows had for years a much better way of managing network settings for anyone with wireless or a laptop that moved between work and home. Windows did (and does) for years a completely different task. Windows does not leave you the choice between several desktops. Windows does not have a single user mode. Your are confusing two things: Giving a user a graphical user interface for easy configuration does not necessarily mean to give it a bad implementation as well. You could give Network Manger a much more robust and better design and still have a graphical user interface. Hadmut ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager does not find system wide connections
2009/8/9 Hadmut Danisch had...@danisch.de Graham Lyon wrote: Then documentation should be fixed, not the method itself. DBus is the best approach to do this, it uniffies IPC in unix, which is a *good* thing. Network configuration is such an essential and basic function, that it should not depend on IPC. IPC means that several processes must exist, and this is error prone by default. IPC may be an addon, but it should work without IPC. I can see what you're saying here and I sympathise. Perhaps the best solution would be one where there is a single NM daemon on the system level that manages the interfaces and deal with the system config and then supplies a (probably the same) DBus API that allows user processes to manage user-configured connections. A merger of NetworkManager and nm-system-settings, basicly. This removes the need for IPC in order to get the core of it working whilst at the same time still supplying the same funcionality. The more that I think about it the more I agree with you on this point that NetworkManager shouldn't be useless without DBus and the nm-settings-daemon running also. NM is not interweaved with desktop applications. You're confusing the user settings manager with network manager itself. A plain user will store his network settings under Gnome or KDE and such within the Gnome and KDE configuration methods. This depends on desktop applications. Without a desktop network manager will not find any user specific config. I'm not entirely sure what you meant here, but I suspect you mean that an ordinary user will configure their system using the applets in gnome/kde and so their settings will not be system settings? They only need to tick the make available to all users ticky box. If I completely misread what you're saying, please do correct me. And I did not yet see any command line front end. There is cnetworkmanager, apparently (I've never used it) and there was discussions on this list somewhere about a rewrite of it to make it more functional. It's actually the best way to get the two levels of configuration that I can think of. Storing network configuration in Gnome or KDE in a way that they are not available if someone uses the other Desktop is a bad idea. Network settings are not desktop settings and thus should not be stored in the Gnome or KDE configuration. Fair point, but how often do you switch to using the other desktop environment as the same user login? It's not a particularly common use case... I will admit that the network settings are not part of your desktop settings and the problem here is that there is no unified settings daemon for all user's applications (something like this is really lacking in the world of linux and would be great as it would stop everyone having to roll their own config file reading/writing mechanism. It doesn't need a running desktop to be configured, and lots of system relevent applications require DBus (it's not a desktop program). And that's wrong. DBus is not started in single user mode. So NetworkManager could not be used in single user mode. A network configuration that does not work in single user mode is a flaw. See above. I'm not particularly familiar with single user mode (I've never had the need to use it, rather thankfully) but is it possible that dbus could be added to the things that are started in single user mode? Networking must be able to work even in single user mode in a simple terminal with a shell session and must not depend on anything else. Correct me if I'm wrong, but I think it does as long as the daemon is started and the system settings daemon is started. That's one of the problems. Network configuration must not depend on that many daemons. Network configuration must be able to work on its own, even if everything else is absent. I proposed a possible solution to this a little further up in this mail. I'm not sure how the devs will feel about it but it actually makes more sense from a design point of view to me. Though I don't pretend to know about the network manager internals so it could be impossible... Graham ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
