GNOME Bugzilla – Bug 681668
make NM correctly work with Debian's ifupdown system
Last modified: 2012-08-28 10:11:09 UTC
Hi. Marking this as severity blocker, as it makes using the traditional ifupdown system of Debian nearly impossible, if NM is in place, too. I know there's a plugin for iupfdown, but (and I don't want to step on anyone's toes) support seem to be very limited. Issues I've noted: 1) NM exports /etc/network/interfaces configuration (at least parts) to the ordinary user, even if that file is not readable by the ordinary user. IMHO, that's a security issue. Per default /etc/network/interfaces is world-readble, but it's not uncommon to make it readable by only root, some groups or others (via ACLs) when sensitive information is contained, typically when passwords for wireless connections are contained. NM at least exports the names of the interfaces (see (2) to the ordinary user, though. Cannot tell whether it exports more (i.e. passwords) as this seem to be broken, too, (see (3)). 2) Make it work with ifscheme. ifscheme is the standard tool in Debian to have different configurations for the same interfaces (especially common with WiFi), when managing all this via ifupdown. This works typically by having definitions in /etc/network/interfaces like wlan0-home or wlan0-work. 3) The most annoying bug is probably, what I've already described here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647620 NM seems to ignore all wifi interfaces in /etc/network/interfaces that have some key management in place (WPA and that like), it shows such however, that have no key management configured. Subsequently it also doesn't recognise such interfaces as being up/down, when I started them with ifup/down.. (and they work). This is also a main reason for the severity of this bug, as it basically prevents one from using ifupdown (which one needs to do though, because of (3), as all NM aware applications will think the network is down, and refuse their work. 4) Handle the case when connections are managed outside of NM. When I bring up/down interfaces outside of NM (with ifup/ifdown) this leads usually to all kinds of problems. Either NM doesn't recognise this at all (even though the connection is up), or the handling outside doesn't work anymore. Also, when I stop/start/restart NM itself than it confuse the system's network configuration, the ifaces that I brought up are no longer shown as configured in ifconfig but still somehow marked as being configured (but they don't work anymore). Cheers, Chris.
http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_modern_network_configuration_for_desktop says: "Keep configuration of "/etc/network/interfaces" as simple as the the following. auto lo iface lo inet loopback ". So for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647620 this recommendation from the Debian Reference is ignored as it is about using "managed=true so that it respects /etc/network/interfaces".
Hmm. Rereading it my last comment probably didn't make sense. Sigh.
a) Even if it would make sense,... I meant that's the whole point, that I don't want to put configuration into NM, but have the canonical location of network connections in the normal/usual system locations. And there are many reasons for that, imagine just, that you want all you faculties users to have some default connections available automatically in their system and you manage this somehow by some central configuration system (cfengine, puppet, etc.)... One does not want to handle that again for NM (and especially not for all possible users on a system that use NM), because on already handles it the normal way for other managed systems that don't use NM at all (servers, etc.) You'll notice that I've opened up several tickets (vpnc, ppp/modem connections, and also over at the strongswan guys NM plugin) to add functionality to respect and fully correctly handle the normal/traditional configuration for their respective connection types. Don't get me offensive or stepping on anyone's toes, but IMHO that was really a design error of NM to not make this the standard case (i.e. using the tradition configuration places when possible), but rather thinking every user sets the connections up manually in the GUI. It's fine to have this, of course, but that should always be only the 2nd choice. b) I AM using managed=true... otherwise things would even work less. Cheers, Chris.
> You'll notice that I've opened up several tickets (vpnc, ppp/modem connections, > and also over at the strongswan guys NM plugin) to add functionality to respect > and fully correctly handle the normal/traditional configuration for their > respective connection types. > Don't get me offensive or stepping on anyone's toes, but IMHO that was really a > design error of NM to not make this the standard case (i.e. using the tradition > configuration places when possible), but rather thinking every user sets the > connections up manually in the GUI. It's fine to have this, of course, but that > should always be only the 2nd choice. This is a common misinterpretation of the design of NetworkManager. The current NetworkManager branch (0.9.x) has its standard configuration in /etc/NetworkManager with connections in /etc/NetworkManager/system-connections. Currently, you can make it your second choice without any problem. It's up to the administrator. As for seamless integration with ifupdown, I don't have much to say about it other than that it won't work unless someone puts huge effort in it. But I'm afraid it is much easier to fix NetworkManager so that it doesn't need ifupdown at all (if it still does). This is exactly the same case as with ifcfg-rh. > 2) Make it work with ifscheme I am curious about specific usecases you would use ifscheme for. And ideas what needs to be done so that you don't need ifscheme at all :). I'm afraid I will have to close this bug report as it's a mixture of various not-very-related stuff unless someone using Debian/Ubuntu wants to take it. Could you please help me by opening specific reports for specific bugs that would be managable? Currently only (3) seems to be interesting at all unless someone wants to spend time tickling with NM-ifupdown-ifscheme-whatever integration.
Hi Pavel. (In reply to comment #4) > This is a common misinterpretation of the design of NetworkManager. > The current NetworkManager branch (0.9.x) has its standard configuration > in /etc/NetworkManager with connections in /etc/NetworkManager/system- > connections. Yeah sorry,.. I wasn't clear enough in my wording (or better with what I mean). I knew about the system configuration in these locations... But I think,... NM should (at first, respectively in addition) use (i.e. read, not write) the canonical configuration... - in Debian this is /etc/network/interfaces (well mainly) - in RedHat/SUSE you have some files in /etc/sysconfig - for strongswan it's /etc/ipsec.conf, /etc/ipsec.secrets and /etc/ipsec.d/* - for vpnc it's /etc/vpnc/ So the current design (as it seems to me) implies that NM considers it self the new central and _canonical_ network configuration. ( Admittedly, many (especially desktop) distros more or less disable their own systems, as they had to use NM and as this only works limited with the actual config systems (see André's comment on the Debian manual above). ) But I guess NM won't make lots of friends with this... And it also has the disadvantage of (usually) loosing functionally that the actual ("native") systems would provide... or even breaking them. E.g. there's another issue I haven't reported yet, which leads to the effect that I cannot ifup wlan0 anymore (wpa_supplicant crashes then), when I disabled wireless in NM,... pretty annoying to be honest. I know it from Debian,... there frequently large discussions (close to flame wars) pop up, on how much NM should be integrated... mainly because of all this. Well if things would just perfectly work,... and if NM would be just a handling layer above (in the Debian case:) ifupdown,... fully working with it, fully using it... then there would be no more reason for these discussions. > Currently, you can make it your second choice without any problem. It's up to > the administrator. Yeah,... but that would then be just another location (in addition to /etc/network/interfaces, /etc/vpnc/* and friends) I'd always have to maintain. > As for seamless integration with ifupdown, I don't have much to say about it > other than that it won't work unless someone puts huge effort in it. But I'm > afraid it is much easier to fix NetworkManager so that it doesn't > need ifupdown Yeah well,... as mentioned previously,... I really doubt NM will make many friends by "trying" to replace the native systems... > I am curious about specific usecases you would use ifscheme for. You have one wlan0 device in your /etc/network/interfaces.... but you may have many different networks/keys/etc. you connect to with that wlan0 device. Therefore you need ifscheme, to get many schemas (wlan0-<name>) with different configurations for the very same device. > And ideas what needs to be done so that you don't need ifscheme at all :). With the native Debian infrastrucutre, this is AFAIK now possible (though there exist some less popular similar tools to ifscheme). But as I mention below,... I guess NM wouldn't need to do a lot (if something at all) about it. > I'm afraid I will have to close this bug report as it's a mixture of various > not-very-related stuff unless someone using Debian/Ubuntu wants to take it. > Could you please help me by opening specific reports for specific bugs that > would be managable? Well I wouldn't know how... I mean we can split up the points (1), (2), (3) and (4) from above in separate points... But the mainpoint,... correctly parse /etc/network/interfaces and export only those connections the user would be able to "read" to the user remains... That would likely already fix (1) and (3). (2) might be a non issue at all (I just couldn't test it due to (3). ifscheme just extends the typical name of interfaces (e.g. wlan0) by -<name>. So there should bet not much work for NM here, unless perhaps noting, that not more than one wlan0-<name> connection can be up. I mentioned above, that NM already exports parts of my wlan0-<name> configs from /etc/network/interfaces... (but just those without any key management)... so maybe ifscheme+NM works out of the box. Closing that bug would be really a shame I think,... even if no-one finds who wants to spent time on these.... the issues still exist... With (1) being actually a security issue. I further cannot understand why you (in the light of this) lowered the severity. I think I'll need to request a CVE for this, once I have had a more detailed look at it. Redhat seems to have very differing policies on this,... I recently found a "hole" which even I would have considered not that important, where information was leaked to the user... and one of your colleagues immediately requested a CVE on it. ;) Best wishes, Chris.
> But I think,... NM should (at first, respectively in addition) use (i.e. read, > not write) the canonical configuration... > - in Debian this is /etc/network/interfaces (well mainly) > - in RedHat/SUSE you have some files in /etc/sysconfig NetworkManager has plugins for distribution-specific configuration formats. > - for strongswan it's /etc/ipsec.conf, /etc/ipsec.secrets and /etc/ipsec.d/* > - for vpnc it's /etc/vpnc/ This often may not be the right way to do that. You can file individual bug reports for this and you will get answers from individual developers. > So the current design (as it seems to me) implies that NM considers it self > the new central and _canonical_ network configuration. Exactly. > ( Admittedly, many (especially desktop) distros more or less disable their own > systems, as they had to use NM and as this only works limited with the actual > config systems (see André's comment on the Debian manual above). ) > But I guess NM won't make lots of friends with this... NM is a network configuration tool. And it's opensource. If it has bugs, they can be reported. If you want NetworkManager to make a lot of friends, patches welcome. > And it also has the disadvantage of (usually) loosing functionally that the > actual ("native") systems would provide... If network-scripts and ifupdown are the 'native' systems you are talking about, NM is gradually becoming a better alternative to them and already in many respects offers better functionality. > or even breaking them. Bug reports about specific interoperability are welcome. Patches even more so. > E.g. there's another issue I haven't reported yet, which leads to the effect > that I cannot ifup wlan0 anymore (wpa_supplicant crashes then), when I disabled > wireless in NM,... pretty annoying to be honest. Please do. > I know it from Debian,... there frequently large discussions (close to flame > wars) pop up, on how much NM should be integrated... mainly because of all > this. I can imagine. > Well if things would just perfectly work,... and if NM would be just a handling > layer above (in the Debian case:) ifupdown,... fully working with it, fully > using it... then there would be no more reason for these discussions. Utopia. > > Currently, you can make it your second choice without any problem. It's up to > > the administrator. > Yeah,... but that would then be just another location (in addition to > /etc/network/interfaces, /etc/vpnc/* and friends) I'd always have to maintain. That's why I prefer disabling the plugins and working with /etc/NetworkManager/system-connections in the keyfile format. But that's matter of personal preference. > > As for seamless integration with ifupdown, I don't have much to say about it > > other than that it won't work unless someone puts huge effort in it. But I'm > > afraid it is much easier to fix NetworkManager so that it doesn't > > need ifupdown > Yeah well,... as mentioned previously,... I really doubt NM will make many > friends by "trying" to replace the native systems... I realy doubt that NM would make *any* friends by being a useless layer on top of insufficient network configuration tools. > > I am curious about specific usecases you would use ifscheme for. > You have one wlan0 device in your /etc/network/interfaces.... but you may have > many different networks/keys/etc. you connect to with that wlan0 device. I'm using NetworkManager's connections for this. This is exactly what they were made for. > Therefore you need ifscheme, to get many schemas (wlan0-<name>) with different > configurations for the very same device. Thanks for describing your use case. > > And ideas what needs to be done so that you don't need ifscheme at all :). > With the native Debian infrastrucutre, this is AFAIK now possible (though there > exist some less popular similar tools to ifscheme). > But as I mention below,... I guess NM wouldn't need to do a lot (if something > at all) about it. > > > > I'm afraid I will have to close this bug report as it's a mixture of various > > not-very-related stuff unless someone using Debian/Ubuntu wants to take it. > > Could you please help me by opening specific reports for specific bugs that > > would be managable? > Well I wouldn't know how... I mean we can split up the points (1), (2), (3) and > (4) from above in separate points... > But the mainpoint,... correctly parse /etc/network/interfaces and export only > those connections the user would be able to "read" to the user remains... 'Correctly parse' is not a bug report. But specific bugreports about specific problems would be very useful. > That would likely already fix (1) and (3). Then please help us with testing and discover missing or broken stuff in the ifupdown plugin. > (2) might be a non issue at all (I just couldn't test it due to (3). > ifscheme just extends the typical name of interfaces (e.g. wlan0) by -<name>. > So there should bet not much work for NM here, unless perhaps noting, that not > more than one wlan0-<name> connection can be up. > > I mentioned above, that NM already exports parts of my wlan0-<name> configs > from /etc/network/interfaces... (but just those without any key management)... > so maybe ifscheme+NM works out of the box. Testing welcome. > Closing that bug would be really a shame I think,... Then I'm taking that same upon myself. We are hard trying to maintain bugzilla in a shape that actually helps us and enables us to help users. > even if no-one finds who > wants to spent time on these.... the issues still exist... Yes. They still exist and they should still be reported in an appropriate way with steps to reproduce, versions, specific information and so on. > With (1) being actually a security issue. I have no problem if you file it as a security issue with a reasonable proposed solution. > I further cannot understand why you (in the light of this) lowered the > severity. The whole bug report will be closed anyway. > I think I'll need to request a CVE for this, once I have had a more detailed > look at it. And please file a bug report too. > Redhat seems to have very differing policies on this,... I recently found a > "hole" which even I would have considered not that important, where information > was leaked to the user... and one of your colleagues immediately requested a > CVE on it. ;) Then do it or ask the Debian maintainers to do it for you. > Best wishes, > Chris. Thanks for your information. But I'm closing this bug with all due respect because it's unmaintainable and more like a general forum discussion than a bug report. I will be glad if you or anyone else file proper bug reports for these issues.
(In reply to comment #6) > NetworkManager has plugins for distribution-specific configuration formats. Yes,.. and that's in principle good,... but as I explained in this whole bug... at least the debian plugin doesn't work well. I just found other issues: NM is stopped, I bring up wlan if ifupdown,... now I start NM a) it kills my connection b) it doesn't connect itself anymore,... and I cannot click enable networking/wireless in the GNOME applet anymore. > This often may not be the right way to do that. You can file individual bug > reports for this and you will get answers from individual developers. #681666, #681667 and http://wiki.strongswan.org/issues/215 > > So the current design (as it seems to me) implies that NM considers it self > > the new central and _canonical_ network configuration. > > Exactly. Well I guess that's already a problem. I think it's highly unlikely the NM will really replace the native management system on all distros... > NM is a network configuration tool. And it's opensource. If it has bugs, they > can be reported. If you want NetworkManager to make a lot of friends, patches > welcome. ;-) I would have written some if a) I had time b) I knew about the inner workings of NM .... and I already stumbled into too many new open source projects recently,.. I can't bear another one. Anyway,... I hope you don't get my bugs as negative or offensive,... they're rather meant as help or at least as "I think this and that should work like so". :) > If network-scripts and ifupdown are the 'native' systems you are talking > about, > NM is gradually becoming a better alternative to them and already in many > respects > offers better functionality. Really,... I believe you'll run in a dead-end with that approach. There are so many programs out there, which somehow deal with networking and all have their own native configuration, just take the examples I've already provided, vpnc, strongswan, openswan,... they surely won't give up "their" configs... And I'd also say it's a long way till Debian (and derviates) will even think about replacing ifupdown... > > Yeah,... but that would then be just another location (in addition to > > /etc/network/interfaces, /etc/vpnc/* and friends) I'd always have to maintain. > > That's why I prefer disabling the plugins and working with > /etc/NetworkManager/system-connections > in the keyfile format. But that's matter of personal preference. Ok,.. now,... as you suggested I'll try to files smallish bugs in the next days :) I hope the ones for vpnc and ppp already do their job?! :) The strongswan one is probably not "your" business, as it's developed by strongswan itself (which may or may not be better ;) ). I don't think NM will change trying to "supersede" the distro's "native" tools just because I suggest... and after all... I'm not always right and it may prove the better solution in the end. But I think one should try to improve integration with them as far as possible, because they're still there and people still use them. And actually there are several other projects out there which seem to also potentially become "native" tools... (e.g. ipcfg).
> I think it's highly unlikely the NM will really replace the native management > system on all distros... I, personally, don't see much point in combining NetworkManager and legacy network scripts. > ;-) I would have written some if a) I had time b) I knew about the inner > workings of NM .... and I already stumbled into too many new open source > projects recently,.. I can't bear another one. Sure. > Anyway,... I hope you don't get my bugs as negative or offensive,... Nope. Your comments are perfectly valid. I would be only happy if there was someone into Debian and NetworkManager that would like to spend time on this. > Really,... I believe you'll run in a dead-end with that approach. My crystal ball shows different future from yours :). > There are so many programs out there, which somehow deal with networking and > all have their own native configuration, just take the examples I've already > provided, vpnc, strongswan, openswan,... they surely won't give up "their" > configs... That's probably a misunderstanding. We don't actually ask anyone to give up their configs. It is optional to use NetworkManager and its configuration to connect to VPN. But it is often convenient. > And I'd also say it's a long way till Debian (and derviates) will even think > about replacing ifupdown... It's actually only their decision wheter to stick with (IMO) insufficient 'ifupdown', migrate to NetworkManager or use both. If they want ifupdown and NetworkManager to integrate well, they have all the means to do that. Patches welcome. > Ok,.. now,... as you suggested I'll try to files smallish bugs in the next days > :) Great! > I hope the ones for vpnc and ppp already do their job?! :) > The strongswan one is probably not "your" business, as it's developed by > strongswan itself (which may or may not be better ;) ). I'm personally not involved in strongswan's code but I'm maintaining the strongswan package for Fedora and EPEL and I occasionally chat with the strongswan devs and file tickets in their bugtracker. > I don't think NM will change trying to "supersede" the distro's "native" tools > just because I suggest... and after all... I'm not always right and it may > prove the better solution in the end. I prefer whatever solution is maintainable. > But I think one should try to improve integration with them as far as possible, > because they're still there and people still use them. Anyone is welcome :). We are currently mostly focused on delivering features and stability which is already quite some work :).
I started splitting out small isolated issues to separate bugs: (1) from the initial report was split out to bug #682406.
(3) was split out into bug #682407 and bug #682408.
(4) was split out into bug #682409. I will point at all these bugs in a current discussion on the debian-devel mailing list. So even if the NM developers themselves don't have time to implement themselves now, I suggest keeping them open for the records, as someone may find time later to implement them.
> I will point at all these bugs in a current discussion on the debian-devel > mailing list. Thanks! > So even if the NM developers themselves don't have time to implement themselves > now, I suggest keeping them open for the records, as someone may find time > later to implement them. Greakt! I asked Dan to create a separate component for ifupdown bug reports (and the same for ifcfg-rh and ifnet). We appreciate any help with distro-specific plugins.
(In reply to comment #8) > I, personally, don't see much point in combining NetworkManager and > legacy network scripts. "legacy" would require that they're already planned to be phased out ;) > My crystal ball shows different future from yours :). Well I guess no one can tell for sure what will really happen, neither you nor I :) (and if you can, please tell me the next lottery numbers). I guess for now the best approach is what we've already done now, namely trying to improve integration as much as possible, for which reason I've filed the "small" bugs / enhancement ideas :) Thanks for creating the ipupdown/etc. components... I was already about to ask for that ;) Cheers, Chris.
Oh I forgot one thing; you've mentioned you'd open a bug at strongswan; I've already did that. See one of the comments above for the link.
(In reply to comment #13) > (In reply to comment #8) > > I, personally, don't see much point in combining NetworkManager and > > legacy network scripts. > "legacy" would require that they're already planned to be phased out ;) We are still trying to keep it easy for those who would like to take the burden of maintaining interoperability that we cannot afford for systems we don't work with. We are doing the same for people who want to use various tools together with NetworkManager. But the main project's objective is to be *the* network configuration subsystem. > > My crystal ball shows different future from yours :). > Well I guess no one can tell for sure what will really happen, neither you nor > I :) (and if you can, please tell me the next lottery numbers). Agreed. > I guess for now the best approach is what we've already done now, namely trying > to improve integration as much as possible, for which reason I've filed the > "small" bugs / enhancement ideas :) > > > Thanks for creating the ipupdown/etc. components... I was already about to ask > for that ;) Cheers.
(In reply to comment #14) > Oh I forgot one thing; you've mentioned you'd open a bug at strongswan; I've > already did that. See one of the comments above for the link. Thanks. I don't see it, unfortunately.
Somewhere hidden in commet #7: http://wiki.strongswan.org/issues/215 :)
Thanks.