GNOME Bugzilla – Bug 681666
vpnc should respect the normal vpnc configuration if possible
Last modified: 2013-08-21 10:13:08 UTC
Hi. I strongly dislike that one has to duplicate interface configurations for NM all the time. So may I suggest that you extend the vpnc plugin, so that it respects the normal vpnc configuration from /etc/vpnc/*.conf and offers the connections defined there. Of course these files are typically non-readable for the user, so they should only be shown and usable for a user if he has read access the files (which can be easily done for many users via group memberships or ACLs). Cheers, Chris.
Oh and also, NM should recongnise if one brings such connections up outside of NM (e.g. by a normal vpnc <connection-name>) and handle that gracefully. The same of course when stopping it outside of NM.
Oh... and IMHO, NM should never allow the user to edit any of the system wide config files... These should be handled outside of NM and only be used for reading/exporting connections.
Somebody could, in theory, enhance NM-vpnc to provide a NetworkManager system settings plugin that would read these files and create read-only connections for them, but that seems unlikely to happen unless somebody picks that task up. If that happens, this bug can be re-opened.
It's really disturbing... NM (and GNOME) apparently wants to have NM spread and be used by everyone... and yet, it is not even half finished to be usable, not to talk about countless bugs and problems. I guess you guys can't be that blind, that you don't see that NM receives a lot of criticism not to say hate amongst the user community and that many discussions at the distributions are ongoing on what one should do with it. Debian was only the most recent and, given NM's state, they took the right decision in prohibiting that "unrelated" packages (especially GNOME) depends on it. Now when people as I report the issues that prevent NM from at least being somewhat usable and acceptable at least on desktop systems (I don't want to talk about servers at all)... these are ignored and closed away. Do you really think that this policy will end-users make accept NM more? Also the policy of making NM more and more an unavoidable MUST will surely not lead distros to give in and force a unusable system on their users - it's rather NM that will be kicked out completely at some point. Now VPNC is obviously only one and the lesser important of all integration issues that you have all over the places, ranging from ifupdown in Debian to the "connection" providers like strongswan, etc. pp.
(In reply to comment #0) > So may I suggest that you extend the vpnc plugin, so that it respects the > normal vpnc configuration from /etc/vpnc/*.conf and offers the connections > defined there. I'm personally not against enabling you to *optionally* use the /etc/vpnc configuration, but after all I don't think it is such a great idea. Theoretically, if you want to use /etc/vpnc, you wouldn't need to use NetworkManager to connect to the the VPN (just to step out from interfering with your connection). Therefore the particular feature you would like to see is just one of possible solutions. Sadly you can't point to a developer and tell him to fix your VPN issues by either of those solutions, unless you're his employer. NetworkManager's VPN code works for the most basic use cases and that's it. While it is good that you are interested in the issue *enough to visit bugzilla*, we would also need someone interested *enough to get the code done and accepted*. > Of course these files are typically non-readable for the user, so they should > only be shown and usable for a user if he has read access the files (which can > be easily done for many users via group memberships or ACLs). This would bring up serious security issues as the user would be feeding the privileged vpnc binary with data. I don't think vpnc is ready for that. Therefore this doesn't sound acceptable to me. (In reply to comment #4) > NM (and GNOME) apparently wants to have NM spread and be used by everyone... NetworkManager is an open source software project just like others, developed by community consisting of both company-paid and volunteer developers/contributors. Gnome is another project that depends on NetworkManager just like other projects do. > and yet, it is not even half finished Like any other open source project. If you came to help us, you're most welcome. If you came to yell at us, we'll simply ignore you. > to be usable, not to talk about countless bugs and problems. As above, you are free to help us with many things from running NetworkManager and reporting problems to regularly submitting patches. Or you are free to write your own replacement software if that sounds better for you. > I guess you guys can't be that blind, that you don't see that NM receives a lot > of criticism Every successful project receives a *lot* of criticism. > not to say hate And hate. > amongst the user community and that many > discussions at the distributions are ongoing on what one should do with it. We are not blind. Each of us have our own reasons to work on NetworkManager. We are aware of many bugs and unaware of many others. > Debian was only the most recent and, given NM's state, they took the right > decision in prohibiting that "unrelated" packages (especially GNOME) depends on > it. Link, please. Reducing hard dependencies where possible is generally a good thing. It should be done regardless of the software quality. > Now when people as I report the issues that prevent NM from at least being > somewhat usable and acceptable at least on desktop systems (I don't want to > talk about servers at all)... these are ignored and closed away. As you said, NetworkManager has *many* issues to be solved and we are closing bug reports that are not likely to be solved. There's no need to be offended by that. > Do you really think that this policy will end-users make accept NM more? Yes. In my opinion proper maintainance of NetworkManager bugzilla already helped to improve our community picture during the past year. > Also the policy of making NM more and more an unavoidable You're in the wrong bugzilla for that. There are distribution bugzillas for issues with making a specific software avoidable or unavoidable. Here we just maintain the upstream project. > MUST will surely not lead > distros to give in and force a unusable system on their users - it's rather NM > that will be kicked out completely at some point. If NetworkManager is kicked out from distributions, that would most probably mean there's a better replacement. That would be a great news! That's how open source works. But guess what, the opposite is happening. > Now VPNC is obviously only one and the lesser important of all integration > issues that you have all over the places, Anyone is free to help in reasonable ways. > ranging from ifupdown in Debian to We recently agreed that the upstream project doesn't have resources to maintain distribution-specific issues. Please contact Debian maintainers for help. > the "connection" providers like strongswan, etc. pp. The Strongswan plugin is not part of the NetworkManager project, as well as a couple of other plugins. Feel free to contact their maintainers. Keeping the bug RESOLVED/WONTFIX as there's apparently no developer willing to solve this issue. But we might start a FAQ for issues like this one.