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

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

Question to new network device names

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

Contents

  Question to new network device names Hans <hans.ullrich@loop.de> - 2017-08-24 13:20 +0200
    Re: Question to new network device names Dejan Jocic <jodejka@gmail.com> - 2017-08-24 13:40 +0200
    Re: Question to new network device names Jude DaShiell <jdashiel@panix.com> - 2017-08-24 13:50 +0200
    Re: Question to new network device names <tomas@tuxteam.de> - 2017-08-24 14:00 +0200
      Re: Question to new network device names The Wanderer <wanderer@fastmail.fm> - 2017-08-24 15:20 +0200
        Re: Question to new network device names <tomas@tuxteam.de> - 2017-08-24 15:30 +0200
        Re: Question to new network device names Dave Sherohman <dave@sherohman.org> - 2017-08-24 15:40 +0200
          Re: Question to new network device names The Wanderer <wanderer@fastmail.fm> - 2017-08-24 16:00 +0200
          Re: Question to new network device names Dan Ritter <dsr@randomstring.org> - 2017-08-24 16:30 +0200
            Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-24 17:50 +0200
              Re: Question to new network device names The Wanderer <wanderer@fastmail.fm> - 2017-08-24 18:10 +0200
                Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-24 18:50 +0200
                  Re: Question to new network device names Dan Ritter <dsr@randomstring.org> - 2017-08-24 19:10 +0200
                    Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-24 20:20 +0200
                  Re: Question to new network device names The Wanderer <wanderer@fastmail.fm> - 2017-08-25 05:10 +0200
                    Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-25 07:30 +0200
              Re: Question to new network device names Dan Ritter <dsr@randomstring.org> - 2017-08-24 18:40 +0200
                Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-24 21:30 +0200
                Re: Question to new network device names Gene Heskett <gheskett@shentel.net> - 2017-08-25 03:00 +0200
                  Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-25 04:30 +0200
                    Re: Question to new network device names Gene Heskett <gheskett@shentel.net> - 2017-08-25 07:00 +0200
                      Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-25 07:30 +0200
                        Re: Question to new network device names Gene Heskett <gheskett@shentel.net> - 2017-08-25 08:30 +0200
                          Re: Question to new network device names Dan Ritter <dsr@randomstring.org> - 2017-08-25 15:30 +0200
                            Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-25 17:10 +0200
          Re: Question to new network device names Darac Marjal <mailinglist@darac.org.uk> - 2017-08-24 17:50 +0200
            Re: Question to new network device names The Wanderer <wanderer@fastmail.fm> - 2017-08-24 18:00 +0200
              Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-24 19:00 +0200
                Re: Question to new network device names Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-24 19:40 +0200
                  Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-24 20:00 +0200
        Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-24 18:20 +0200
    Re: Question to new network device names Hans <hans.ullrich@loop.de> - 2017-08-25 14:00 +0200

Page 2 of 2 — ← Prev page 1 [2]

#185880

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 <http://geneslinuxbox.net:6309/gene>

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

#185883

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.

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

#185886

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


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 <http://geneslinuxbox.net:6309/gene>

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

#185910

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

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

#185922

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

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

#185836

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

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.

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

#185837

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

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

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

#185845

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.

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

#185847

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.

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

#185849

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.

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

#185840

On Thu 24 Aug 2017 at 09:17:00 (-0400), The Wanderer wrote:
> On 2017-08-24 at 07:52, tomas@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 0000:02:02.0 enp2s2: renamed from eth0

 kernel: [  134.994910] ipw2200 0000: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.

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

#185901

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 

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web