Defaulting to MAC-based names for network interfaces

Defaulting to MAC-based names for network interfaces

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi everyone,

Upon personal reflection, a declarative operating system like Guix probably
ought to use only predictable interface names.

More details about this proposal, including the text below, are
available in Bug#63508.

While shorter names like 'eno1' offer an indisputable convenience and beauty
when typing on the command line, administrators in Guix are unlikely to do so
due to the declarative configuration system.

Some system services may explicitly refer to interface names in their
configuration. They would also benefit from the predictable and constant
nature of MAC-based names.

The latter is particularly relevant on multi-homed machines, i.e. those with
more than one network connection.

A MAC-based interface name as issued by 'eudev' looks like this:

  enx0123456789af   (fictitious)

The commit in Bug#63508 was deployed on two production machines. The
migration to MAC-based interface names took place without issues. A
second reconfiguration was used to add the new interface name in
services tha needed it. The second step can be skipped, since the name
is known with certainty in advance.

The current naming scheme is less desirable because some services may silently
refuse to start after equipment was added or removed. A removal may take
place, for example, when something broke or when equipment was sold.

The device enumeration may also change when a CMOS battery fails and system
options are lost. In the author's option, Guix should not depend on BIOS
enumeration for device names.

In the author's case, the name of the sole network interface changed from
enp3s0 to enp4s0 when a PCIe disk controller (a SAS host-based adapter) was
installed. As a result, OpenSMTPd silently failed to start.

This commit switches 'eudev' from the standard naming order

  ID_NET_NAME_ONBOARD
  ID_NET_NAME_SLOT
  ID_NET_NAME_PATH

to ID_NET_NAME_MAC, which is always available. [1]

The author initially attempted to achieve the same result via

