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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#210423

On Tue, Jun 25, 2019 at 07:51:53PM -0400, 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.

When dealing with other people's systems, there was always an element of 
randomness. I've run into it so often that it's just hard to understand 
why that's even debatable but I suppose people have differing 
experiences. If you're absolutely convinced that the world can't work if 
the first ethernet interface in a system isn't named eth0, just stop 
reading here because it won't get any better.

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

Really.

>> 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 never changed anything, because locking the names via udev was 
necessary to keep them from renaming themselves. So if you bought a new 
nic it would never, ever show up as eth0 without some edits.

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

The en, wl, ww, etc, prefixes tell you the exact same information (what 
the class of interface is). The remaining information also relates 
useful information as to how the interface is attached. You might 
personally not care about that information, but it seems presumptuous to 
decide that nobody should. 

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

Since I've already explained how that's helpful, I assume this is 
intentional? I understand that you refuse to believe that having more 
than one NIC is a thing.

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

So your entire issue boils down to not wanting to explain a few 
fundamental concepts and instead take some shortcuts which would *never* 
have worked reliably in all cases? I'd rather just show people how to 
find out which interfaces they have and cover all the cases without all 
the drama.

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

Then look for the line that starts with w or e. Honestly, it seems like 
you're looking for problems. (Actually it's likely that the command 
above won't work with a wireless card, which was probably configured 
with network manager via a GUI. The issues with trying to support users 
in the wild on a variety of hardware are a lot more complicated than 
what the interface is named, and few of those issues are as trivial to 
overcome. It's basically impossible to easily cover all the ways a 
modern system might be configuring its network.)

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

Since this is a debian list, forgive me for putting the command that 
works on a standard wired debian install first.

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

I never found it all that unusual to see more than one interface on a 
single user workstation. For all kinds of reasons like, "it came with 
two ethernet ports" or "the builtin one was a realtek and I wanted it to 
have an intel" or "it came with 100Mbps onboard and it needed gigabit 
(adjust to 1 and 10gbps for newer sytems)" or "the onboard one flaked 
out so I added this other thing". At this point it seems like you think 
that *your specific environment* is the only one that matters, even 
though other people are trying to make a distribution that reliably 
addresses a lot of different use cases. You're likely to continue to be 
disappointed that things are not optimized for your personal 
requirements. 

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

Criticisms based on honest investigation and grounded in facts have much 
more weight. Yes, there is a simple way to distinguish between physical 
network types.

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

#210426

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

(This shouldn't have to be said, but please don't CC me on list messages
unless you both specifically want to draw my attention to them and think
I might not read them on-list otherwise. I am clearly subscribed to the
mailing list.)

On 2019-06-26 at 14:49, Michael Stone wrote:

> On Tue, Jun 25, 2019 at 07:51:53PM -0400, The Wanderer wrote:
> 
>> On 2019-06-25 at 09:28, Michael Stone wrote:

>>> They're perfectly predictable for a given system.
>> 
>> And reasonably unpredictable between systems.
> 
> When dealing with other people's systems, there was always an
> element of randomness. I've run into it so often that it's just hard
> to understand why that's even debatable but I suppose people have 
> differing experiences. If you're absolutely convinced that the world 
> can't work if the first ethernet interface in a system isn't named 
> eth0, just stop reading here because it won't get any better.

That's such an excessive exaggeration of my position that I have a hard
time taking your associated arguments seriously.

>>> 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 never changed anything, because locking the names via udev was 
> necessary to keep them from renaming themselves. So if you bought a 
> new nic it would never, ever show up as eth0 without some edits.

Which isn't possible anyway if the network device is hardwired into the
motherboard, as is the case on every consumer-targeted system I remember
encountering for as long as I've been paying conscious attention.

