{"id":66653,"date":"2022-08-23T09:01:26","date_gmt":"2022-08-23T09:01:26","guid":{"rendered":"https:\/\/www.cryptocabaret.com\/?p=66653"},"modified":"2022-08-23T09:01:26","modified_gmt":"2022-08-23T09:01:26","slug":"how-i-migrated-to-networkmanager-keyfiles-for-configuration","status":"publish","type":"post","link":"https:\/\/www.cryptocabaret.com\/?p=66653","title":{"rendered":"How I migrated to NetworkManager keyfiles for configuration"},"content":{"rendered":"

How I migrated to NetworkManager keyfiles for configuration<\/span>
\nDavid Both<\/a><\/span>
\nTue, 08\/23\/2022 – 03:00<\/span><\/p>\n

\n
Register<\/a> or Login<\/a> to like<\/div>\n
Register<\/a> or Login<\/a> to like<\/div>\n<\/div>\n
\n

NetworkManager was introduced in 2004 to make network configuration more flexible and dynamic. The old SystemV startup shell scripts, of which the interface configuration files were a part, were incapable of handling WiFi, wired, VPNs, broadband modems, and more\u2014or at least incapable of doing it quickly or efficiently.<\/p>\n

In a series of articles, I’ve written about why I’m a fan of NetworkManager and how I’ve used it. In part 1<\/a>, I looked at what NetworkManager does and some of the tools it provides for viewing network connections and devices. In that article, I mentioned that NetworkManager does not need interface configuration files for most hosts. However, it can create its own ini-style configuration files, and it recognizes the older network interface configuration files. The NetworkManager configuration files are officially called keyfiles. In part 2<\/a>, I looked at the deprecated interface configuration files and how to configure them, should you still be using them.<\/p>\n

Support for the deprecated ifcfg<\/code> files is no longer provided by default for new installations beginning with Fedora 36. It will continue to use them on systems that have been upgraded from earlier versions of Fedora to release 36\u2014at least for a while longer. Still, it is not a good idea at this late stage to depend on deprecated ifcfg<\/code> configuration files. So for part 3 of this series, I will demonstrate migrating existing interface configuration files to the NetworkManager keyfiles using the command-line tool provided. I will also look at using both command-line and GUI tools to create new keyfiles from scratch and compare them for ease of use.<\/p>\n

The migration is considerably more straightforward than it sounds. I used the nmcli connection migrate<\/code> command on the two systems I needed to migrate, one with a single network interface card (NIC) and one, my router\/firewall, with three NICs. After some extensive testing on a VM, it also worked perfectly the first time on both production hosts. That’s it: No other commands, options, or arguments required. And it is fast, taking much less than one second on both hosts.<\/p>\n

Why should I migrate my files?<\/h2>\n

Most of the restrictions of the old shell scripts lay in the structure\u2014or lack thereof\u2014of the ifcfg<\/code> files. NetworkManager introduced the new network connection keyfiles to overcome those issues. But until Fedora 36, it still would recognize the old ifcfg<\/code> configuration files. Now, NetworkManager no longer creates or supports ifcfg<\/code> files for new installations.<\/p>\n

I experimented with NetworkManager on a new Fedora 36 installation and could not convince it to use newly created ifcfg<\/code> files. It continued to treat the interfaces as dynamic host configuration protocol (DHCP) and obtain its configuration values from the DHCP server. The ifcfg<\/code> files are no longer supported on new installations because the NetworkManager-initscripts-ifcfg-rh<\/code> package is no longer installed. That package contains the tools needed to use the ifcfg<\/code> files. Hosts upgraded from older releases of Fedora will still have the NetworkManager-initscripts-ifcfg-rh<\/code> package installed, so it will, for the time being, be upgraded along with the rest of the installation to Fedora 36. This may not be true in the future.<\/p>\n

If you are using DHCP configuration for your network hosts, you do not need to migrate any ifcfg<\/code> files. In fact, you can simply delete them, if they still exist, and NetworkManager will deal with managing the network connections. Personally, I prefer to move deprecated files like these to an archive subdirectory in \/root<\/code> so that I can find them later, just in case.<\/p>\n

All hosts with static connections should be migrated. This usually includes servers, firewalls, and other hosts that may need to perform their network functions without the DHCP server being active. I have two hosts like this: my main server and my firewall\/router.<\/p>\n

My experiments<\/h2>\n

When NetworkManager officially deprecated the interface configuration files located in \/etc\/sysconfig\/network-scripts<\/code>, it did not immediately stop using them, but the update procedure did drop in a readme file, \/etc\/sysconfig\/network-scripts\/readme-ifcfg-rh.txt<\/code>. This short file states explicitly that the ifcfg<\/code>-style files are deprecated. It also provides a simple command that performs the migration for us.<\/p>\n

I suggest you read that file on your host and then experiment in a non-production environment. I used a VM for my experiments and learned a lot. Before I started making changes, I displayed the connection data shown below to get the current state of the network connection.<\/p>\n

\n
[<\/span>root@<\/span>myserver ~]<\/span># nmcli<\/span>
\nenp0s3: connected to Wired connection 1<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 \"Intel 82540EM\"<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 ethernet (<\/span>e1000)<\/span>, 08:00:27<\/span>:07:CD:FE, hw, mtu 1500<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 ip4 default
\n\u00a0 \u00a0 \u00a0 \u00a0 inet4 192.168.0.136\/<\/span>24<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 route4 192.168.0.0\/<\/span>24<\/span> metric 100<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 route4 default via 192.168.0.254 metric 100<\/span>

\nlo: unmanaged
\n\u00a0 \u00a0 \u00a0 \u00a0 \"lo\"<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 loopback (<\/span>unknown)<\/span>, 00:00:00:00:00:00, sw, mtu 65536<\/span>

\nDNS configuration:
\n\u00a0 \u00a0 \u00a0 \u00a0 servers: 192.168.0.52 8.8.8.8 8.8.4.4
\n\u00a0 \u00a0 \u00a0 \u00a0 domains: example.org
\n\u00a0 \u00a0 \u00a0 \u00a0 interface: enp0s3<\/div><\/div><\/pre>\n
I created a simple ifcfg<\/code> file that defines a static configuration on one of my VMs then tested it to verify that this static config worked properly. Here is the ifcfg-enp0s3<\/code> file I created for this testing:<\/p>\n
\n
TYPE<\/span>=Ethernet
PROXY_METHOD<\/span>=none
BROWSER_ONLY<\/span>=no
BOOTPROTO<\/span>=static
# HWADDR=08:00:27:07:CD:FE<\/span>
IPADDR<\/span>=192.168.0.95
PREFIX<\/span>=24<\/span>
DEFROUTE<\/span>=no
IPV4_FAILURE_FATAL<\/span>=no
IPV6INIT<\/span>=no
NAME<\/span>=enp0s3
ONBOOT<\/span>=yes<\/span>
DNS1<\/span>=192.168.0.52
DNS2<\/span>=8.8.8.8
AUTOCONNECT_PRIORITY<\/span>=-999<\/span>
DEVICE<\/span>=enp0s3<\/div><\/div><\/pre>\n
I commented out the hardware address in the ifcfg-enp0s3<\/code> file because it does not seem necessary. I tried it both ways, and it works just as well either way\u2014once I finally got it working at all. NetworkManager completely ignored the contents of this file until I installed the NetworkManager-initscripts-ifcfg-rh<\/code> package. After that, NetworkManager was able to set the network configuration from this\u00a0ifcfg-enp0s3<\/code> file.<\/p>\n
Then it was time to try the migration tool. I ran the command shown below to migrate the ifcfg<\/code> file to a keyfile.<\/p>\n
\n
[<\/span>root@<\/span>myserver system-connections]<\/span># nmcli connection migrate <\/span>
\nConnection 'Wired connection 1'<\/span> (<\/span>c7b11d30-522e-306f-8622<\/span>-527119911afc)<\/span> successfully migrated.
[<\/span>root@<\/span>myserver system-connections]<\/span># <\/span><\/div><\/div><\/pre>\n
This command took less than a second. It creates the new keyfile and then deletes the ifcfg<\/code> file. I suggest making a copy of the original ifcfg<\/code> file before running this migration tool. It created the \/etc\/NetworkManager\/system-connections\/enp0s3.nmconnection<\/code> file for my host. Without specifying a specific interface, this command will migrate all ifcfg<\/code> files located in \/etc\/sysconfig\/network-scripts<\/code>. If a host has multiple NICs and corresponding ifcfg<\/code> files, only some of which you want to migrate, you can specify a list of connections to migrate.<\/p>\n
The keyfiles can be modified using your favorite editor. I tried this by changing the IPADDR<\/code> entry and restarting NetworkManager just to make sure it worked. The\u00a0nmcli connection reload<\/code> command did not work for me. Making changes directly to the keyfiles using an editor is not recommended, but it does work. To be honest, many experienced sysadmins (like me) really prefer editing ASCII text configuration files directly, so\u2014recommended or not\u2014that is how I do things most of the time. I just like to know what is actually in those files so I can recognize when something is wrong with them. It helps with solving configuration problems.<\/p>\n
Doing it for real<\/h2>\n
After a day of experimenting so that I fully understood how this all works and how to recover in case it fails, I was ready to do it for real. I chose my main server for this initial attempt because it only has a single NIC, which will make it faster to get back online if there is a problem.<\/p>\n
First, I copied the file \/etc\/sysconfig\/network-scripts\/ifcfg-eno1<\/code> shown in below to \/root<\/code> as a backup. The nmcli connection migrate<\/code> command can make the conversion back from keyfile to ifcfg<\/code> file. But why bother when I can have an exact backup ready to drop back in?<\/p>\n
\n
HWADDR<\/span>=e0:d5:5e:a2:de:a4
TYPE<\/span>=Ethernet
PROXY_METHOD<\/span>=none
BROWSER_ONLY<\/span>=no
BOOTPROTO<\/span>=static
DEFROUTE<\/span>=yes<\/span>
IPADDR<\/span>=192.168.0.52
PREFIX<\/span>=24<\/span>
GATEWAY<\/span>=192.168.0.254
DOMAIN<\/span>=example.org
IPV6INIT<\/span>=no
DNS1<\/span>=192.168.0.52
DNS2<\/span>=8.8.8.8
DNS3<\/span>=8.8.4.4
IPV4_FAILURE_FATAL<\/span>=no
IPV6INIT<\/span>=no
PEERROUTES<\/span>=no
NAME<\/span>=\"enp0s31f6\"<\/span>
ONBOOT<\/span>=yes<\/span>
AUTOCONNECT_PRIORITY<\/span>=-999<\/span>
DEVICE<\/span>=\"enp0s31f6\"<\/span><\/div><\/div><\/pre>\n
After running the nmcli connection migrate<\/code> command, I verified that it emits the status line to indicate that the conversion took place, which it did. I next verified that the ifcfg<\/code> file was gone and the \/etc\/NetworkManager\/system-connections\/enp0s31f6.nmconnection<\/code> keyfile was in place:<\/p>\n
\n
[<\/span>connection]<\/span>
id<\/span>=enp0s31f6
uuid<\/span>=abf4c85b-57cc-4484<\/span>-4fa9-b4a71689c359
type<\/span>=ethernet
\nautoconnect-priority=-999<\/span>
\ninterface-name=enp0s31f6

[<\/span>ethernet]<\/span>
\nmac-address=E0:D5:5E:A2:DE:A4

[<\/span>ipv4]<\/span>
address1<\/span>=192.168.0.52\/<\/span>24<\/span>,192.168.0.254
dns<\/span>=192.168.0.52;8.8.8.8;8.8.4.4;
\ndns-search=example.org;
\nignore-auto-routes=true<\/span>
method<\/span>=manual

[<\/span>ipv6]<\/span>
\naddr-gen-mode=stable-privacy
method<\/span>=ignore
\nnever-default=true<\/span>

[<\/span>proxy]<\/span><\/div><\/div><\/pre>\n
This file will not be used until the NetworkManager is restarted or the host is rebooted. I first restarted NetworkManager and then checked the result, as shown below. The network configuration looks correct:<\/p>\n
\n
[<\/span>root@<\/span>myserver ~]<\/span># nmcli<\/span>
\nenp0s31f6: connected to enp0s31f6
\n\u00a0 \u00a0 \u00a0 \u00a0 \"Intel I219-V\"<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 ethernet (<\/span>e1000e)<\/span>, E0:D5:5E:A2:DE:A4, hw, mtu 1500<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 ip4 default
\n\u00a0 \u00a0 \u00a0 \u00a0 inet4 192.168.0.52\/<\/span>24<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 route4 default via 192.168.0.254 metric 100<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 route4 192.168.0.0\/<\/span>24<\/span> metric 100<\/span>

\nlo: unmanaged
\n\u00a0 \u00a0 \u00a0 \u00a0 \"lo\"<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 loopback (<\/span>unknown)<\/span>, 00:00:00:00:00:00, sw, mtu 65536<\/span>

\nDNS configuration:
\n\u00a0 \u00a0 \u00a0 \u00a0 servers: 192.168.0.52 8.8.8.8 8.8.4.4
\n\u00a0 \u00a0 \u00a0 \u00a0 domains: example.org
\n\u00a0 \u00a0 \u00a0 \u00a0 interface: enp0s31f6<\/div><\/div><\/pre>\n
After a complete reboot, I verified the network configuration again, and it looked identical to the output above. With that working, I removed the NetworkManager-initscripts-ifcfg-rh<\/code> package and rebooted again, just because it can’t hurt to verify everything.<\/p>\n
Once I knew that the migration tool works on one of my production systems, and an important one at that, I was ready to do this on my firewall\/router, the one with three NICs. I ran the same nmcli connection migrate<\/code> command on that host and verified the results. After ensuring all was working correctly, I used DNF to remove the NetworkManager-initscripts-ifcfg-rh<\/code> package from both production hosts. And I tested with a couple more reboots of each host just to ensure nothing got borked during the removal of the initscripts<\/code> package.<\/p>\n<\/p>\n
\n
More Linux resources<\/div>\n
\n
Linux commands cheat sheet<\/a><\/div>\n
Advanced Linux commands cheat sheet<\/a><\/div>\n
Free online course: RHEL technical overview<\/a><\/div>\n
Linux networking cheat sheet<\/a><\/div>\n
SELinux cheat sheet<\/a><\/div>\n
Linux common commands cheat sheet<\/a><\/div>\n
What are Linux containers?<\/a><\/div>\n
Our latest Linux articles<\/a><\/div>\n<\/p><\/div>\n<\/p><\/div>\n
What if I don’t have ifcfg files?<\/h2>\n
New installations of Fedora don’t create any type of network interface configuration files. The default is for NetworkManager to handle network interfaces as DHCP connections. So you don’t need to do anything for hosts that use DHCP to obtain their network configuration information.<\/p>\n
However, you may need to create a static configuration for some new hosts even when you don‘<\/b>t have a deprecated ifcfg<\/code> file to migrate.<\/p>\n
Reverting to DHCP<\/h2>\n
Reversion to the use of DHCP is easy. Just remove the keyfile for the desired connection from \/etc\/NetworkManager\/system-connections\/<\/code> and restart the NetworkManager. Remove<\/i> can mean moving the file somewhere else or just deleting it.<\/p>\n
In preparation for my next series of experiments in creating new keyfiles, I moved the enp0s31f6.nmconnection<\/code> keyfile to \/root<\/code> and restarted NetworkManager.<\/p>\n
Creating new keyfiles<\/h4>\n
Although the old ip<\/code> command can still be used to modify network interface settings in a live environment, those changes are not persistent after a reboot. Changes made using NetworkManager tools such as nmcli\u00a0<\/code>or nmtui<\/code>, the GUI NetworkManager connection editor (nm-connection-editor<\/code>), and your favorite text editor are persistent. The connection editor is available for Fedora on the system tray for each of the desktops I tried\u2014Xfce, Cinnamon, LXDE, KDE Plasma\u2014and probably the rest of the desktops I haven’t yet tried.<\/p>\n
Text editor<\/h4>\n
Assuming you are familiar with the keyfile structure, syntax, and variables, creating or modifying keyfiles from scratch is possible with just an ASCII text editor. As much as I appreciate and use that capability, using one of the three tools provided is usually much simpler.<\/p>\n
Using nmtui<\/h4>\n
The nmtui<\/code> tool (NetworkManager Text User Interface) is my second choice for a tool in this trio. I find the interface cumbersome, unattractive, and not intuitive. This tool is not installed by default, and I probably would not have installed it if I were not writing this article.<\/p>\n
However, it does work, and it created a keyfile for me that was essentially identical to the one created by the GUI Connection Manager I discuss below. The only differences I found\u00a0 (using the diff<\/code> command, of course) were the timestamp field in the file and one different selection I intentionally made when configuring the connection. The interface does provide some clues about the data you need to provide to create a working keyfile.<\/p>\n
Start this tool by entering the command nmtui<\/code> on the command line. In general, the arrow keys allow movement between the fields on the displayed pages, and the Enter<\/strong> key selects an item to modify or add. The Page Up\/Page Down<\/strong> keys scroll the page. Select Edit a connection<\/b> and press Enter<\/b> to create a new keyfile.<\/p>\n
\n
  \"A<\/div>\n
Image by: <\/span><\/p>\n
(David Both, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
After wending my way through the interface, I arrived at the Edit Connection page. It was not clear to me from this interface that the CIDR prefix should be appended to the IP address, but I did that anyway, and it worked. Fill in the appropriate data on this page to configure the interface. Notice that I have disabled IPV6.<\/p>\n
\n
  \"The<\/div>\n
Image by: <\/span><\/p>\n
(David Both, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
Next, scroll down to the bottom of the page using the keyboard and press OK<\/b> to save the keyfile. The keyfile is saved immediately, but NetworkManager must be restarted to activate this file, whether new or changed. Although this is not my favorite interface for creating and managing NetworkManager keyfiles, I plan to use it when the GUI Connection Editor is unavailable, such as when working on a remote host.<\/p>\n
Using nmcli<\/h4>\n
I have used the nmcli<\/code> tool (Network Manager Command Line Interface) to configure an interface in the past, and this tool also works very well. I just like it the least because it requires the most typing and reading of the man page and online references. Executing the command immediately creates the interface configuration file in the \/etc\/NetworkManager\/system-connections\/<\/code> directory.<\/p>\n
The command shown below adds the needed keyfile, just like the other tools.<\/p>\n
\n
[<\/span>root@<\/span>myserver system-connections]<\/span># nmcli connection add connection-name enp0s3-Wired ifname enp0s3 type ethernet ipv4.addresses 192.168.0.136\/24 ipv4.gateway 192.168.0.254 ipv4.dns 192.168.0.254,8.8.8.8,8.8.4.4 ipv4.dns-search example.org ipv6.method disabled <\/span>
\nConnection 'ethernet-enp0s3'<\/span> (<\/span>67d3a3c1-3d08-474b-ae91-a1005f323459)<\/span> successfully added.
[<\/span>root@<\/span>myserver system-connections]<\/span># cat enp0s3-Wired.nmconnection <\/span>
[<\/span>connection]<\/span>
id<\/span>=ethernet-enp0s3
uuid<\/span>=67d3a3c1-3d08-474b-ae91-a1005f323459
type<\/span>=ethernet
\ninterface-name=enp0s3

[<\/span>ethernet]<\/span>

[<\/span>ipv4]<\/span>
address1<\/span>=192.168.0.136\/<\/span>32<\/span>,192.168.0.254
dns<\/span>=192.168.0.52;8.8.8.8;8.8.4.4;
\ndns-search=example.org;
method<\/span>=manual

[<\/span>ipv6]<\/span>
\naddr-gen-mode=stable-privacy
method<\/span>=disabled

[<\/span>proxy]<\/span>
[<\/span>root@<\/span>myserver system-connections]<\/span># <\/span><\/div><\/div><\/pre>\n
One of the assistance tools available while using nmcli connection add<\/code> is the Bash tab-completion sequence that shows the available subcommands:<\/p>\n
\n
[<\/span>root@<\/span>myserver system-connections]<\/span># nmcli connection add <\/tab><\/tab><\/span>
\nautoconnect \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ifname \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv6.dhcp-send-hostname
\ncon-name \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv4.addresses \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv6.dhcp-timeout
\nconnection.auth-retries \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv4.dad-timeout \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv6.dns
\nconnection.autoconnect \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv4.dhcp-client-id \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv6.dns-options
\nconnection.autoconnect-priority \u00a0 \u00a0ipv4.dhcp-fqdn \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv6.dns-priority
\nconnection.autoconnect-retries \u00a0 \u00a0 ipv4.dhcp-hostname \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv6.dns-search
\nconnection.autoconnect-slaves \u00a0 \u00a0 \u00a0ipv4.dhcp-hostname-flags \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv6.gateway
\nconnection.dns-over-tls \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv4.dhcp-iaid \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv6.ignore-auto-dns
\nconnection.gateway-ping-timeout \u00a0 \u00a0ipv4.dhcp-reject-servers \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv6.ignore-auto-routes
\nconnection.id \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv4.dhcp-send-hostname \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv6.ip6-privacy
\nconnection.interface-name \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv4.dhcp-timeout \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv6.may-fail
\nconnection.lldp \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv4.dhcp-vendor-class-identifier \u00a0ipv6.method
\nconnection.llmnr \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv4.dns \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv6.never-default
\nconnection.master \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv4.dns-options \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv6.ra-timeout
\nconnection.mdns \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv4.dns-priority \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv6.required-timeout
\nconnection.metered \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv4.dns-search \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv6.route-metric
\nconnection.mud-url \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv4.gateway \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv6.routes
\nconnection.multi-connect \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv4.ignore-auto-dns \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv6.route-table
\nconnection.permissions \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv4.ignore-auto-routes \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv6.routing-rules
\nconnection.read-only \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv4.may-fail \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv6.token
\nconnection.secondaries \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv4.method \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0master
\nconnection.slave-type \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv4.never-default \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 match.driver
\nconnection.stable-id \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv4.required-timeout \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0match.interface-name
\nconnection.timestamp \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv4.route-metric \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0match.kernel-command-line
\nconnection.type \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv4.routes \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0match.path
\nconnection.uuid \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv4.route-table \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 proxy.browser-only
\nconnection.wait-device-timeout \u00a0 \u00a0 ipv4.routing-rules \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 proxy.method
\nconnection.zone \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv6.addresses \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 proxy.pac-script
help<\/span> \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv6.addr-gen-mode \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 proxy.pac-url
\nhostname.from-dhcp \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv6.dhcp-duid \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 slave-type
\nhostname.from-dns-lookup \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ipv6.dhcp-hostname \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 tc.qdiscs
\nhostname.only-from-default \u00a0 \u00a0 \u00a0 \u00a0 ipv6.dhcp-hostname-flags \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 tc.tfilters
\nhostname.priority \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ipv6.dhcp-iaid \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 type<\/span>
[<\/span>root@<\/span>myserver system-connections]<\/span># nmcli connection add <\/span><\/div><\/div><\/pre>\n
I typically prefer the command line for most tasks. However, the complexity of getting the syntax and options of this command correct means that I must always use the man page and research the command before I issue it. That takes time. And it still complained about things I missed or got incorrect. Even when it did not throw an error, it created keyfiles that worked poorly, if at all. For example, the connection worked when I would SSH out from the test VM, but I could not SSH into the test VM. I am still not sure what the problem was, but that keyfile had the wrong CIDR prefix for the IP address. I eventually got the command correct by referring to the example on the manual page nmcli-examples(7)<\/b>.<\/p>\n
When this is the only available method, I can do it, but it is my least preferred tool.<\/p>\n
Using the GUI NetworkManager connection editor<\/h4>\n
I have used one of my laptops for parts of this section to show both wired and wireless connections. Although I typically prefer command-line tools, I like this GUI NetworkManager connection editor tool best of all the three available tool options. It is easy to use, intuitive, provides fast access to any configuration item that would ever be needed, and is directly available itself in the desktop system tray of all the desktops I have tried.<\/p>\n
Just right-click on the network icon, the one that looks like a pair of computers, in the system tray. Then choose Edit Connections.<\/b><\/p>\n
\n
  \"A<\/div>\n
Image by: <\/span><\/p>\n
(David Both, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
This opens the connection editing window, as pictured below. Double-click the desired connection from the connection list, usually Wired Connection 1<\/code> or a WiFi SSID. The illustration below shows both wired and wireless connections open for editing on one of my laptops. I have never needed to edit a wireless connection because the ones I connect to always use DHCP for configuration. It is possible to require static addressing for wireless connections, but I have never encountered that.<\/p>\n
\n
  \"Two<\/div>\n
Image by: <\/span><\/p>\n
(David Both, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
The Ethernet<\/b> tab of the Editing Wired Connection 1 dialog window shows the device name enp111s0<\/code> for this laptop. In most cases, nothing on this page needs to be changed.<\/p>\n
Back on my VM, I changed the Method<\/b> field from Automatic (DHCP)<\/b> to Manual<\/b>. I added the IP Address, the CIDR prefix, and the default route (gateway) I want for this host. I also added three DNS servers and the search domain. These are the minimum configuration variables needed for a network connection. They are also the same ones defined in the interface configuration files and the previous keyfiles. The device name for this NIC is enp0s3<\/code>. Here is\u00a0<\/i>the configuration for the wired connection using the GUI NetworkManager connection editor tool.<\/p>\n
\n
  \"The<\/div>\n
Image by: <\/span><\/p>\n
(David Both, CC BY-SA 4.0)<\/p>\n<\/div>\n<\/article>\n
Another option available for the Method<\/b> field is Disabled.<\/b> I set the IPV6 to Disabled<\/strong> since I don’t use IPV6.<\/p>\n
After setting these values, clicking the Save<\/b> button creates the new keyfile immediately. Making changes to existing keyfiles is just as easy. However, NetworkManager must be restarted for these configuration changes to take effect.<\/p>\n
In terms of the amount of time and work involved in creating new NetworkManager keyfiles, the GUI Connection Editor is far better than the other options. It provides an easy-to-use interface with enough information about the data required to be helpful.<\/p>\n
Conclusions<\/h2>\n
Fedora 36 changes the equation for using the old-style, deprecated interface configuration files. For new installations of Fedora 36, those files will not work unless the NetworkManager-initscripts-ifcfg-rh<\/code> package is explicitly installed. This is a warning sign that all support for those deprecated ifcfg<\/code> scripts will be completely ignored in the future.<\/p>\n
Fortunately, the migration from any existing ifcfg<\/code> scripts is trivially easy, and creating new ones is not much more difficult using one of the three tools available. I prefer the GUI NetworkManager connection editor tool because it is clear and easy. I can use the nmtui<\/code> tool, which does the same thing as the GUI version but has a somewhat clunkier user interface. I try not to use the nmcli<\/code> tool if I can help it. It does work but is cumbersome and takes a lot of reading and experimentation to get the correct command syntax and all of the right arguments to create a fully usable keyfile.<\/p>\n
So go ahead and migrate now. I did, and it was easy.<\/p>\n<\/div>\n
\n
Interface configuration files may not be supported in Fedora much longer, but migrating to NetworkManager is easier than you might think.<\/p>\n<\/div>\n
\n
\n
  \"A<\/div>\n
Image by: <\/span><\/p>\n
Opensource.com<\/p>\n<\/div>\n<\/article>\n<\/div>\n
\n
Linux<\/a><\/div>\n
Sysadmin<\/a><\/div>\n<\/p><\/div>\n
What to read next<\/div>\n
\n
Get started with NetworkManager on Linux<\/a><\/div>\n
A sysadmin’s guide to network interface configuration files<\/a><\/div>\n<\/p><\/div>\n

\n        \"Creative<\/a>This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.<\/div>\n
\n
\n
Register<\/a> or Login<\/a> to post a comment.<\/div>\n<\/p><\/div>\n<\/section>\n
Powered by WPeMatico<\/a><\/small><\/p>\n","protected":false},"excerpt":{"rendered":"
How I migrated to NetworkManager keyfiles for configuration David Both Tue, 08\/23\/2022 – 03:00 Register or Login to like Register or Login to like NetworkManager was introduced in 2004 to make network configuration more flexible and dynamic. The old SystemV startup shell scripts, of which the interface configuration files were a part, were incapable of […]<\/p>\n","protected":false},"author":1,"featured_media":66654,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[307],"tags":[],"class_list":["post-66653","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-open-source"],"_links":{"self":[{"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=\/wp\/v2\/posts\/66653","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=66653"}],"version-history":[{"count":0,"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=\/wp\/v2\/posts\/66653\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=\/wp\/v2\/media\/66654"}],"wp:attachment":[{"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=66653"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=66653"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cryptocabaret.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=66653"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}