Re: Question to new network device names

[David Wright]

On Fri 25 Aug 2017 at 09:22:56 (-0400), Dan Ritter wrote:
> On Fri, Aug 25, 2017 at 02:20:38AM -0400, Gene Heskett wrote:
> > On Friday 25 August 2017 01:27:47 David Wright wrote:
> > 
> > > > But what has that to do with having the proper entry's
> > > > in /etc/resolv.conf?  Whose active lines are:
> > > >
> > > > nameserver 192.168.71.1
> > > > search host,dns
> > >
> > > I can't parse ↑ this line. Are you sure your resolver can?
> > > Why does it contain a comma? Are "host" and "dns" domain names?
> > 
> > From man resolv.conf:
> > 
> > > search Search list for host-name lookup.
> >   The  search  list  is  normally determined from the local 
> > domain name; by default, it contains only the local domain
> >   name.  This may be changed by listing the desired domain 
> > search path following the search  keyword  with  spaces  or
> >   tabs  separating  the names.
> > 
> > So I have it wrong with my comma, but its been working for about 20 years 
> > that way. I'll fix it for S To continue
> 
> That search line makes the default domains to be searched
> ".host" and ".dns". Is that what you want?
> 
> I suspect what you actually want is in /etc/nsswitch.conf:

…which is in the previous line to the quotation above, so this
analogous aside has hopefully closed on a circle.

> hosts:  files dns
> 
> which means "look at /etc/hosts first, then check DNS".
> 
> This is the default, by the way, and has been for at least
> a decade. The most likely override to it is using an alternate
> name resolution protocol like Samba's winbind or such.

…and the longer version that I quoted,

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

indicates that I have libnss-mdns installed, related to avahi,
just in case someone comments.

Cheers,
David.

Re: Question to new network device names

[Dan Ritter]

On Fri, Aug 25, 2017 at 02:20:38AM -0400, Gene Heskett wrote:
> On Friday 25 August 2017 01:27:47 David Wright wrote:
> 
> > > But what has that to do with having the proper entry's
> > > in /etc/resolv.conf?  Whose active lines are:
> > >
> > > nameserver 192.168.71.1
> > > search host,dns
> >
> > I can't parse ↑ this line. Are you sure your resolver can?
> > Why does it contain a comma? Are "host" and "dns" domain names?
> 
> From man resolv.conf:
> 
> > search Search list for host-name lookup.
>   The  search  list  is  normally determined from the local 
> domain name; by default, it contains only the local domain
>   name.  This may be changed by listing the desired domain search 
> path following the search  keyword  with  spaces  or
>   tabs  separating  the names.
> 
> So I have it wrong with my comma, but its been working for about 20 years 
> that way. I'll fix it for S To continue

That search line makes the default domains to be searched
".host" and ".dns". Is that what you want?

I suspect what you actually want is in /etc/nsswitch.conf:

hosts:  files dns

which means "look at /etc/hosts first, then check DNS".

This is the default, by the way, and has been for at least
a decade. The most likely override to it is using an alternate
name resolution protocol like Samba's winbind or such.

-dsr-

Re: Question to new network device names

[Hans]

Hi all, 

with great interest I read all your discusssions. They were very interesting 
and I got a lot of informations. Thanks for it!

I still wondered, if the new naming scheme is more usable for unexperienced 
users, say, someone with a notebook and often changing devices, like usb-
drives, usb-sticks, wlan-sticks, gsm-sticks, mice, keyboard and so on.

I am not sure, the kernel will recognize them after a lot of use during a 
longer time. 

The other thing, I thought of: If the kernel decides, which one is the first 
network card, and which is the second, maybe this is not the line I want it, 
maybe I want it in another line, say: first ethernet is onboard, second the 1GB 
pci-card, third the pci-wireless card, fourth the usb-gsm-card.

But as I understood, the kernel telles, which one is the number 1, 2, 3 and so 
on.

I am looking at the view of an ordinary user. A user, who wants to make 
backups on an external drive, using unison or back-in-time. For me it is 
simple, to manually mount the drive with the correct folder, an unexprienced 
user expects the extrnal hard drive to be automaticlly mounted to the required 
folder - regardless which of his 5 hard-drives he chooses.

IMO, although I believe to understand the thoughts of the new scheme, I also 
believe, there are still lots of trouble following.

Last but not least, it looks like most livefile systems (i.e. kali linux) seem 
still use the old style. Maybe it is because on rescue systems people are more 
comfortable with it.

Have a nice weekend!

Best regards

Hans 

Re: Question to new network device names

[Gene Heskett]

On Friday 25 August 2017 01:27:47 David Wright wrote:

> On Fri 25 Aug 2017 at 00:54:11 (-0400), Gene Heskett wrote:
> > On Thursday 24 August 2017 22:15:53 David Wright wrote:
> > > On Thu 24 Aug 2017 at 20:58:18 (-0400), Gene Heskett wrote:
> > > > On Thursday 24 August 2017 12:30:37 Dan Ritter wrote:
> > > > > On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:
> > > > > > The history of computing is littered with statements like
> > > > > > "virtually every computer has exactly one or two NICs".
> > > > >
> > > > > It used to be zero.
> > > > >
> > > > > We are currently in the phase of history where this statement
> > > > > is true. NICs are both ubiquitous and cheap, yet devices tend
> > > > > to come with one (only an ethernet port or only a wifi radio)
> > > > > or two (one of each of those, or a wifi radio and a cell
> > > > > radio).
> > > > >
> > > > > Devices can add more, but they are always special cases: my
> > > > > Debian-running firewall has 5 ethernet ports. I occasionally
> > > > > add a USB ethernet frob in order to isolate a device that I
> > > > > want to talk to directly. Special cases deserve special
> > > > > treatment.
> > > > >
> > > > > I expect the statement to remain true for the next ten years.
> > > > >
> > > > > Do you expect differently? If so, why?
> > > > >
> > > > > > This list is full of postings about the complex DNS system.
> > > > > > But how long did /etc/hosts last? Some complexity is
> > > > > > unavoidable, but if you try to avoid it, you pay for it
> > > > > > later. Look at timezones. Ever allowing computers' internal
> > > > > > clocks to run on local time was, with hindsight, a big
> > > > > > mistake. Leap seconds might also be seen the same way (still
> > > > > > under debate).
> > > > >
> > > > > /etc/hosts still acts the way it always did -- put in an
> > > > > entry, it overrides DNS.
> > > >
> > > > That depends entirely on who wrote your /etc/resolv.conf and
> > > > whether or not your did a sudo chattr +i /etc/resolv.conf,
> > > > immediately after verifying that it works. (and of course that
> > > > implies it is a real file, not a softlink to something else. 
> > > > With N-M in the mix and active that is the only way to keep it
> > > > from tearing down your network configuration and leaving you
> > > > empty files, and no network, if it cannot find a dhcpd server)
> > >
> > > (We've heard about your problems concerning /etc/resolv.conf
> > > several times now.)
> > >
> > > I think the file that affects the priority of /etc/hosts is
> > > /etc/nsswitch.conf which typically contains a line like:
> > >
> > > hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
> >
> > But what has that to do with having the proper entry's
> > in /etc/resolv.conf?  Whose active lines are:
> >
> > nameserver 192.168.71.1
> > search host,dns
>
> I can't parse ↑ this line. Are you sure your resolver can?
> Why does it contain a comma? Are "host" and "dns" domain names?

From man resolv.conf:

> search Search list for host-name lookup.
  The  search  list  is  normally determined from the local domain 
name; by default, it contains only the local domain
  name.  This may be changed by listing the desired domain search 
path following the search  keyword  with  spaces  or
  tabs  separating  the names.

So I have it wrong with my comma, but its been working for about 20 years that 
way. I'll fix it for S To continue

  Resolver queries having fewer than ndots dots (default is 1) in them will be 
attempted
  using each component of the search path in turn until a match is 
found.  For environments with  multiple  subdomains
  please  read  options  ndots:n  below  to  avoid 
man-in-the-middle attacks and unnecessary traffic for the root-dns-
  servers.  Note that this process may be slow and will generate a 
lot of network  traffic  if  the  servers  for  the
  listed domains are not local, and that queries will time out if 
no server is available for one of the domains.

  The search list is currently limited to six domains with a total 
of 256 characters.

> > domain coyote.den
> >
> > I am willing to learn IF there is a simpler, even faster and more
> > secure way to do it than what I preach.  If those 3 criteria can be
> > satisfied, show me how.
> >
> > That search line "hosts,dns" draws a fine line between my local
> > network, which is all in the /etc/hosts file, and the rest of this
> > planet for which I need a dns server. dd-wrt in my router relays the
> > resolution requests on to my ISP's assigned dns servers, and relays
> > the results back to whatever asked for it on my home network
> > regardless of which machine or program on that machine originated
> > the request.
> >
> > AFAIK, no other processing seems to be involved.  According to htop
> > (root session) no trace of named or any other dns helper can be
> > found running on any of the 

Re: Question to new network device names

[David Wright]