While I do know where to find add-in network cards if I need or want
them, I don't know if I'd even be able to find a motherboard without
integrated networking, at least on the desktop side. (And if you're
doing expansion-card replacement on laptops, except maybe something like
replacing one wireless card with another, you're better than I am. I'm
not sure I've ever even seen a laptop with a *free* expansion slot.)

>> 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.
> 
> The en, wl, ww, etc, prefixes tell you the exact same information 
> (what the class of interface is).

I guessed there might be something like that, but couldn't remember with
confidence.

> The remaining information also relates useful information as to how 
> the interface is attached. You might personally not care about that 
> information, but it seems presumptuous to decide that nobody should.

That information can be useful in some contexts, and I'm certainly not
saying that it should not be available to people who do care about it.

But as far as I can discern, it does not tell you anything about how
you(r software) needs to handle the interface, whereas wired vs.
wireless does - and the overwhelming majority of potential end users do
not care about anything it does tell you.

If you know of any cases/examples where the exact path by which a
network device is connected to the system makes a difference to how the
system's software needs to handle it, please do explain it, and what the
different handling involved is; I haven't been able to think of any
such.

>>> That does change the name, that's the entire point.
>> 
>> With no real benefit as far as I can tell, but yes.
> 
> Since I've already explained how that's helpful, I assume this is 
> intentional? I understand that you refuse to believe that having
> more than one NIC is a thing.

Of course it's possible to have more than one NIC. That's why having the
new naming pattern available as an option is a good thing.

It's just not remotely the common case, so it shouldn't be the default;
people who need it will have an easy enough time of turning it on, but
people who don't need it are much less likely to have enough skill etc.
to turn it off. (And if they don't turn it off, it's that much harder
for skilled people to advise them on how to do things.)

>>> 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.
> 
> So your entire issue boils down to not wanting to explain a few
> fundamental concepts and instead take some shortcuts which would
> *never* have worked reliably in all cases? I'd rather just show
> people how to find out which interfaces they have and cover all the
> cases without all the drama.

In about the same terms as your entire issue boils down to not wanting
to accept that your environments are in the minority and insisting that
the defaults should reflect your special case.

No, that's not a particularly fair way to express it, but neither was
yours a particularly fair way of describing my position.

Explaining the same few fundamental concepts *over and over*, to
*everyone* you're trying to help (some of whom you may have never
encountered before, and may never encounter again), is an unwieldy and
daunting prospect, the more so when the entire thing is so unnecessary.

>>> 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.
> 
> I never found it all that unusual to see more than one interface on
> a single user workstation. For all kinds of reasons like, "it came
> with two ethernet ports"

Was this ever common on consumer systems (the sort which become
desktops)? I don't remember seeing it in more than a tiny fraction.

> or "the builtin one was a realtek and I wanted it to have an
> intel"or "it came with 100Mbps onboard and it needed gigabit (adjust
> to 1 and 10gbps for newer sytems)" or "the onboard one flaked out so
> I added this other thing".

All of those are, in fact, unusual cases. The large majority of end
users do not have enough technical savvy to swap in an expansion card.

> At this point it seems like you think that *your specific
> environment* is the only one that matters, even though other people
> are trying to make a distribution that reliably addresses a lot of
> different use cases. You're likely to continue to be disappointed
> that things are not optimized for your personal requirements.

I gave my environment as one example, and have been responding based on
it because it's what I know best. (It's not even based on Debian,
although it is based on a distro which has adopted the new naming pattern.)

Yes, of course addressing a lot of use cases is a worthwhile goal, and
I'm not trying to argue against or detract from that. It's just that it
makes more sense to optimize the default for the most common case,
especially when the less common cases all correspond to more likelihood
of being able to change away from the default.


All of which is actually afield from my original point in replying to
this thread, which is that it's not really appropriate to call either
type of configuration "predictable", because they're equally
unpredictable in different circumstances. (With the implication that
it's unfortunate at best that the people responsible for the new name
pattern decided to call it that anyway.)

Most of the other commentary about the subject, in my initial reply, was
intended as explanatory context for that point. I should arguably have
left out the remainder, regardless of how strongly I may feel about some
of it, but I didn't realize at the time that it would prove to be so
much of a distraction.

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

#210433

On Wed, Jun 26, 2019 at 08:01:56PM -0400, The Wanderer wrote:
>On 2019-06-26 at 14:49, Michael Stone wrote:
>> And never changed anything, because locking the names via udev was
>> necessary to keep them from renaming themselves. So if you bought a
>> new nic it would never, ever show up as eth0 without some edits.
>
>Which isn't possible anyway if the network device is hardwired into the
>motherboard, as is the case on every consumer-targeted system I remember
>encountering for as long as I've been paying conscious attention.

I guess you never swapped a motherboard due to a failure. I did, and it 
meant reconfiguring the network after the machine came back. This was 
much more of a pain in the neck than simply having a service tech swap 
the motherboard and turn the machine back on (in many places it means 
that you need one hardware support person and one software support 
person on hand instead of just one hardware support person). With the 
new scheme, if it was eno1 on the old motherboard, it will be eno1 on 
the new motherboard. The fact that you never ran into the problems 
doesn't mean they didn't exist.

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

#210427

On Tue 25 Jun 2019 at 19:51:53 (-0400), 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.

I think you should understand that "predictable" means capable of
being predicted. It doesn't mean you necessarily have the information
at hand to make that prediction. Someone who works on PC buses would
be in a better position.

My zodiac sign is predictable, depending only on my birthday. But
you can't tell me which.

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

By "type" I take it you mean ethernet or whatever. Well, no, if you
added a faster card, or one in a more "privileged slot", it would
grab eth0 at the next boot, and your old one would become eth1.
That's in the distant past.

