The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.
For details on how to fill out this form, see the documentation.
To report an issue with this template, file an issue in the pgm_docs repo.
Migrate NetworkManager ifcfg profiles to keyfile
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
Summary
Migrate NetworkManager network connection profiles stored in ifcfg format to the keyfile format.
Owner
- Name: Beniamino Galvani, Fernando Fernández Mancera, Till Maas
- Email: <bgalvani@redhat.com>, <ferferna@redhat.com>, <till@fedoraproject.org>
Current status
- Targeted release: Fedora Linux 39
- Last updated: 2023-06-27
- [<will be assigned by the Wrangler> devel thread]
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
NetworkManager supports different formats to persist connection profiles to disk. On Fedora the two formats used are keyfile and ifcfg. The former stores connections in {/etc,/usr/lib,/run}/NetworkManager/system-connections in a format similar to INI files. Connections in ifcfg format are compatible with the legacy network scripts and are saved in /etc/sysconfig/network-scripts as a collection of shell variables. Not all connection types are supported by ifcfg, and NetworkManager always uses the keyfile format for unsupported types.
Since Fedora33, NetworkManager writes profiles by default in the keyfile format. Also, since Fedora36 the plugin to persist ifcfg files is included in a separate package (NetworkManager-initscripts-ifcfg-rh) and is not shipped in new installations.
The upstream NetworkManager project has recently declared the ifcfg plugin as deprecated. This means that the code will only receive bug fixes, and will not get new functionality such as supporting new properties. In Fedora, we plan to drop the plugin by Fedora 41.
With this change, existing profiles in ifcfg format will be automatically migrated to the native keyfile format via a migration service shipped with the NetworkManager-initscripts-ifcfg-rh package.
Benefit to Fedora
Until recently, both keyfile and ifcfg supported the same set of properties. With the ifcfg deprecation, new properties are only implemented for the keyfile plugin and not for ifcfg. When users try to set an unsupported property on a ifcfg profile, they get an error:
$ nmcli connection modify ethernet-enp1s0 link.tx-queue-length 1234 Error: Failed to modify connection 'ethernet-enp1s0': failed to update connection: The ifcfg-rh plugin doesn't support setting 'link'. If you are modifying an existing connection profile saved in ifcfg-rh format, please migrate the connection to keyfile using 'nmcli connection migrate c3f6f067-e1d5-4bb1-8d67-e09109253a79' or via the Update2() D-Bus API and try again.
At the moment there are only 4 unsupported properties but the list is going to increase with time. Furthermore, ifcfg support will be dropped in future versions of NetworkManager.
The benefit of this change is that users having ifcfg files will be migrated to the more modern and future-proof format supporting all the functionalities offered by NetworkManager.
Scope
- Proposal owners: introduce a migration service and ship it with the
NetworkManager-initscripts-ifcfg-rhpackage
- Other developers: N/A
- Release engineering: N/A
- Policies and guidelines: N/A
- Trademark approval: N/A
Upgrade/compatibility impact
The majority of users will not be impacted by the change. Only users that meet all the following criteria will be affected:
- the user is upgrading from a previous Fedora version
- the user has the the NetworkManager-initscripts-ifcfg-rh package installed
- the user has at least one connection profile stored in ifcfg format
Since keyfile was made the default in Fedora 33, and ifcfg was dropped from new installations in Fedora 36, the only scenarios in which users meet those criteria are:
- the user originally installed Fedora 32 or a previous version
- the user installed Fedora 33 or later, then manually switched the default plugin to “ifcfg-rh” in the configuration and then added new connections
- the user installed Fedora 36 or later, explicitly installed the NetworkManager-initscripts-ifcfg-rh package, manually switched the default plugin to “ifcfg-rh” in the configuration and then added new connections
How To Test
- Install the NetworkManager-initscripts-ifcfg-rh package
- Restart NetworkManager
- Migrate a connection to ifcfg-rh via nmcli:
nmcli connection migrate --plugin ifcfg-rh $NAME - Check that the migration had effect with
nmcli -f name,filename connection: the profile should now be stored in/etc/sysconfig/network-scripts - Upgrade to Fedora 39
- Check that all profiles are now stored in
/etc/NetworkManager/system-connectionsin keyfile format.
User Experience
For users that are affected by the migration, there should not be any observable change in behavior. The keyfile format supports a superset of the features supported by ifcfg. Furthermore, the migration is done by the NetworkManager daemon using the same code path used to store new connections in keyfile format. Any bug in the migration would also affect the creation of new connections.
If users have custom scripts or tools that parse the ifcfg files, those will break and need to be adjusted. One notable example of such tools is in package initscripts-rename-device, which provides a udev helper to rename interfaces based on the MAC and interface name found in ifcfg files. Users relying on this mechanism will need to switch to systemd .link files (or udev rules) to perform the renaming.
The release notes for the Fedora version shipping this change will mention these aspects.
Dependencies
N/A
Contingency Plan
- Contingency mechanism: Revert the change, try again the next Fedora release.
- Contingency deadline: Beta freeze
- Blocks release? no
Documentation
No doc change required.
Release Notes
The change will be mentioned in the Release Notes.