On Fri 25 Aug 2017 at 00:54:11 (-0400), Gene Heskett wrote:
> On Thursday 24 August 2017 22:15:53 David Wright wrote:
> 
> > On Thu 24 Aug 2017 at 20:58:18 (-0400), Gene Heskett wrote:
> > > On Thursday 24 August 2017 12:30:37 Dan Ritter wrote:
> > > > On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:
> > > > > The history of computing is littered with statements like
> > > > > "virtually every computer has exactly one or two NICs".
> > > >
> > > > It used to be zero.
> > > >
> > > > We are currently in the phase of history where this statement is
> > > > true. NICs are both ubiquitous and cheap, yet devices tend to
> > > > come with one (only an ethernet port or only a wifi radio) or
> > > > two (one of each of those, or a wifi radio and a cell radio).
> > > >
> > > > Devices can add more, but they are always special cases: my
> > > > Debian-running firewall has 5 ethernet ports. I occasionally
> > > > add a USB ethernet frob in order to isolate a device that I want
> > > > to talk to directly. Special cases deserve special treatment.
> > > >
> > > > I expect the statement to remain true for the next ten years.
> > > >
> > > > Do you expect differently? If so, why?
> > > >
> > > > > This list is full of postings about the complex DNS system. But
> > > > > how long did /etc/hosts last? Some complexity is unavoidable,
> > > > > but if you try to avoid it, you pay for it later. Look at
> > > > > timezones. Ever allowing computers' internal clocks to run on
> > > > > local time was, with hindsight, a big mistake. Leap seconds
> > > > > might also be seen the same way (still under debate).
> > > >
> > > > /etc/hosts still acts the way it always did -- put in an entry,
> > > > it overrides DNS.
> > >
> > > That depends entirely on who wrote your /etc/resolv.conf and whether
> > > or not your did a sudo chattr +i /etc/resolv.conf, immediately after
> > > verifying that it works. (and of course that implies it is a real
> > > file, not a softlink to something else.  With N-M in the mix and
> > > active that is the only way to keep it from tearing down your
> > > network configuration and leaving you empty files, and no network,
> > > if it cannot find a dhcpd server)
> >
> > (We've heard about your problems concerning /etc/resolv.conf
> > several times now.)
> >
> > I think the file that affects the priority of /etc/hosts is
> > /etc/nsswitch.conf which typically contains a line like:
> >
> > hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
> >
> But what has that to do with having the proper entry's 
> in /etc/resolv.conf?  Whose active lines are:
> 
> nameserver 192.168.71.1
> search host,dns

I can't parse ↑ this line. Are you sure your resolver can?
Why does it contain a comma? Are "host" and "dns" domain names?

> domain coyote.den
> 
> I am willing to learn IF there is a simpler, even faster and more secure 
> way to do it than what I preach.  If those 3 criteria can be satisfied, 
> show me how.
> 
> That search line "hosts,dns" draws a fine line between my local network, 
> which is all in the /etc/hosts file, and the rest of this planet for 
> which I need a dns server. dd-wrt in my router relays the resolution 
> requests on to my ISP's assigned dns servers, and relays the results 
> back to whatever asked for it on my home network regardless of which 
> machine or program on that machine originated the request.
> 
> AFAIK, no other processing seems to be involved.  According to htop (root 
> session) no trace of named or any other dns helper can be found running 
> on any of the machines(5) running here ATM.  Pure, boiled it down to the 
> simplest way I know how, and it Just Works(TM). FWIW, denyhosts and 
> portsentry still work just fine.
> 
> Whats not to like?

Cheers,
David.

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 23:00:19 (-0400), The Wanderer wrote:
> On 2017-08-24 at 12:40, David Wright wrote:
> 
> > On Thu 24 Aug 2017 at 12:02:11 (-0400), The Wanderer wrote:
> 
> >> On 2017-08-24 at 11:43, David Wright wrote:
> 
> >>> There are plenty of ways that you, or Debian, can set a default.
> >>> But it surprises me that so many people grumble about this
> >>> change. The history of computing is littered with statements like
> >>> "virtually every computer has exactly one or two NICs".
> >> 
> >> The thing is, currently that statement[1] *is* correct, so
> >> *currently* the default should be suited for that configuration.
> >> 
> >> If things ever do reach a point where that is no longer the common
> >> case, it would then become appropriate to propose changing the
> >> default to one suited for that more-complex configuration.
> >> 
> >> But we are not yet there, or indeed anywhere close to there, so
> >> that should not yet be the default.
> > 
> > By that argument, you wait until lots of people have problems before 
> > you change the default to accomodate them, instead of thinking
> > ahead.
> 
> Well, yes - or at least until lots of people are *about to* have
> problems pretty soon, unless the default is changed first. That is at
> least preferable to *causing* lots of people to have problems (or at
> least experience additional inconvenience) by changing the default too
> far in advance.

I see. So you never consider the vanguard's problems or expectations?
If it's a question of timing, then waiting would usually suit me; as
I said, I'm usually at the trailing rather than the cutting edge.

> > If you want a simpler default, can you not follow the instructions 
> > and give yourself one.
> 
> Er... what?
> 
> A default is "what you get if you don't take steps to get something else".
> 
> If you have to take steps to achieve a given configuration, by
> definition that configuration is not the default.
> 
> Thus, since the "old" naming scheme here no longer comes as the default
> (for new installs, et cetera), I cannot make it the default.
> 
> I can certainly make local changes to get a non-default configuration,
> but that does not make that configuration the default.

Fair enough. Pick a word you prefer and override my choice of default.
Perhaps "prefer" or "override" will do. Meanwhile, I shall have words
with whoever chose the directory name /etc/default/. At the back of
my mind was adding net.ifnames=0 to GRUB_CMDLINE_LINUX in
/etc/default/grub.

> > For people upgrading, Debian ensured that there would not be an
> > unexpected change; the older methods prevail¹.
> 
> Missing footnote?

No, I put the matching ¹ at the words "udev's persistent-net rules"
in the footnote (which was more of an aside) as this is an older
method that prevails. I guess the visibility of the ¹ is something
I have no control over.

> >>> This list is full of postings about the complex DNS system. But
> >>> how long did /etc/hosts last?
> >> 
> >> It's still there and still in use, albeit not as a primary source,
> >> last I checked...
> > 
> > It's the *only* source here for such as 192.168.1.13wasp but I was
> > assuming you'd understand I was talking about non-local hosts on the
> > Internet.
> 
> Just offhand, I don't think I even remember a time when that file was
> used (outside of special one-off cases) for such hosts. I also don't
> remember encountering such a special one-off case in the past several
> years to a decade, at least, although I wouldn't be at all surprised to
> learn they still crop up.

That can't be right. You don't mean to say that people use
dotted quads to communicate with their local hosts. That's
a lot to commit to memory. I wouldn't say we have an abundance
of devices, but I am using over half the area I reserved for
static addresses, 16 out of 31. I might have been using more
but for the fact that IPv6 is available for direct links.

Cheers,
David.

Re: Question to new network device names

[Gene Heskett]

On Thursday 24 August 2017 22:15:53 David Wright wrote:

> On Thu 24 Aug 2017 at 20:58:18 (-0400), Gene Heskett wrote:
> > On Thursday 24 August 2017 12:30:37 Dan Ritter wrote:
> > > On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:
> > > > The history of computing is littered with statements like
> > > > "virtually every computer has exactly one or two NICs".
> > >
> > > It used to be zero.
> > >
> > > We are currently in the phase of history where this statement is
> > > true. NICs are both ubiquitous and cheap, yet devices tend to
> > > come with one (only an ethernet port or only a wifi radio) or
> > > two (one of each of those, or a wifi radio and a cell radio).
> > >
> > > Devices can add more, but they are always special cases: my
> > > Debian-running firewall has 5 ethernet ports. I occasionally
> > > add a USB ethernet frob in order to isolate a device that I want
> > > to talk to directly. Special cases deserve special treatment.
> > >
> > > I expect the statement to remain true for the next ten years.
> > >
> > > Do you expect differently? If so, why?
> > >
> > > > This list is full of postings about the complex DNS system. But
> > > > how long did /etc/hosts last? Some complexity is unavoidable,
> > > > but if you try to avoid it, you pay for it later. Look at
> > > > timezones. Ever allowing computers' internal clocks to run on
> > > > local time was, with hindsight, a big mistake. Leap seconds
> > > > might also be seen the same way (still under debate).
> > >
> > > /etc/hosts still acts the way it always did -- put in an entry,
> > > it overrides DNS.
> >
> > That depends entirely on who wrote your /etc/resolv.conf and whether
> > or not your did a sudo chattr +i /etc/resolv.conf, immediately after
> > verifying that it works. (and of course that implies it is a real
> > file, not a softlink to something else.  With N-M in the mix and
> > active that is the only way to keep it from tearing down your
> > network configuration and leaving you empty files, and no network,
> > if it cannot find a dhcpd server)
>
> (We've heard about your problems concerning /etc/resolv.conf
> several times now.)
>
> I think the file that affects the priority of /etc/hosts is
> /etc/nsswitch.conf which typically contains a line like:
>
> hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
>
But what has that to do with having the proper entry's 
in /etc/resolv.conf?  Whose active lines are:

nameserver 192.168.71.1
search host,dns
domain coyote.den

