8:43 a.m.
a big BTW when /etc/init.d/network will be removed or migrate to
systemd scripts ?
rpm -qf /etc/init.d/network --qf "packge = %{sourcerpm}\nsub-package =
%{name}\n"
packge = initscripts-10.09-1.fc34.src.rpm
sub-package = network-scripts
On Wed, 2022-01-05 at 09:05 -0500, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
== Summary ==
Do not not include NetworkManager support for legacy network
configuration files by in new installations.
== Owner ==
* Name: [[User:Lkundrak| Lubomir Rintel]]
* Email: <lkundrak(a)v3.sk>
* Name: Ana Cabral
* Email: <acabral(a)redhat.com>
* Name: [[User:Thaller| Thomas Haller]]
* Email: <thaller(a)redhat.com>
== 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
[
https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_...
Fedora 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.
== 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 33 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.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to
devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Sérgio M. B.