New nomeclature of ethernet devices

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

New nomeclature of ethernet devices

Hans-J. Ullrich
Hi folks,

there is a little thing, we should either discuss or I should be pointed to
your solution.

The issue:
Since some time the ethernet devices like wlan0 or eth0 got new names, like
wlp2s0 or enp0s9 or similar.

Whilst this is no problem to change these manually in /etc/network/interfaces,
there are a lot of programms with configration files or just scripts, which are
still using the old names.

Looking to "/etc/init.d/ifplugd" for examle, still eth* and wlan* is used.
This is only one example.

So, IMO, this is a problem, which should be discussed. Maybe this is no
problem whith a fresh installation, but many of us have systems running since
years.

The solutions coiming in my mind, are either to change scripts and config files,
which may read the existing devices (dicovered by the kernel) and then add
these into its configuration files.

The second solution, is just to add a kernel paramter, which renames the
devices (net.ifrenames=0?). But doing so, great, then you do need not the
special kernel function for the devices. I think, this is not the good idea.

The third solution, coming into my mind, is to manually edit all the
configurations and the scripts, too. Also no good idea, because after an
update, all scripts and "maybe" configuration files are overwritten.

Thinking of all solutions, there is not a really good one. The easiest is,
adding the kernel parameter into /etc/default/grub and forget about the rest.
Is this really, what we want? If so, then the kernel function (finding devices
and name them) should be removed from the kernel. Unnecessary code.

But: Maybe I am all the way wrong, and I have something not well understood.
Then please point me to my mistakes. If not, we should find a better solution
than my suggestions.

Thank you for reading this and your clemency.

Best regards

Hans



 

 

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

tomas@tuxteam.de
On Tue, Jun 25, 2019 at 10:03:48AM +0200, Hans wrote:
> Hi folks,

[...]

> The issue:
> Since some time the ethernet devices like wlan0 or eth0 got new names, like
> wlp2s0 or enp0s9 or similar.
>
> Whilst this is no problem to change these manually in /etc/network/interfaces,
> there are a lot of programms with configration files or just scripts, which are
> still using the old names.

The moniker for that is "predictable interface names". And you
seem to assume that there hasn't been a discussion.

This being Debian, there sure has been one, you just didn't
notice :-)

The default (Debian /has/ to settle for one default, since many
people installing Debian don't know or care what an interface
name is, let alone what the heck a /predictable interface name/
is), is "predictable interface names".

Since not everyone wants or likes that default, you can override
it: just just add net.ifnames=0  to your linux commandline (e.g.
in /etc/default/grub, like so [1]:

  GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0"

don't forget to run update-grub afterwards, ask here if unsure,
proceed with care, etc. etc.).

Cheers

[1] https://wiki.debian.org/NewInStretch#If_you_install_fresh_instead_of_upgrading...
   You do read the release notes, don't you? ;-)
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

Hans-J. Ullrich
Hi Tomas,

> The moniker for that is "predictable interface names". And you
> seem to assume that there hasn't been a discussion.
>
> This being Debian, there sure has been one, you just didn't
> notice :-)
>
Might be, but this does not explain, why there are still scripts and
configurations, which are still using the old names. And THAT is the problem.

> The default (Debian /has/ to settle for one default, since many
> people installing Debian don't know or care what an interface
> name is, let alone what the heck a /predictable interface name/
> is), is "predictable interface names".
>
Yes, I wrote about it. And I also told my opinion about it: If people shall
use it, why change to predictable names? That makes no sense.

> Since not everyone wants or likes that default, you can override
> it: just just add net.ifnames=0  to your linux commandline (e.g.
> in /etc/default/grub, like so [1]:
>
I did so some time, but I changed to the new names. However, looks like I have
to go back, due to the problems I mentioned.

BTW: After an upgrade there suddenly appeared a new line
GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0"
in /etc/default/grub, without my intervention! Who added this line???
 
>   GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0"
>
> don't forget to run update-grub afterwards, ask here if unsure,
> proceed with care, etc. etc.).