I am willing to learn IF there is a simpler, even faster and more secure 
way to do it than what I preach.  If those 3 criteria can be satisfied, 
show me how.

That search line "hosts,dns" draws a fine line between my local network, 
which is all in the /etc/hosts file, and the rest of this planet for 
which I need a dns server. dd-wrt in my router relays the resolution 
requests on to my ISP's assigned dns servers, and relays the results 
back to whatever asked for it on my home network regardless of which 
machine or program on that machine originated the request.

AFAIK, no other processing seems to be involved.  According to htop (root 
session) no trace of named or any other dns helper can be found running 
on any of the machines(5) running here ATM.  Pure, boiled it down to the 
simplest way I know how, and it Just Works(TM). FWIW, denyhosts and 
portsentry still work just fine.

Whats not to like?

> But that misses the point I was making, which requires one to know
> a fragment of Internet history. /etc/hosts started life as a file
> containing the address of every host on the network (then ARPANET).
> Simple, sufficient at the time, but obviously not going to stay
> the course.
>
> Similarly, /dev/sdX just about works well enough for simple, static
> systems but not for more complex, dynamic ones; eth0 likewise is
> showing its age for scaling and flexibility, particularly as the
> newer scheme adds functionality without removing the legacy.
>
> Cheers,
> David.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Question to new network device names

[The Wanderer]

On 2017-08-24 at 12:40, David Wright wrote:

> On Thu 24 Aug 2017 at 12:02:11 (-0400), The Wanderer wrote:

>> On 2017-08-24 at 11:43, David Wright wrote:

>>> There are plenty of ways that you, or Debian, can set a default.
>>> But it surprises me that so many people grumble about this
>>> change. The history of computing is littered with statements like
>>> "virtually every computer has exactly one or two NICs".
>> 
>> The thing is, currently that statement[1] *is* correct, so
>> *currently* the default should be suited for that configuration.
>> 
>> If things ever do reach a point where that is no longer the common
>> case, it would then become appropriate to propose changing the
>> default to one suited for that more-complex configuration.
>> 
>> But we are not yet there, or indeed anywhere close to there, so
>> that should not yet be the default.
> 
> By that argument, you wait until lots of people have problems before 
> you change the default to accomodate them, instead of thinking
> ahead.

Well, yes - or at least until lots of people are *about to* have
problems pretty soon, unless the default is changed first. That is at
least preferable to *causing* lots of people to have problems (or at
least experience additional inconvenience) by changing the default too
far in advance.

> If you want a simpler default, can you not follow the instructions 
> and give yourself one.

Er... what?

A default is "what you get if you don't take steps to get something else".

If you have to take steps to achieve a given configuration, by
definition that configuration is not the default.

Thus, since the "old" naming scheme here no longer comes as the default
(for new installs, et cetera), I cannot make it the default.

I can certainly make local changes to get a non-default configuration,
but that does not make that configuration the default.

> For people upgrading, Debian ensured that there would not be an
> unexpected change; the older methods prevail¹.

Missing footnote?

>>> This list is full of postings about the complex DNS system. But
>>> how long did /etc/hosts last?
>> 
>> It's still there and still in use, albeit not as a primary source,
>> last I checked...
> 
> It's the *only* source here for such as 192.168.1.13  wasp but I was
> assuming you'd understand I was talking about non-local hosts on the
> Internet.

Just offhand, I don't think I even remember a time when that file was
used (outside of special one-off cases) for such hosts. I also don't
remember encountering such a special one-off case in the past several
years to a decade, at least, although I wouldn't be at all surprised to
learn they still crop up.

-- 
   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
Description: OpenPGP digital signature

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 20:58:18 (-0400), Gene Heskett wrote:
> On Thursday 24 August 2017 12:30:37 Dan Ritter wrote:
> > On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:

> > > The history of computing is littered with statements like
> > > "virtually every computer has exactly one or two NICs".
> >
> > It used to be zero.
> >
> > We are currently in the phase of history where this statement is
> > true. NICs are both ubiquitous and cheap, yet devices tend to
> > come with one (only an ethernet port or only a wifi radio) or
> > two (one of each of those, or a wifi radio and a cell radio).
> >
> > Devices can add more, but they are always special cases: my
> > Debian-running firewall has 5 ethernet ports. I occasionally
> > add a USB ethernet frob in order to isolate a device that I want
> > to talk to directly. Special cases deserve special treatment.
> >
> > I expect the statement to remain true for the next ten years.
> >
> > Do you expect differently? If so, why?
> >
> > > This list is full of postings about the complex DNS system. But
> > > how long did /etc/hosts last? Some complexity is unavoidable,
> > > but if you try to avoid it, you pay for it later. Look at timezones.
> > > Ever allowing computers' internal clocks to run on local time
> > > was, with hindsight, a big mistake. Leap seconds might also
> > > be seen the same way (still under debate).
> >
> > /etc/hosts still acts the way it always did -- put in an entry,
> > it overrides DNS.
> >
> That depends entirely on who wrote your /etc/resolv.conf and whether or 
> not your did a sudo chattr +i /etc/resolv.conf, immediately after 
> verifying that it works. (and of course that implies it is a real file, 
> not a softlink to something else.  With N-M in the mix and active that 
> is the only way to keep it from tearing down your network configuration 
> and leaving you empty files, and no network, if it cannot find a dhcpd 
> server)

(We've heard about your problems concerning /etc/resolv.conf
several times now.)

I think the file that affects the priority of /etc/hosts is
/etc/nsswitch.conf which typically contains a line like:

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

But that misses the point I was making, which requires one to know
a fragment of Internet history. /etc/hosts started life as a file
containing the address of every host on the network (then ARPANET).
Simple, sufficient at the time, but obviously not going to stay
the course.

Similarly, /dev/sdX just about works well enough for simple, static
systems but not for more complex, dynamic ones; eth0 likewise is
showing its age for scaling and flexibility, particularly as the
newer scheme adds functionality without removing the legacy.

Cheers,
David.

Re: Question to new network device names

[Gene Heskett]

On Thursday 24 August 2017 12:30:37 Dan Ritter wrote:

> On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:
> > On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> > > There are, of course, five different ways to do this (at a
> > > minimum):
> > >
> > > 1. /dev/sda1 is based on discovery order. Changes in discovery
> > > order may indicate a significant problem that you need to
> > > investigate -- or not.
> >
> > I'm having difficulty imagining a scenario where the identity
> > of sdaX, in particular, is unimportant (for most people).
>
> Say you boot from /dev/nvme0n1p1 (a high speed NVMe SSD) and
> have /dev/sda, b, c and d in an mdadm RAID10.
>
> mdadm will scan all disks looking for its signature, and will
> assemble them into /dev/md/0 regardless of physical disk
> location. So it really won't matter to you whether you have the
> same disks in /dev/sdX from boot to boot as long as they are
> all there.
>
> But for most people, most of the time, swapping /dev/sda and
> /dev/sdc would be a problem.
>
> > But in connection with the original NIC discussion, the absence
> > of disk/by-uuid would be sorely missed if it weren't there, which
> > is why some improvement on eth0, eth1 assignment was needed,
> > and the result was a very flexible system IMO.
> >
> > > 6. Various advanced systems -- mdadm, LVM, btrfs, ZFS, hardware
> > > RAID -- have their own ideas about what to do and how to do it,
> > > which may include any of the above methods as well as their own
> > > peculiarities.
> > >
> > > That said, if you have a laptop or a desktop with 1-2 disks, you
> > > are probably going to be perfectly happy with either /dev/sda1 or
> > > LABEL=root-$HOSTNAME addressing.
> >
> > With two disks on a BIOS computer, you have an immediate problem,
> > don't you? That what disk-swapping was all about. And that was when
> > everything was on ATA.
>
> On a well-working computer, device discovery order is constant without
> physical changes. sda will always be sda, until it breaks or
> something else (bad) happens.
>
> > But now look at the debates here on, for example, how an SD card
> > is going to appear to the system. The schematic diagram of any
> > laptop looks like a forest of USBs (and other types) so which is
> > going to win the race to become sda?
>
> They don't. The SATA, SATA-DOM or NVMe disk selected by the UEFI or
> BIOS will become sda. Or if you've got an internal USB port with a
> stick in it, that might be a selected candidate. In no case
> should it change without hardware failure or physical
> rearrangement.
>
> The question is, how will your newly plugged in SD card become
> sdk rather than sdj, and the answer is that mass storage devices
> that are expected to be rearranged should be treated differently
> from those which are expected to always be available from
> boot-time onwards.
>
> > > Getting back to the original point, NIC names -- virtually every
> > > computer has exactly one or two NICs, and is best served by eth0
> > > and wlan0. The computers with 3-5 NICs are usually best served
> > > that way. More complex naming schemes are helpful when you have a
> > > router or switch, and it's nice that Debian supports that, but
> > > hardly a good default.
> >
> > There are plenty of ways that you, or Debian, can set a default.
> > But it surprises me that so many people grumble about this change.
>
> People grumble about changes for several nonexclusive reasons:
>
> 1. The change broke what they were doing.
> 2. The change broke their mental model of what they were doing.
> 3. The change did not bring them perceived benefits.
> 4. The change appears arbitrary.
> 5. The change fixed a problem but they perceive better ways to
>solve the problem.
> 6. The change creates new problems.
>
> > The history of computing is littered with statements like
> > "virtually every computer has exactly one or two NICs".
>
> It used to be zero.
>
> We are currently in the phase of history where this statement is
> true. NICs are both ubiquitous and cheap, yet devices tend to
> come with one (only an ethernet port or only a wifi radio) or
> two (one of each of those, or a wifi radio and a cell radio).
>
> Devices can add more, but they are always special cases: my
> Debian-running firewall has 5 ethernet ports. I occasionally
> add a USB ethernet frob in order to isolate a device that I want
> to talk to directly. Special cases deserve special treatment.
>
> I expect the statement to remain true for the next ten years.
>
> Do you expect differently? If so, why?
>
> > This list is full of postings about the complex DNS system. But
> > how long did /etc/hosts last? Some complexity is unavoidable,
> > but if you try to avoid it, you pay for it later. Look at timezones.
> > Ever allowing computers' internal clocks to run on local time
> > was, with hindsight, a big mistake. Leap seconds might also
> > be seen the same way (still under debate).
>
> /etc/hosts still acts the way it always did 

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 12:30:37 (-0400), Dan Ritter wrote:
> On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:
> > On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> > > There are, of course, five different ways to do this (at a
> > > minimum):
> > > 
> > > 1. /dev/sda1 is based on discovery order. Changes in discovery order
> > > may indicate a significant problem that you need to investigate -- or not.
> > 
> > I'm having difficulty imagining a scenario where the identity
> > of sdaX, in particular, is unimportant (for most people).
↑↑↑

> Say you boot from /dev/nvme0n1p1 (a high speed NVMe SSD) and 
> have /dev/sda, b, c and d in an mdadm RAID10. 
> 
> mdadm will scan all disks looking for its signature, and will
> assemble them into /dev/md/0 regardless of physical disk
> location. So it really won't matter to you whether you have the
> same disks in /dev/sdX from boot to boot as long as they are
> all there.
> 
> But for most people, most of the time, swapping /dev/sda and
> /dev/sdc would be a problem.

Yes, I assumed that *most* people boot from sda.

> > But in connection with the original NIC discussion, the absence
> > of disk/by-uuid would be sorely missed if it weren't there, which
> > is why some improvement on eth0, eth1 assignment was needed,
> > and the result was a very flexible system IMO.
> > 
> > > 6. Various advanced systems -- mdadm, LVM, btrfs, ZFS, hardware RAID --
> > > have their own ideas about what to do and how to do it, which may include
> > > any of the above methods as well as their own peculiarities.
> > > 
> > > That said, if you have a laptop or a desktop with 1-2 disks, you
> > > are probably going to be perfectly happy with either /dev/sda1 or
> > > LABEL=root-$HOSTNAME addressing.
> > 
> > With two disks on a BIOS computer, you have an immediate problem,
> > don't you? That what disk-swapping was all about. And that was when
> > everything was on ATA.
> 
> On a well-working computer, device discovery order is constant without
> physical changes. sda will always be sda, until it breaks or
> something else (bad) happens.

Passing comment: our memories are short. I remember the time when the
sole disk in a machine would vacillate between hda and sda if one was
running (as I always do) two consecutive versions of Debian. A
different cause, however.

I haven't looked back to see the number of screams. I'd left
debian-user by then on the grounds of traffic volume.

> > But now look at the debates here on, for example, how an SD card
> > is going to appear to the system. The schematic diagram of any laptop
> > looks like a forest of USBs (and other types) so which is going to win
> > the race to become sda?
> 
> They don't. The SATA, SATA-DOM or NVMe disk selected by the UEFI or BIOS
> will become sda. Or if you've got an internal USB port with a
> stick in it, that might be a selected candidate. In no case
> should it change without hardware failure or physical
> rearrangement.
> 
> The question is, how will your newly plugged in SD card become
> sdk rather than sdj, and the answer is that mass storage devices
> that are expected to be rearranged should be treated differently 
> from those which are expected to always be available from
> boot-time onwards.

You just made an assumption that does not match my reality, and
you didn't even realize that you made it. :) The SD card may
already be plugged in and contain the OS itself.

But seriously, the only point I'm trying to make here is that even the
single disk computer user should not rely on /dev/sdX names. When they
buy a new disk with perhaps a new technology, or have a failing drive
and want to copy at device-level (ie dd-style), that's precisely not
the time to be distracted by coping with hardware races and shifting
device names.

> > > Getting back to the original point, NIC names -- virtually every computer
> > > has exactly one or two NICs, and is best served by eth0 and wlan0. The
> > > computers with 3-5 NICs are usually best served that way. More complex
> > > naming schemes are helpful when you have a router or switch, and it's
> > > nice that Debian supports that, but hardly a good default.
> > 
> > There are plenty of ways that you, or Debian, can set a default.
> > But it surprises me that so many people grumble about this change.
> 
> People grumble about changes for several nonexclusive reasons:
> 
> 1. The change broke what they were doing.
> 2. The change broke their mental model of what they were doing.
> 3. The change did not bring them perceived benefits.
> 4. The change appears arbitrary.
> 5. The change fixed a problem but they perceive better ways to
>solve the problem.
> 6. The change creates new problems.

Summarising, people will grumble.

> > The history of computing is littered with statements like
> > "virtually every computer has exactly one or two NICs".
> 
> It used to be zero.
> 
> We are currently in the 

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 12:59:46 (-0400), Dan Ritter wrote:
> On Thu, Aug 24, 2017 at 11:40:28AM -0500, David Wright wrote:
> > On Thu 24 Aug 2017 at 12:02:11 (-0400), The Wanderer wrote:
> > > On 2017-08-24 at 11:43, David Wright wrote:
> > > 
> > > > On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> > > If things ever do reach a point where that is no longer the common case,
> > > it would then become appropriate to propose changing the default to one
> > > suited for that more-complex configuration.
> > > 
> > > But we are not yet there, or indeed anywhere close to there, so that
> > > should not yet be the default.
> > 
> > By that argument, you wait until lots of people have problems before
> > you change the default to accomodate them, instead of thinking ahead.
> > If you want a simpler default, can you not follow the instructions
> > and give yourself one. For people upgrading, Debian ensured that
> > there would not be an unexpected change; the older methods prevail¹.
> 
> This is the biggest systemic problem I have with Debian today.
> 
> You just made an assumption that does not match my reality, and
> you didn't even realize that you made it. 

That's rather patronising.

> I'm in charge of a lot of Debian-running machines. One of the major
> reasons that we chose Debian is because of the promise that we would be
> able to upgrade in place, rather than wiping the old OS and reinstalling.
> 
> As a result, we buy machines when we need them, not necessarily all at
> once. And we expect a new install of Stretch to behave the same way as
> an upgraded Wheezy-to-Jessie-to-Stretch. 
> 
> It does not.
> 
> That makes Debian worth less than it used to be.

Are you saying that you can get a Wheezy-to-Jessie-to-Stretch machine
to be identical to a new Stretch one without any configuration
adjustments? All you have to do is remove the constraints on the
upgraded machines to make them behave like the new ones. The place
to look is /etc/udev/rules.d/70-persistent-net.rules AIUI.

Cheers,
David.

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 13:35:17 (-0400), Greg Wooledge wrote:
> On Thu, Aug 24, 2017 at 11:51:48AM -0500, David Wright wrote:
> > For you, they wrote the last screenful of
> > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> 
> One of the bullet points on that page says:
> 
>  * Stable interface names even if you have to replace broken ethernet
>cards by new ones
> 
> But this is clearly an error, unless they meant "replace with a new
> one of exactly the same type as the old one", which is absolutely not a
> common practice.  You may not even be able to *find* another instance of
> the old one, because the manufacturer has silently changed the internal
> chipset whithout changing the model number on the box.  So you end up
> replacing your interface with a different kind, and voila!  Your
> interface name changes.

When I read that line, I assumed that replacing a NIC in the same slot
would give rise to the same enpXsY numbers which would satisfy the
user alluded to earlier when I wrote 'You can find threads here
complaining loud and long about udev's persistent-net rules, one of
the preceding methods "foisted" on us by Debian.' With the latter, the
NICs new MAC would result in a new entry in persistent-net and a name
change to eth(N+1):.

I don't think I have the hardware to try this out; my only loose NICs
are identical twins.

Cheers,
David.

Re: Question to new network device names

[Greg Wooledge]

On Thu, Aug 24, 2017 at 11:51:48AM -0500, David Wright wrote:
> For you, they wrote the last screenful of
> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

One of the bullet points on that page says:

 * Stable interface names even if you have to replace broken ethernet
   cards by new ones

But this is clearly an error, unless they meant "replace with a new
one of exactly the same type as the old one", which is absolutely not a
common practice.  You may not even be able to *find* another instance of
the old one, because the manufacturer has silently changed the internal
chipset whithout changing the model number on the box.  So you end up
replacing your interface with a different kind, and voila!  Your
interface name changes.

Of course debian-user is not the place to get errors on the freedesktop
page corrected, but the author of that page is clearly not playing by
the same rules as the rest of us.

Re: Question to new network device names

