Naming of network devices
- Date: Sat, 15 Jul 2017 12:24:33 +0000
- From: Ivan Shmakov <ivan@xxxxxxxxxxx>
- Subject: Naming of network devices
>>>>> Marvin Renich <mrvn@xxxxxxxxxx> writes:
> The only benefit I have seen between the new scheme and the previous
> one is that there is no state file. While getting rid of the state
> file is a nice goal, it is extremely minor compared to having short,
> simple names in common use cases like inserting a wifi usb dongle.
> And no, enp2s0f1 is neither short nor simple. It requires
> remembering three numbers and three letters that identify internal
> parts of the hardware hierarchy that are irrelevant to the sysadmin.
> With the previous scheme, an interface would be assigned a short,
> simple name the first time it was seen. The sysadmin could easily
> edit the state file to give it a more meaningful name, if desired.
> The state file already had all the other information needed to
> identify the interface; a simple one-word change in the file was
> sufficient. Whatever name was in the state file was used for that
> piece of hardware from then on. The names were at least as
> predictable as they are with the new scheme.
Somewhat recently I’ve got a bunch of nearly identical servers
to care about. With the /persistent/ (pre-Stretch) interface
names, were I to, say, move an HDDs from one box and into
another, I'd likely to end up with some “new” ethN interface
names unaccounted to in interfaces(5), and possibly other
places. Some manual intervention would be required.
With the /predictable/ (Stretch) interface names, I’d get a
fully operational system outright.
I admit that the new scheme makes considerably less sense for
the cases where you have /no/ spare identical hardware.
(As such, I’ve added a -persistent-net.rules to the udev
configuration on my few new Debian installs.)
> With the new scheme, if I want to rename the interface to something
> more meaningful, I have to go find an older machine that already has
> a persistent-net.rules file or read through a lot of documentation to
> figure out the correct syntax. I then have to determine the correct
> ATTR elements to identify the interface in question, and type all of
> that information by hand, hoping I type everything correctly.
I concur that there ought to be some more user-visible
documentation concerning the differences and how to get the
behavior the user desires.
> There is an easy fix to revert the default behavior while still
> allowing knowledgeable sysadmins to get the new behavior. On the
> other hand, those who need to administer systems but are not
> sysadmins by trade (and thus will have to do significantly more
> research to even know that the older behavior is possible) are the
> ones who need the older behavior as the default.
FSF associate member #7257 np. Home (Instrumental) — Jeff Burgess 230E 334A