Of course. :)
>
> Cheers
>
> [1]
> https://wiki.debian.org/NewInStretch#If_you_install_fresh_instead_of_upgrad
> ing... You do read the release notes, don't you? ;-)
> -- t

IMO the handling of names is still half-baked and we should have a look at it.

Best

Hans

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

Richard Owlett-3
In reply to this post by tomas@tuxteam.de
On 06/25/2019 03:49 AM, [hidden email] wrote:
>
> [1] https://wiki.debian.org/NewInStretch#If_you_install_fresh_instead_of_upgrading...
>     You do read the release notes, don't you? ;-)

That reference leads to two pages worth reading by fellow newbies.

For good description of the problem (unpredictable names) and the logic
behind the chosen solution:
> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

That pages lacked explanatory examples. The fine grained details are
available at:
> https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html

Both are very well written.






Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

tomas@tuxteam.de
On Tue, Jun 25, 2019 at 05:07:07AM -0500, Richard Owlett wrote:

> On 06/25/2019 03:49 AM, [hidden email] wrote:
> >
> >[1] https://wiki.debian.org/NewInStretch#If_you_install_fresh_instead_of_upgrading...
> >    You do read the release notes, don't you? ;-)
>
> That reference leads to two pages worth reading by fellow newbies.
>
> For good description of the problem (unpredictable names) and the
> logic behind the chosen solution:
> >https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
>
> That pages lacked explanatory examples. The fine grained details are
> available at:
> >https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
>
> Both are very well written.
Thanks for clarifications

Cheers
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

Hans-J. Ullrich
In reply to this post by Richard Owlett-3
Hi Richard and Tomas,

maybe I was not clear enough. So I try to explain again:

When it is recommended to use the predictable names, then please explain me
(and all the other people), why the heck are configuration files and scripts
still using the old names.

I do not want to know, WHY these are used, and what are the CONs and PROs, and
how to disable it, I already know this.

The point is: There are many OLD files from FORMER installations of times ago,
which are NOT compatible with predictable names. THAT is the point. And THAT
should be fixed (IMHO).

Hope, that makes my point of arguing clearer. However, if this is not
interesting for anyone, just let me know and I will stop argumenting in this
discussion at once. No problem for me, I will find a solution for me. I always
do.

Best regards

Hans



And please

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

tomas@tuxteam.de
On Tue, Jun 25, 2019 at 12:56:45PM +0200, Hans wrote:
> Hi Richard and Tomas,
>
> maybe I was not clear enough. So I try to explain again:

[...]

> The point is: There are many OLD files from FORMER installations of times ago,

You mean *your* old files or those coming with *new* Debian packages?

In the former case, it's obviously on you to decide which way
you go (predictable filenames + fix your configs versus keep
the "old way" [1]). In the second, it's obviously a bug in the
package: if you spot one of those, you might want to file a bug
report.

Cheers

[1] Both are valid decisions, it's your machine, after all. I, for
   example, went the "old ways", because I do much manual config
   at the shell, and it's definitely more ergonomical to type

     ip addr show dev eth0

   than

     ip addr show dev en&$*#@p?#$%foo

   (yes, I'm exaggerating a bit for dramatical effect ;-)
   But your mileage will almost surely vary.

-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

Hans-J. Ullrich
> You mean *your* old files or those coming with *new* Debian packages?
Here I mean *new* Debian packages. What I want to say is this: Upgrading to a
new package version should not destroy the system or force the admin to edit
many configurations manually.

When it was decided to use new names, then ALL related packages should be
adapted to the new style. If it is not done, this is a bug. More over, IMO it
is a critical release bug. For a new release I expect those things fixed. It is
a thing of quality.

My intention was, to point to a problem, which for me, that no one cared and
which was noticed by nobody. To say: "We don't care, just go back to the old
style or file a bug for every package" is easy.

On the other hand: I do not care for new installations, I care for existing
installations. I do not care for my few systems, which I am using. I am
thinking of someone running hundreds or thousands of systems.

As I said, I find a solution, I always do.

Ok, let me tell my last words: You do not need to care anymore. I showed up
the problem, described it and for myself I got a solution. So: Not my problem.

Thank you for the feedback.

Best regards

Hans

P.S. I will stop talking this thematic on this list. Feel free to write to me
directly.

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

tomas@tuxteam.de
On Tue, Jun 25, 2019 at 01:36:23PM +0200, Hans wrote:
> > You mean *your* old files or those coming with *new* Debian packages?
> Here I mean *new* Debian packages. What I want to say is this: Upgrading to a
> new package version should not destroy the system or force the admin to edit
> many configurations manually.

I see. Then, these are bugs.

> When it was decided to use new names, then ALL related packages should be
> adapted to the new style [...]

I'm sure Debian developers tried to do that. But they may have missed
something. Coming up with concrete, reproducible examples would be now
the thing to do.

[...]

> P.S. I will stop talking this thematic on this list. Feel free to write to me
> directly.

This won't be possible, since your mail provider bounces my mails
(I already complained at them).

Cheers
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

Michael Stone-2
In reply to this post by Hans-J. Ullrich
On Tue, Jun 25, 2019 at 11:09:12AM +0200, Hans wrote:
>Might be, but this does not explain, why there are still scripts and
>configurations, which are still using the old names. And THAT is the problem.

It isn't because:
1) the new names are predictable but not constant, so you can't
configure a single default across all systems
2) most software doesn't care about interfaces, so doesn't need to have
an interface configured
3) software that does care about interfaces generally needs some
additional configuration, so the defaults aren't relevant
4) if there are isolated exceptions, they can be dealt with as they are
noticed. if software is used so little that nobody has noticed that it's
not working, there are probably bigger issues with the package.

>> The default (Debian /has/ to settle for one default, since many
>> people installing Debian don't know or care what an interface
>> name is, let alone what the heck a /predictable interface name/
>> is), is "predictable interface names".
>>
>Yes, I wrote about it. And I also told my opinion about it: If people shall
>use it, why change to predictable names? That makes no sense.

They are tremendously helpful if you build servers with multiple
interfaces, or you ever have to swap out a broken nic. If you have a
simple system it gets set once at install time, so who cares?

Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

Curt
In reply to this post by Hans-J. Ullrich
On 2019-06-25, Hans <[hidden email]> wrote:
>
> When it was decided to use new names, then ALL related packages should be
> adapted to the new style. If it is not done, this is a bug. More over, IMO it
> is a critical release bug. For a new release I expect those things fixed. It is
> a thing of quality.

How about coughing up the actual names, as you seem not adverse to
firing off an email or three---for those of us here in the balcony
seats---of a couple of the packages/programs with critical release bugs
related to the switch to predictable interface names to which you are
alluding.

Thanks in advance.

Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

The Wanderer
In reply to this post by Michael Stone-2
On 2019-06-25 at 08:11, Michael Stone wrote:

> On Tue, Jun 25, 2019 at 11:09:12AM +0200, Hans wrote:
>
>> Might be, but this does not explain, why there are still scripts
>> and configurations, which are still using the old names. And THAT
>> is the problem.
>
> It isn't because:
> 1) the new names are predictable but not constant, so you can't
> configure a single default across all systems

Which seems reasonable to describe as "unpredictable".

The way I usually describe it is as a difference of predictability
"between computers" vs. "between boots".


On a single computer with multiple interfaces of a given type (wired vs.
wireless), the old names are not predictable from one boot to the next.
This is the problem which the new-names approach was designed to solve.

However, on a single computer with at most one interface of a given
type, the names are 100% predictable from one boot to the next.

On multiple computers with at most one interface of a given type, the
names are likewise 100% predictable from one computer to the next.


On a single computer with any number of interfaces of any type, the new
names are 100% predictable from one boot to the next. (At least assuming
you don't change which slot a given network device is connected to; IIRC
that can change the assigned name, in at least some cases.)

