Lead Image © godrick, 123RF.com

Lead Image © godrick, 123RF.com

NetworkManager at the command line

Building Bridges

Article from ADMIN 39/2017
By
A variety of approaches are available for customizing the network on modern Linux systems. Here, we focus on the NetworkManager tool.

NetworkManager should be familiar to most readers, because many of today's Linux distributions use it to configure the network. One reason for changing from legacy init scripts to a system such as NetworkManager is the more complex boot process where many actions run in parallel thanks to the use of systemd. The old init scripts are not geared for this, which could cause problems in some setups. NetworkManager eliminates these problems.

Applet for the Desktop

The tool usually takes the form of an applet on the desktop that gives you access to WiFi networks in addition to configuring wired networks. When the user clicks on the applet, the available wireless networks are shown alongside the existing network devices. All settings for access to networks can be configured via the applet. Plugins also let you set up mobile or InfiniBand connections, and even VPNs, via this approach. For access to devices in the immediate vicinity, the tool can also configure Bluetooth devices and set up corresponding connections. The same also applies to the usage of virtual adapters, such as VLANs, bridges, or bonding and teaming devices.

The use of applets is probably out of the question for server operations and even for power users. But, there are two tools for the command line: nmtui and nmcli. The former offers a simple text interface for rudimentary service configuration tasks, whereas the latter is a comprehensive tool that can be used to configure all service functions. Alternatively, there is a D-Bus API [1] for addressing the services in your own applications.

Objects as a Basis

In this article, I will look at the nmcli command-line tool, because it is likely to be used by most admins for configuring the NetworkManager service. To use the tool properly, it is important to understand that NetworkManager works with objects. One of these objects is the connections type. This defines connection profiles with which the service works. These profiles contain all the properties of a connection and the device used for the connection. The information contained in the connections can be stored in various formats. The administrator can define what format to use via plugins in the /etc/NetworkManager/NetworkManager.conf configuration file.

On Red Hat-based systems, for example, you will see the ifcfg-rh plugin, which ensures that NetworkManager stores the connection profiles in the network configuration files below /etc/sysconfig/network-scripts/, from where it also loads them to enable a connection. If you do not want to place a particular connection under the control of the service, you can define this exception in the configuration file of the device used for the connection with the NM_CONTROLLED = no option. If this option is not used, all the options in the NetworkManager configuration files are used. They go well beyond the scope of the options used by the traditional init scripts. However, compatibility with these scripts is given so that conventional network connections can still be managed with the legacy mechanisms.

Compatibility Issues

However, there are some exceptions, so you will need to clarify very early in your system planning whether you want to rely on the legacy init scripts or the newer NetworkManager. Some NetworkManager options are not understood by the traditional init scripts. They primarily include the options for setting up 802.1x-based connections, but also some other settings.

A detailed overview about different options in the scripts you use, and which of them are not compatible with legacy init scripts, can be found in the man page for nm-settings-ifcfg-rh.

To get started, you need to know which devices exist on your system:

# nmcli device status
DEVICE TYPE STATE CONNECTION
wls1 wifi connected --
enp0s25 ethernet connected --
lo loopback unmanaged --

To configure the Ethernet card with a static IPv4 address and a gateway, you would invoke the following command:

# nmcli con add type ethernet con-name office ifname enp0s25 ip4 192.168.0.111 gw4 192.168.0.1
Connection 'office' (e2abff10-6085-4be5-b327-820379b5e527) successfully added.

Immediately the NetworkManager creates a profile for the new connection in the /etc/sysconfig/network-scripts/ifcfg-office file. If you want to customize the connection at a later date, you can do so with nmcli:

# nmcli con mod office ipv4.dns 8.8.8.8

The change is immediately reflected in the profile. Each connection type has certain properties. If you cannot remember all of them, Bash completion can be a big help. If you just type in ipv4 from the last command and press the tab key twice, you will see all of the valid settings for the adapter's IPv4 configuration.

To see the complete profile, call the following command:

# nmcli -p con show office

And, finally, to enable the connection, just run this command:

# nmcli con up office

If you want to edit the configuration file for the profile manually, you have to remember that the change requires a reload of the profile before it takes effect on the function:

# nmcli con reload office

Using this call

# nmcli con del office
Connection 'office' (e2abff10-6085-4be5-b327-820379b5e527) successfully deleted.

will get rid of the connection again.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • What's New in NetworkManager
    The current version of NetworkManager introduces some changes to this de facto standard for configuring the network stack on Linux. We look at the configuration changes you need to make to keep the network running smoothly.
  • Systemd network management and container handling
    Version 219 of the controversial systemd init system introduces a number of comprehensive changes. We take a closer look at the innovations in network management and container handling.
  • networkd and nspawn in systemd
    Version 219 of the controversial init system, systemd, comes with a few major changes. We look at the new features in network management and container handling.
  • Spanning Tree Protocol
    Ethernet is so popular because it simply works and is inexpensive. However, the administration side looks a bit more complicated: For the network to run smoothly, the admin might need to make important decisions about the Spanning Tree protocol.
  • Software-defined networking with Windows Server 2016
    Windows Server 2016 takes a big step toward software-defined networking, with the Network Controller server role handling the centralized management, monitoring, and configuration of network devices and virtual networks. This service can also be controlled with PowerShell and is particularly interesting for Hyper-V infrastructures.
comments powered by Disqus