Wiki: https://fedoraproject.org/wiki/Changes/StopCreatingDefaultNetworkProfilesByAnaconda
Discussion Thread: https://discussion.fedoraproject.org/t/177637
**This is a proposed Change for Fedora Linux.**
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 ==
Traditionally Anaconda installer used to create default network profiles (NetworkManager ifcfg files or keyfiles) on the installed sytem for each wired device. With the change only ... [truncated]
== Owner ==
* Name: [[User:rvykydal| Radek Vykydal]]
* Email: rvykydal@redhat.com
== Detailed Description ==
The reasons for the current behavior - creating of the default profiles for each wired network device - were from large part technical, imposed by the architecture of the installer network configuration module. The Anaconda default profiles were created at the initial stage of installation from NetworkManager connections where possible - either by dumping a connection (for example 'Wired Connection' created in initramfs) - or cloning a default connection ('Wired Connection 1' created after switchroot) with connection id updated to the interface name. In cases where reusing the connection created by NM was not possible Anaconda created new connection on its own via NetworkManager API. In some cases Anaconda was also updating some values of the connections like addr-gen-mode.
Over the years there were requests from the users to stop creating the profiles for unconfigured devices - only the devices configured in installer should have persistent profile created on the installed system. The updates in the NewtworkManager backend and its integration in the installer, together with improved CI coverage, now allows to drop the default connections and by this also to address several long term issues:
* There were bugs reported related to the default connections present on the installed system unexpectedly by the users (https://bugzilla.redhat.com/show_bug.cgi?id=2031385#c8, https://bugzilla.redhat.com/show_bug.cgi?id=2115783, https://issues.redhat.com/browse/RHEL-100200). In some cases the profiles prevented proper activation of virtual connections configured by the user. The issues were usually addressed by installer by updating already complex logic for management of the profiles by the installer. For port devices installer already stopped to create the profiles recently (https://github.com/rhinstaller/anaconda/pull/5703).
* On the Live ISO installations (as Fedora Workstation) the installer network configuration UI and the connection management had to be disabled because it was conflicting with the Gnome configuration tools present in the environment. In scope of the ongoing move towards the WebUI graphical user interface the installer team aims to provide UI that can seamlessly integrate with other tools, usable both in Live ISO environment and installer image environment (for example Server variant using Netinst ISO or DVD ISO), preferably reusing Cockpit network configuration module. This requires dropping some parts of installer network connections management - with this change being an important step (see https://issues.redhat.com/browse/INSTALLER-3088).
* Significant part of installer users work around the current behavior by removing the default connections created by installer in their custom kickstart '%post' scripts or other installation post-processing ([https://pagure.io/fedora-kickstarts/blob/f43/f/fedora-cloud-base.ks#_146 fedora-cloud-base.ks] for example).
* There was already a request from NetworkManager side for installer team to drop creating of default profiles: https://github.com/rhinstaller/anaconda/pull/1588. Installer team was not able to prioritize it to be addressed yet.
== Feedback ==
The feedback we were getting from the community over the past years was asking for removing of the default Anaconda profiles, as pointed out in the **Detailed Description**.
On the other hand we may expect negative feedback triggered by potential need for adaptation to the new behavior.
== Benefit to Fedora ==
* Improved consistency - persistent profiles exist only for configured devices.
* Single point of truth for defaults - installer steps out of the business of creating default network profiles (name, id, binding) and even setting its default values.
* User perspective: no unexpected network configuration produced by installation. Workarounds for removing undesired profiles in post installation steps are no more needed.
* More flexibility for network configuration tooling choices in the installer environment (like LiveISO).
* Makes shared use of Cockpit network configuration module in installer WebUI for non-live ISO variants feasible.
== Scope ==
* Proposal owners: replace the DumpMissingConfigFiles API with API for just persisting initramfs configuration. The work is in advanced progress in https://github.com/rhinstaller/anaconda/pull/6787.
* Other developers: potentially adapt scripts and tools assuming existence of the persistent profiles for non-configured devices
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
Upgrades impact: none, the change is applied only to newly installed systems.
Compatibility impact: automation tools used to post process network configuration of systems after installation might need adjustments if they are working with network profiles without verifying its existence
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? Y/N
== How To Test ==
The change can be tested by installing Fedora variants which are using installer environment iso (boot.iso, netinst or DVD, for example Fedora Server) on various installation scenarios with or without network configuration in installer:
* via boot options (for example 'ip=dhcp', 'ip=enp1s0:dhcp')
* via kickstart ('network' command)
* via text UI
* via Gtk UI
The devices not configured by any of these means should not have persistent configuration profile on installed system (in '/etc/NetworkManager/system-connecitons'). See also the examples in the **User Experience** section.
== User Experience ==
**Example 1**: Fedora Server Network Installation, no network configuration during installation.
*Without the change* - state after installed system reboot:
root@ibm-p8-kvm-03-guest-02:~# nmcli con
NAME UUID TYPE DEVICE..
enp0s22 2c4fb9f7-feab-3c4e-a4d5-549b34feab67 ethernet enp0s22.
lo eff6e9ee-ffe6-4cd8-8d91-a131d75ccdaf loopback lo......
root@ibm-p8-kvm-03-guest-02:~# ls /etc/NetworkManager/system-connections/
enp0s22.nmconnection
root@ibm-p8-kvm-03-guest-02:~# cat /etc/NetworkManager/system-connections/enp0s22.nmconnection.
[connection]
id=enp0s22
uuid=2c4fb9f7-feab-3c4e-a4d5-549b34feab67
type=ethernet
autoconnect-priority=-999
interface-name=enp0s22
timestamp=1765956677
[ethernet]
[ipv4]
method=auto
[ipv6]
addr-gen-mode=eui64
method=auto
[proxy]
*With the change* - state after installed system reboot:
root@ibm-p8-kvm-03-guest-02:~# nmcli con
NAME UUID TYPE DEVICE..
Wired connection 1 3500649e-c341-3a36-bb89-02e29d6f6f4f ethernet enp0s22.
lo 4147084d-dedd-4513-aed2-bb8ecbe0b26e loopback lo......
root@ibm-p8-kvm-03-guest-02:~# ls /etc/NetworkManager/system-connections/
root@ibm-p8-kvm-03-guest-02:~# ls /run/NetworkManager/system-connections/
lo.nmconnection 'Wired connection 1.nmconnection'
root@ibm-p8-kvm-03-guest-02:~# cat /run/NetworkManager/system-connections/Wired\ connection\ 1.nmconnection.
[connection]
id=Wired connection 1
uuid=3500649e-c341-3a36-bb89-02e29d6f6f4f
type=ethernet
autoconnect-priority=-999
interface-name=enp0s22
timestamp=1765959194
[ethernet]
[ipv4]
method=auto
[ipv6]
addr-gen-mode=default
method=auto
[proxy]
[.nmmeta]
nm-generated=true
**Example 2**: Fedora Server DVD installation with network device unplugged during installation and plugged in before booting installed system. No network configuration during installation.
*Without the change* - state after installed system reboot:
root@dhcp193:~# nmcli con
NAME UUID TYPE DEVICE.
lo 60c2b452-c923-44b7-b119-484f1fc119dc loopback lo.....
enp1s0 f986e267-90bc-4e3a-bc89-d16ffa581246 ethernet --.....
root@dhcp193:~# ls /etc/NetworkManager/system-connections/
enp1s0.nmconnection
root@dhcp193:~# ls /run/NetworkManager/system-connections/
lo.nmconnection
root@dhcp193:~# cat /run/NetworkManager/system-connections/enp1s0.nmconnection
[connection]
id=enp1s0
uuid=f986e267-90bc-4e3a-bc89-d16ffa581246
type=ethernet
autoconnect=false
interface-name=enp1s0
[ethernet]
[ipv4]
method=auto
[ipv6]
addr-gen-mode=eui64
method=auto
[proxy]
*With the change* - state after installed system reboot (is the same as in Example 1):
root@dhcp193:~# nmcli con
NAME UUID TYPE DEVICE
Wired connection 1 9196327c-a909-3cda-8733-06d6c77546f9 ethernet enp1s0
lo 64f89f2c-85c8-40eb-92bf-b6712e3162d5 loopback lo
root@dhcp193:~# ls /etc/NetworkManager/system-connections/
root@dhcp193:~# ls /run/NetworkManager/system-connections/
lo.nmconnection 'Wired connection 1.nmconnection'
root@dhcp193:~# cat /run/NetworkManager/system-connections/Wired\ connection\ 1.nmconnection
[connection]
id=Wired connection 1
uuid=9196327c-a909-3cda-8733-06d6c77546f9
type=ethernet
autoconnect-priority=-999
interface-name=enp1s0
timestamp=1765961287
[ethernet]
[ipv4]
method=auto
[ipv6]
addr-gen-mode=default
method=auto
[proxy]
[.nmmeta]
nm-generated=true
== Dependencies ==
It is possible that some Anaconda installer clients performing installed system post processing will need to adapt to the change, expecting the Anaconda default profiles existing (for their modification, removal, etc).
Regarding system management / configuration tools, I think the risk they may assume the profiles existing on the installed system is reasonably small, and the tools should be able to handle their removing without issues.
== Contingency Plan ==
* Contingency mechanism: Reverting the change.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
I am not aware of the current behavior being documented anywhere else then in the [https://anaconda-installer.readthedocs.io/en/latest/autoapi/pyanaconda/modules/network/network_interface/index.html#pyanaconda.modules.network.network_interface.NetworkInterface.DumpMissingConfigFilesWithTask DumpMissingConfigFiles API].
The new behavior should be the one users would expected by default, so no explicit documentation is required.
The change of behavior will be documented in release notes.
== Release Notes ==
Discussion Thread: https://discussion.fedoraproject.org/t/177637
**This is a proposed Change for Fedora Linux.**
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 ==
Traditionally Anaconda installer used to create default network profiles (NetworkManager ifcfg files or keyfiles) on the installed sytem for each wired device. With the change only ... [truncated]
== Owner ==
* Name: [[User:rvykydal| Radek Vykydal]]
* Email: rvykydal@redhat.com
== Detailed Description ==
The reasons for the current behavior - creating of the default profiles for each wired network device - were from large part technical, imposed by the architecture of the installer network configuration module. The Anaconda default profiles were created at the initial stage of installation from NetworkManager connections where possible - either by dumping a connection (for example 'Wired Connection' created in initramfs) - or cloning a default connection ('Wired Connection 1' created after switchroot) with connection id updated to the interface name. In cases where reusing the connection created by NM was not possible Anaconda created new connection on its own via NetworkManager API. In some cases Anaconda was also updating some values of the connections like addr-gen-mode.
Over the years there were requests from the users to stop creating the profiles for unconfigured devices - only the devices configured in installer should have persistent profile created on the installed system. The updates in the NewtworkManager backend and its integration in the installer, together with improved CI coverage, now allows to drop the default connections and by this also to address several long term issues:
* There were bugs reported related to the default connections present on the installed system unexpectedly by the users (https://bugzilla.redhat.com/show_bug.cgi?id=2031385#c8, https://bugzilla.redhat.com/show_bug.cgi?id=2115783, https://issues.redhat.com/browse/RHEL-100200). In some cases the profiles prevented proper activation of virtual connections configured by the user. The issues were usually addressed by installer by updating already complex logic for management of the profiles by the installer. For port devices installer already stopped to create the profiles recently (https://github.com/rhinstaller/anaconda/pull/5703).
* On the Live ISO installations (as Fedora Workstation) the installer network configuration UI and the connection management had to be disabled because it was conflicting with the Gnome configuration tools present in the environment. In scope of the ongoing move towards the WebUI graphical user interface the installer team aims to provide UI that can seamlessly integrate with other tools, usable both in Live ISO environment and installer image environment (for example Server variant using Netinst ISO or DVD ISO), preferably reusing Cockpit network configuration module. This requires dropping some parts of installer network connections management - with this change being an important step (see https://issues.redhat.com/browse/INSTALLER-3088).
* Significant part of installer users work around the current behavior by removing the default connections created by installer in their custom kickstart '%post' scripts or other installation post-processing ([https://pagure.io/fedora-kickstarts/blob/f43/f/fedora-cloud-base.ks#_146 fedora-cloud-base.ks] for example).
* There was already a request from NetworkManager side for installer team to drop creating of default profiles: https://github.com/rhinstaller/anaconda/pull/1588. Installer team was not able to prioritize it to be addressed yet.
== Feedback ==
The feedback we were getting from the community over the past years was asking for removing of the default Anaconda profiles, as pointed out in the **Detailed Description**.
On the other hand we may expect negative feedback triggered by potential need for adaptation to the new behavior.
== Benefit to Fedora ==
* Improved consistency - persistent profiles exist only for configured devices.
* Single point of truth for defaults - installer steps out of the business of creating default network profiles (name, id, binding) and even setting its default values.
* User perspective: no unexpected network configuration produced by installation. Workarounds for removing undesired profiles in post installation steps are no more needed.
* More flexibility for network configuration tooling choices in the installer environment (like LiveISO).
* Makes shared use of Cockpit network configuration module in installer WebUI for non-live ISO variants feasible.
== Scope ==
* Proposal owners: replace the DumpMissingConfigFiles API with API for just persisting initramfs configuration. The work is in advanced progress in https://github.com/rhinstaller/anaconda/pull/6787.
* Other developers: potentially adapt scripts and tools assuming existence of the persistent profiles for non-configured devices
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
Upgrades impact: none, the change is applied only to newly installed systems.
Compatibility impact: automation tools used to post process network configuration of systems after installation might need adjustments if they are working with network profiles without verifying its existence
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? Y/N
== How To Test ==
The change can be tested by installing Fedora variants which are using installer environment iso (boot.iso, netinst or DVD, for example Fedora Server) on various installation scenarios with or without network configuration in installer:
* via boot options (for example 'ip=dhcp', 'ip=enp1s0:dhcp')
* via kickstart ('network' command)
* via text UI
* via Gtk UI
The devices not configured by any of these means should not have persistent configuration profile on installed system (in '/etc/NetworkManager/system-connecitons'). See also the examples in the **User Experience** section.
== User Experience ==
**Example 1**: Fedora Server Network Installation, no network configuration during installation.
*Without the change* - state after installed system reboot:
root@ibm-p8-kvm-03-guest-02:~# nmcli con
NAME UUID TYPE DEVICE..
enp0s22 2c4fb9f7-feab-3c4e-a4d5-549b34feab67 ethernet enp0s22.
lo eff6e9ee-ffe6-4cd8-8d91-a131d75ccdaf loopback lo......
root@ibm-p8-kvm-03-guest-02:~# ls /etc/NetworkManager/system-connections/
enp0s22.nmconnection
root@ibm-p8-kvm-03-guest-02:~# cat /etc/NetworkManager/system-connections/enp0s22.nmconnection.
[connection]
id=enp0s22
uuid=2c4fb9f7-feab-3c4e-a4d5-549b34feab67
type=ethernet
autoconnect-priority=-999
interface-name=enp0s22
timestamp=1765956677
[ethernet]
[ipv4]
method=auto
[ipv6]
addr-gen-mode=eui64
method=auto
[proxy]
*With the change* - state after installed system reboot:
root@ibm-p8-kvm-03-guest-02:~# nmcli con
NAME UUID TYPE DEVICE..
Wired connection 1 3500649e-c341-3a36-bb89-02e29d6f6f4f ethernet enp0s22.
lo 4147084d-dedd-4513-aed2-bb8ecbe0b26e loopback lo......
root@ibm-p8-kvm-03-guest-02:~# ls /etc/NetworkManager/system-connections/
root@ibm-p8-kvm-03-guest-02:~# ls /run/NetworkManager/system-connections/
lo.nmconnection 'Wired connection 1.nmconnection'
root@ibm-p8-kvm-03-guest-02:~# cat /run/NetworkManager/system-connections/Wired\ connection\ 1.nmconnection.
[connection]
id=Wired connection 1
uuid=3500649e-c341-3a36-bb89-02e29d6f6f4f
type=ethernet
autoconnect-priority=-999
interface-name=enp0s22
timestamp=1765959194
[ethernet]
[ipv4]
method=auto
[ipv6]
addr-gen-mode=default
method=auto
[proxy]
[.nmmeta]
nm-generated=true
**Example 2**: Fedora Server DVD installation with network device unplugged during installation and plugged in before booting installed system. No network configuration during installation.
*Without the change* - state after installed system reboot:
root@dhcp193:~# nmcli con
NAME UUID TYPE DEVICE.
lo 60c2b452-c923-44b7-b119-484f1fc119dc loopback lo.....
enp1s0 f986e267-90bc-4e3a-bc89-d16ffa581246 ethernet --.....
root@dhcp193:~# ls /etc/NetworkManager/system-connections/
enp1s0.nmconnection
root@dhcp193:~# ls /run/NetworkManager/system-connections/
lo.nmconnection
root@dhcp193:~# cat /run/NetworkManager/system-connections/enp1s0.nmconnection
[connection]
id=enp1s0
uuid=f986e267-90bc-4e3a-bc89-d16ffa581246
type=ethernet
autoconnect=false
interface-name=enp1s0
[ethernet]
[ipv4]
method=auto
[ipv6]
addr-gen-mode=eui64
method=auto
[proxy]
*With the change* - state after installed system reboot (is the same as in Example 1):
root@dhcp193:~# nmcli con
NAME UUID TYPE DEVICE
Wired connection 1 9196327c-a909-3cda-8733-06d6c77546f9 ethernet enp1s0
lo 64f89f2c-85c8-40eb-92bf-b6712e3162d5 loopback lo
root@dhcp193:~# ls /etc/NetworkManager/system-connections/
root@dhcp193:~# ls /run/NetworkManager/system-connections/
lo.nmconnection 'Wired connection 1.nmconnection'
root@dhcp193:~# cat /run/NetworkManager/system-connections/Wired\ connection\ 1.nmconnection
[connection]
id=Wired connection 1
uuid=9196327c-a909-3cda-8733-06d6c77546f9
type=ethernet
autoconnect-priority=-999
interface-name=enp1s0
timestamp=1765961287
[ethernet]
[ipv4]
method=auto
[ipv6]
addr-gen-mode=default
method=auto
[proxy]
[.nmmeta]
nm-generated=true
== Dependencies ==
It is possible that some Anaconda installer clients performing installed system post processing will need to adapt to the change, expecting the Anaconda default profiles existing (for their modification, removal, etc).
Regarding system management / configuration tools, I think the risk they may assume the profiles existing on the installed system is reasonably small, and the tools should be able to handle their removing without issues.
== Contingency Plan ==
* Contingency mechanism: Reverting the change.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
I am not aware of the current behavior being documented anywhere else then in the [https://anaconda-installer.readthedocs.io/en/latest/autoapi/pyanaconda/modules/network/network_interface/index.html#pyanaconda.modules.network.network_interface.NetworkInterface.DumpMissingConfigFilesWithTask DumpMissingConfigFiles API].
The new behavior should be the one users would expected by default, so no explicit documentation is required.
The change of behavior will be documented in release notes.
== Release Notes ==
No comments:
Post a Comment