[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Defaulting to MAC-based names for network interfaces
From: |
Efraim Flashner |
Subject: |
Re: Defaulting to MAC-based names for network interfaces |
Date: |
Mon, 15 May 2023 17:47:06 +0300 |
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
signature.asc
Description: PGP signature