NetworkManager is a tool to configure the network on a Linux host. I am a NetworkManager developer and work at Red Hat. In my opinion the biggest value it provides is the API. That is what makes NetworkManager unique among other network configuration projects. Here is why.
Configuring the Network
To configure the local network on the host, you need a stateful process.
Configuring networking means to setup the Linux kernel and user space so that applications can use the network. This involves setting up network interfaces, addresses and routes, DNS and the system’s hostname, and more. For most scenarios a stateful service is necessary to monitor and re-configure the system. This is for example the case for DHCP (ISC’s dhclient), Wi-Fi (wpa_supplicant), IPv6 SLAAC (kernel itself or a user space daemon), bluetooth (bluez), ppp (pppd), and more. For example, if you write a shell script to configure a networking interface with DHCP, it needs to spawn a manager deamon like ISC’s dhclient or dhcpcd.
Today we have various software that aims to manage networking exhaustively. We have NetworkManager, which is a freedesktop.org project. There is also ConnMan, netctl (on ArchLinux), systemd-networkd, wicd (unmaintained), wicked (on SUSE). Any of these will work well to setup networking on your machine.
Providing an API for other Tools
NetworkManager is more than just a tool to configure the network. Its main purpose is to provide an API for other applications.
Did you wonder why GNOME or KDE only has UI integration with NetworkManager? NetworkManager was created from the start as a configuration daemon that serves the needs of applications, independent from the UI. It is ahead of any other solution providing such an API, and that is why desktop environments integrate with it. It fits the requirements like no other. Most alternatives mentioned above don’t even have such an API as their explicit goal. Their focus is to configure the network. Of course, every program that is usable will have some form of API and a manner how to use it. But such APIs are often targeted directly towards a human, towards a user who edits a file, who invokes an ad-hoc command and who is around to react to with failures.
NetworkManager’s API aims to be used by other programs, the clients of NetworkManager. Some of these clients (GUIs) may directly target a human end user too. Or they provide integration with OpenStack or OpenShift, where the human administrator is much more detached from the host. When no human is around, it becomes critical that the current state of the system can be determined programmatically. The API is not only for configuration actions, but also to determine the current state of the system.
Generalist and Featureful
NetworkManager is a generalist and featureful and complex.
When your application relies on NetworkManager, then NetworkManager must be at least as portable as your application. That means, NetworkManager must be suitable for a wide range of environments and not only for the desktop. NetworkManager works well on the phone, the server, in a container, on a notebook and on a workstation. Likewise, NetworkManager must support a whole lot of use cases, technologies and features. The API must be powerful and ubiquitous. If there are shortcomings, then these problems are supposed to be fixable and should be fixed. Running NetworkManager on your phone or in your container is not out of scope, it is something that is supposed to work well and what is an explicit goal.
NetworkManager may not be the optimal solution in every scenario, yet. For example, on a BGP router with thousands of routes, there are still performance issues. Or running inside a container doesn’t work well with macvlan devices. Or NetworkManager running a DHCP server is simple but not very flexible. But most scenarios that you imagine are scenarios where NetworkManager wants to excel. The Linux kernel itself is the prime example of the benefits of being a generalist, and NetworkManager is also one.
This means NetworkManager is not a simple piece of software. But its complexity is there to provide features for other applications, so they themselves can be simpler. Solving hard problems once.
Integration of Tools
Using NetworkManager API allows the integration of tools.
Whether you use nmcli or nmtui on the command line, Cockpit, the GUIs, or Ansible, they all are just front ends for the same underlying configuration. And of course, you can write your own applications that uses NetworkManager’s API, and your application will naturally integrate with these other tools.
Wherever you have NetworkManager, it works and behaves the same. On RHEL and Fedora, you configure a server and the workstation using the same tools. Most Linux distributions provide NetworkManager. If you know how to configure NetworkManager on Ubuntu, you know how to configure networking on Fedora, too.
What’s Next?
NetworkManger also has issues and lacking features. Some people dislike it for being too large or complex, think it is not stable, or not suitable for anything except the desktop. NetworkManager is software, and like every software could be replaced by another piece of software. Should we instead replace it with some hypothetical, future alternative? I believe that it will be significantly simpler to incrementally improve NetworkManager, than to throw it away and start over.
In my opinion, the majority of shortcomings we face in free software comes down to lack of contributors and people. Under such circumstances, the solution for a problem is not to provide more alternatives, but to focus on making one solution work well.
One current area of focus is to integrate with Openstack, Openshift, CoreOS and dracut. I am also excited about the prospect of running NetworkManager on phones, like with UBPorts or Librem5.
NetworkManager is an active free software project. Let’s work together and run NetworkManager everywhere.