However, on multiple computers, the new names are not at all predictable
from one computer to the next, unless the computers have "sufficiently"
identical hardware configurations.


Computers with multiple interfaces of the same type are, AFAIK always
have been, and IMO are likely to always be, much less common than
computers with at most one interface of a given type.

As a result, the problems of unpredictability between boots (with the
old names) are going to be much less commonly encountered than are the
problems of unpredictability between computers (with the new ones).

It is my opinion that the default should be set to produce predictable
results in the more common case, both because it's easier to change away
from the default on the smaller number of systems involved in the less
common case, and because those computers (being more likely to be
servers, et cetera) are more likely to be run by people who are skilled
enough to figure out how to change away from the default.


Regardless, IMO calling *either* approach "predictable network interface
names" is inappropriate, because they're both unpredictable in different
circumstances; all either one does is move the unpredictability around
as compared with the other.

>>> The default (Debian /has/ to settle for one default, since many
>>> people installing Debian don't know or care what an interface
>>> name is, let alone what the heck a /predictable interface name/
>>> is), is "predictable interface names".
>>>
>> Yes, I wrote about it. And I also told my opinion about it: If
>> people shall use it, why change to predictable names? That makes no
>> sense.
>
> They are tremendously helpful if you build servers with multiple
> interfaces, or you ever have to swap out a broken nic. If you have a
> simple system it gets set once at install time, so who cares?
Among possibly other things: anyone who has to work with multiple
systems with different hardware configurations, which have at most one
interface of each type.

Imagine carrying around a live-CD type of environment, for rescue-boot
or maintenance-boot purposes, to use on end-user computers. I work in
exactly that situation, and adapting - both scripts, and tech habits /
expectations / etc. - to the way network interface names now vary
between machines has been quite a pain.

(Setting net.ifnames=0 for that environment would be possible, but a
pain to maintain because of the way that environment gets updated from
upstream, who are outside of our control and would reject requests to
change their default because they need to support the
multiple-interfaces configuration out of the box for people who don't
have the skill to make the reverse change.)

--
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

Greg Wooledge
On Tue, Jun 25, 2019 at 08:46:28AM -0400, The Wanderer wrote:
> On a single computer with any number of interfaces of any type, the new
> names are 100% predictable from one boot to the next. (At least assuming
> you don't change which slot a given network device is connected to; IIRC
> that can change the assigned name, in at least some cases.)

At least one person in IRC reported that their interface name changed
after a motherboard firmware upgrade.  So, that's another thing to
watch for.

Debian's defaults are a bit baffling sometimes.  They assumed a mobile
device when they decided to put "allow-hotplug" on your wired ethernet
interfaces, which breaks everything under the sun on traditional
servers or workstations in a work environment.

And then they assumed a multiple-interface server when they decided to
use "net.ifnames=1" in stretch.

So I guess the full assumed target for a Debian installation is a mobile
laptop server with multiple removable ethernet interfaces, which is
not starting any network services at boot time.  (And doesn't need any
non-free firmware to do its job.)

I'm sure such a machine exists somewhere in the universe....

Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

celejar
In reply to this post by tomas@tuxteam.de
On Tue, 25 Jun 2019 13:12:58 +0200
<[hidden email]> wrote:

...

> [1] Both are valid decisions, it's your machine, after all. I, for
>    example, went the "old ways", because I do much manual config
>    at the shell, and it's definitely more ergonomical to type
>
>      ip addr show dev eth0
>
>    than
>
>      ip addr show dev en&$*#@p?#$%foo
>
>    (yes, I'm exaggerating a bit for dramatical effect ;-)
>    But your mileage will almost surely vary.

Forgive me if I'm pointing out the obvious - your CLI skills are
certainly greater than mine - but tab completion works in this context,
so you can simply do 'ip addr show dev e<TAB>', etc.

Celejar

Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

Michael Stone-2
In reply to this post by The Wanderer
On Tue, Jun 25, 2019 at 08:46:28AM -0400, The Wanderer wrote:

>On 2019-06-25 at 08:11, Michael Stone wrote:
>
>> On Tue, Jun 25, 2019 at 11:09:12AM +0200, Hans wrote:
>>
>>> Might be, but this does not explain, why there are still scripts
>>> and configurations, which are still using the old names. And THAT
>>> is the problem.
>>
>> It isn't because:
>> 1) the new names are predictable but not constant, so you can't
>> configure a single default across all systems
>
>Which seems reasonable to describe as "unpredictable".

They're perfectly predictable for a given system. The old names also
weren't constant, but people didn't seem to care as much about the
nuances because "that's the way it's always been". (Sometimes it was an
eth, sometimes it was a wlan, etc.) Why were those differences ok but
these differences aren't? Familiarity.

>On a single computer with any number of interfaces of any type, the new
>names are 100% predictable from one boot to the next. (At least assuming
>you don't change which slot a given network device is connected to; IIRC
>that can change the assigned name, in at least some cases.)

That does change the name, that's the entire point.

>Computers with multiple interfaces of the same type are, AFAIK always
>have been, and IMO are likely to always be, much less common than
>computers with at most one interface of a given type.

They're also the only computers where the name actually matters. In the
simple case it's set at install time and doesn't change, so it could be
completely random and it wouldn't make a difference.

>> They are tremendously helpful if you build servers with multiple
>> interfaces, or you ever have to swap out a broken nic. If you have a
>> simple system it gets set once at install time, so who cares?
>
>Among possibly other things: anyone who has to work with multiple
>systems with different hardware configurations, which have at most one
>interface of each type.
>
>Imagine carrying around a live-CD type of environment, for rescue-boot
>or maintenance-boot purposes, to use on end-user computers. I work in
>exactly that situation, and adapting - both scripts, and tech habits /
>expectations / etc. - to the way network interface names now vary
>between machines has been quite a pain.

ifquery --list | grep -v lo

If there's more than one result, it was going to be hard "the old way"
also. More portably, something like

ip -o l | awk '{sub(/:/, "", $2); if ($2 != "lo") print $2}'

or

ip -o l | awk '{sub(/:/, "", $2); if ($2 != "lo") {print $2; exit 0}}'

if you just want the first interface

Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

Michael Stone-2
In reply to this post by Greg Wooledge
On Tue, Jun 25, 2019 at 09:05:30AM -0400, Greg Wooledge wrote:
>Debian's defaults are a bit baffling sometimes.  They assumed a mobile
>device when they decided to put "allow-hotplug" on your wired ethernet
>interfaces, which breaks everything under the sun on traditional
>servers or workstations in a work environment.

How? If the interface is in the system then allow-hotplug and auto are
synonyms. I have not observed the breakage in hundreds of servers.

Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

Greg Wooledge
On Tue, Jun 25, 2019 at 09:30:59AM -0400, Michael Stone wrote:
> On Tue, Jun 25, 2019 at 09:05:30AM -0400, Greg Wooledge wrote:
> > Debian's defaults are a bit baffling sometimes.  They assumed a mobile
> > device when they decided to put "allow-hotplug" on your wired ethernet
> > interfaces, which breaks everything under the sun on traditional
> > servers or workstations in a work environment.
>
> How? If the interface is in the system then allow-hotplug and auto are
> synonyms. I have not observed the breakage in hundreds of servers.

With the default "allow-hotplug eth0" (or whatever interface name)
setting, the NFS server will typically come up before DNS lookups are
possible.  When the NFS server starts up, it attempts to look up all
of the client hostnames in /etc/exports.  This is the *one* and *only*
time the NFS server will perform this lookup.  If the lookups fail at
this time, the NFS server will not share anything with anyone, ever.
(Until you notice the problem, and manually restart the NFS server.
A mere exportfs -a will not suffice.  It has to be a full restart.)

NIS has similar issues.  If ypbind can't contact its NIS server when
you try to start it, well, that's just too bad.  ypbind gives up and
dies, and it is not respawned.  I hope you weren't planning to login
to that machine with an NIS account.

