Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Michael Mol]

On 03/29/2013 08:20 AM, Samuli Suominen wrote:
> On 29/03/13 13:38, Diego Elio Pettenò wrote:
>> On 29/03/2013 12:29, Samuli Suominen wrote:
>>> One you can control, the another you can't. So still not FUD.
>>
>> You do not really control it any more than the kernel. The fact that me
>> and you can edit an udev ruleset to "control" it, does not mean that
>> most users see it as a black box.
>
> I don't agree with that, /etc/udev/rules.d and overriding udev rules is
> very basic administration, very basic...

I'd love to believe that, but do you have any idea how many people
aren't familiar with it? It took a long time before the default response
to "help, I've replaced my NIC or motherboard, and eth0 is gone!" became
"find and remove this line from
/etc/udev/rules.d/70-persistent-net.rules" instead of "remove
/etc/udev/rules.d/70-persistent-net.rules"

Something else...I've not encountered *one* other person to use anything
other than the system-default names for NICs...except myself. And when
I've done it, and despite giving them descriptive names, other people
are completely flummoxed when they see my configurations. "What's this
'wan', 'lan' and 'wifilan'? Where are eth0, eth1 and eth2?"

And of those I've found who knew of the feature and knew how to use it,
none have ever felt motivated to use it except when hardware was replaced.

(Personally, I find the feature underused; I could easily see networks
benefiting from rules like "any interface prefixed with 'p' is public
facing without the benefit of a firewall", "any interface prefixed with
's' points to a SAN" or "any interface prefixed with a 'c' is touches a
network region where PCI-compliance rules are in effect.")

> I'll put a bit more trust on our users.
>
>> The news item reads better. I would still either avoid showing the
>> NET_PATH example or describe that that is not the final result because
>> on a laptop, NET_PATH almost certainly will *not* match the final
>> interface name:
>>
>> flame@saladin~ % udevadm test-builtin net_id /sys/class/net/eno1
>> 2>/dev/null
>> ID_NET_NAME_MAC=enx0026b9d7bf1f
>> ID_OUI_FROM_DATABASE=Dell Inc
>> ID_NET_NAME_ONBOARD=eno1
>> ID_NET_LABEL_ONBOARD=en Onboard LAN
>> ID_NET_NAME_PATH=enp0s25
>>
>> And I would not expect users to all go read the wiki and try to figure
>> out why you said it would be named enp0s25 when it gets the name eno1.
>>
>
> Nod.
> Attached new version again, more generic than before.
> Hope it'll do what it's meant to do... push users into right direction...
> It's not meant to be a complete documentation or rewrite of the upstream
> wiki page :-p
> Just a push...

I would probably replace this:

"If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's
a symlink to /dev/null, the new names will be disabled and kernel will
do all the interface naming, which will be random."

With something like this:

"If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's
a symlink to /dev/null, the new names will be disabled and kernel will
do all the interface naming, and the resulting names will vary by kernel
and hardware configuration, and may vary by kernel version."