Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #210356 > unrolled thread

New nomeclature of ethernet devices

Back to article view | Back to linux.debian.user

Contents

  New nomeclature of ethernet devices Hans <hans.ullrich@loop.de> - 2019-06-25 10:10 +0200
    Re: New nomeclature of ethernet devices <tomas@tuxteam.de> - 2019-06-25 10:50 +0200
      Re: New nomeclature of ethernet devices Hans <hans.ullrich@loop.de> - 2019-06-25 11:10 +0200
        Re: New nomeclature of ethernet devices Michael Stone <mstone@debian.org> - 2019-06-25 14:20 +0200
          Re: New nomeclature of ethernet devices The Wanderer <wanderer@fastmail.fm> - 2019-06-25 14:50 +0200
            Re: New nomeclature of ethernet devices Greg Wooledge <wooledg@eeg.ccf.org> - 2019-06-25 15:10 +0200
              Re: New nomeclature of ethernet devices Michael Stone <mstone@debian.org> - 2019-06-25 15:40 +0200
                Re: New nomeclature of ethernet devices Greg Wooledge <wooledg@eeg.ccf.org> - 2019-06-25 15:50 +0200
            Re: New nomeclature of ethernet devices Michael Stone <mstone@debian.org> - 2019-06-25 15:30 +0200
              Re: New nomeclature of ethernet devices Dan Purgert <dan@djph.net> - 2019-06-25 16:10 +0200
                Re: New nomeclature of ethernet devices Michael Stone <mstone@debian.org> - 2019-06-25 17:10 +0200
                  Re: New nomeclature of ethernet devices Nate Bargmann <n0nb@n0nb.us> - 2019-06-25 17:40 +0200
                Re: New nomeclature of ethernet devices Nate Bargmann <n0nb@n0nb.us> - 2019-06-25 17:40 +0200
                Re: New nomeclature of ethernet devices Nicholas Geovanis <nickgeovanis@gmail.com> - 2019-06-26 01:10 +0200
              Re: New nomeclature of ethernet devices The Wanderer <wanderer@fastmail.fm> - 2019-06-26 02:00 +0200
                Re: New nomeclature of ethernet devices Richard Owlett <rowlett@cloud85.net> - 2019-06-26 12:40 +0200
                Re: New nomeclature of ethernet devices Dan Purgert <dan@djph.net> - 2019-06-26 12:40 +0200
                Re: New nomeclature of ethernet devices Greg Wooledge <wooledg@eeg.ccf.org> - 2019-06-26 14:20 +0200
                  Re: New nomeclature of ethernet devices Stefan Monnier <monnier@iro.umontreal.ca> - 2019-06-26 16:10 +0200
                  Re: New nomeclature of ethernet devices Reco <recoverym4n@enotuniq.net> - 2019-06-26 16:40 +0200
                Re: New nomeclature of ethernet devices Michael Stone <mstone@debian.org> - 2019-06-26 21:00 +0200
                  Re: New nomeclature of ethernet devices The Wanderer <wanderer@fastmail.fm> - 2019-06-27 02:10 +0200
                    Re: New nomeclature of ethernet devices Michael Stone <mstone@debian.org> - 2019-06-27 13:40 +0200
                Re: New nomeclature of ethernet devices David Wright <deblis@lionunicorn.co.uk> - 2019-06-27 04:30 +0200
                  Re: New nomeclature of ethernet devices Ric Moore <wayward4now@gmail.com> - 2019-06-27 09:00 +0200
                    Re: New nomeclature of ethernet devices David Wright <deblis@lionunicorn.co.uk> - 2019-06-27 16:10 +0200
            Re: New nomeclature of ethernet devices "Martin S. Weber" <Ephaeton@gmx.net> - 2019-06-25 20:30 +0200
              Re: New nomeclature of ethernet devices Michael Stone <mstone@debian.org> - 2019-06-25 21:00 +0200
        Re: New nomeclature of ethernet devices David Wright <deblis@lionunicorn.co.uk> - 2019-06-25 20:10 +0200
          Re: New nomeclature of ethernet devices Greg Wooledge <wooledg@eeg.ccf.org> - 2019-06-25 20:30 +0200
      Re: New nomeclature of ethernet devices Richard Owlett <rowlett@cloud85.net> - 2019-06-25 12:10 +0200
        Re: New nomeclature of ethernet devices <tomas@tuxteam.de> - 2019-06-25 12:20 +0200
        Re: New nomeclature of ethernet devices Hans <hans.ullrich@loop.de> - 2019-06-25 13:00 +0200
          Re: New nomeclature of ethernet devices <tomas@tuxteam.de> - 2019-06-25 13:20 +0200
            Re: New nomeclature of ethernet devices Hans <hans.ullrich@loop.de> - 2019-06-25 13:40 +0200
              Re: New nomeclature of ethernet devices <tomas@tuxteam.de> - 2019-06-25 13:50 +0200
              Re: New nomeclature of ethernet devices Curt <curty@free.fr> - 2019-06-25 14:20 +0200
            Re: New nomeclature of ethernet devices Celejar <celejar@gmail.com> - 2019-06-26 00:10 +0200
              Re: New nomeclature of ethernet devices The Wanderer <wanderer@fastmail.fm> - 2019-06-26 01:40 +0200
                Re: New nomeclature of ethernet devices Celejar <celejar@gmail.com> - 2019-06-26 01:50 +0200
        Re: New nomeclature of ethernet devices Stefan Monnier <monnier@iro.umontreal.ca> - 2019-06-25 18:10 +0200
          Re: New nomeclature of ethernet devices David Wright <deblis@lionunicorn.co.uk> - 2019-06-25 18:30 +0200
          Re: New nomeclature of ethernet devices Michael Stone <mstone@debian.org> - 2019-06-25 18:30 +0200
            Re: New nomeclature of ethernet devices Stefan Monnier <monnier@iro.umontreal.ca> - 2019-06-25 22:30 +0200
              Re: New nomeclature of ethernet devices Michael Stone <mstone@debian.org> - 2019-06-25 22:30 +0200

Page 1 of 3  [1] 2 3  Next page →

#210356 — New nomeclature of ethernet devices

[Multipart message — attachments visible in raw view] — view raw

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



 

  

[toc] | [next] | [standalone]

#210357

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#210359

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#210367

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?

[toc] | [prev] | [next] | [standalone]

#210368

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#210372

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....

[toc] | [prev] | [next] | [standalone]

#210374

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.

[toc] | [prev] | [next] | [standalone]

#210376

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.)

[toc] | [prev] | [next] | [standalone]

#210373

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

[toc] | [prev] | [next] | [standalone]

#210377

-----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

[toc] | [prev] | [next] | [standalone]

#210378

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.

[toc] | [prev] | [next] | [standalone]

#210380

[Multipart message — attachments visible in raw view] — view raw

Thanks for explaining the limitation of the udev assignment mechanism
and why the present system was adopted.

- 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

[toc] | [prev] | [next] | [standalone]

#210379

[Multipart message — attachments visible in raw view] — view raw

* 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

[toc] | [prev] | [next] | [standalone]

#210398

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jun 25, 2019 at 9:00 AM Dan Purgert <dan@djph.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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).
>

I can't remember it ever happening either. The best "intel" I got on the
actual linux shortcoming was that NIC numbering depended
on the order in which the NICs came up and responded at power-on. Although
as you observe, I never actually saw a server come-up
out-of-order like that. Maybe PCI-mounted circuit boards are still
deterministic devices today :-) If you work in a datacenter, you are
configuring many servers at a time and machines are doing the work for you,
so you tie the MAC address to the NIC and that's done at
install time. If you were not doing that or other software you installed
relied on fixed or slowly-changing interface names, there could
be problems.


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

[toc] | [prev] | [next] | [standalone]

#210401

[Multipart message — attachments visible in raw view] — view raw

On 2019-06-25 at 09:28, 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:

>>> 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.

And reasonably unpredictable between systems.

Just reiterating the case where they *are* predictable misses my point
so badly that it almost seems as if it must be intentional.

> 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.

No, not just familiarity.

To the best of my awareness, the old names were 100% constant, as long
as you had no more than one interface *of a given type*.

And because you have to deal differently with interfaces of different
types (wireless interfaces need different userspace software from what
you need for wired ones), naming them differently - but still
predictably, in the same sense as before wireless interfaces ever
existed - was useful, because it let you easily distinguish which ones
needed which type of handling.

With the new names, the fact that two interfaces get different name
prefixes (etc.) tells you basically nothing useful about how to handle
them; it just exposes underlying hardware details of some kind, which
you don't actually need to know in order to make effective use of those
interfaces.

>> 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.

With no real benefit as far as I can tell, but yes.

It's also rare even on servers, much less on end-user systems (which
tend to have the network device hardwired into the motherboard, as often
as not). I only included that line for completism's sake - and
apparently it even misses a few cases where things can change even
without doing that, at least one of which I hadn't even considered.

>> 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.

It matters if you're giving someone directions, with the computer sight
unseen.

Before, you could write directions - or even a script - which just
referenced 'eth0' and/or 'wlan0', and hand the result out Internet-wide,
with assurance that it would work reliably for the large majority of people.

Now, you have to do something to detect the interface(s) and choose the
right one.

>>> 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

And what about when you only want the wired interface, or only the
wireless one, but the machine might have one of each type?