In more recent times, the new one would become eth(N+1). But here the
problem was that each new card you added would itself become eth(N+2),
eth(N+3) etc, even if you were removing the old ones. That's because
udev was busy populating /etc/udev/rules.d/70-persistent-net.rules
with all the MACs it had ever caught sight of.

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

That's just not true. Here's a PC with a ethernet and wireless
interfaces running jessie:

2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0e:35:3f:68:7c brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.10/24 brd 192.168.1.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::20e:35ff:fe3f:687c/64 scope link 
       valid_lft forever preferred_lft forever
3: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 00:c0:9f:44:15:b5 brd ff:ff:ff:ff:ff:ff

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

Eh? Here's the same PC running stretch's netboot installer:

3: wlp2s4: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0e:35:3f:68:7c brd ff:ff:ff:ff:ff:ff
4: enp2s2: <BROADCAST,MULTICAST> mtu 1500 qdisc mq qlen 1000
    link/ether 00:c0:9f:44:15:b5 brd ff:ff:ff:ff:ff:ff

I'm guessing it's the p2s4 stuff that offends you. But the point is
that to know what the interface is called, you should ask the system,
not just make it up in some "traditional" manner.

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

Well, the obvious one is that you can label the slots at the back if
you have several cables to plug in. Not something many of us do, but
now it's possible for those that want it, as opposed to impossible
(or very risky).

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

I'm still running one PC with just a NIC (Seattle 2 mobo). I'm sure
I'm not alone. That's one of the virtues of linux: prolonging the
useful life of aging hardware.

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

And when it didn't: confusion and the back-and-forth so often seen on
this list.

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

Yes, ip a. Difficult, eh?

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

See the example above.

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

You're unlikely to have ifconfig and not ip. (And ifconfig has the
well-known gotcha: you need to type its path.)

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

See the example above. Again.

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

Wait a minute—you haven't paid attention to the new names yet you're
already arguing here that they shouldn't be the default?

Cheers,
David.

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

#210429

On 6/26/19 10:23 PM, David Wright wrote:

> Wait a minute—you haven't paid attention to the new names yet you're
> already arguing here that they shouldn't be the default?

I thought the naming changes (virtual IP addresses) were to benefit 
cluster management, fencing and nodes, so you could have live backup 
schemes and redundancies. ??  Ric

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

#210434

On Thu 27 Jun 2019 at 02:54:11 (-0400), Ric Moore wrote:
> On 6/26/19 10:23 PM, David Wright wrote:
> 
> > Wait a minute—you haven't paid attention to the new names yet you're
> > already arguing here that they shouldn't be the default?
> 
> I thought the naming changes (virtual IP addresses) were to benefit
> cluster management, fencing and nodes, so you could have live backup
> schemes and redundancies. ??  Ric

Sorry, I don't have a clue what this statement has to do with my comment.
And perhaps you could elaborate on how the new naming scheme for physical
interfaces relates to VIPAs.

Cheers,
David.

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

#210386

Hi!

To derail this discussion a bit more ...

On 2019-06-25 08:46:28, The Wanderer wrote:
> On 2019-06-25 at 08:11, Michael Stone wrote:
> > (...)
> > 1) the new names are predictable but not constant, so you can't
> > configure a single default across all systems
> (...)
> 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.)


This is not true. I use USB OTGs of embedded devices behind an USB hub,
and the interface names vary between various power cycles of the embedded
devices. Note the debian box keeps running in the meantime. I can turn on
the device, get interface name #1, then turn it off again, then get
interface name #1i1 (note the i1), then turn it off again, then get
interface name #2 ad nauseatum. This is all but predictable.
(on a side note, systemd-networkd can't properly Match= these things
on name as well).

I file it under "systemd promises not kept", which fills several binders,
shrug, cope with it, and move on.

Regards,
-Martin

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

#210387

On Tue, Jun 25, 2019 at 08:23:31PM +0200, Martin S. Weber wrote:
>This is not true. I use USB OTGs of embedded devices behind an USB hub,
>and the interface names vary between various power cycles of the embedded
>devices.

Current default for USB ethernet (AFAIK) is to use enxNNNNNNNNNNNN 
where the NNNNNNNNNNN is the MAC address. It might be that the fact that 
they're OTG that's confusing something, you might have an alternate 
configuration, or it could be an older version. If it is the current 
version on a clean install I'd simply consider it a bug.

>Note the debian box keeps running in the meantime. I can turn on
>the device, get interface name #1, then turn it off again, then get
>interface name #1i1 (note the i1), then turn it off again, then get
>interface name #2 ad nauseatum. This is all but predictable.