I did say *traditional*.  I know all you young kiddies are saying "but but
but but nobody uses NIS or NFS any more, it's like, so OLD, bro, it's from
like a previous DECADE".  Well, they're still in use.  This I promise you.

And allow-hotplug breaks them.  A lot.

(I'm sure there are other services that break when allow-hotplug prevents
them from doing name lookups or whatever at boot time, but these are
the two big ones for me.)

Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

Dan Purgert
In reply to this post by Michael Stone-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Michael Stone wrote:

> On Tue, Jun 25, 2019 at 08:46:28AM -0400, The Wanderer wrote:
>>On 2019-06-25 at 08:11, Michael Stone wrote:
>>
>>> On Tue, Jun 25, 2019 at 11:09:12AM +0200, Hans wrote:
>>>
>>>> Might be, but this does not explain, why there are still scripts
>>>> and configurations, which are still using the old names. And THAT
>>>> is the problem.
>>>
>>> It isn't because:
>>> 1) the new names are predictable but not constant, so you can't
>>> configure a single default across all systems
>>
>>Which seems reasonable to describe as "unpredictable".
>
> They're perfectly predictable for a given system. The old names also

Okay, what's the ethernet interface name of this PC? :)

> weren't constant, but people didn't seem to care as much about the
> nuances because "that's the way it's always been". (Sometimes it was an
> eth, sometimes it was a wlan, etc.) Why were those differences ok but
> these differences aren't? Familiarity.

The old names were constant across systems with the same interface(s) --
i.e. an ethernet or a wifi (or both).

The "problem" with them was that they apparently weren't consistent
across boots if you had multiples of the same "type" -- although I can't
remember that ever happenening, even on crazy frankenboxes that had 3
and 4 PCI NICs in them (barring moving things around, but these
"predictable names" change too).

While the new naming has forced "predictability" of some regard, it
comes at the cost of having removed the "predictability" of naming when
communicating about disparate systems. That is, before these names a
"network problem" could be resolved with an interaction along the lines
of:

  (0) (problem description)
  (1) OK, run 'ip a list eth0 | nc termbin.com 9999' and share the link
  (2) (get the output)
  (3) Ah, there you go - it's only getting an APIPA address, check on
      your DHCP server...
 
Nowadays, with these "predictable" names, if we tell the other party the
"wrong" name, all we get is an error message that "Device 'en###'
doesn't exist".



-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl0SKL0ACgkQjhHd8xJ5
ooFauggAm8fRq0DSKayQ5E2ogdymH1GZCGyA8eleoSR3V3Ml+KE+cWqLldCsfhEa
jiOyZ4JPzr01ORuVsyWBbORNCzGVF779wFp880uANJhOZmTFgphbiOtCOFWnfM4m
lEZj0LhyJL3gojQ+2IIQZZExjHcng8YWF6NXgpbcswvXECY+RyFL15AmM2trTRRU
oZ1MYW9YWHPHcz5ut/m0/GsBTLUMlzRGhy4ead5jhypP9JW2MW6pWEvhVTvRa50I
gQo1tgpUOFH+EWiCO5A44zftnpnXLZeoTtAZ+ieOO1TTwnA7MIN23Ot3CCTDS33Z
JB4+Axu584w9/4/Y1zAYB3v2YYZjOA==
=T01x
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

Michael Stone-2
On Tue, Jun 25, 2019 at 01:59:27PM -0000, Dan Purgert wrote:
>Michael Stone wrote:
>> weren't constant, but people didn't seem to care as much about the
>> nuances because "that's the way it's always been". (Sometimes it was an
>> eth, sometimes it was a wlan, etc.) Why were those differences ok but
>> these differences aren't? Familiarity.
>
>The old names were constant across systems with the same interface(s) --
>i.e. an ethernet or a wifi (or both).

Unless you were born with that knowledge (unlikely) someone needed to
explain why some interfaces had different names than others. Now there's
just more to explain. (Actually, it's about the same, because other
things we used to have to know have faded away entirely.) Or, in the
common case, you just don't worry about it. Only if you're in the
awkward spot of really wanting to do something with a named interface
based on old knowledge, and aren't willing to learn the new rules, is
this an issue.