(Plus, I'm pretty sure the environment I work with doesn't have ifquery;
it has ifconfig, but not necessarily much beyond that. The older
versions didn't even have a DHCP client more sophisticated than dhcpcd.
I can add tools to it, but that becomes a pain to maintain, for the same
reasons as adding 'net.ifnames=0' to the kernel command line would be.)

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

Why?

Just using 'eth0' blindly wasn't hard at all, and since we're dealing
with single-user workstations which will never have more than one wired
and one wireless interface, it was a safe assumption to rely on.

> 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

I want the first (only) *wired* interface. Do the new names even
distinguish between the types? (I haven't paid them enough close
attention to have the necessary awareness of what names result in order
to be able to answer that question with any confidence.)

-- 
   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

[toc] | [prev] | [next] | [standalone]

#210411

On 06/25/2019 06:51 PM, The Wanderer wrote:
> 
> 
> I want the first (only) *wired* interface. Do the new names even
> distinguish between the types? (I haven't paid them enough close
> attention to have the necessary awareness of what names result in order
> to be able to answer that question with any confidence.)
> 

https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
> All names start with a two-character prefix that signifies the
> interface type.

[toc] | [prev] | [next] | [standalone]

#210412

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The Wanderer wrote:
> On 2019-06-25 at 09:28, 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:
>
>>>> 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.
>
> And reasonably unpredictable between systems.
>
> Just reiterating the case where they *are* predictable misses my point
> so badly that it almost seems as if it must be intentional.
>
>> 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.
>
> No, not just familiarity.
>
> To the best of my awareness, the old names were 100% constant, as long
> as you had no more than one interface *of a given type*.

Quite so.

> [...]
> With the new names, the fact that two interfaces get different name
> prefixes (etc.) tells you basically nothing useful about how to handle
> them; it just exposes underlying hardware details of some kind, which
> you don't actually need to know in order to make effective use of those
> interfaces.

To some degree.  Unless they've changed *again* (I don't follow the
"latest and greatest" changes that closely), you essentially get
"en[...]" and "wl[...]" in place of 'eth0' and 'wlan0', respectively.

That being said, the "new" names are relatively clunky to use when
working outside of "my machine here" (e.g. with users abandoning W10).

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

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl0TRvUACgkQjhHd8xJ5
ooFB9wf+MLfx2BrNGRphEH7QyBWAn1+JEdQ8LzwOVx0z3emkQavrMyHocUrafO7d
TMUwSlT/yYasePwLh7mwn1ii9/z2jmiegwdR8Ip5w6YmfSszjOu006GtKoUvHe4R
4QATY2ZiZxg0BCCWtnAG48flb81c0n+8/eC4x3OGbiSFu0/JYGEuQiWSrPeT8fRi
w9O2CA027fz6zOM+LZe1hMFNwOkManniKYrovxUqb6ydRaqyrLL9QDaWjOdBITUc
EskGRSNz2eTA6aIPrl8K3C++2C0JPYjgWpbOqXwPBasXMfd0C6YSX7Gpo3mJajFq
muN9VYkHO9ia6adcs+R8CrTi0x67ug==
=sff2
-----END PGP SIGNATURE-----

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

[toc] | [prev] | [next] | [standalone]

#210415

On Tue, Jun 25, 2019 at 07:51:53PM -0400, The Wanderer wrote:
> On 2019-06-25 at 09:28, Michael Stone wrote:
> > ifquery --list | grep -v lo
> 
> And what about when you only want the wired interface, or only the
> wireless one, but the machine might have one of each type?

/sbin/ifquery --list | grep ^en   # or grep ^wl

I'm not disagreeing with you, though.  I think the "predictable" names
cause as many problems as they solve.

[toc] | [prev] | [next] | [standalone]

#210417

> /sbin/ifquery --list | grep ^en   # or grep ^wl

Of course, this fails when for some reason (either local configuration
or lack or necessary info for "predictable" naming) the interface is
called ... eth0!


        Stefan

[toc] | [prev] | [next] | [standalone]

#210418

	Hi.

On Wed, Jun 26, 2019 at 08:15:00AM -0400, Greg Wooledge wrote:
> On Tue, Jun 25, 2019 at 07:51:53PM -0400, The Wanderer wrote:
> > On 2019-06-25 at 09:28, Michael Stone wrote:
> > > ifquery --list | grep -v lo
> > 
> > And what about when you only want the wired interface, or only the
> > wireless one, but the machine might have one of each type?
> 
> /sbin/ifquery --list | grep ^en   # or grep ^wl

$ /sbin/ifquery --list
lo
intbr
int0

The result is lacking both eth0 and wlan0 which I do have here.
The reason is - 'ifquery --list' lists only interfaces which are marked
as 'auto' in e/n/i.

I'm sticking to the plain 'ls /proc/sys/net/ipv4/conf'.
It does lie if network namespaces are taken into the account, but does
not require copious amounts of perl, sed and awk to be readable.

Reco

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web