[Dan Ritter]

On Thu, Aug 24, 2017 at 11:40:28AM -0500, David Wright wrote:
> On Thu 24 Aug 2017 at 12:02:11 (-0400), The Wanderer wrote:
> > On 2017-08-24 at 11:43, David Wright wrote:
> > 
> > > On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> > If things ever do reach a point where that is no longer the common case,
> > it would then become appropriate to propose changing the default to one
> > suited for that more-complex configuration.
> > 
> > But we are not yet there, or indeed anywhere close to there, so that
> > should not yet be the default.
> 
> By that argument, you wait until lots of people have problems before
> you change the default to accomodate them, instead of thinking ahead.
> If you want a simpler default, can you not follow the instructions
> and give yourself one. For people upgrading, Debian ensured that
> there would not be an unexpected change; the older methods prevail¹.

This is the biggest systemic problem I have with Debian today.

You just made an assumption that does not match my reality, and
you didn't even realize that you made it. 

I'm in charge of a lot of Debian-running machines. One of the major
reasons that we chose Debian is because of the promise that we would be
able to upgrade in place, rather than wiping the old OS and reinstalling.

As a result, we buy machines when we need them, not necessarily all at
once. And we expect a new install of Stretch to behave the same way as
an upgraded Wheezy-to-Jessie-to-Stretch. 

It does not.

That makes Debian worth less than it used to be.

-dsr-

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 11:56:55 (-0400), The Wanderer wrote:

> At my workplace, we have over 4,000 computers, which run Windows most of
> the time but are occasionally booted to a bare-bones live-CD type of
> Linux environment (and not a particularly customizable one) for
> diagnostic and/or maintenance work.
> 
> We've had enough trouble with the fact that some of them come up with
> the interface name /dev/em1 (which I think is supplied directly by the
> kernel) rather than /dev/eth0; having the full multiplicity of names
> available under the "predictable network interface names" scheme to sort
> through, rather than at least being limited to only two, would be enough
> more of a pain that I don't want to consider it.

For you, they wrote the last screenful of
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Cheers,
David.

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 12:02:11 (-0400), The Wanderer wrote:
> On 2017-08-24 at 11:43, David Wright wrote:
> 
> > On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> 
> >> Getting back to the original point, NIC names -- virtually every
> >> computer has exactly one or two NICs, and is best served by eth0
> >> and wlan0. The computers with 3-5 NICs are usually best served that
> >> way. More complex naming schemes are helpful when you have a router
> >> or switch, and it's nice that Debian supports that, but hardly a
> >> good default.
> > 
> > There are plenty of ways that you, or Debian, can set a default. But
> > it surprises me that so many people grumble about this change. The
> > history of computing is littered with statements like "virtually
> > every computer has exactly one or two NICs".
> 
> The thing is, currently that statement[1] *is* correct, so *currently*
> the default should be suited for that configuration.
> 
> If things ever do reach a point where that is no longer the common case,
> it would then become appropriate to propose changing the default to one
> suited for that more-complex configuration.
> 
> But we are not yet there, or indeed anywhere close to there, so that
> should not yet be the default.

By that argument, you wait until lots of people have problems before
you change the default to accomodate them, instead of thinking ahead.
If you want a simpler default, can you not follow the instructions
and give yourself one. For people upgrading, Debian ensured that
there would not be an unexpected change; the older methods prevail¹.

> > This list is full of postings about the complex DNS system. But how
> > long did /etc/hosts last?
> 
> It's still there and still in use, albeit not as a primary source, last
> I checked...

It's the *only* source here for such as 192.168.1.13wasp
but I was assuming you'd understand I was talking about non-local
hosts on the Internet.

> [1] Actually, the more precise statement involving "at most one NIC of
> each type, wired and wireless" would be more accurate, because a machine
> with two NICs of the same type would still benefit from the "predictable
> network interface names" scheme.

Yes, and I remember the problems I had when all my NICs were
3c509s from the free shop (Academic Computing Services) and
I put two in the same box. These (problems) would be unacceptable
nowadays.

You can't please everyone. You can find threads here complaining
loud and long about udev's persistent-net rules¹, one of the
preceding methods "foisted" on us by Debian.

Cheers,
David.

Re: Question to new network device names

[Dan Ritter]

On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:
> On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> > There are, of course, five different ways to do this (at a
> > minimum):
> > 
> > 1. /dev/sda1 is based on discovery order. Changes in discovery order
> > may indicate a significant problem that you need to investigate -- or not.
> 
> I'm having difficulty imagining a scenario where the identity
> of sdaX, in particular, is unimportant (for most people).

Say you boot from /dev/nvme0n1p1 (a high speed NVMe SSD) and 
have /dev/sda, b, c and d in an mdadm RAID10. 

mdadm will scan all disks looking for its signature, and will
assemble them into /dev/md/0 regardless of physical disk
location. So it really won't matter to you whether you have the
same disks in /dev/sdX from boot to boot as long as they are
all there.

But for most people, most of the time, swapping /dev/sda and
/dev/sdc would be a problem.

> But in connection with the original NIC discussion, the absence
> of disk/by-uuid would be sorely missed if it weren't there, which
> is why some improvement on eth0, eth1 assignment was needed,
> and the result was a very flexible system IMO.
> 
> > 6. Various advanced systems -- mdadm, LVM, btrfs, ZFS, hardware RAID --
> > have their own ideas about what to do and how to do it, which may include
> > any of the above methods as well as their own peculiarities.
> > 
> > That said, if you have a laptop or a desktop with 1-2 disks, you
> > are probably going to be perfectly happy with either /dev/sda1 or
> > LABEL=root-$HOSTNAME addressing.
> 
> With two disks on a BIOS computer, you have an immediate problem,
> don't you? That what disk-swapping was all about. And that was when
> everything was on ATA.

On a well-working computer, device discovery order is constant without
physical changes. sda will always be sda, until it breaks or
something else (bad) happens.

> But now look at the debates here on, for example, how an SD card
> is going to appear to the system. The schematic diagram of any laptop
> looks like a forest of USBs (and other types) so which is going to win
> the race to become sda?

They don't. The SATA, SATA-DOM or NVMe disk selected by the UEFI or BIOS
will become sda. Or if you've got an internal USB port with a
stick in it, that might be a selected candidate. In no case
should it change without hardware failure or physical
rearrangement.

The question is, how will your newly plugged in SD card become
sdk rather than sdj, and the answer is that mass storage devices
that are expected to be rearranged should be treated differently 
from those which are expected to always be available from
boot-time onwards.


> > Getting back to the original point, NIC names -- virtually every computer
> > has exactly one or two NICs, and is best served by eth0 and wlan0. The
> > computers with 3-5 NICs are usually best served that way. More complex
> > naming schemes are helpful when you have a router or switch, and it's
> > nice that Debian supports that, but hardly a good default.
> 
> There are plenty of ways that you, or Debian, can set a default.
> But it surprises me that so many people grumble about this change.

People grumble about changes for several nonexclusive reasons:

1. The change broke what they were doing.
2. The change broke their mental model of what they were doing.
3. The change did not bring them perceived benefits.
4. The change appears arbitrary.
5. The change fixed a problem but they perceive better ways to
   solve the problem.
6. The change creates new problems.


> The history of computing is littered with statements like
> "virtually every computer has exactly one or two NICs".

It used to be zero.

We are currently in the phase of history where this statement is
true. NICs are both ubiquitous and cheap, yet devices tend to
come with one (only an ethernet port or only a wifi radio) or
two (one of each of those, or a wifi radio and a cell radio).

Devices can add more, but they are always special cases: my 
Debian-running firewall has 5 ethernet ports. I occasionally
add a USB ethernet frob in order to isolate a device that I want
to talk to directly. Special cases deserve special treatment.

I expect the statement to remain true for the next ten years.

Do you expect differently? If so, why?


> This list is full of postings about the complex DNS system. But
> how long did /etc/hosts last? Some complexity is unavoidable,
> but if you try to avoid it, you pay for it later. Look at timezones.
> Ever allowing computers' internal clocks to run on local time
> was, with hindsight, a big mistake. Leap seconds might also
> be seen the same way (still under debate).

/etc/hosts still acts the way it always did -- put in an entry,
it overrides DNS.

Timezones are a human legal-social problem, and the ability of
technology to deal with those is known to be problematic.

