9.14 Network Configuration Managers
There are several ways to automatically configure networks in Linux-based systems. The most widely used option on desktops and notebooks is NetworkManager. There is an add-on to systemd, called systemd-networkd, that can do basic network configuration and is useful for machines that don’t need much flexibility (such as servers), but it doesn’t have the dynamic capabilities of NetworkManager. Other network configuration management systems are mainly targeted for smaller embedded systems, such as OpenWRT’s netifd, Android’s ConnectivityManager service, ConnMan, and Wicd.
We’ll briefly discuss NetworkManager because it’s the one you’re most likely to encounter. We won’t go into a tremendous amount of detail, though, because after you see the basic concepts, NetworkManager and other configuration systems will be much easier to understand. If you’re interested in systemd-networkd, the systemd.network(5) manual page describes the settings, and the configuration directory is /etc/systemd/network.
9.14.1 NetworkManager Operation
NetworkManager is a daemon that the system starts upon boot. Like most daemons, it does not depend on a running desktop component. Its job is to listen to events from the system and users and to change the network configuration based on a set of rules.
When running, NetworkManager maintains two basic levels of configuration. The first is a collection of information about available hardware devices, which it normally collects from the kernel and maintains by monitoring udev over the Desktop Bus (D-Bus). The second configuration level is a more specific list of connections: hardware devices and additional physical and network layer configuration parameters. For example, a wireless network can be represented as a connection.
To activate a connection, NetworkManager often delegates the tasks to other specialized network tools and daemons, such as dhclient, to get internet layer configuration from a locally attached physical network. Because network configuration tools and schemes vary among distributions, NetworkManager uses plug-ins to interface with them, rather than imposing its own standard. There are plug-ins for the both the Debian/Ubuntu and Red Hat–style interface configuration, for example.
Upon startup, NetworkManager gathers all available network device information, searches its list of connections, and then decides to try to activate one. Here’s how it makes that decision for Ethernet interfaces:
- If a wired connection is available, try to connect using it. Otherwise, try the wireless connections.
- Scan the list of available wireless networks. If a network is available that you’ve previously connected to, NetworkManager will try it again.
- If more than one previously connected wireless network is available, select the most recently connected.
After establishing a connection, NetworkManager maintains it until the connection is lost, a better network becomes available (for example, you plug in a network cable while connected over wireless), or the user forces a change.
9.14.2 NetworkManager Interaction
Most users interact with NetworkManager through an applet on the desktop; it’s usually an icon in the upper or lower right that indicates the connection status (wired, wireless, or not connected). When you click the icon, you get a number of connectivity options, such as a choice of wireless networks and an option to disconnect from your current network. Each desktop environment has its own version of this applet, so it looks a little different on each one.
In addition to the applet, there are a few tools that you can use to query and control NetworkManager from your shell. For a very quick summary of your current connection status, use the nmcli command with no arguments. p. 242 You’ll get a list of interfaces and configuration parameters. In some ways, this is like ip except that there’s more detail, especially when you’re viewing wireless connections.
The nmcli command allows you to control NetworkManager from the command line. This is a somewhat extensive command; in fact, there’s an nmcli-examples(5) manual page in addition to the usual nmcli(1) manual page.
Finally, the utility nm-online will tell you whether the network is up or down. If the network is up, the command returns 0 as its exit code; it’s nonzero otherwise. (For more on how to use an exit code in a shell script, see Chapter 11.)
9.14.3 NetworkManager Configuration
NetworkManager’s general configuration directory is usually /etc/NetworkManager, and there are several different kinds of configuration. The general configuration file is NetworkManager.conf. The format is similar to the XDG-style .desktop and Microsoft .ini files, with key-value parameters falling into different sections. You’ll find that nearly every configuration file has a [main] section that defines the plug-ins to use. Here’s a simple example that activates the ifupdown plug-in used by Ubuntu and Debian:
[main]
plugins=ifupdown,keyfile
Other distribution-specific plug-ins are ifcfg-rh (for Red Hat–style distributions) and ifcfg-suse (for SuSE). The keyfile plug-in that you also see here supports NetworkManager’s native configuration file support. When using the plug-in, you can see all of the system’s known connections in /etc/NetworkManager/system-connections.
For the most part, you won’t need to change NetworkManager.conf because the more specific configuration options are found in other files.
Unmanaged Interfaces
Although you may want NetworkManager to manage most of your network interfaces, there will be times when you want it to ignore interfaces. For example, most users wouldn’t need any kind of dynamic configuration on the localhost (lo; see Section 9.16) interface, because its configuration never changes. You also want to configure this interface early in the boot process, because basic system services often depend on it. Most distributions keep NetworkManager away from localhost.
You can tell NetworkManager to disregard an interface by using plug-ins. If you’re using the ifupdown plug-in (for example, in Ubuntu and Debian), add the interface configuration to your /etc/network/interfaces file and then set the value of managed to false in the ifupdown section of the NetworkManager.conf file:
[ifupdown]
managed=false
For the ifcfg-rh plug-in that Fedora and Red Hat use, look for a line like this in the /etc/sysconfig/network-scripts directory that contains the ifcfg-* configuration files:
NM_CONTROLLED=yes
If this line is not present or the value is set to no, NetworkManager ignores the interface. In the case of localhost, you’ll find it deactivated in the ifcfg-lo file. You can also specify a hardware address to ignore, like this:
HWADDR=10:78:d2:eb:76:97
If you don’t use either of these network configuration schemes, you can still use the keyfile plug-in to specify the unmanaged device directly inside your NetworkManager.conf file using its MAC address. Here’s an example showing two unmanaged devices:
[keyfile]
unmanaged-devices=mac:10:78:d2:eb:76:97;mac:1c:65:9d:cc:ff:b9
Dispatching
One final detail of NetworkManager configuration relates to specifying additional system actions for when a network interface goes up or down. For example, some network daemons need to know when to start or stop listening on an interface in order to work correctly (such as the secure shell daemon discussed in the next chapter).
When a system’s network interface status changes, NetworkManager runs everything in /etc/NetworkManager/dispatcher.d with an argument such as up or down. This is relatively straightforward, but many distributions have their own network control scripts so they don’t place the individual dispatcher scripts in this directory. Ubuntu, for example, has just one script named 01ifupdown that runs everything in an appropriate subdirectory of /etc/network, such as /etc/network/if-up.d.
As with the rest of the NetworkManager configuration, the details of these scripts are relatively unimportant; all you need to know is how to track down the appropriate location if you need to make an addition or change (or use Netplan and let it figure out the location for you). As ever, don’t be shy about looking at scripts on your system.