The good and bad of Linux's NetworkManager

January 8, 2014

I have a conflicted relationship with NetworkManager that gives me rather divided opinions of it. The short version is that sometimes it's good and other times it's terrible, depending mostly on what sort of machine you're using it on (by choice or otherwise).

Where NetworkManager is good is on graphical machines with relatively simple network configurations, especially if they move between networks. This is typical for 'plug it into the network and do DHCP' desktops and for laptops in general. In most distributions, NM is going to be by far the easiest way to manage roving between wired networking and one or more wireless networks, possibly with VPNs on top of them. Although there are rough edges, especially in Gnome 3 and derived desktops, everything is generally easily discoverable and manageable without hassle or long reads of manual pages.

(I'm sure you can build a suite of tools that work just as well as NM. The great advantage of NM on a graphical machine like this is that someone has already done all of the work for you.)

Where NetworkManager is bad is on servers or on machines with complex networking configurations (where by this I mean things like bridged VLANs with policy based routing and per-network firewall rules, nailed up IPSec tunnels, and so on). On servers without graphics and with static network configurations, NetworkManager is overkill, over-complication at boot time, and hard to manage. While I'm not intrinsically opposed to setting up networks through commands instead of configuration files, NetworkManager's command line programs come across very much as underdocumented and incomplete afterthoughts.

(Also, defaults like 'interfaces are not enabled until someone logs in' are completely wrong for servers and apparently too hard-coded for people like Red Hat to change.)

Given that people are using NetworkManager by default on distributions aimed at servers, I find its current limitations there to be extremely irritating. It wouldn't take all that much work to make NetworkManager fully usable in a server environment and with the right features it could actually offer some interesting capabilities that you can't get easily today.

(For instance NetworkManager knows right away when link status goes away or comes back on an Ethernet interface. There are server environments where that would be very handy to know and to react to.)

There are also simple things that NetworkManager could add to make itself much more useful in a complex server environment. The easiest one is to the option to run a command for you when a specific network came up or went down, which would give people with complex needs a hook where they could take care of things that NetworkManager can't handle itself. I don't think that NetworkManager ever will add something like that, though, because its goal seem to be to completely own and control the machine's networking inside itself.

(Arguably this is the core problem with NetworkManager in sophisticated environments; in them it's never, ever going to be the sole arbiter over all networking. If it insists on all or nothing in practice the answer must be 'nothing'.)

Comments on this page:

By Zoltan Mezei at 2014-01-08 08:25:30:

In RHEL7 RedHat will try to improve some of the not-server-compatibile features of NetworkManager:

"A number of improvements have been made to NetworkManager to make it more suitable for use in server applications. In particular, NetworkManager no longer watches for configuration file changes by default, such as those made by editors or deployment tools. It allows administrators to make it aware of external changes through the nmcli connection reload command. Changes made through NetworkManager's D-Bus API or with the NetworkManager command-line tool, nmcli, are still effective immediately. The nmcli tool is introduced to allow users and scripts to interact with NetworkManager."


I'll at least give it a try.

By KC Marshall at 2014-05-12 13:29:29:

Scripts in /etc/NetworkManager/dispatcher.d/ should get called when network events happen, particularly interface up and interface down. The scripts receive two arguments: the interface name and the event. I have used scripts in this directory to start (or restart) some system services after the network has come up.

Written on 08 January 2014.
« The problem with compiling your own version of Python 3
Using different sshd options for different origin hosts »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jan 8 02:00:03 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.