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: <lkund...@v3.sk>
>
> * Name: Ana Cabral
> * Email: <acab...@redhat.com>
>
> * Name: [[User:Thaller| Thomas Haller]]
> * Email: <thal...@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_ifcfg_rh
> 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@lists.fedoraproject.org
> To unsubscribe send an email to
> devel-announce-le...@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.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
--
Sérgio M. B.
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@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.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
