[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning


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

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).


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: