Re: Defaulting to MAC-based names for network interfaces

[Efraim Flashner <efraim@flashner.co.il>]

[-- 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 --]