| Message ID | 89b635e974a7d570cbd19b847fc3eb8ac903103b.1684100044.git.felix.lechner@lease-up.com |
|---|---|
| State | New |
| Headers | show |
| Series | Use MAC-based names for network interfaces | expand |
Am Sonntag, dem 14.05.2023 um 14:42 -0700 schrieb Felix Lechner: > The change here resulted in the recompilation of several seemingly > unrelated packages such as Emacs and GTK. Perhaps those dependency > relationships should be examined. What? GUI libraries and packages that depend on them need to be rebuilt when we change the way we handle our (input, media) devices?! Can't have that! > gnu/packages/linux.scm | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm > index 98e683bdb0..724c621fed 100644 > --- a/gnu/packages/linux.scm > +++ b/gnu/packages/linux.scm > @@ -4173,6 +4173,12 @@ (define-public eudev > (substitute* (string-append #$output > "/lib/libudev.la") > (("old_library=.*") > "old_library=''\n"))))) > + (add-before 'install 'net-name-mac > + (lambda _ > + (use-modules (ice-9 regex)) > + (substitute* "rules/80-net-name-slot.rules" > + (((regexp-quote "ID_NET_NAME_ONBOARD")) Wherefore the regexp-quote? There is no regexp to be found here, is there? > + "ID_NET_NAME_MAC")))) I don't see how this change allows users *or upstream package maintainers* to continue using onboard names as they have done for ages and as they would want to continue to do. I think you should a) File a patch upstream to add ID_NET_NAME_MAC into net-name- slot.rules b) Add that patch to our eudev package with a reference to the upstream bug report. Cheers
Hi Liliana, Thank you for your review! On Sun, May 14, 2023 at 9:31 PM Liliana Marie Prikler <liliana.prikler@gmail.com> wrote: > > Wherefore the regexp-quote? Whoops! That was left over from the attempt to get udevadm to use /etc/udev/rules.d as it should. Thanks for the pointer! > I don't see how this change allows users *or upstream package > maintainers* to continue using onboard names as they have done for ages > and as they would want to continue to do. I have one of those cards. While the interface name did not change when I fiddled with the PCI configuration, I am not sure that prioritizing ID_NET_NAME_ONBOARD over ID_NET_NAME_MAC is a reasonable default for Guix. To rank ID_NET_NAME_ONBOARD below ID_NET_NAME_MAC would not address the shortcoming you perceived because the latter always exists. Instead, I think people wishing to use ID_NET_NAME_ONBOARD should install a custom udev script (and those should be recognized by the udevadm we ship). > a) File a patch upstream to add ID_NET_NAME_MAC into net-name- > slot.rules If upstream accepts such a patch, I believe they would give ID_NET_NAME_MAC the lowest possible priority, but that does nothing for Guix. Common relative priorities are outlined here. [1] For Guix, I think we would like to see ID_NET_NAME_MAC at the top. Kind regards Felix [1] https://wiki.debian.org/NetworkInterfaceNames#How_to_migrate_to_this_scheme_on_upgraded_systems
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm index 98e683bdb0..724c621fed 100644 --- a/gnu/packages/linux.scm +++ b/gnu/packages/linux.scm @@ -4173,6 +4173,12 @@ (define-public eudev (substitute* (string-append #$output "/lib/libudev.la") (("old_library=.*") "old_library=''\n"))))) + (add-before 'install 'net-name-mac + (lambda _ + (use-modules (ice-9 regex)) + (substitute* "rules/80-net-name-slot.rules" + (((regexp-quote "ID_NET_NAME_ONBOARD")) + "ID_NET_NAME_MAC")))) (add-after 'install 'build-hwdb (lambda _ ;; Build OUT/etc/udev/hwdb.bin. This allows 'lsusb' and
Upon personal reflection, a declarative operating system like Guix probably ought to use only predictable interface names. 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) This commit was deployed on two production machines. The migration to MAC-based interface names took place without issues. A second reconfiguration was the 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 compatibilty 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 * gnu/packages/linux.scm (eudev): Always use MAC-based names for network interfaces. --- gnu/packages/linux.scm | 6 ++++++ 1 file changed, 6 insertions(+)