From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id cNPNJVpYYWQBDAEASxT56A (envelope-from ) for ; Sun, 14 May 2023 23:53:30 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id WE7PJVpYYWS3EwAAauVa8A (envelope-from ) for ; Sun, 14 May 2023 23:53:30 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 4428431588 for ; Sun, 14 May 2023 23:53:30 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pyJeS-0003Ik-LR; Sun, 14 May 2023 17:53:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pyJeR-0003IZ-De for guix-devel@gnu.org; Sun, 14 May 2023 17:53:11 -0400 Received: from sail-ipv4.us-core.com ([208.82.101.137]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1pyJeP-0005Xf-Ej for guix-devel@gnu.org; Sun, 14 May 2023 17:53:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=2017; bh=NxmOIlHrZpdsigV NKKybv3039acayUtGVpkGonODR5w=; h=to:subject:date:from; d=lease-up.com; b=ELrPx0lifzC7JkdBGypUbBtmnrnJWZ+IMXu0iRbMjoSqstAsC3B7xyG22A+sSFe704YZ VlwvDmIbOkGngK6Pcnh1AvNRv9nDCI6zQLtNbI9q91TajdDlVL4yWw5jhdwqKlGbXQVTaJ j3Jj7yuSXTSSwVw1xi3temy69ah3sM0QI= Received: by sail-ipv4.us-core.com (OpenSMTPD) with ESMTPSA id 0f22cf46 (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO) for ; Sun, 14 May 2023 21:53:05 +0000 (UTC) Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-4efe8991b8aso14235040e87.0 for ; Sun, 14 May 2023 14:53:05 -0700 (PDT) X-Gm-Message-State: AC+VfDwJmUH2W7AlKoBaJYFZk+morII0vdXQxsByEpIIok2RNxX7b6G6 gsN0Jrx+HlqeOgZZ/9u3Tr6SOlb3Rl1VR/BYAr4= X-Google-Smtp-Source: ACHHUZ5ixZkeNdqcrLrkZFXwmFp+XWHS48h6rAmfAyAHCxN5rJa+d4+8m+JZ/yC8kOEX1hVkl52eCUl50VoQgHeEp/g= X-Received: by 2002:ac2:5a0f:0:b0:4ea:fdcf:8f60 with SMTP id q15-20020ac25a0f000000b004eafdcf8f60mr5598143lfn.3.1684101182860; Sun, 14 May 2023 14:53:02 -0700 (PDT) MIME-Version: 1.0 Date: Sun, 14 May 2023 14:52:26 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Defaulting to MAC-based names for network interfaces To: Guix Devel Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=208.82.101.137; envelope-from=felix.lechner@lease-up.com; helo=sail-ipv4.us-core.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Felix Lechner From: Felix Lechner via "Development of GNU Guix and the GNU System distribution." Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Seal: i=1; s=key1; d=yhetil.org; t=1684101210; a=rsa-sha256; cv=none; b=UlwX3gtej0bFgu0Qbk+uepFMES+ejLcMReXGkktWdDMOXdcbitRDqN0cwjMwzXoqNnYqim I5G7mUKLCLz36jKao/F6+Hsjq0Bhe47SyDy+AfbO/PIyLJ4XzpzN382gu6F8ijI2/wUL3F K8HEjo2VqALXNhqI4H2kWK70r4+zuEzsRgiTwi4vMk7ZuUuQcUyKBXFuqCh8nmd82YX+Tp dJLBdZHMhjvFHNIDFfbMlNzmbCu0hOntTt+/6bk4NYbYjmXTrqPbVdfdzfHxSW2TZ6+iao lLphFoeUS8vE3vKzYx/z64+LRFI0JQur+9zkQtPR985zD0knF9P9/tCYfLkwjQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=lease-up.com header.s=2017 header.b=ELrPx0li; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1684101210; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=44Ji/Ib74fLPKdLsXbpR87LYqmvWmWLRuSc7rjmPkGI=; b=GvUgK6bNDHgA67VrYy295RyxeFFH9Btk4HLWCjL96Bh3aVz6Dq6eyDupw49cT0N0YAvBsj fXpHvuI4/WPTybx299LfYXP5GsXtIqIsfJxo9sXe68ns7LqFU7S6HOPBucX9w/konML5XP 8mbOLr4byQhSlthO1ECscU22lkF4sZvaGCpR8jgQTYucXDWE4gZL02yK/GSdwTsvA1OJ8k ntysDXtXssy18WWoOvyWVtPvkxrLm3Am0irVz2wtrQgTWIUksUpfp9sGQSDck7z3d9UKeT Zfl7sN0MHaeXLRmVfSYzT2KBT8JlddE8eOZB7jjUktkf6rUqkvQxy2n8PqsY+A== X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=lease-up.com header.s=2017 header.b=ELrPx0li; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -3.49 X-Spam-Score: -3.49 X-Migadu-Queue-Id: 4428431588 X-TUID: xWCm7/KiMwJw 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