Naming of network devices

[Ivan Shmakov <ivan@siamics.net>]

>>>>> Marvin Renich <mrvn@renich.org> 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