Re: Network Manager does not find system wide connections
On Sun, 2009-08-09 at 00:51 +0100, Graham Lyon wrote: 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 master (0.8) already has merged NM + nm-system-settings; there is only one core NetworkManager process now. However, to control NM, you still need D-Bus. It is completely pointless to re-implement IPC via a socket just so you don't depend on D-Bus. So then you've got both (a) a standard, well-understood, type-safe D-Bus interface, and (b) a non-standard, hacked up duplicated socket-based control interface. Fail. There is nothing wrong with D-Bus, period. Or maybe people will finally accept D-Bus when it's a kernel module (as Marcel Holtmann has proposed)? Something Hadmut didn't consider was that maybe the distros *should* start D-Bus in single-user mode. That's what I mean by change; the distros aren't stuck in stone in how they are configured and what software they run by default. 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. Probably not a rewrite, but another tool in C more suitable to size-constrained installs, or people who just don't want to depend on Python. There is certainly room for both and neither would obsolete the other. Martin does good work. 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. If you want to use user connections in a different DE, you can make them system connections and they will be available to any DE that you use. That's actually the whole point of system connections; it doesn't matter what user or GUI you're using, they are still there. 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
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
Re: Network Manager does not find system wide connections
On Wed, 2009-08-05 at 19:46 +0200, Hadmut Danisch wrote: Dan Williams wrote: There are two reasons I've not yet added pre-up and pre-down. They are: Whatever reasons there might be to have or not to have a pre-up and pre-down phase: Omitting them in a single tool is simply the wrong place. 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. If someone believes that this is wrong, then it should be discussed in general and not just omitted randomly by a single tool breaking the distribution policy. I am fully aware that network manager has never been designed for debian/ubuntu, and is a redhat tool (although I am astonished that these good reasons 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. should not apply to any distribution, e.g. security reasons). I do not see any reason why NetworkManager should not call external pre-up and pre-down commands/scripts. It is the admin's or package maintainers problem if this script does not work properly. Leave it empty if you want. It is not simply the admins and packagers problem. It's also the user's problem. However, if NetworkManager is strictly designed to not support more than two phases, then it might fit into RedHat, but not into the four phases-system of debian and ubuntu. Then it is simply the wrong tool for these distributions and the wrong decision to choose it. So lets add some cold hard facts to the discussion. What things are people doing in pre-down scripts? 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. 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? I still believe that Network Manager is based on too many design mistakes requires a severe redesign and improved programming style (or replacement for ubuntu). 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. I've written about that extensively in various places. That said, I'm perfectly willing to have a discussion about the merits or shortcomings of NetworkManager, and what we are already doing to improve it. Dan ___ 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 (maybe found the reason)
On Tue, Aug 04, 2009 at 11:41:41AM -0400, Dan Williams wrote: On Sat, 2009-08-01 at 01:02 +0200, Hadmut Danisch wrote: I just got a little further with the problem and might have found a reason: I was wondering why the function get_connections() in the keyfile plugin was never called. I put some debugging code in the load_connections() function in system-settings/src/dbus-settings.c It shows: load_connections() is called several times. It's call for the first time, and the Ifupdown plugin gets called and initalized, and its get_connections() called. But at the same time as ifupdown gets loaded, keyfile should also get loaded if I'm not mistaken. At the time load_connections() gets called, the command line/config file will have been parsed, and all plugins will have been registered. I can confirm that it works with latest 0.7 packages (https://edge.launchpad.net/~network-manager/+archive/ppa); i can maintain keyfile connections even if there is an ifupdown connection configured. Maybe there was a bug in the version we shipped in jaunty (0.7.1 git commit: cf199a964)? - Alexander ___ 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: There are two reasons I've not yet added pre-up and pre-down. They are: Whatever reasons there might be to have or not to have a pre-up and pre-down phase: Omitting them in a single tool is simply the wrong place. Many packets for debian/ubuntu are designed for the four phases of the ifup/down system of debian for pretty good reasons. If someone believes that this is wrong, then it should be discussed in general and not just omitted randomly by a single tool breaking the distribution policy. I am fully aware that network manager has never been designed for debian/ubuntu, and is a redhat tool (although I am astonished that these good reasons should not apply to any distribution, e.g. security reasons). I do not see any reason why NetworkManager should not call external pre-up and pre-down commands/scripts. It is the admin's or package maintainers problem if this script does not work properly. Leave it empty if you want. However, if NetworkManager is strictly designed to not support more than two phases, then it might fit into RedHat, but not into the four phases-system of debian and ubuntu. Then it is simply the wrong tool for these distributions and the wrong decision to choose it. Beyond the dispute whether two or four phases should be supported, Network Manager does not pass the required Information to the up/down scripts. 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. I still believe that Network Manager is based on too many design mistakes requires a severe redesign and improved programming style (or replacement for ubuntu). regards 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 (maybe found the reason)
On Sat, 2009-08-01 at 01:02 +0200, Hadmut Danisch wrote: I just got a little further with the problem and might have found a reason: I was wondering why the function get_connections() in the keyfile plugin was never called. I put some debugging code in the load_connections() function in system-settings/src/dbus-settings.c It shows: load_connections() is called several times. It's call for the first time, and the Ifupdown plugin gets called and initalized, and its get_connections() called. But at the same time as ifupdown gets loaded, keyfile should also get loaded if I'm not mistaken. At the time load_connections() gets called, the command line/config file will have been parsed, and all plugins will have been registered. Then, later, load_connections() is called again, but does terminate due to this code: if (priv-connections_loaded) return; And then, after that, the keyfile plugin is loaded. But then, because of this code, load_connections does not call get_connections anymore. That doesn't make sense, because the keyfile plugin gets loaded at the same time as the ifupdown plugin. priv-plugins gets set up in nm_sysconfig_settings_add_plugin(), which is called from main.c::load_plugins(), which is called once after reading the config file or command line. Dan Thus, get_connections of the keyfile plugin is never called. regards ___ 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
On Sat, 2009-08-01 at 13:31 -0400, John Mahoney wrote: Here is a quick, incomplete overview of the configs. I recommend playing with the program cnetworkmanager to see how the dbus works. The following Doc assumes Ubuntu 9.04 with Gnome This doc has no License feel free to edit, sell, hide, destroy, distribute. User-settings Note - only the first person logged into the system has access to user-settings.(needs verification) Correct. user settings are stored in the directory ~/.gconf/system/networking/connections/[num] and ~/.gconf/system/networking/wireless/networks -(note:someone please differentiate the two folders) -each number is a folder representing a connection(Ethernet, wifi, cellular, etc) -most these settings can be changed through system---Preferences---Network Connections The preferred method to view these settings is through gcong-editor( most those settings can be changed through the Network-Manager GUI and that is the preferred method) Applications---Accessories--Terminal u...@user-laptop:~$ gconf-editor system---networking---networking | |--connections | |--wireless #* System settings -These connections are available to all users and before xserver loads(needs verification) Correct. -System connections are stored in /etc/NetworkManager/system-connections/ Not entirely correct. System connections are provided by plugins, and the plugin may read/write the connections it provides from anywhere. Their main purpose is to interpret the normal distro network config files so you don't have to learn some new config format if you don't want to. So, of the plugins currently available: keyfile (rw): /etc/NetworkManager/system-connections/ ifcfg-rh (rw): /etc/sysconfig/network-scripts/ ifcfg-suse (r): /etc/sysconfig/network-scripts/ ifupdown (r): /etc/network/interfaces (rw) = read/write capability, (r) = read-only Dan # Fun facts *go to system---Preferences---Network Connections -To make a user setting available as a system setting *highlight connection, select edit, and check box Available to all users(bottom corner) -If a connection is not a wan and will only be used for local access(aka. never get default route) *highlight connection, select edit, select tab ipv4 settings, select routes, check box use connection for resource on its network *note:you can also add custom routes to be added in this area On Sat, Aug 1, 2009 at 7:14 AM, Timothy Murphy gayle...@eircom.net wrote: Brian Morrison wrote: The whole point of Linux is that it is not magic; you are meant to be able to work out what is going on. There is a complex interaction between NM, dbus and various other things like udev, hal (becoming deprecated), PolicyKit etc. All of these packages do something different but in a way that isn't always clear. If anyone has any bright ideas about how to describe their interaction in a clear and simple manner please go ahead. I have not managed to work it out completely, so I suppose I should feel lucky that NM works for me. You clearly have a pretty good idea of how NM works. If you, or someone like you, could just pen a short account that would be immensely helpful. If there were mistakes they could quickly be corrected. I would love to know, for example, which files NM looks at, or which files one can usefully change. I just get hints from time to time in various postings but there doesn't seem to be anything written down. -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ 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
On Sat, 2009-08-01 at 00:58 +0100, Timothy Murphy wrote: Brian Morrison wrote: I do not believe that it was a good idea to use nm as a standard software tool in ubuntu. Works perfectly fine in Fedora You should say, It works fine for ME in Fedora. It is obvious from the Fedora newsgroups that many people have serious problems with NM. I don't, personally, but I find the complete lack of documentation a major drawback with NM. The whole point of Linux is that it is not magic; you are meant to be able to work out what is going on. It's pretty simple. NM takes connection configuration from a few sources, and applies that to network interfaces based on certain criteria. Those criteria are: (a) whether the connection is available, ie whether the wifi network can be seen or whether there is an ethernet carrier, or (b) when the user tells NM to do so. That's it. Seriously. Where it gets complex is because people expect it to interact seamlessly with their normal distribution's config files and mechanisms, and for finer-grained security so you don't need to be root to do everything. a) distro config files: we've added interpretation of you distros config files to NM. In many cases, those config files operated like bash scripts with variable subsitution and backtick commands, etc. So the mapping isn't always exact, and that's sometimes confusing. However, for many people, it's a lot less confusing than learning a completely new configuration system, and building up new tools to work with that config system. For example, /etc/resolv.conf is *not* static, because lots of things need to update it (vpns, ppp, dhcp, etc). In Fedora, people were confused when /etc/resolv.conf was rewritten periodically by NM to accomodate VPNs or mobile broadband, etc. Because in reality resolv.conf cannot be static (yet some people expected that because it had always worked that way before), they were surprised when this happened. Instead, placing the DNS information into the connection configuration itself, instead of out-of-band in resolv.conf, fixes this issue. b) DNS indirection: Debian uses resolvconf to mediate /etc/resolv.conf, which duplicates a large part of what NM does. Various bugs and other issues with resolvconf have led to some frustration when user's blame NetworkManager for blowing away their /etc/resolv.conf (and of course don't understand how things work because the interactions are complex). In it's most simple use-case, NM completely manages /etc/resolv.conf and we don't have these problems. c) permissions: much of the time, you don't want to have to become root just to connect to a different network. However, most of the older tools required SUID or sudo or some other privilege escalation mechanism. Additionally, making that complete mechanism (executed by the user) SUID made security vulnerability windows larger. By using PolicyKit, we can grant users only the permissions they need, *or* grant them all permissions if they so desire. Thus, users can control networking with only the permissions they need, instead of having to grant the user access to an entire unix group (debian-style) or using SUID binaries (console-helper, Fedora style). These are some of the ways that NM is unfortunately more complex than previous script-based networking systems. A combination of user-driven requirements and security-based goals. Dan ___ 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
On Fri, 2009-07-31 at 09:49 +0200, Hadmut Danisch wrote: Alexander Sack wrote: Maybe you have something configured in /etc/network/interfaces? I think there was a report that keyfile connections are not considered if there is anything configured in ifupdown. Sure I have. Some things need to be done without graphical desktops and without trouble with interchanging between gnome and kde. How would one update or repair a system that does not start X for any reason? I try to deal with eth0 over /etc/network/interfaces on some machines, while using network manager for other connections such as UMTS mobile phones as a fallback, or VPN connections. Nevertheless, In my eyes it is inacceptable to choose such a black-box-design for a tool that's so vitally important as a network configuration. If it is just guessing and maybe try this, maybe try that, and no way to do proper and systematic debugging, and if network manager depends on so many other systems like notification, gnome or kde storage and other things that nobody can survey, then this is bad design. If you don't even know what it is doing and why, and what's going on. Sorry to say that, but network manager's design is pure bullshit. (And btw. it absolutely does not fit into the debian/ubuntu environment. Some time ago I issued a list of bugs/problems to the bug tracker, but the main author simply did not understand why some things need to be done and e.g. why four instead of just two configuration phases (pre-/post up and pre/post down) are needed for proper There are two reasons I've not yet added pre-up and pre-down. They are: 1) latency - do we expect NM to block the connect process on these scripts? If so, for how long? Should NM have a timeout for each script before it kills the script and proceeds? Should NM run them in parallel or in series? Each script's execution time makes the connection attempt longer. Badly written scripts can make the connection attempt never succeed, hence the need for a timer and killing of scripts that exceed that timer, if only to make it clear what is making the connection take longer than usual. 2) appropriateness a) many of the things people used to do in pre-up or pre-down scripts (munging routing tables, other stuff) are better done by *modifying the connection config itself* b) by the time any pre-down script will run, often the connection has already gone away (the AP is out of range, the cable has been unplugged already, etc) so any operation a pre-down script does *cannot* depend on the interface being up; it must gracefully fail. Common things people wanted to do here were unmount network shares; but since the script must always handle unexpected disconnects (which not all network file systems do well), you might as well just run this from post-down anyway. With 0.7 and multiple active devices, I'm not against *pre-down* scripts per-se, with the following caveats: 1) any pre-down operation is *advisory*, and the network interface that the script is called for may no longer be connected (associated, cable plugged in, etc). The scripts have to understand and account for that. 2) NM wouldn't wait more than 2 or 3 seconds for *all* pre-down operations to complete, before removing the IP addresses from the interface or routes from the routing table, because the scripts could be blocking a re-activation of the device to a new network. There is room for optimization here, ie if there is no other connection that the device can possibly activate at this time (the cable is still unplugged, or the rfkill switch is flipped, or the device was manually disconnected at the users' request) then the timeout can be extended somewhat, but certainly not to infinity. 3) This implies that pre-down scripts would have to run in parallel, so as to complete within the time given. The implementation for pre-down would re-factor the dispatcher to create a context for each operation, a UUID for which would be returned to NM in the response to the dispatch dbus method call. In NM, the NMDevice object would then start a timer of 2 or 3 seconds, and cancel that timer if the dispatcher signaled that it was done running the scripts. Otherwise, NM would instruct the dispatcher to cancel any running scripts in that context (via the UUID) if the timer fired before the dispatcher context was complete. NM would then proceed to remove the IP configuration information from the interface. Basically, allowing arbitrary pre-up and pre-down scripts opens the door to more bug reports and requires more diagnostics when stuff goes wrong. Thus, the requirement to *do it right* and ensure that when somebody writes these scripts incorrectly, that the user does not suffer the consequences, and that the guilty party (the script) is correctly identified. And, as always happens with timeouts, somebody will inevitably ask for the timeout to be extended because my use-case just takes a
Re: Network Manager does not find system wide connections
On Sat, 01 Aug 2009 00:58:22 +0100 Timothy Murphy gayle...@eircom.net wrote: Brian Morrison wrote: I do not believe that it was a good idea to use nm as a standard software tool in ubuntu. Works perfectly fine in Fedora You should say, It works fine for ME in Fedora. It is obvious from the Fedora newsgroups that many people have serious problems with NM. I should have added a tongue-in-cheek smiley. NM does actually do what I need, but I can see that it could be a problem if I were trying to do something more complex. Networking is a complex area. Everyone has a different need. I don't, personally, but I find the complete lack of documentation a major drawback with NM. That's true for many packages, the difficulty is that documentation needs stability and rapid development doesn't provide that. Fedora is about rapid development The whole point of Linux is that it is not magic; you are meant to be able to work out what is going on. There is a complex interaction between NM, dbus and various other things like udev, hal (becoming deprecated), PolicyKit etc. All of these packages do something different but in a way that isn't always clear. If anyone has any bright ideas about how to describe their interaction in a clear and simple manner please go ahead. I have not managed to work it out completely, so I suppose I should feel lucky that NM works for me. -- Brian Morrison bdm at fenrir dot org dot uk Arguing with an engineer is like wrestling with a pig in the mud; after a while you realize you are muddy and the pig is enjoying it. GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html ___ 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
Brian Morrison wrote: The whole point of Linux is that it is not magic; you are meant to be able to work out what is going on. There is a complex interaction between NM, dbus and various other things like udev, hal (becoming deprecated), PolicyKit etc. All of these packages do something different but in a way that isn't always clear. If anyone has any bright ideas about how to describe their interaction in a clear and simple manner please go ahead. I have not managed to work it out completely, so I suppose I should feel lucky that NM works for me. You clearly have a pretty good idea of how NM works. If you, or someone like you, could just pen a short account that would be immensely helpful. If there were mistakes they could quickly be corrected. I would love to know, for example, which files NM looks at, or which files one can usefully change. I just get hints from time to time in various postings but there doesn't seem to be anything written down. -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland ___ 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
Here is a quick, incomplete overview of the configs. I recommend playing with the program cnetworkmanager to see how the dbus works. The following Doc assumes Ubuntu 9.04 with Gnome This doc has no License feel free to edit, sell, hide, destroy, distribute. User-settings Note - only the first person logged into the system has access to user-settings.(needs verification) user settings are stored in the directory ~/.gconf/system/networking/connections/[num] and ~/.gconf/system/networking/wireless/networks -(note:someone please differentiate the two folders) -each number is a folder representing a connection(Ethernet, wifi, cellular, etc) -most these settings can be changed through system---Preferences---Network Connections The preferred method to view these settings is through gcong-editor( most those settings can be changed through the Network-Manager GUI and that is the preferred method) Applications---Accessories--Terminal u...@user-laptop:~$ gconf-editor system---networking---networking | |--connections | |--wireless #* System settings -These connections are available to all users and before xserver loads(needs verification) -System connections are stored in /etc/NetworkManager/system-connections/ # Fun facts *go to system---Preferences---Network Connections -To make a user setting available as a system setting *highlight connection, select edit, and check box Available to all users(bottom corner) -If a connection is not a wan and will only be used for local access(aka. never get default route) *highlight connection, select edit, select tab ipv4 settings, select routes, check box use connection for resource on its network *note:you can also add custom routes to be added in this area On Sat, Aug 1, 2009 at 7:14 AM, Timothy Murphy gayle...@eircom.net wrote: Brian Morrison wrote: The whole point of Linux is that it is not magic; you are meant to be able to work out what is going on. There is a complex interaction between NM, dbus and various other things like udev, hal (becoming deprecated), PolicyKit etc. All of these packages do something different but in a way that isn't always clear. If anyone has any bright ideas about how to describe their interaction in a clear and simple manner please go ahead. I have not managed to work it out completely, so I suppose I should feel lucky that NM works for me. You clearly have a pretty good idea of how NM works. If you, or someone like you, could just pen a short account that would be immensely helpful. If there were mistakes they could quickly be corrected. I would love to know, for example, which files NM looks at, or which files one can usefully change. I just get hints from time to time in various postings but there doesn't seem to be anything written down. -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ 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
Alexander Sack wrote: Maybe you have something configured in /etc/network/interfaces? I think there was a report that keyfile connections are not considered if there is anything configured in ifupdown. Sure I have. Some things need to be done without graphical desktops and without trouble with interchanging between gnome and kde. How would one update or repair a system that does not start X for any reason? I try to deal with eth0 over /etc/network/interfaces on some machines, while using network manager for other connections such as UMTS mobile phones as a fallback, or VPN connections. Nevertheless, In my eyes it is inacceptable to choose such a black-box-design for a tool that's so vitally important as a network configuration. If it is just guessing and maybe try this, maybe try that, and no way to do proper and systematic debugging, and if network manager depends on so many other systems like notification, gnome or kde storage and other things that nobody can survey, then this is bad design. If you don't even know what it is doing and why, and what's going on. Sorry to say that, but network manager's design is pure bullshit. (And btw. it absolutely does not fit into the debian/ubuntu environment. Some time ago I issued a list of bugs/problems to the bug tracker, but the main author simply did not understand why some things need to be done and e.g. why four instead of just two configuration phases (pre-/post up and pre/post down) are needed for proper network management. It is obvious that network manager was designed by desktop people writing just another graphical toy deeply interweaved with all that complex desktop APIs, but without administration and network experience. My advice is to throw it away and completely rewrite from scratch. At least for debian and ubuntu. network manager is really lousy software. regards 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
Hadmut Danisch a écrit : Alexander Sack wrote: Maybe you have something configured in /etc/network/interfaces? I think there was a report that keyfile connections are not considered if there is anything configured in ifupdown. Sure I have. Some things need to be done without graphical desktops and without trouble with interchanging between gnome and kde. How would one update or repair a system that does not start X for any reason? NetworkManager's system connections do NOT depend on X. My advice is to throw it away and completely rewrite from scratch. I had some problems with NetworkManager myself, so I am looking forward to your rewrite. Please keep us posted on your progress, thanks! ___ 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
On Fri, Jul 31, 2009 at 09:49:45AM +0200, Hadmut Danisch wrote: Alexander Sack wrote: Maybe you have something configured in /etc/network/interfaces? I think there was a report that keyfile connections are not considered if there is anything configured in ifupdown. Sure I have. Some things need to be done without graphical desktops and without trouble with interchanging between gnome and kde. How would one update or repair a system that does not start X for any reason? I try to deal with eth0 over /etc/network/interfaces on some machines, while using network manager for other connections such as UMTS mobile phones as a fallback, or VPN connections. Pleaes contribute proactively and confirm that removing stuff from there fixes the keyfile for you. Otherwise you waste everyones time here. Sorry to say that, but network manager's design is pure bullshit. It is ok to express your opinion, but it does not belong in this thread for sure. - Alexander ___ 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
Alexander Sack wrote: Pleaes contribute proactively and confirm that removing stuff from there fixes the keyfile for you. Otherwise you waste everyones time here. Removing stuff from /etc/network/interfaces was the first step I tried for debugging. Currently my /e/n/i contains auto lo eth0 iface lo inet loopback ... iface eth0 inet static ... and nothing else. The problems I have with network-manager on that machine are related to an GSM device (UMTS mobile phone connected through USB cable). I also tried removing anything but the lo configuration, and it did not fix the problem. 1. I do not see how an /e/n/i containing configs for lo and eth0 could cause nm's trouble with gsm or other connections. 2. Even if so, nm should behave similar for configurations put in the user's individual desktop settings or in the system wide settings. The problem occurs with the system wide setting only. 3. Even if my configuration was wrong in any way and would make using GSM connections unusable with nm, then nm should not offer me the configuration assistant for the mobile phone at login time if a system wide configuration already exists. 4. I, btw., cannot understand why killing nm-system-settings causes nm to take down eth0 even if eth0 is not managed by nm but by /e/n/i. How can nm be configured to deal with particular types of interfaces only (e.g. GSM, VPN) and keep it's fingers from eth0? This boils down to the problem, that the nm-system-settings manager for whatever reason does not find its configuration. Even if my /e/n/i was wrong or incompatible, nm should behave consistantly and issue any usefull warning or debugging messages. It is ok to express your opinion, but it does not belong in this thread for sure. What would be the appropriate thread to express that nm suffers from severe mis-design? I do not believe that it was a good idea to use nm as a standard software tool in ubuntu. regards 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
On Fri, Jul 31, 2009 at 5:19 PM, Hadmut Danisch had...@danisch.de wrote: Alexander Sack wrote: Pleaes contribute proactively and confirm that removing stuff from there fixes the keyfile for you. Otherwise you waste everyones time here. Removing stuff from /etc/network/interfaces was the first step I tried for debugging. Currently my /e/n/i contains auto lo eth0 iface lo inet loopback ... iface eth0 inet static ... and nothing else. The problems I have with network-manager on that machine are related to an GSM device (UMTS mobile phone connected through USB cable). I also tried removing anything but the lo configuration, and it did not fix the problem. 1. I do not see how an /e/n/i containing configs for lo and eth0 could cause nm's trouble with gsm or other connections. 2. Even if so, nm should behave similar for configurations put in the user's individual desktop settings or in the system wide settings. The problem occurs with the system wide setting only. 3. Even if my configuration was wrong in any way and would make using GSM connections unusable with nm, then nm should not offer me the configuration assistant for the mobile phone at login time if a system wide configuration already exists. 4. I, btw., cannot understand why killing nm-system-settings causes nm to take down eth0 even if eth0 is not managed by nm but by /e/n/i. How can nm be configured to deal with particular types of interfaces only (e.g. GSM, VPN) and keep it's fingers from eth0? This boils down to the problem, that the nm-system-settings manager for whatever reason does not find its configuration. Even if my /e/n/i was wrong or incompatible, nm should behave consistantly and issue any usefull warning or debugging messages. It is ok to express your opinion, but it does not belong in this thread for sure. What would be the appropriate thread to express that nm suffers from severe mis-design? I do not believe that it was a good idea to use nm as a standard software tool in ubuntu. This is not a Ubuntu mailing-list. Go troll here http://ubuntuforums.org/showthread.php?t=527365. regards Hadmut ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ 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
On Fri, 31 Jul 2009 23:19:37 +0200 Hadmut Danisch had...@danisch.de wrote: I do not believe that it was a good idea to use nm as a standard software tool in ubuntu. Works perfectly fine in Fedora -- Brian Morrison bdm at fenrir dot org dot uk Arguing with an engineer is like wrestling with a pig in the mud; after a while you realize you are muddy and the pig is enjoying it. GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html ___ 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
John Mahoney wrote: This is not a Ubuntu mailing-list. It was a direct reply to someone with an ubuntu.com mail address. Go troll here Insulting people who report and describe bugs and problems is exactly that type of ignorance that leads to such problematic software. ___ 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
On Fri, Jul 31, 2009 at 6:38 PM, Hadmut Danisch had...@danisch.de wrote: John Mahoney wrote: This is not a Ubuntu mailing-list. Sorry I did not realize. Still, this is not a Ubuntu specific mail-list. It was a direct reply to someone with an ubuntu.com mail address. Go troll here Insulting people who report and describe bugs and problems is exactly that type of ignorance that leads to such problematic software. I believe if you reported *bugs and problems* in a more gracious fashion you may get better results.The link was how to remove Network Manager in Ubuntu. I have no involvement in the creation of Network Manager, which happens to work great for me on Ubuntu. I will not comment further on this thread. ___ 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 (maybe found the reason)
I just got a little further with the problem and might have found a reason: I was wondering why the function get_connections() in the keyfile plugin was never called. I put some debugging code in the load_connections() function in system-settings/src/dbus-settings.c It shows: load_connections() is called several times. It's call for the first time, and the Ifupdown plugin gets called and initalized, and its get_connections() called. Then, later, load_connections() is called again, but does terminate due to this code: if (priv-connections_loaded) return; And then, after that, the keyfile plugin is loaded. But then, because of this code, load_connections does not call get_connections anymore. Thus, get_connections of the keyfile plugin is never called. regards ___ 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
Brian Morrison wrote: I do not believe that it was a good idea to use nm as a standard software tool in ubuntu. Works perfectly fine in Fedora You should say, It works fine for ME in Fedora. It is obvious from the Fedora newsgroups that many people have serious problems with NM. I don't, personally, but I find the complete lack of documentation a major drawback with NM. The whole point of Linux is that it is not magic; you are meant to be able to work out what is going on. -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland ___ 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
On Tue, 2009-07-28 at 20:23 +0200, Hadmut Danisch wrote:
Dan Williams wrote:
You'll want to start looking in the keyfile's
system-settings/plugins/keyfile/plugin.c dir_changed() function. That
function is called whenever inotify sees new files or changes in the
config directory. Does that function get called when the new file
appears there? Since the new keyfile appears at all, I assume that
means the keyfile plugin is loaded (otherwise nothing would get written
to that directory in the first place).
Eventually this code will be triggered in dir_chagned():
/* New */
connection = nm_keyfile_connection_new (name);
if (connection) {
NMConnection *tmp;
NMSettingConnection *s_con;
const char *connection_uuid;
NMKeyfileConnection *found = NULL;
Nope, dir_changed() is not called at all, neither at restart of the
nm-system-settings daemon, nor when a new file appears.
Ok, this is odd, and it indicates a problem either with glib or with
inotify. What glib version are you using? Are any of the files you're
changing hardlinked to something else?
Dan
___
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: Ok, this is odd, and it indicates a problem either with glib or with inotify. What glib version are you using? Are any of the files you're changing hardlinked to something else? Using current version of Ubuntu 9.04, libc6 is 2.9-4ubuntu6 No hardlinked files. And, btw. the files exist before the system configuration manager is started. As far as I know programs are not triggered by notify about files that already exist. Question is why nm does not even find files that already exist. regards ___ 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
On Thu, 2009-07-30 at 19:45 +0200, Hadmut Danisch wrote: Dan Williams wrote: Ok, this is odd, and it indicates a problem either with glib or with inotify. What glib version are you using? Are any of the files you're changing hardlinked to something else? Using current version of Ubuntu 9.04, libc6 is 2.9-4ubuntu6 No hardlinked files. And, btw. the files exist before the system configuration manager is started. As far as I know programs are not triggered by notify about files that already exist. They are if the files change and a watch has been placed on the directory that contains the files. Is the keyfile plugin definitely getting loaded via /etc/NetworkManager/nm-system-settings.conf? Question is why nm does not even find files that already exist. Well, it certainly should if the keyfile plugin gets loaded by nm-system-settings. The function system-settings/plugins/keyfile/plugin.c :: read_connections() does this for you when the plugin gets initialized. Can you check to see whether read_connections() ever gets called? Dan ___ 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: Is the keyfile plugin definitely getting loaded via /etc/NetworkManager/nm-system-settings.conf? [main] plugins=ifupdown,keyfile [ifupdown] managed=false To verify this, I had also placed a debug message in G_MODULE_EXPORT GObject * nm_system_config_factory (void) in ./system-settings/plugins/keyfile/plugin.c which is successfully printed. So it looks as if the plugin is started. Well, it certainly should if the keyfile plugin gets loaded by nm-system-settings. The function system-settings/plugins/keyfile/plugin.c :: read_connections() does this for you when the plugin gets initialized. Can you check to see whether read_connections() ever gets called? Nope. I put a debug message into read_connections() at the very beginning of the procedure, but it was not printed. regards ___ 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
On Thu, Jul 30, 2009 at 09:19:27PM +0200, Hadmut Danisch wrote: Dan Williams wrote: Is the keyfile plugin definitely getting loaded via /etc/NetworkManager/nm-system-settings.conf? [main] plugins=ifupdown,keyfile [ifupdown] managed=false Maybe you have something configured in /etc/network/interfaces? I think there was a report that keyfile connections are not considered if there is anything configured in ifupdown. - Alexander ___ 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
Hadmut Danisch a écrit : Dan Williams wrote: You'll want to start looking in the keyfile's system-settings/plugins/keyfile/plugin.c dir_changed() function. That function is called whenever inotify sees new files or changes in the config directory. Does that function get called when the new file appears there? Since the new keyfile appears at all, I assume that means the keyfile plugin is loaded (otherwise nothing would get written to that directory in the first place). Nope, dir_changed() is not called at all, neither at restart of the nm-system-settings daemon, nor when a new file appears. I filed a different, but similar problem here: http://bugzilla.gnome.org/show_bug.cgi?id=583025 ___ 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:
You'll want to start looking in the keyfile's
system-settings/plugins/keyfile/plugin.c dir_changed() function. That
function is called whenever inotify sees new files or changes in the
config directory. Does that function get called when the new file
appears there? Since the new keyfile appears at all, I assume that
means the keyfile plugin is loaded (otherwise nothing would get written
to that directory in the first place).
Eventually this code will be triggered in dir_chagned():
/* New */
connection = nm_keyfile_connection_new (name);
if (connection) {
NMConnection *tmp;
NMSettingConnection *s_con;
const char *connection_uuid;
NMKeyfileConnection *found = NULL;
Nope, dir_changed() is not called at all, neither at restart of the
nm-system-settings daemon, nor when a new file appears.
regards
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
On Sat, 2009-07-25 at 01:13 +0200, Hadmut Danisch wrote:
Hi,
maybe someone can give me a hint about where to start debugging:
I am using Ubuntu 9.04 on several machines. On some machines Network
Manager works as expected when making connections system wide available
with the connection editor: It puts a file into
/etc/NetworkManager/system-connections. When starting
nm-connection-editor, they appear as connections, and they can be used
as normal.
But then on two of my machines this does not work. When setting
connections to system wide availability, it puts a file into
/etc/NetworkManager/system-connections as well, but then does not find
it again, as if the file would not exist. Network connections are not
configured, and nm-connection-editor does not find it (i.e. does not
display the connection).
I wrote a little tool to fetch connections from dbus. It works on those
machines where nm works, but it returns an emtpy list of connections on
those machines where it doesn't.
debugging with strace showed that nm-system-connections does not look at
all into /etc/NetworkManager/system-connections at all. Reading the
source code is almost pointless, highly complex without any comments,
source code of the quality 'virtually unreadable'.
Depends on your point of view; yes, more comments and explanation of
theory are needed (especially in the public API). But the processes are
also quite complex, and a familiarity with GObject and some of the
technologies used (PolicyKit, GObject, dbus-glib) is assumed.
You'll want to start looking in the keyfile's
system-settings/plugins/keyfile/plugin.c dir_changed() function. That
function is called whenever inotify sees new files or changes in the
config directory. Does that function get called when the new file
appears there? Since the new keyfile appears at all, I assume that
means the keyfile plugin is loaded (otherwise nothing would get written
to that directory in the first place).
Eventually this code will be triggered in dir_chagned():
/* New */
connection = nm_keyfile_connection_new (name);
if (connection) {
NMConnection *tmp;
NMSettingConnection *s_con;
const char *connection_uuid;
NMKeyfileConnection *found = NULL;
which creates a new keyfile connection from the file. It would be
useful to see if 'connection' is NULL after this, which indicates an
invalid file format, whcih would indicate a bug in the keyfile code.
Any chance you could dig down a bit more to see what's going on? Even
just setting a breakpoint on dir_changed() would be useful to ensure
it's getting triggered when a new keyfile gets created there.
Dan
I still could not figure out what makes the difference between those
machines where it works and those where it doesn't.
Any idea or hint?
regards
Hadmut
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
___
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
Hi,
Dan Williams wrote:
Depends on your point of view; yes, more comments and explanation of
theory are needed (especially in the public API). But the processes are
also quite complex, and a familiarity with GObject and some of the
technologies used (PolicyKit, GObject, dbus-glib) is assumed.
Well, my point of view is being a Unix/Linux user and admin for about
20 years. And from my point of view it is the wrong way to construct
such important software for basic functions such as network connectivity
in such a complex way that it is impossible to figure out a problem
with a simple strace call.
The problems with the opaque and unpredictable nature of network manager
and the lack of documentation and debugging functions do not qualify
nm as a tool for basic functions of the operating system in my eyes.
You'll want to start looking in the keyfile's
system-settings/plugins/keyfile/plugin.c dir_changed() function. That
function is called whenever inotify sees new files or changes in the
config directory. Does that function get called when the new file
appears there? Since the new keyfile appears at all, I assume that
means the keyfile plugin is loaded (otherwise nothing would get written
to that directory in the first place).
Eventually this code will be triggered in dir_chagned():
/* New */
connection = nm_keyfile_connection_new (name);
if (connection) {
NMConnection *tmp;
NMSettingConnection *s_con;
const char *connection_uuid;
NMKeyfileConnection *found = NULL;
I'll try that later this week. I'm busy today.
Any chance you could dig down a bit more to see what's going on? Even
just setting a breakpoint on dir_changed() would be useful to ensure
it's getting triggered when a new keyfile gets created there.
I'll do that, gimme some time.
regards
Hadmut
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