The kernel increments the USB device number for each new device. If 
you're using the systemd option to name based on device path rather than 
MAC, it's inevitable that it will change on add/remove because systemd 
is getting the information from the kernel.

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

#210384

On Tue 25 Jun 2019 at 11:09:12 (+0200), Hans wrote:
> 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.

That would depend on whether they're being *used* on systems that have
interfaces with the newer names. If so, report as a bug.

However, if you upgraded to stretch, I think you'd have to show that
you'd allowed the system to preserve the old names, rather than trying
to circumvent Debian's methods for doing so. Isn't that what you've done?

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

I expect you did, indirectly. It all depends on the conversation you
had whenever Grub was upgraded (eg, Nov 2018) as Grub attempted to
preserve changes made to /etc/default/grub. Do you have any other
files matching /etc/default/grub* ?

After all, you just wrote: "but I changed to the new names" so it
looks as if Grub succeeded in hanging on to that change. I think
you're meant to live with the old names if you were upgrading, unless
you know more that the wiki writer who wrote: "Upgrades to Stretch
will retain the old device names - despite what you will read on the
web - removing /etc/udev/rules.d/70-local-persistent-net.rules will
not give you the new names even if followed with a update-initramfs -u
and update-grub. ( have not yet found the correct Debian incantations
for this yet?? )"

Cheers,
David.

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

#210385

On Tue, Jun 25, 2019 at 01:05:56PM -0500, David Wright wrote:
> However, if you upgraded to stretch, I think you'd have to show that
> you'd allowed the system to preserve the old names, rather than trying
> to circumvent Debian's methods for doing so. Isn't that what you've done?

Upgrades to stretch keep the "eth0" style names.

> I think
> you're meant to live with the old names if you were upgrading, unless
> you know more that the wiki writer who wrote: "Upgrades to Stretch
> will retain the old device names - despite what you will read on the
> web - removing /etc/udev/rules.d/70-local-persistent-net.rules will
> not give you the new names even if followed with a update-initramfs -u
> and update-grub. ( have not yet found the correct Debian incantations
> for this yet?? )"

Had to use google to search the wiki to find out what page you're
talking about here.

Here's when it was added:

<https://wiki.debian.org/NetworkConfiguration?action=diff&rev2=95&rev1=94>

For what it's worth, the Buster (not Stretch) release notes say:

  If your system was upgraded from an earlier release, and still uses
  the old-style network interface names that were deprecated with
  stretch (such as eth0 or wlan0), you should be aware that udev in
  buster no longer supports the mechanism of defining their names via
  /etc/udev/rules.d/70-persistent-net.rules. To avoid the danger of
  your machine losing networking after the upgrade to buster, it is
  recommended that you migrate in advance to the new naming scheme [...]

This is at
<https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names>
and includes steps to do this.

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

#210360

On 06/25/2019 03:49 AM, tomas@tuxteam.de 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.

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

#210361

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

On Tue, Jun 25, 2019 at 05:07:07AM -0500, Richard Owlett wrote:
> On 06/25/2019 03:49 AM, tomas@tuxteam.de 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

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

#210362

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

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

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

#210363

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

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

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

#210364

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

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

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

#210365

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

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

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

#210366

On 2019-06-25, Hans <hans.ullrich@loop.de> 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.

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

#210395

On Tue, 25 Jun 2019 13:12:58 +0200
<tomas@tuxteam.de> 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

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

#210399

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

On 2019-06-25 at 09:06, Celejar wrote:

> On Tue, 25 Jun 2019 13:12:58 +0200
> <tomas@tuxteam.de> 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.

Not in my environment, it doesn't. That's presumably because I've
disabled programmable completion, which I do intentionally because it
produces results (IIRC relating to directory completion) which I don't like.

It's still perfectly reasonable to point this out as an approach to
take, but it would be better to note the prerequisite for it to
function, even though AFAIK that prerequisite comes enabled by default.

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

#210400

On Tue, 25 Jun 2019 19:35:03 -0400
The Wanderer <wanderer@fastmail.fm> wrote:

> On 2019-06-25 at 09:06, Celejar wrote:

...

> > certainly greater than mine - but tab completion works in this context,
> > so you can simply do 'ip addr show dev e<TAB>', etc.
> 
> Not in my environment, it doesn't. That's presumably because I've
> disabled programmable completion, which I do intentionally because it
> produces results (IIRC relating to directory completion) which I don't like.
> 
> It's still perfectly reasonable to point this out as an approach to
> take, but it would be better to note the prerequisite for it to
> function, even though AFAIK that prerequisite comes enabled by default.

Fair enough - I'm no expert in this area, and I generally use the
defaults with this sort of thing.

Celejar

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web