>The "problem" with them was that they apparently weren't consistent
>across boots if you had multiples of the same "type" -- although I can't
>remember that ever happenening, even on crazy frankenboxes that had 3
>and 4 PCI NICs in them (barring moving things around, but these
>"predictable names" change too).

The problem got increasingly bad as intialization was parallellized, to
the point that it was *quite noticible* given a large sample set of
servers. The "solution" was to lock a name to a mac via udev, but that
just made the system stable as far as which random name was assigned at
install time. So, for example, on a large set of servers with both
internal NICs and external NICs, sometimes eth0 would be an internal 1G
copper interface, and sometimes eth0 would be an external 10G fiber
interface. This sucked. The "solution" of locking the name to a MAC made
things even worse, because if you replaced a failed NIC it was
guaranteed to *not* have the same name on boot unless you went in and
manually changed the udev config. (And--DANGER WILL ROBINSON--if you
simply nuked the udev config entirely you were back to a coin flip as to
which interfaces would have which names and the machine might or might
not have a working network configuration on startup. This sucked.) Now
with a large population of servers your built-in NIC will come up as
something like eno1 and your add-in NIC will be something like ens1f0
and its second interface will be ens1f1 and even if that looks "weird"
to some, it's one hell of a lot better than flipping a coin at boot. If
hardware is replaced (literally swapped) it will come back the same way.
That's very, very good. And, again, if you're not in a position where
you want to learn what names will be used in a given situation because
you're not managing a bunch of servers, then just ignore the interface
names because they don't matter for simpler systems.

>While the new naming has forced "predictability" of some regard, it
>comes at the cost of having removed the "predictability" of naming when
>communicating about disparate systems. That is, before these names a
>"network problem" could be resolved with an interaction along the lines
>of:
>
>  (0) (problem description)
>  (1) OK, run 'ip a list eth0 | nc termbin.com 9999' and share the link
>  (2) (get the output)
>  (3) Ah, there you go - it's only getting an APIPA address, check on
>      your DHCP server...
>
>Nowadays, with these "predictable" names, if we tell the other party the
>"wrong" name, all we get is an error message that "Device 'en###'
>doesn't exist".

That's a good example of "the interface doesn't matter". Just run "ip a"
instead. If there's only one interface it's simple enough to ignore the
lo entry and if there's more than one interface *you needed to know that
anyway* because that could be the source of the problem.

Reply | Threaded
Open this post in threaded view
|

Re: New nomeclature of ethernet devices

Nate Bargmann-4
In reply to this post by Dan Purgert
* On 2019 25 Jun 09:00 -0500, Dan Purgert wrote:
> The "problem" with them was that they apparently weren't consistent
> across boots if you had multiples of the same "type" -- although I can't
> remember that ever happenening, even on crazy frankenboxes that had 3
> and 4 PCI NICs in them (barring moving things around, but these
> "predictable names" change too).

Disclaimer, I am not nor ever have been a professional admin and I've
not dealt with a computer with multiple ethernet NICs.

I seem to recall that on initial installation with some prior releases
that udev would write a rules file that mapped a hardware address to an
interface name.  I hit this a couple of times when moving a disk into
another machine and found that firewall rules didn't work since the NIC
was now eth1 instead of eth0.  A simple edit of the rules file to
comment out the eth0 stanza and renaming eth1 to eth0 and restarting
networking resolved the issue, as I recall.  It may have taken a system
restart instead, I don't remember exactly.

I'm unsure why the udev approach wasn't good enough, but here we are.
On this desktop I restored the old naming convention for various reasons
while the laptop has the new convention.  Both work, but the predictable
names are a bit of random noise to my eyes and require a moment's
parsing.

- Nate

--

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us  GPG key: D55A8819  GitHub: N0NB

signature.asc (201 bytes) Download Attachment
123