Hey. I hope this won't become too much of a rant, but IMHO we long ago crossed the point where something (well actually many things) would have needed to be seriously done. My grandparents always warned me about UNIX programs written in capital letters ;-). Seriously... I have nothing against a high level daemon that manages underlying network control systems (ifupdown, vpnc, ppp, strongswan, openswan, openvpn) but not the way NM does it, especially as it doesn't work correctly at all edges and ends. Until "recently" all that wasn't a big problem, because one was easily able to simply not install NM, but nowadays more and more packages start to depend on it (of those I know, most notably gnome-core) or at least use it's functionality to determine whether one is online or not. I know there was recently the discussion about recommends and meta-package, this is _not_ about repeating it. And as said above, in principle I like the idea of having a high level system that exposes networking for users and also software. Where do I see the main problems of NM? 1) In parts it has some security issues. - At least the default setting seems to be that any user can connect to any network. This alone may already be a security risk, or method to intentionally or accidentally circumvent things (like a VPN). It may well be that one can disable this, but at least the default seems to allow it. - At least the network connections from /etc/network/interfaces are exported to the normal user, even if that user cannot read that file. A typical example is that I put in network connections that the normal user should not be able to enable, or even connections that require credentials in /etc/network/interfaces. So NM should only export a connection, if the user would be able to read the necessary config files. 2) NM's design seems to be wrong. AFAIU (I didn't look into too much depth, though), NM is based on the design idea, that it replaces all network management and configuration from the respective distros. So when NM brings up a connection, it does not simply invoke some e.g. ifscheme wlan0-myHomeNet ifup wlan0 but directly invokes wpa_supplicant. That's IMHO quite awful, as you loose all the proper integration of ifupdown by gaining nothing. Moreover it complicates the code, as now NM needs to come with its own /e/n/interfaces parsers (which will everytime the something changes there) The same problem exists for configuration. NM tries to be its own canonical location for network configuration. In most places (the quite defunct /etc/network/interfaces support is the only exception I'd know of) it does not even export the connections from the canonical locations (examples: vpnc, strongswan, ppp) In my opinion, NM should: - export any connections from the real canonical places (e.g. /etc/network/interfaces, /etc/vpnc/*, /etc/ppp/peers/* and /etc/chatscripts/*, /etc/ipsec.conf and /etc/ipsec.d/*, etc. pp.) - only if a user doesn't find something there, a per user connection configuration should be set up. - I know, NM supports system wide configuration, too, but IMHO that should be dropped altogether and NM should also not try to edit the real canonical configuration. If someone want's a system wide IPsec connection, that should e.g. go to strongswan's /etc/ipsec.conf. 3) ifupdown integration is really bad ifupdown is really a good framework, it offers hooks and and is properly integrated in many packages. Well this is similar to (2). a) NM (AFAIU) doesn't really use ifupdown for controlling, it merely parses /etc/network/interfaces b) barely nothing from /etc/network/interfaces is supported, some bugs I've noticed: - the dns-* options from resolvconf don't work at all - wireless connections aren't exported if wpa-key-mgmt is not set (which there should be no need to in many cases), and for WPA-EAP it seems to generally not work. - the same is the case with many advanced options (ap_scan, etc. pp.) c) when NM is running, I cannot use ifup foo / ifdown foo / ifconfig <parameters>... well I can.. but then everything gets really messed up d) when I disable wireless in NM it really blocks it, so I can't use it with ifupdown. Now one can rfkill unblock then... but why? and even if one does...NM seems to get confused again. 4) upstream more or less doesn't want to support these scenarios... Already many months ago, I've opened a Debian bug, that some /e/n/i connections are simply not shown by NM. Given that this is actually an upstream issue, I've reported this (and most other problems I've mentioned before, especially the poor ifupdown integration but also the ideas about adding support for all the canonical configurations) upstream. I guess the conclusion is: "this won't be implemented". It seems the "desired" scenario for NM is that /e/n/i is empty and everything is handled Apple™ like: hide-everything, don't support advanced setups. So,... at least I want to continue our wonderful ifupdown and also the other native tools (ppp, ipsec, etc. pp.) because these are what I need to use when I need to debug something or do something advanced. I'd blindly guess that many other would want that, too. Personally, I'm not to inclined to get deeper into NM development as I stumbled into too many other projects recently (and at least the few parts of its code I've looked at seemed a bit messy). So what are the opinions of the others? Will we continue to live with the current disease? Are the alternatives better integrated? Could we get discourage NMs use if necessary? Or will we just mothball ifupdown silently and slowly (as it's replaced by NM). Cheers, Chri
Attachment:
smime.p7s
Description: S/MIME cryptographic signature