From Fedora Project Wiki
(Moved to FeatureReadyForFesco for approval (#1022))
(→‎Release Notes: possibility of ifcfg breakage)
(2 intermediate revisions by 2 users not shown)
Line 12: Line 12:
== Current status ==
== Current status ==
* Targeted release: [[Releases/19 | Fedora 19 ]]  
* Targeted release: [[Releases/19 | Fedora 19 ]]  
* Last updated: 2012-01-17
* Last updated: 2012-01-29
* Percentage of completion: 100%
* Percentage of completion: 95%


== Detailed Description ==
== Detailed Description ==
Line 28: Line 28:


== Scope ==
== Scope ==
It's just a simple udev rules file we need to enable or disable in the Fedora RPM spec.
It's a simple udev rules file we need to enable or disable in the Fedora RPM spec.
 
As part of this feature we also want to remove biosdevname from comps, so that it is not installed anymore for new installations.
 
Optionally, if FESCO desires so we can disable the udev rules files for upgrades (but leave it enabled for new installs), in order to ensure that even on systems that lack biosdevname the network interface naming scheme does not change on upgrades. We don't particularly like a behaviour like this (i.e. where installing an RPM in version 1, and then upgrading to 2 yields a different result than just installing version 2), but we have no better idea either, so we'd like to ask FESCO to decide on this.


== How To Test ==
== How To Test ==
Line 34: Line 38:


== User Experience ==
== User Experience ==
Users generally won't see this, as interface names are not exposed in high-level UIs.
Normal users generally won't see this, as interface names are not exposed in high-level UIs (or if they are not prominently.)


As biosdevname is installed by default and anaconda usually creates an interface configuration file for the hosts' ethernet network connection most administrators won't see this either.
On upgrades, as biosdevname previously was installed by default and anaconda usually creates an interface configuration file for the hosts' ethernet network connection most pro users/administrators won't see much of this either. That said, as the new scheme also applies to USB devices and WLAN/WWAN where biosdevname did not apply this might also affect these systems.


This will be immediately visible only on systems which have no explcitly set network interface names, and do not have biosdevname installed.
On new installs, pro users/administrators will see this change.


== Dependencies ==
== Dependencies ==
Line 52: Line 56:
We should direct the user to http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames and include information how the new naming scheme can be turned off or altered.
We should direct the user to http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames and include information how the new naming scheme can be turned off or altered.


Other than that it should be enough to just announce availability of this feature, plus a paste from the Summary section of this feature page-  
Users upgrading from previous releases ''may'' need to worry about updating ifcfg files in /etc/system/network-scripts to refer to new device names rather than old ones. However, as noted above, most upgrading users will have biosdevname installed, and so will continue to see the old names.
 
Other than that it should be enough to just announce availability of this feature, plus a paste from the Summary section of this feature page-


== Comments and Discussion ==
== Comments and Discussion ==
* See [[Talk:Features/SystemdPredictableNetworkInterfaceNames]]
* See [[Talk:Features/SystemdPredictableNetworkInterfaceNames]]


[[Category:FeatureReadyForFesco]]
[[Category:FeatureAcceptedF19]]

Revision as of 15:36, 8 March 2013

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

systemd/udev Predictable Network Interface Names

Summary

The udevd service has a long history of providing predicatable names for block devices and others. For Fedora 19 we'd like to provide the same for network interfaces, following a similar naming scheme, but only as fallback if not other solution such as biosdevname is installed or the administrator manually defined network interface names via udev rules or the old network scripts.

Owner

Current status

  • Targeted release: Fedora 19
  • Last updated: 2012-01-29
  • Percentage of completion: 95%

Detailed Description

The classic naming scheme for network interfaces applied by the kernel is to simply assign names beginning with "eth0", "eth1", ... to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable for modern technology this means that as soon as multiple network interfaces are available the assignment of the names "eth0", "eth1" and so on is generally not fixed anymore and it might very well happen that "eth0" on one boot ends up being "eth1" on the next. This can have serious security implications, for example in firewall rules which are coded for certain naming schemes, and which are hence very sensitive to unpredictable changing names.

Starting with v197 systemd/udev can automatically assign predictable, stable network interface names for all local Ethernet, WLAN and WWAN interfaces. This is a departure from the traditional interface naming scheme ("eth0", "eth1", "wlan0", ...), but should fix real problems.

This feature is about enabling this as default in Fedora, but only as a fallback if the user/administrator did not manually assign names to interfaces via udev rules, or via the old networking scripts, or if biosdevname is installed.

For a longer discussion about this feature see the upstream documentation.

Benefit to Fedora

Stable, predictable, reliable naming of all network interfaces by default, with on-board tools.

Scope

It's a simple udev rules file we need to enable or disable in the Fedora RPM spec.

As part of this feature we also want to remove biosdevname from comps, so that it is not installed anymore for new installations.

Optionally, if FESCO desires so we can disable the udev rules files for upgrades (but leave it enabled for new installs), in order to ensure that even on systems that lack biosdevname the network interface naming scheme does not change on upgrades. We don't particularly like a behaviour like this (i.e. where installing an RPM in version 1, and then upgrading to 2 yields a different result than just installing version 2), but we have no better idea either, so we'd like to ask FESCO to decide on this.

How To Test

If you don't have biosdevname installed and no explicit network interface configuration in /etc/sysconfig/network-scripts/, and did not install any udev rules that rename your interfaces for you, then your interfaces should now be named "eno1", "ens1", "enp2s0" or similar.

User Experience

Normal users generally won't see this, as interface names are not exposed in high-level UIs (or if they are not prominently.)

On upgrades, as biosdevname previously was installed by default and anaconda usually creates an interface configuration file for the hosts' ethernet network connection most pro users/administrators won't see much of this either. That said, as the new scheme also applies to USB devices and WLAN/WWAN where biosdevname did not apply this might also affect these systems.

On new installs, pro users/administrators will see this change.

Dependencies

Nothing.

Contingency Plan

We can turn the udev rule that enables this fallback default off/or on with a simple RPM spec line.

Documentation

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

Release Notes

We should direct the user to http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames and include information how the new naming scheme can be turned off or altered.

Users upgrading from previous releases may need to worry about updating ifcfg files in /etc/system/network-scripts to refer to new device names rather than old ones. However, as noted above, most upgrading users will have biosdevname installed, and so will continue to see the old names.

Other than that it should be enough to just announce availability of this feature, plus a paste from the Summary section of this feature page-

Comments and Discussion