Gentoo Archives: gentoo-dev

From: Michael Mol <mikemol@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
Date: Fri, 29 Mar 2013 12:47:49
In Reply to: Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt by Samuli Suominen
1 On 03/29/2013 08:20 AM, Samuli Suominen wrote:
2 > On 29/03/13 13:38, Diego Elio Pettenò wrote:
3 >> On 29/03/2013 12:29, Samuli Suominen wrote:
4 >>> One you can control, the another you can't. So still not FUD.
5 >>
6 >> You do not really control it any more than the kernel. The fact that me
7 >> and you can edit an udev ruleset to "control" it, does not mean that
8 >> most users see it as a black box.
9 >
10 > I don't agree with that, /etc/udev/rules.d and overriding udev rules is
11 > very basic administration, very basic...
13 I'd love to believe that, but do you have any idea how many people
14 aren't familiar with it? It took a long time before the default response
15 to "help, I've replaced my NIC or motherboard, and eth0 is gone!" became
16 "find and remove this line from
17 /etc/udev/rules.d/70-persistent-net.rules" instead of "remove
18 /etc/udev/rules.d/70-persistent-net.rules"
20 Something else...I've not encountered *one* other person to use anything
21 other than the system-default names for NICs...except myself. And when
22 I've done it, and despite giving them descriptive names, other people
23 are completely flummoxed when they see my configurations. "What's this
24 'wan', 'lan' and 'wifilan'? Where are eth0, eth1 and eth2?"
26 And of those I've found who knew of the feature and knew how to use it,
27 none have ever felt motivated to use it except when hardware was replaced.
29 (Personally, I find the feature underused; I could easily see networks
30 benefiting from rules like "any interface prefixed with 'p' is public
31 facing without the benefit of a firewall", "any interface prefixed with
32 's' points to a SAN" or "any interface prefixed with a 'c' is touches a
33 network region where PCI-compliance rules are in effect.")
35 > I'll put a bit more trust on our users.
36 >
37 >> The news item reads better. I would still either avoid showing the
38 >> NET_PATH example or describe that that is not the final result because
39 >> on a laptop, NET_PATH almost certainly will *not* match the final
40 >> interface name:
41 >>
42 >> flame@saladin~ % udevadm test-builtin net_id /sys/class/net/eno1
43 >> 2>/dev/null
44 >> ID_NET_NAME_MAC=enx0026b9d7bf1f
48 >> ID_NET_NAME_PATH=enp0s25
49 >>
50 >> And I would not expect users to all go read the wiki and try to figure
51 >> out why you said it would be named enp0s25 when it gets the name eno1.
52 >>
53 >
54 > Nod.
55 > Attached new version again, more generic than before.
56 > Hope it'll do what it's meant to do... push users into right direction...
57 > It's not meant to be a complete documentation or rewrite of the upstream
58 > wiki page :-p
59 > Just a push...
61 I would probably replace this:
63 "If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's
64 a symlink to /dev/null, the new names will be disabled and kernel will
65 do all the interface naming, which will be random."
67 With something like this:
69 "If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's
70 a symlink to /dev/null, the new names will be disabled and kernel will
71 do all the interface naming, and the resulting names will vary by kernel
72 and hardware configuration, and may vary by kernel version."


File name MIME type
signature.asc application/pgp-signature