(udev-rules-service 'net-name-mac
  (udev-rule
    "01-net-name-mac.rules"
    "SUBSYSTEM==\"net\", ACTION==\"add\", NAME=\"$env{ID_NET_NAME_MAC}\"
")))

but that did not work. While the situation was not examined exhaustively, it
was not clear that udevadm can currently work because the standard command to
test udev setups: [2]

  $ udevadm --debug test /sys/class/net/*

did not find the script installed via the 'udev-service-type'.

A review of the 'eudev' sources indicated that the path to find rules [3] is
hard-coded to the store location during installation. An attempt to set the
path to /etc/udev/rules.d yielded a build error because that target folder
outside the store was understandably not writable.

The manual page for udevadm did not offer a way to select the runtime location
of the udev/rules.d folder via environment variables or a command-line option.

Anyone for whom such a setup is working properly should please contact the
author. Thank you!

This commit may result in some loss of privacy, although it is presently not
clear how meaningful that is. With this commit, anyone using privacy-enhanced
IPv6 addresses risks having their MAC exposed when they publish their
configuration files in Git or post a well-meant sample in a chat rooms,
because that configuration may mention the MAC address.

Moreover, the compatibility with schemes to generate fake one-time MAC
addresses upon boot should be evaluated. One concern is that the explicit
reference to a network interface in a configuration file would likely force
the use of a single and constant MAC address for that interface.

This commit was tested in production and is currently being used.

The change here resulted in the recompilation of several seemingly unrelated
packages such as Emacs and GTK. Perhaps those dependency relationships should
be examined.

[1] https://wiki.debian.org/NetworkInterfaceNames#How_to_migrate_to_this_scheme_on_upgraded_systems
[2] https://wiki.archlinux.org/title/Udev#Testing_rules_before_loading
[3] https://github.com/eudev-project/eudev/blob/39979ddf46e75d1b75bf381e1c73914c226c4302/configure.ac#L180
[4] https://en.wikipedia.org/wiki/IPv6_address#Temporary_addresses

Re: Defaulting to MAC-based names for network interfaces

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 5186 bytes --]

On Sun, May 14, 2023 at 02:52:26PM -0700, Felix Lechner via Development of GNU Guix and the GNU System distribution. wrote:
> Hi everyone,
> 
> Upon personal reflection, a declarative operating system like Guix probably
> ought to use only predictable interface names.
> 
> More details about this proposal, including the text below, are
> available in Bug#63508.
> 
> While shorter names like 'eno1' offer an indisputable convenience and beauty
> when typing on the command line, administrators in Guix are unlikely to do so
> due to the declarative configuration system.
> 
> Some system services may explicitly refer to interface names in their
> configuration. They would also benefit from the predictable and constant
> nature of MAC-based names.
> 
> The latter is particularly relevant on multi-homed machines, i.e. those with
> more than one network connection.
> 
> A MAC-based interface name as issued by 'eudev' looks like this:
> 
>   enx0123456789af   (fictitious)
> 
> The commit in Bug#63508 was deployed on two production machines. The
> migration to MAC-based interface names took place without issues. A
> second reconfiguration was used to add the new interface name in
> services tha needed it. The second step can be skipped, since the name
> is known with certainty in advance.
> 
> The current naming scheme is less desirable because some services may silently
> refuse to start after equipment was added or removed. A removal may take
> place, for example, when something broke or when equipment was sold.
> 
> The device enumeration may also change when a CMOS battery fails and system
> options are lost. In the author's option, Guix should not depend on BIOS
> enumeration for device names.
> 
> In the author's case, the name of the sole network interface changed from
> enp3s0 to enp4s0 when a PCIe disk controller (a SAS host-based adapter) was
> installed. As a result, OpenSMTPd silently failed to start.
> 
> This commit switches 'eudev' from the standard naming order
> 
>   ID_NET_NAME_ONBOARD
>   ID_NET_NAME_SLOT
>   ID_NET_NAME_PATH
> 
> to ID_NET_NAME_MAC, which is always available. [1]
> 
> The author initially attempted to achieve the same result via
> 
> (udev-rules-service 'net-name-mac
>   (udev-rule
>     "01-net-name-mac.rules"
>     "SUBSYSTEM==\"net\", ACTION==\"add\", NAME=\"$env{ID_NET_NAME_MAC}\"
> ")))
> but that did not work. While the situation was not examined exhaustively, it
> was not clear that udevadm can currently work because the standard command to
> test udev setups: [2]
> 
>   $ udevadm --debug test /sys/class/net/*
> 
> did not find the script installed via the 'udev-service-type'.

I was curious about this, since I've been using a udev rule for quite a
while to setup zram swap. I definitely have my zram swap enabled and
working, but 'udevadm --debug test /dev/zram0' didn't find any rule for
zram.

> A review of the 'eudev' sources indicated that the path to find rules [3] is
> hard-coded to the store location during installation. An attempt to set the
> path to /etc/udev/rules.d yielded a build error because that target folder
> outside the store was understandably not writable.
> 
> The manual page for udevadm did not offer a way to select the runtime location
> of the udev/rules.d folder via environment variables or a command-line option.
> 
> Anyone for whom such a setup is working properly should please contact the
> author. Thank you!

/etc/udev points to /etc/static/udev, which itself is a symlink to a
combined udev item in the store, made up of all the udev rules installed
in the current system.

> This commit may result in some loss of privacy, although it is presently not
> clear how meaningful that is. With this commit, anyone using privacy-enhanced
> IPv6 addresses risks having their MAC exposed when they publish their
> configuration files in Git or post a well-meant sample in a chat rooms,
> because that configuration may mention the MAC address.
> 
> Moreover, the compatibility with schemes to generate fake one-time MAC
> addresses upon boot should be evaluated. One concern is that the explicit
> reference to a network interface in a configuration file would likely force
> the use of a single and constant MAC address for that interface.
> 
> This commit was tested in production and is currently being used.
> 
> The change here resulted in the recompilation of several seemingly unrelated
> packages such as Emacs and GTK. Perhaps those dependency relationships should
> be examined.
> 
> [1] https://wiki.debian.org/NetworkInterfaceNames#How_to_migrate_to_this_scheme_on_upgraded_systems
> [2] https://wiki.archlinux.org/title/Udev#Testing_rules_before_loading
> [3] https://github.com/eudev-project/eudev/blob/39979ddf46e75d1b75bf381e1c73914c226c4302/configure.ac#L180
> [4] https://en.wikipedia.org/wiki/IPv6_address#Temporary_addresses
> 

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Defaulting to MAC-based names for network interfaces

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Efraim,

On Mon, May 15, 2023 at 7:47 AM Efraim Flashner <efraim@flashner.co.il> wrote:
>
> > the standard command to test udev setups: [2]
> >
> >   $ udevadm --debug test /sys/class/net/*
> >
> > did not find the script installed via the 'udev-service-type'.
>
> I was curious about this, since I've been using a udev rule for quite a
> while to setup zram swap. I definitely have my zram swap enabled and
> working, but 'udevadm --debug test /dev/zram0' didn't find any rule for
> zram.

Your zram probably works because your udev rule does not need a
working udevadm. I believe that network interfaces actually use
udevadm to determine their name. Either way, my latest amendments to
Bug#63508 (v2) will fix your udevadm. [1]

In a concession to Liliana's opposition, I retitled the bug to
sidestep the question of the MAC-based names as a default setting. My
position has not changed but that should probably be a separate
discussion.

Personally, I hope to win everyone's hearts with this: My fix allows
folks to experiment with MAC-based names so everyone can see their
great utility. Anyone interested, please put this in your system
services:

            (udev-rules-service 'net-name-mac
                                (udev-rule
                                 "79-net-name-mac.rules"
                                 "
SUBSYSTEM==\"net\", ACTION==\"add\", NAME=\"$env{ID_NET_NAME_MAC}\"
")))

Sorry I cannot offer substitutes. The change rebuilds more than it should.

As a side note, I looked into upgrading to eudev 3.2.12, which was
tagged yesterday, but that will bring more pain because upstream
hardcoded the path to the hwdb. [2] I have a partial fix, although
some consuming packages like upower aren't working yet.

Kind regards
Felix

[1] https://issues.guix.gnu.org/63508#12
[2] https://github.com/eudev-project/eudev/blob/2703baf55615b7554fb67c4f1c241f057f8c0a79/src/udev/udevadm-hwdb.c#L588