No ifcfg by default
Summary
Do not not include NetworkManager support for legacy network configuration files by in new installations.
Owner
- Name: Lubomir Rintel
- Email: <lkundrak@v3.sk>
Current status
- Targeted release: Fedora Linux 36
- Last updated: 2022-01-03
- 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
Long ago, network was configured using "network" service.
It was essentially a set of shell scripts, that sourced snippets of configuration from /etc/sysconfig/network-scripts/ifcfg-* ("ifcfg files").
The ifcfg files compatible with the legacy network service were kept when NetworkManager was intruduced.
As the NetworkManager feature set was expanding beyond what the legacy network service could support, the ifcfg files written by NetworkManager could no longer be guarranteed to be compatible. NetworkManager eventually gained support for connection types completely unknown to the legacy network service and ended up using a more streamlined configuration file format for those, known as keyfile.
NetworkManager's use of various configuration files is, in fact, configurable and extensible with plugins. Prior to Fedora 33, NetworkManager by default was configured to enable both ifcfg files and keyfiles, with the former taking precedence when possible. The precedence changed in [33] to perfer keyfile.
The precedence has an effect when a network connection profile is created. Once the connection profile exists, NetworkManager is unable to convert the profile to a different configuration backend. This makes it necessary for NetworkManager to support the same feature set in all configuration backend. Given the complexities stemming from historical legacy of ifcfg files not being designed (or documented) in a particularly forward-looking way, this has been a huge and complex effort with all the downsides: The ifcfg support code is huge (130K lines, not counting the enormous test suite) and has constantly been a source of bugs.
Feedback
Benefit to Fedora
This change removes a body of code that has a large cost in terms of bugs and maintenance at questionable benefit.
It slightly reduces the default installation size.
Scope
- Proposal owners: Split the ifcfg plugin into a subpackage package. Make sure the ifcfg plugin stays on upgrades. Provide a migration tool.
- Other developers: N/A
- Release engineering: N/A
- Policies and guidelines: N/A
- Trademark approval: N/A
- Alignment with Objectives: N/A
Upgrade/compatibility impact
For the time being the ifcfg plugin is kept around, albeit in a sub-package that's not included in new installations. The appropriate RPM tags will ensure the sub-package with the ifcfg plugin will be installed on upgrades. A migration tool will be provided for users who'd like to remove the legacy package from their systems after upgrade.
How To Test
N/A. The keyfiles are used by default in Fedora 35 already, so any problem with them would've already been spotted.
User Experience
Regular users will not notice anything. Users of old installations with ifcfg files will get the new sub-package on upgrade. New systems will default to use keyfiles, which is not something regulars user would notice.
System integrators and administrators might use tools that drop in ifcfg files during automated installations (e.g. via kickstart or a configration management tool). They will need to update their tools -- convert the ifcfg files to keyfiles or include the ifcfg sub-package.
Dependencies
N/A
Contingency Plan
- Contingency mechanism: If it turns out we can't drop support for ifcfg files by default, we can either fold the ifcfg sub-package back into the main NetworkManager package or make sure it is included in new installations (via comps change).
- Contingency deadline: Any time.
- Blocks release? No.
Documentation
We'll need to write the documentation for the migration tool. Perhaps also something the sysadmins wondering why their ifcfg files don't work anymore could find and refer to.
TODO: Update this once it's done.
Release Notes
We'll need to include a paragraph about this in the release notes.
TODO: Update this with the actual release note text.