-dsr-

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 09:17:00 (-0400), The Wanderer wrote:
> On 2017-08-24 at 07:52, to...@tuxteam.de wrote:
> 
> > On Thu, Aug 24, 2017 at 01:11:27PM +0200, Hans wrote:
> >
> >> Hi folks,
> > 
> >> I stumbled over the new network names (i.e. wl0p8 instead of wlan0), and 
> >> of 
> >> course I know, that this is obviously the newe standard (please correct 
> >> me, i 
> >> I am wrong).
> 
> >> So, what is the status today? How have people accepted the new names also 
> >> for 
> >> long running systems? 
> > 
> > I'd say: if you have a box with a huge number of interfaces, or if your
> > interface's hardware is brought up dynamically (picture a bunch of USB
> > hubs with 16 eth interface adapters at its tips, to have something your
> > phantasy can attach to), where the loading order of the corresponding
> > kernel modules determine who is first and who is last, whoever is eth0
> > and whoever is eth15 may change from boot to boot.
> > 
> > You don't want that, especially when those are attached to different
> > networks (picture a firewall/router...)
> > 
> > A similar case is when the interfaces come and go (e.g. plugging in and
> > out said USB adapters. All this doesn't need to be USB -- in the more
> > expensive world you can plug in (and out!) RAM and CPUs, while the
> > system is running).
> > 
> > Predictable names (try to) bring up the "same" interface with the "same"
> > name each time (although "same" itself isn't well-defined; IMHO this
> > makes a 100% job impossible anyway).
> 
> However, I'll point out that machines with this many network interfaces
> are *by far* the exception rather than the rule; indeed, even machines
> with more than *one* interface each of wired and wireless are reasonably
> rare. As such, the scenario in which this naming scheme makes interface
> names more predictable is not one which most people will ever encounter.
> (...which calls into question the appropriateness of making this scheme
> the default.)
> 
> To the best of my awareness, the rationale for calling this "predictable
> network interface names" is that, on a single computer which has
> multiple network interfaces of a given type, this naming scheme makes
> it possible to predict *from one boot to the next* what the name of each
> one will be. On such a computer, this is extremely valuable.
> 
> By contrast, on a computer which has at most one interface of a given
> type, this naming scheme provides - so far as I can tell - no advantage
> at all.
> 
> What's more, when working on *multiple* computers of that latter type,
> this naming scheme makes it impossible to predict *from one computer to
> the next* what the name of the sole available interface will be.
> 
> As such, IMO this naming scheme makes network-interface names
> significantly *less* predictable in the real-world scenario which is
> most commonly encountered.
> 
> On that basis and from that perspective, the choice of "predictable
> network interface names" as the label for this naming scheme seems
> downright Orwellian.

Running wheezy and jessie, the lspci output from this laptop included
the lines

 02:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705 Gigabit 
Ethernet (rev 03)
 02:04.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] 
Network Connection (rev 05)

so it was "predictable¹" that installing stretch would yield these:

 kernel: [  111.443209] tg3 :02:02.0 enp2s2: renamed from eth0

 kernel: [  134.994910] ipw2200 :02:04.0 wlp2s4: renamed from eth0

in its syslog. In case the eth0 duplication perplexes you, the
wireless card in squeeze, wheezy and jessie is called eth1. Don't ask
me why. That *was* unpredictable AFAICT.

¹Predictability is based on the output of lspci, according to the
page referenced earlier.

Cheers,
David.

Re: Question to new network device names

[The Wanderer]

On 2017-08-24 at 11:43, David Wright wrote:

> On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:

>> Getting back to the original point, NIC names -- virtually every
>> computer has exactly one or two NICs, and is best served by eth0
>> and wlan0. The computers with 3-5 NICs are usually best served that
>> way. More complex naming schemes are helpful when you have a router
>> or switch, and it's nice that Debian supports that, but hardly a
>> good default.
> 
> There are plenty of ways that you, or Debian, can set a default. But
> it surprises me that so many people grumble about this change. The
> history of computing is littered with statements like "virtually
> every computer has exactly one or two NICs".

The thing is, currently that statement[1] *is* correct, so *currently*
the default should be suited for that configuration.

If things ever do reach a point where that is no longer the common case,
it would then become appropriate to propose changing the default to one
suited for that more-complex configuration.

But we are not yet there, or indeed anywhere close to there, so that
should not yet be the default.

> This list is full of postings about the complex DNS system. But how
> long did /etc/hosts last?

It's still there and still in use, albeit not as a primary source, last
I checked...


[1] Actually, the more precise statement involving "at most one NIC of
each type, wired and wireless" would be more accurate, because a machine
with two NICs of the same type would still benefit from the "predictable
network interface names" scheme.

-- 
   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
Description: OpenPGP digital signature

Re: Question to new network device names

[The Wanderer]

On 2017-08-24 at 11:48, Darac Marjal wrote:

> On Thu, Aug 24, 2017 at 08:30:33AM -0500, Dave Sherohman wrote:
> 
>> On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:

