RHEL 9 networking: Say goodbye to ifcfg-files, and hello to keyfiles

In my first Red Hat Certified Engineer (RHCE) fast-track training in 2002, we were using Red Hat Linux 7.2, and I learned to love the network configuration files in /etc/sysconfig/network-scripts. Later, Red Hat Enterprise Linux (RHEL) 6 introduced NetworkManager (also known as ‘NM’). When reading the RHEL 9 release notes, this change stood out for me: 

By default, NetworkManager now uses the key file format to store new
connection profiles. Note that the ifcfg format is still supported. 

The details

In RHEL 9, /etc/sysconfig/network-scripts (also known as ifcfg files) will no longer be the primary storage for network configuration files. While the ifcfg style is still available, it is no longer the default location where NetworkManager stores new network profiles. Have a look:

[root@rhel9a ~]# NetworkManager --print-config
# NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf

[main]
# plugins=keyfile,ifcfg-rh
[...]
[root@rhel9a ~]#

This refers to the different storage locations like ‘keyfile’ and ‘ifcfg-rh’. It looks up key files first, and then the ifcfg-rh files. You can find details on key files in the NetworkManager docs and the RHEL 9 docs. NetworkManager looks for key files in various places, but this article focuses on the files in /etc/NetworkManager/system-connections.

With the default config, you can keep using ifcfg-rh files in /etc/sysconfig/network-scripts, but you need to be aware that:

• In the default config, NetworkManager will prioritize key files. For example, if a key file and an ifcfg-file both have an interface config with the same UUID, then NetworkManager will use the key file config for that interface.

• When creating new network interface configs with tools using the NetworkManager API, such as nmcli, nmtui, gnome-control-center, anaconda, cockpit, nmstate, the RHEL System Role for networking, or network-manager-applet, they will be deployed as key files.

While the ifcfg- and key file formats do not have the same syntax, they mostly represent similar data about the interface configuration. Here is a comparison of both formats:

How to change interface settings

Whether you decide to keep using ifcfg-rh files (although not recommended) or to use key files, you can change interface settings (like IPs) in either of these ways:

• Tool based: You can use graphical tools like nm-connection-editor or the `nmcli` command-line tool. An advantage is that these tools allow you to check your commands' syntax, in contrast to modifying the files directly. You can find some good examples in man nmcli, such as:

nmcli con mod enp2s0 ipv4.addr “10.0.0.4/24”
nmcli con down enp2s0
nmcli con up enp2s0

• File based: You can also use a text editor to edit the key file in /etc/NetworkManager/system-connections or the ifcfg-rh file in /etc/sysconfig/network-connections, and then notify NetworkManager of the changes. For example:

vi /etc/NetworkManager/system-connections/<name>.nmconnection
nmcli connection load \
  /etc/NetworkManager/system-connections/<name>.nmconnection
nmcli connection up filename \
  /etc/NetworkManager/system-connections/<name>.nmconnection

The ‘nmcli connection load [..]’ command will reload just one specific NetworkManager profile; alternatively, you can use ‘nmcli connection reload’ to reload all profiles or ‘nmcli general reload’ to reload settings in general; this behaves like a signal hangup (SIGHUP) to NetworkManager.

What happened to ifcfg-rh?

Historically, various Linux distributions have spread interface configurations over many places: Debian and its derivatives traditionally use /etc/network/interfaces, CentOS and related distros use /etc/sysconfig/network-scripts, and so on. With more distros adopting NetworkManager, keyfiles in /etc/NetworkManager/system-connections have become the canonical place for network connections on Linux.

This change landed in Fedora 33, and now it's in RHEL 9. New major versions of RHEL (like RHEL 9) are where heavy changes like this, things that could break existing scripts and workflows, can be implemented. Since RHEL's current plan is to provide 10 years of minor releases, it's smart to familiarize yourself with this change and start incorporating it into your code.

If you have further questions, please check this knowledgebase article, which we will update as new questions arise.