>>> To the best of my awareness, the rationale for calling this
>>> "predictable network interface names" is that, on a single
>>> computer which has multiple network interfaces of a given type,
>>> this naming scheme makes it possible to predict *from one boot to
>>> the next* what the name of each one will be. On such a computer,
>>> this is extremely valuable.
>>> 
>>> By contrast, on a computer which has at most one interface of a
>>> given type, this naming scheme provides - so far as I can tell -
>>> no advantage at all.
>>> 
>>> What's more, when working on *multiple* computers of that latter
>>> type, this naming scheme makes it impossible to predict *from one
>>> computer to the next* what the name of the sole available
>>> interface will be.
>>> 
>>> As such, IMO this naming scheme makes network-interface names 
>>> significantly *less* predictable in the real-world scenario which
>>> is most commonly encountered.
>> 
>> This closely parallels the move from using /dev/sdXn to UUIDs for 
>> referring to filesystems.  Probably superior in theory and doesn't
>> cause any issues as long as you're dealing with a single machine
>> and unchanging hardware configuration... but then you have a drive
>> failure, restore your backups onto new hardware, and you're hosed
>> because the system wants to boot from a UUID that no longer exists.
>> (Yes, you can recover from that situation - I know because I've had
>> to do it - but it doesn't Just Work(TM) effortlessly.)
> 
> I think you're right here and, in both cases, if you're not using
> more manageable names, then you're not using the system to its
> fullest.
> 
> You wouldn't refer to a host by it's IP address, or it's MAC address
> or it's Serial Number, you'd give it a name. So why not name your
> drives (and then use the by-label or LABEL= system) and why not name
> your interfaces (core-network0, core-network1, backup-lan,
> monitoring-lan - they don't HAVE to have numbers)

While that's not a bad idea... how does it help the case of "network
names are not predictable from one computer to the next"?

At my workplace, we have over 4,000 computers, which run Windows most of
the time but are occasionally booted to a bare-bones live-CD type of
Linux environment (and not a particularly customizable one) for
diagnostic and/or maintenance work.

We've had enough trouble with the fact that some of them come up with
the interface name /dev/em1 (which I think is supplied directly by the
kernel) rather than /dev/eth0; having the full multiplicity of names
available under the "predictable network interface names" scheme to sort
through, rather than at least being limited to only two, would be enough
more of a pain that I don't want to consider it.

-- 
   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
Description: OpenPGP digital signature

Re: Question to new network device names

[Darac Marjal]

On Thu, Aug 24, 2017 at 08:30:33AM -0500, Dave Sherohman wrote:

On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:

However, I'll point out that machines with this many network interfaces
are *by far* the exception rather than the rule; indeed, even machines
with more than *one* interface each of wired and wireless are reasonably
rare.


In the home desktop space, perhaps.  When you deal with rackmount
servers, OTOH, four (wired) network ports is pretty standard these days.

Of course, they're all on the same bus and using identical hardware/
firmware, so the "order might change based on which drivers load first"
case still doesn't apply.


To the best of my awareness, the rationale for calling this "predictable
network interface names" is that, on a single computer which has
multiple network interfaces of a given type, this naming scheme makes
it possible to predict *from one boot to the next* what the name of each
one will be. On such a computer, this is extremely valuable.

By contrast, on a computer which has at most one interface of a given
type, this naming scheme provides - so far as I can tell - no advantage
at all.

What's more, when working on *multiple* computers of that latter type,
this naming scheme makes it impossible to predict *from one computer to
the next* what the name of the sole available interface will be.

As such, IMO this naming scheme makes network-interface names
significantly *less* predictable in the real-world scenario which is
most commonly encountered.


This closely parallels the move from using /dev/sdXn to UUIDs for
referring to filesystems.  Probably superior in theory and doesn't cause
any issues as long as you're dealing with a single machine and
unchanging hardware configuration... but then you have a drive failure,
restore your backups onto new hardware, and you're hosed because the
system wants to boot from a UUID that no longer exists.  (Yes, you can
recover from that situation - I know because I've had to do it - but it
doesn't Just Work(TM) effortlessly.)


I think you're right here and, in both cases, if you're not using more 
manageable names, then you're not using the system to its fullest.


You wouldn't refer to a host by it's IP address, or it's MAC address or 
it's Serial Number, you'd give it a name. So why not name your drives 
(and then use the by-label or LABEL= system) and why not name your 
interfaces (core-network0, core-network1, backup-lan, monitoring-lan - 
they don't HAVE to have numbers)



--
For more information, please reread.


signature.asc
Description: PGP signature

Re: Question to new network device names

[David Wright]

On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> On Thu, Aug 24, 2017 at 08:30:33AM -0500, Dave Sherohman wrote:

> > This closely parallels the move from using /dev/sdXn to UUIDs for
> > referring to filesystems.  Probably superior in theory and doesn't cause
> > any issues as long as you're dealing with a single machine and
> > unchanging hardware configuration... but then you have a drive failure,
> > restore your backups onto new hardware, and you're hosed because the
> > system wants to boot from a UUID that no longer exists.  (Yes, you can
> > recover from that situation - I know because I've had to do it - but it
> > doesn't Just Work(TM) effortlessly.)
> 
> There are, of course, five different ways to do this (at a
> minimum):
> 
> 1. /dev/sda1 is based on discovery order. Changes in discovery order
> may indicate a significant problem that you need to investigate -- or not.

I'm having difficulty imagining a scenario where the identity
of sdaX, in particular, is unimportant (for most people).

> 2. /dev/disk/by-id/ata-Samsung_SSD_850_PRO_256GB_S251NXAH217600A is based
> on drive type and serial number. This is great if you treat changing a
> disk as a serious problem that requires human intervention, and terrible
> if you want a replacement disk to be handled automatically.

I find this useful for identifying bootable Debian USB sticks
whose 'soft' identities vary from one revision/architecture/whatever
to the next. It probably fails for multiple cheap generic USBs
that have no firmware serial number.

> 3. /dev/disk/by-label/sheepdog is based on filesystem labels.  These are
> very good for mounting but useless for identifying specific disks,
> and they can have collision problems.

I find this ideal for most disks. It's amazingly easy to write the
human-friendly LABEL on the device with a marker pen, and I do use
stable partitioning numbering. All my hard drives are labelled thus,
and the USB sticks and SD cards that aren't already identifiable.

But I understand that I'm working within my own defined universe
of devices, and don't expect this to work for all others.
(Now think NICs.)

> 4. /dev/disk/by-path/pci-:00:1f.2-ata-1-part1 is based on disk
> controller topology. If you are interested in what's in a particular
> disk slot rather than the particular disk in it, this is your choice.
> 
> 5. /dev/disk/by-uuid/428366118125845852 identifies filesystems just
> like by-label, and while it is unlikely to have an accidental collision
> problem, does have a deliberate collision problem when you have copies
> of filesystems.

If genuine GUIDs, they're great for machines but no so much for
humans. If they're not genuine, they have to be checked, if it
matters, and that can be tedious.

But in connection with the original NIC discussion, the absence
of disk/by-uuid would be sorely missed if it weren't there, which
is why some improvement on eth0, eth1 assignment was needed,
and the result was a very flexible system IMO.

> 6. Various advanced systems -- mdadm, LVM, btrfs, ZFS, hardware RAID --
> have their own ideas about what to do and how to do it, which may include
> any of the above methods as well as their own peculiarities.
> 
> That said, if you have a laptop or a desktop with 1-2 disks, you
> are probably going to be perfectly happy with either /dev/sda1 or
> LABEL=root-$HOSTNAME addressing.

With two disks on a BIOS computer, you have an immediate problem,
don't you? That what disk-swapping was all about. And that was when
everything was on ATA.

But now look at the debates here on, for example, how an SD card
is going to appear to the system. The schematic diagram of any laptop
looks like a forest of USBs (and other types) so which is going to win
the race to become sda?

> Getting back to the original point, NIC names -- virtually every computer
> has exactly one or two NICs, and is best served by eth0 and wlan0. The
> computers with 3-5 NICs are usually best served that way. More complex
> naming schemes are helpful when you have a router or switch, and it's
> nice that Debian supports that, but hardly a good default.

There are plenty of ways that you, or Debian, can set a default.
But it surprises me that so many people grumble about this change.
The history of computing is littered with statements like
"virtually every computer has exactly one or two NICs".
This list is full of postings about the complex DNS system. But
how long did /etc/hosts last? Some complexity is unavoidable,
but if you try to avoid it, you pay for it later. Look at timezones.
Ever allowing computers' internal clocks to run on local time
was, with hindsight, a big mistake. Leap seconds might also
be seen the same way (still under debate).

Cheers,
David.

Re: Question to new network device names

[Dan Ritter]

On Thu, Aug 24, 2017 at 08:30:33AM -0500, Dave Sherohman wrote:
> On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:
> > However, I'll point out that machines with this many network interfaces
> > are *by far* the exception rather than the rule; indeed, even machines
> > with more than *one* interface each of wired and wireless are reasonably
> > rare.
> 
> In the home desktop space, perhaps.  When you deal with rackmount
> servers, OTOH, four (wired) network ports is pretty standard these days.
> 
> Of course, they're all on the same bus and using identical hardware/
> firmware, so the "order might change based on which drivers load first"
> case still doesn't apply.
> 
> > To the best of my awareness, the rationale for calling this "predictable
> > network interface names" is that, on a single computer which has
> > multiple network interfaces of a given type, this naming scheme makes
> > it possible to predict *from one boot to the next* what the name of each
> > one will be. On such a computer, this is extremely valuable.
> > 
> > By contrast, on a computer which has at most one interface of a given
> > type, this naming scheme provides - so far as I can tell - no advantage
> > at all.
> > 
> > What's more, when working on *multiple* computers of that latter type,
> > this naming scheme makes it impossible to predict *from one computer to
> > the next* what the name of the sole available interface will be.
> > 
> > As such, IMO this naming scheme makes network-interface names
> > significantly *less* predictable in the real-world scenario which is
> > most commonly encountered.
> 
> This closely parallels the move from using /dev/sdXn to UUIDs for
> referring to filesystems.  Probably superior in theory and doesn't cause
> any issues as long as you're dealing with a single machine and
> unchanging hardware configuration... but then you have a drive failure,
> restore your backups onto new hardware, and you're hosed because the
> system wants to boot from a UUID that no longer exists.  (Yes, you can
> recover from that situation - I know because I've had to do it - but it
> doesn't Just Work(TM) effortlessly.)

There are, of course, five different ways to do this (at a
minimum):

1. /dev/sda1 is based on discovery order. Changes in discovery order
may indicate a significant problem that you need to investigate -- or not.

2. /dev/disk/by-id/ata-Samsung_SSD_850_PRO_256GB_S251NXAH217600A is based
on drive type and serial number. This is great if you treat changing a
disk as a serious problem that requires human intervention, and terrible
if you want a replacement disk to be handled automatically.

3. /dev/disk/by-label/sheepdog is based on filesystem labels.  These are
very good for mounting but useless for identifying specific disks,
and they can have collision problems.

4. /dev/disk/by-path/pci-:00:1f.2-ata-1-part1 is based on disk
controller topology. If you are interested in what's in a particular
disk slot rather than the particular disk in it, this is your choice.

5. /dev/disk/by-uuid/428366118125845852 identifies filesystems just
like by-label, and while it is unlikely to have an accidental collision
problem, does have a deliberate collision problem when you have copies
of filesystems.

6. Various advanced systems -- mdadm, LVM, btrfs, ZFS, hardware RAID --
have their own ideas about what to do and how to do it, which may include
any of the above methods as well as their own peculiarities.

That said, if you have a laptop or a desktop with 1-2 disks, you
are probably going to be perfectly happy with either /dev/sda1 or
LABEL=root-$HOSTNAME addressing.

Getting back to the original point, NIC names -- virtually every computer
has exactly one or two NICs, and is best served by eth0 and wlan0. The
computers with 3-5 NICs are usually best served that way. More complex
naming schemes are helpful when you have a router or switch, and it's
nice that Debian supports that, but hardly a good default.

-dsr-

Re: Question to new network device names

[The Wanderer]

On 2017-08-24 at 09:30, Dave Sherohman wrote:

> On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:
> 
>> However, I'll point out that machines with this many network
>> interfaces are *by far* the exception rather than the rule; indeed,
>> even machines with more than *one* interface each of wired and
>> wireless are reasonably rare.
> 
> In the home desktop space, perhaps.  When you deal with rackmount 
> servers, OTOH, four (wired) network ports is pretty standard these
> days.

The computers I'm considering as what Carroll called the "universe of
discourse" here are "all computers on which this naming scheme is being
used". Whether they are servers or home desktops or business desktops or
smartphones or wireless access points or televisions or coffeepots or
anything else is irrelevant.

(Although of course several of those are unlikely to have anyone looking
at the interface names directly in the first place, so they may also be
irrelevant to the discussion.)

> Of course, they're all on the same bus and using identical hardware/ 
> firmware, so the "order might change based on which drivers load
> first" case still doesn't apply.

That's a detail I don't think I knew about.

-- 
   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
Description: OpenPGP digital signature

Re: Question to new network device names

[Dave Sherohman]

On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:
> However, I'll point out that machines with this many network interfaces
> are *by far* the exception rather than the rule; indeed, even machines
> with more than *one* interface each of wired and wireless are reasonably
> rare.

In the home desktop space, perhaps.  When you deal with rackmount
servers, OTOH, four (wired) network ports is pretty standard these days.

Of course, they're all on the same bus and using identical hardware/
firmware, so the "order might change based on which drivers load first"
case still doesn't apply.

> To the best of my awareness, the rationale for calling this "predictable
> network interface names" is that, on a single computer which has
> multiple network interfaces of a given type, this naming scheme makes
> it possible to predict *from one boot to the next* what the name of each
> one will be. On such a computer, this is extremely valuable.
> 
> By contrast, on a computer which has at most one interface of a given
> type, this naming scheme provides - so far as I can tell - no advantage
> at all.
> 
> What's more, when working on *multiple* computers of that latter type,
> this naming scheme makes it impossible to predict *from one computer to
> the next* what the name of the sole available interface will be.
> 
> As such, IMO this naming scheme makes network-interface names
> significantly *less* predictable in the real-world scenario which is
> most commonly encountered.

This closely parallels the move from using /dev/sdXn to UUIDs for
referring to filesystems.  Probably superior in theory and doesn't cause
any issues as long as you're dealing with a single machine and
unchanging hardware configuration... but then you have a drive failure,
restore your backups onto new hardware, and you're hosed because the
system wants to boot from a UUID that no longer exists.  (Yes, you can
recover from that situation - I know because I've had to do it - but it
doesn't Just Work(TM) effortlessly.)

-- 
Dave Sherohman

Re: Question to new network device names

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:
> On 2017-08-24 at 07:52, to...@tuxteam.de wrote:

[...]

> However, I'll point out that machines with this many network interfaces
> are *by far* the exception rather than the rule [...]

If you meant *me*, you're preaching to the choir :)

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlme1IoACgkQBcgs9XrR2kbmbQCfSJirmY8iieqLwjq7MHmRaDpC
s/oAnROGgCiPMwbMGFb3YjUYRRkyQTmb
=h3zq
-END PGP SIGNATURE-

Re: Question to new network device names

[The Wanderer]

On 2017-08-24 at 07:52, to...@tuxteam.de wrote:

> On Thu, Aug 24, 2017 at 01:11:27PM +0200, Hans wrote:
>
>> Hi folks,
> 
>> I stumbled over the new network names (i.e. wl0p8 instead of wlan0), and of 
>> course I know, that this is obviously the newe standard (please correct me, 
>> i 
>> I am wrong).

>> So, what is the status today? How have people accepted the new names also 
>> for 
>> long running systems? 
> 
> I'd say: if you have a box with a huge number of interfaces, or if your
> interface's hardware is brought up dynamically (picture a bunch of USB
> hubs with 16 eth interface adapters at its tips, to have something your
> phantasy can attach to), where the loading order of the corresponding
> kernel modules determine who is first and who is last, whoever is eth0
> and whoever is eth15 may change from boot to boot.
> 
> You don't want that, especially when those are attached to different
> networks (picture a firewall/router...)
> 
> A similar case is when the interfaces come and go (e.g. plugging in and
> out said USB adapters. All this doesn't need to be USB -- in the more
> expensive world you can plug in (and out!) RAM and CPUs, while the
> system is running).
> 
> Predictable names (try to) bring up the "same" interface with the "same"
> name each time (although "same" itself isn't well-defined; IMHO this
> makes a 100% job impossible anyway).

However, I'll point out that machines with this many network interfaces
are *by far* the exception rather than the rule; indeed, even machines
with more than *one* interface each of wired and wireless are reasonably
rare. As such, the scenario in which this naming scheme makes interface
names more predictable is not one which most people will ever encounter.
(...which calls into question the appropriateness of making this scheme
the default.)

To the best of my awareness, the rationale for calling this "predictable
network interface names" is that, on a single computer which has
multiple network interfaces of a given type, this naming scheme makes
it possible to predict *from one boot to the next* what the name of each
one will be. On such a computer, this is extremely valuable.

By contrast, on a computer which has at most one interface of a given
type, this naming scheme provides - so far as I can tell - no advantage
at all.

What's more, when working on *multiple* computers of that latter type,
this naming scheme makes it impossible to predict *from one computer to
the next* what the name of the sole available interface will be.

As such, IMO this naming scheme makes network-interface names
significantly *less* predictable in the real-world scenario which is
most commonly encountered.

On that basis and from that perspective, the choice of "predictable
network interface names" as the label for this naming scheme seems
downright Orwellian.

-- 
   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
Description: OpenPGP digital signature

Re: Question to new network device names

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Aug 24, 2017 at 01:11:27PM +0200, Hans wrote:
> Hi folks,
> 
> I stumbled over the new network names (i.e. wl0p8 instead of wlan0), and of 
> course I know, that this is obviously the newe standard (please correct me, i 
> I am wrong).

Relax. You can just choose whatever fits you (if you mix and match, though,
you better know what you are doing :)

> What I would like to know: Is this new naming scheme an international 
> standard 
> on all linux distributions, or is this just a debian thing? At the moment, I 
> renamed all devices to the old names (wlan0, eth0 and so on), as I many tools 
> are still want the old names (however, it might be, that these are also not 
> renewed documentations).

Freedesktop has a well-written rationale [1] for the new naming scheme. That
said, freedesktop is... freedesktop, and has a clear stance on this.

> So, what is the status today? How have people accepted the new names also for 
> long running systems? 

I'd say: if you have a box with a huge number of interfaces, or if your
interface's hardware is brought up dynamically (picture a bunch of USB
hubs with 16 eth interface adapters at its tips, to have something your
phantasy can attach to), where the loading order of the corresponding
kernel modules determine who is first and who is last, whoever is eth0
and whoever is eth15 may change from boot to boot.

You don't want that, especially when those are attached to different
networks (picture a firewall/router...)

A similar case is when the interfaces come and go (e.g. plugging in and
out said USB adapters. All this doesn't need to be USB -- in the more
expensive world you can plug in (and out!) RAM and CPUs, while the
system is running).

Predictable names (try to) bring up the "same" interface with the "same"
name each time (although "same" itself isn't well-defined; IMHO this
makes a 100% job impossible anyway).

> I think, most people might rename their stuff, just as I did, because they 
> are 
> more comfortable with the old names.

That's what I do: my workhorse has two built-in interfaces, one wired
and one wireless. Their good-ol' names are thus very predictable indeed,
namely "eth0" and "wlan0". The whole kaboodle is thus useless in this
case.

> I would be happy for a little bit background information and if I am a 
> dinosaur with old names.

If it ain't broke...

Just understand what the new scheme is for. Digest it. Convinced you
want/need it? Go for it! Not convinced? Keep the old.

Change for change's sake is as ill-advised as blind aversion to change
is.

The nice thing about free software is that you have the choice. Once you
climb up the "stack" and pile complexity up, your choice is reduced (gotta
pay a price for that comfort, right?), but the cool thing is that you
yourself find your point of equilibrium (gotta pay a price for that, and
that too: keep yourself informed :-)

Cheers

[1] 
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlmeveMACgkQBcgs9XrR2kYlrQCdGjMIngOGTuE19UYae8oV81K3
/B4AmwfG0cRdI0HnIy7VivcQKm7Tkt8e
=LX6o
-END PGP SIGNATURE-

Re: Question to new network device names

[Jude DaShiell]

No, this is not just debian, you'll find it on archlinux as well.

On Thu, 24 Aug 2017, Hans wrote:


Date: Thu, 24 Aug 2017 07:11:27
From: Hans <hans.ullr...@loop.de>
To: debian-user@lists.debian.org
Subject: Question to new network device names
Resent-Date: Thu, 24 Aug 2017 11:14:06 + (UTC)
Resent-From: debian-user@lists.debian.org

Hi folks,

I stumbled over the new network names (i.e. wl0p8 instead of wlan0), and of
course I know, that this is obviously the newe standard (please correct me, i
I am wrong).

What I would like to know: Is this new naming scheme an international standard
on all linux distributions, or is this just a debian thing? At the moment, I
renamed all devices to the old names (wlan0, eth0 and so on), as I many tools
are still want the old names (however, it might be, that these are also not
renewed documentations).

So, what is the status today? How have people accepted the new names also for
long running systems?

I think, most people might rename their stuff, just as I did, because they are
more comfortable with the old names.

I would be happy for a little bit background information and if I am a
dinosaur with old names.

Best regards

Hans





--

Re: Question to new network device names

[Dejan Jocic]

On 24-08-17, Hans wrote:
> Hi folks,
> 
> I stumbled over the new network names (i.e. wl0p8 instead of wlan0), and of 
> course I know, that this is obviously the newe standard (please correct me, i 
> I am wrong).
> 
> What I would like to know: Is this new naming scheme an international 
> standard 
> on all linux distributions, or is this just a debian thing? At the moment, I 
> renamed all devices to the old names (wlan0, eth0 and so on), as I many tools 
> are still want the old names (however, it might be, that these are also not 
> renewed documentations).
> 
> So, what is the status today? How have people accepted the new names also for 
> long running systems? 
> 
> I think, most people might rename their stuff, just as I did, because they 
> are 
> more comfortable with the old names.
> 
> I would be happy for a little bit background information and if I am a 
> dinosaur with old names.
> 
> Best regards
> 
> Hans
>  
> 

Long answer short:

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Question to new network device names

[Hans]

Hi folks,

I stumbled over the new network names (i.e. wl0p8 instead of wlan0), and of 
course I know, that this is obviously the newe standard (please correct me, i 
I am wrong).

What I would like to know: Is this new naming scheme an international standard 
on all linux distributions, or is this just a debian thing? At the moment, I 
renamed all devices to the old names (wlan0, eth0 and so on), as I many tools 
are still want the old names (however, it might be, that these are also not 
renewed documentations).

So, what is the status today? How have people accepted the new names also for 
long running systems? 

I think, most people might rename their stuff, just as I did, because they are 
more comfortable with the old names.

I would be happy for a little bit background information and if I am a 
dinosaur with old names.

Best regards

Hans