Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Russ Allbery]

Roger Lynn  writes:

> /etc/systemd/network/ doesn't exist on my system. I presume I would just
> need to create it for this to work? I haven't been able to persuade
> packages.debian.org to tell me which package it belongs to.

Yeah, you just create the directory; there isn't anything included in it
in a default Debian install.  The documentation for these files is in
systemd.network(5) and systemd.link(5).

-- 
Russ Allbery (r...@debian.org)   

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Roger Lynn]

On 13/07/17 12:40, Adam Borowski wrote:
> On Thu, Jul 13, 2017 at 05:17:57AM -0400, Tom H wrote:
> > On Wed, Jul 12, 2017 at 2:40 PM, Roger Lynn  wrote:
> > > SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:98", NAME="eth0"
> > 
> > It's simpler to use (for example)
> > 
> > # cat /etc/systemd/network/77-en0.link
> > [Match]
> > MACAddress=1c:1b:0d:9a:34:98
> > [Link]
> > Name=en0

/etc/systemd/network/ doesn't exist on my system. I presume I would just
need to create it for this to work? I haven't been able to persuade
packages.debian.org to tell me which package it belongs to.

> There's apparently also a package "ifrename" which makes writing these
> rules more user friendly. And doesn't place them in obscure places that
> change every release.

Thank you to both of you and to others for all your suggestions. Of course
if I'd read the release notes first I could have saved myself some time, but
they are usually aimed at upgrades rather than new installations and I
haven't performed any upgrades yet. I am curious as to what mechanism will
be used to preserve names on upgrades when reusing the kernel names is such
a bad idea.

Is everyone using their own custom naming schemes actually a good idea, or
would it be preferable to have some standardised names?

Roger

PS Feel free to tell me to go to Debian-User. I hoped the experience of a
"hobbyist" user would be a useful contribution.

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Adam Borowski]

On Thu, Jul 13, 2017 at 05:17:57AM -0400, Tom H wrote:
> > This caught me out on a recent new installation, which gave me these new
> > names which are too complicated to be usable. I wasted hours working out
> > what had happened, how to fix it and how to write a udev rules file from
> > scratch. And having just read this thread, I've discovered that the rules
> > I've written are themselves apparently unreliable, for example:
> > SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:98", NAME="eth0"
> > SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:9a", NAME="eth1"
> 
> It's simpler to use (for example)
> 
> # cat /etc/systemd/network/77-en0.link
> [Match]
> MACAddress=1c:1b:0d:9a:34:98
> [Link]
> Name=en0

There's apparently also a package "ifrename" which makes writing these rules
more user friendly.  And doesn't place them in obscure places that change
every release.

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Tom H]

On Wed, Jul 12, 2017 at 2:40 PM, Roger Lynn  wrote:
> On 10/07/17 19:40, Marvin Renich wrote:
>>
>> There is an easy fix to revert the default behavior while still allowing
>> knowledgeable sysadmins to get the new behavior. On the other hand,
>> those who need to administer systems but are not sysadmins by trade (and
>> thus will have to do significantly more research to even know that the
>> older behavior is possible) are the ones who need the older behavior as
>> the default.
>
> This caught me out on a recent new installation, which gave me these new
> names which are too complicated to be usable. I wasted hours working out
> what had happened, how to fix it and how to write a udev rules file from
> scratch. And having just read this thread, I've discovered that the rules
> I've written are themselves apparently unreliable, for example:
> SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:98", NAME="eth0"
> SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:9a", NAME="eth1"

It's simpler to use (for example)

# cat /etc/systemd/network/77-en0.link
[Match]
MACAddress=1c:1b:0d:9a:34:98
[Link]
Name=en0

# cat /etc/systemd/network/77-en1.link
[Match]
MACAddress=1c:1b:0d:9a:34:9a
[Link]
Name=en1

This rule works even if you use sysvinit as pid 1.

Renaming NICs within the kernel's "eth*" namespace is discouraged upstream.

Suppose that the kernel names "1c:1b:0d:9a:34:9a" "eth0" and
"1c:1b:0d:9a:34:98" "eth1". You'll have a renaming clash when udev
tries to apply your rules.

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Adam Borowski]

On Wed, Jul 12, 2017 at 07:40:13PM +0100, Roger Lynn wrote:
> On 10/07/17 19:40, Marvin Renich wrote:
> 
> 
> 
> > There is an easy fix to revert the default behavior while still allowing
> > knowledgeable sysadmins to get the new behavior.  On the other hand,
> > those who need to administer systems but are not sysadmins by trade (and
> > thus will have to do significantly more research to even know that the
> > older behavior is possible) are the ones who need the older behavior as
> > the default.
> 
> This caught me out on a recent new installation, which gave me these new
> names which are too complicated to be usable. I wasted hours working out
> what had happened, how to fix it and how to write a udev rules file from
> scratch. And having just read this thread, I've discovered that the rules
> I've written are themselves apparently unreliable, for example:
> SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:98", NAME="eth0"
> SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:9a", NAME="eth1"

This worked fine on jessie, but on stretch it doesn't anymore.
I've solved the problem by net.ifnames=0; apparently the cause is rules
numbered 73..80 overwriting those set by 70-persistent-net.rules

You also shouldn't use eth0/eth1 because the races aren't fully solved;
using descriptive names like lan0/out0 has the extra benefit of marking
which interface is used for what purpose.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Michael Biebl]

Am 12.07.2017 um 20:40 schrieb Roger Lynn:
> On 10/07/17 19:40, Marvin Renich wrote:
> 
> 
> 
>> There is an easy fix to revert the default behavior while still allowing
>> knowledgeable sysadmins to get the new behavior.  On the other hand,
>> those who need to administer systems but are not sysadmins by trade (and
>> thus will have to do significantly more research to even know that the
>> older behavior is possible) are the ones who need the older behavior as
>> the default.
> 
> This caught me out on a recent new installation, which gave me these new
> names which are too complicated to be usable. I wasted hours working out
> what had happened, how to fix it and how to write a udev rules file from
> scratch. And having just read this thread, I've discovered that the rules
> I've written are themselves apparently unreliable, for example:
> SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:98", NAME="eth0"
> SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:9a", NAME="eth1"

As mentioned elsewhere, such rules are unreliable indeed as they use the
same names as the kernel. You should a different namespace.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Adam Borowski]

On Wed, Jul 12, 2017 at 08:42:50PM +0200, Vincent Bernat wrote:
>  ❦ 12 juillet 2017 17:35 +0200, Marc Haber  :
> >>> sudo ip link; sudo ip addr;
> >> 
> >>no need for sudo, this is enough: 
> >>
> >>ip link ; ip addr
> >>
> >>or even shorter:
> >>
> >>ip l ; ip a
> >
> > Still, an elderly family member reading this out to you on the phone
> > is very very energy-draining.
> 
> Right click on network manager applet, "Connection Information" (or the
> appropriate translation in user language).

If you rely solely on dynamic configuration via network-manager, you don't
care about interface names so either setup is ok for you.

For the rest of us, though, wlxf81a671bcfae requires copy


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Roger Lynn]

On 10/07/17 19:40, Marvin Renich wrote:



> There is an easy fix to revert the default behavior while still allowing
> knowledgeable sysadmins to get the new behavior.  On the other hand,
> those who need to administer systems but are not sysadmins by trade (and
> thus will have to do significantly more research to even know that the
> older behavior is possible) are the ones who need the older behavior as
> the default.

This caught me out on a recent new installation, which gave me these new
names which are too complicated to be usable. I wasted hours working out
what had happened, how to fix it and how to write a udev rules file from
scratch. And having just read this thread, I've discovered that the rules
I've written are themselves apparently unreliable, for example:
SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:98", NAME="eth0"
SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:9a", NAME="eth1"

Roger

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Vincent Bernat]

 ❦ 12 juillet 2017 17:35 +0200, Marc Haber  :

>>> sudo ip link; sudo ip addr;
>> 
>>no need for sudo, this is enough: 
>>
>>ip link ; ip addr
>>
>>or even shorter:
>>
>>ip l ; ip a
>
> Still, an elderly family member reading this out to you on the phone
> is very very energy-draining.

Right click on network manager applet, "Connection Information" (or the
appropriate translation in user language).
-- 
Don't diddle code to make it faster - find a better algorithm.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Marc Haber]

On Wed, 12 Jul 2017 08:38:36 +, Holger Levsen
 wrote:
>On Tue, Jul 11, 2017 at 10:44:47AM -0500, Don Armstrong wrote:
>> On Tue, 11 Jul 2017, Bjørn Mork wrote:
>> > Previously I could ask a user to do e.g. 'ifconfig wwan0'. Now?
>> 
>> sudo ip link; sudo ip addr;
> 
>no need for sudo, this is enough: 
>
>ip link ; ip addr
>
>or even shorter:
>
>ip l ; ip a

Still, an elderly family member reading this out to you on the phone
is very very energy-draining.

Grüße
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Michael Lustfield]

On Jul 12, 2017 03:39, "Holger Levsen"  wrote:

On Tue, Jul 11, 2017 at 10:44:47AM -0500, Don Armstrong wrote:
> On Tue, 11 Jul 2017, Bjørn Mork wrote:
> > Previously I could ask a user to do e.g. 'ifconfig wwan0'. Now?
>
> sudo ip link; sudo ip addr;

no need for sudo, this is enough:

ip link ; ip addr

or even shorter:

ip l ; ip a


I don't believe the point had anything to do with ifconfig vs. ip. Rather,
it's no longer possible for people doing remote troubleshooting to make an
educated guess what the name of the interface in question is.

Imagine destining to the lay user how to read and parse the bits from the
ip command output that you're after. Now, instead of knowing it's the
add-on card and asking for bits of "ip addr show eth1", you're now along
them to run "ip addr" and figure out which of the devices might be what
you're looking for.

In another scenario, system automation doesn't often involve management of
network interfaces, but it's also not rare. I had been able to look at DCIM
and know what address ethX would have assigned. At the moment, I'm not
really sure how to handle the new naming scheme. I miss simple and
(globally) predictable.

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Holger Levsen]

On Tue, Jul 11, 2017 at 10:44:47AM -0500, Don Armstrong wrote:
> On Tue, 11 Jul 2017, Bjørn Mork wrote:
> > Previously I could ask a user to do e.g. 'ifconfig wwan0'. Now?
> 
> sudo ip link; sudo ip addr;
 
no need for sudo, this is enough: 

ip link ; ip addr

or even shorter:

ip l ; ip a


-- 
cheers,
Holger, who hasn't really noticed this change much, depite maintaining
*lots* of (different) stretch machines… as long as the machines
are not routers but just desktops or laptops because then
network-manager takes care anyway, and if I have a router I
probably don't use Debian anyway and if I have multiple
interfaces on a server I'm very happy about stable names…
so, meh.


signature.asc
Description: Digital signature

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Don Armstrong]

On Tue, 11 Jul 2017, Bjørn Mork wrote:
> Previously I could ask a user to do e.g. 'ifconfig wwan0'. Now?

sudo ip link; sudo ip addr;

and probably also:
sudo iw dev|awk '/^phy/'|xargs -IIFACE sudo iw IFACE info


-- 
Don Armstrong  https://www.donarmstrong.com

What I can't stand is the feeling that my brain is leaving me for 
someone more interesting.

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Bjørn Mork]

Samuel Thibault  writes:
> Vincent Bernat, on lun. 10 juil. 2017 20:55:29 +0200, wrote:
>
>> Other major distributions are using this new scheme (notably Ubuntu
>> which has no reason to have users smarter than ours)
>
> The reasoning is the converse: non-techy users will just not be exposed
> to interface names anyway. Debian users, however, tend to be more techy,
> and do see these interface names. And basically *all* documentation
> before this interface name change is now incomprehensible to techy
> beginners.

Not only old docs, unfortunately.  The change makes it impossible to
describe system independent procedures involving a network device.

As an example, I happen to get a few questions regarding LTE modem
configuration.  Most of these users will have a single modem, so I know
the kernel network interface name is 'wwan0'.  Previously I could ask a
user to do e.g. 'ifconfig wwan0'.  Now?  Depending on how "techy" the
user is, I may have to write more about netdev naming policies than the
real issue.

This isn't something I just made up.  It is a real problem for me.  And
I only see a fraction of the problem.  I can imagine the issues for
those attempting to write any docs touching Linux networking..

> I'm really worried here: this change, like a lot others done recently,
> is making the Linux ecosystem yet more complex to understand, thus
> raising the barrier for techy beginners yet higher.

Yes.  And what is most worrying is all the excuses made, often claiming
the opposite.

We are all going to laugh at enp0s31f6.  But it looks like we are
looking at a couple of years of breakage first, before the advocates
move on to some other shiny project where they can solve a problem that
didn't exist before they entered the scene.


Bjørn

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Samuel Thibault]

Vincent Bernat, on lun. 10 juil. 2017 20:55:29 +0200, wrote:
> but there is nothing difficult in identifying the right interface with
> the new naming scheme.

Errr, it may not look difficult to *you*, but to someone who is learning
how to tinker Linux, things like enp0s25f1 looks really difficult and
scary.

And while I don't find it difficult either, I'm annoyed by having to
find out the name of the network board of the systems I'm using, while
basically 95% of them will ever have only one interface anyway. It looks
really odd that the default is to get annoyed 95% of the time for no
reason there... (again, because it seems this doesn't get through: I'm
*not* saying this naming scheme doesn't fix anything. I'm just saying
that 95% of the time there's only one network device anyway, so the fix
is moot 95% of the time)

> Other major distributions are using this new scheme (notably Ubuntu
> which has no reason to have users smarter than ours)

The reasoning is the converse: non-techy users will just not be exposed
to interface names anyway. Debian users, however, tend to be more techy,
and do see these interface names. And basically *all* documentation
before this interface name change is now incomprehensible to techy
beginners.

I'm really worried here: this change, like a lot others done recently,
is making the Linux ecosystem yet more complex to understand, thus
raising the barrier for techy beginners yet higher.

At which point will we just stop seeing new random contributers, just
become the system has become too complex to grasp by oneself?

Samuel

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Vincent Bernat]

 ❦ 10 juillet 2017 14:36 -0400, Marvin Renich  :

> The only benefit I have seen between the new scheme and the previous
> one is that there is no state file.  While getting rid of the state
> file is a nice goal, it is extremely minor compared to having short,
> simple names in common use cases like inserting a wifi usb dongle.

Knowing the device name of a wifi dongle seems a pretty niche case. Most
users will just use network manager to select the appropriate SSID and
forget about it.

> With the new scheme, if I want to rename the interface to something more
> meaningful, I have to go find an older machine that already has a
> persistent-net.rules file or read through a lot of documentation to
> figure out the correct syntax.  I then have to determine the correct
> ATTR elements to identify the interface in question, and type all of
> that information by hand, hoping I type everything correctly.

Have a look at systemd.link(5) which enables you to do that without
debugging udev.

> There is an easy fix to revert the default behavior while still allowing
> knowledgeable sysadmins to get the new behavior.  On the other hand,
> those who need to administer systems but are not sysadmins by trade (and
> thus will have to do significantly more research to even know that the
> older behavior is possible) are the ones who need the older behavior as
> the default.

Having a default behavior that's unreliable doesn't seem great
either. The change is surprising (and not expected on non-new systems),
but there is nothing difficult in identifying the right interface with
the new naming scheme. Other major distributions are using this new
scheme (notably Ubuntu which has no reason to have users smarter than
ours) and I don't see a lot of drama on their side. It seems that for
some reason, we are the only ones making a fuss about any change.
-- 
The mind is its own place, and in itself
Can make a Heav'n of Hell, a Hell of Heav'n.
-- John Milton


signature.asc
Description: PGP signature

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Marvin Renich]

* Marco d'Itri  [170710 13:12]:
> On Jul 10, Adam Borowski  wrote:
> 
> > Predictability is important, thus let's actually have _predictable_
> > interface names.  The kernel default, eth0 and wlan0, is good enough for
> > most users, why not keep that?  Even just ignoring the issue completely
> Because you cannot know how many interfaces a system has until all of 
> them will have appeared.
> Please stop beating this long time dead horse.

This has been discussed on debian-devel in the past, but this is the
first time that many of our users have seen this.  This horse is very
much alive, just locked in the barn without food.

Neither you, nor any other proponent of the new scheme has addressed the
fact that short, easily remembered names in _all_ cases is significantly
more important than not having a state file.

The only benefit I have seen between the new scheme and the previous one
is that there is no state file.  While getting rid of the state file is
a nice goal, it is extremely minor compared to having short, simple
names in common use cases like inserting a wifi usb dongle.

And no, enp2s0f1 is neither short nor simple.  It requires remembering
three numbers and three letters that identify internal parts of the
hardware hierarchy that are irrelevant to the sysadmin.

With the previous scheme, an interface would be assigned a short, simple
name the first time it was seen.  The sysadmin could easily edit the
state file to give it a more meaningful name, if desired.  The state
file already had all the other information needed to identify the
interface; a simple one-word change in the file was sufficient.
Whatever name was in the state file was used for that piece of hardware
from then on.  The names were at least as predictable as they are with
the new scheme.

With the new scheme, if I want to rename the interface to something more
meaningful, I have to go find an older machine that already has a
persistent-net.rules file or read through a lot of documentation to
figure out the correct syntax.  I then have to determine the correct
ATTR elements to identify the interface in question, and type all of
that information by hand, hoping I type everything correctly.

There is an easy fix to revert the default behavior while still allowing
knowledgeable sysadmins to get the new behavior.  On the other hand,
those who need to administer systems but are not sysadmins by trade (and
thus will have to do significantly more research to even know that the
older behavior is possible) are the ones who need the older behavior as
the default.

...Marvin

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Bjørn Mork]

m...@linux.it (Marco d'Itri) writes:
> On Jul 10, Adam Borowski  wrote:
>
>> Predictability is important, thus let's actually have _predictable_
>> interface names.  The kernel default, eth0 and wlan0, is good enough for
>> most users, why not keep that?  Even just ignoring the issue completely
> Because you cannot know how many interfaces a system has until all of 
> them will have appeared.

Just like you cannot know how many PCI buses a system has until all of
them have appeared.  But depending on the faulty assumption that PCI bus
numbers are static is apparently good enough for most users?

Yes, it *is* definitely a dead horse your are beating here. There is no
such thing as predictable network names.  Continuing to pretend
otherwise will not move this discussion forward.


Bjørn

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Adam Borowski]

On Mon, Jul 10, 2017 at 07:11:58PM +0200, Marco d'Itri wrote:
> On Jul 10, Adam Borowski  wrote:
> 
> > Predictability is important, thus let's actually have _predictable_
> > interface names.  The kernel default, eth0 and wlan0, is good enough for
> > most users, why not keep that?  Even just ignoring the issue completely
> Because you cannot know how many interfaces a system has until all of 
> them will have appeared.
> Please stop beating this long time dead horse.

The problem is, that horse's replacement has just received a yet another
black mark, this time stretch-sized.  At this time I'd say even no horse at
all is way better than "predictable" random names.  The "no horse" solution
has the benefit of working better in 95% cases, the remaining ones being
very well correlated with expected admin skills.

Another potential horse would be to take current "predictable" output and
feeding it to a state file: that would fix at a good part (but not all) of
problems we have.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: New network interface naming scheme [was Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system]

[Vincent Bernat]

 ❦ 10 juillet 2017 18:37 +0200, Adam Borowski  :

>> > The cost of a state file (/etc/udev/rules.d/70-persistent-net.rules) is
>> > extremely small, even in the very worst case where a user continually
>> > plugs in many, many different usb network dongles, which is a very
>> > unrealistic case to begin with.
>> 
>> The state file solution was not perfect either. If you have two brands
>> of NIC (Intel 10G additional NIC and Broadcom 1G integrated NIC for
>> example), it was not uncommon to be left with an interface eth0_rename
>> after boot because the target name was used by the other driver.
>
> Because of a race with the kernel creating eth1 while you're trying to
> rename eth0->eth0_rename->eth1, right?  That's trivially solvable by
> inventing a new scheme, such as e0 e1 (I'm sure someone can sound a scheme
> that sounds better than this).

Yes, that would work. There are still some issues, like random numbering
during the first boot. Note that udev is mostly following this scheme
with "eno1", "eno2", ...

> On the other hand, I use kernel-assigned names on all my machines that don't
> have multiple interfaces, thus I don't know how stable
> 70-persistent-net.rules is on the MAC-less machines.  I guess you guys know
> more.  But even if you take those new "persistent" names as a base for the
> state file, we wouldn't gain stability over kernel upgrades but the names
> would be actually predictable for the user (ie, the admin would know the
> only interface will be "e0").

For a physical machine, the only interface is usually eno1. For a
virtual machine, the numbering may be absent and this case, the
interface name is ensX with X which depends on your provider. Maybe an
exception could have been done for virtio, but there are edge cases they
may be difficult to catch (someone changing virtio to e1000 for example).

This can be checked with:

  udevadm info -p /sys/class/net/eno1 | grep ID_NET_NAME

The default order is onboard, slot, path. Debian has a local
modification to use the MAC address for USB devices.

See also:
 
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/#comeagainwhatgooddoesthisdo
-- 
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Marco d'Itri]

On Jul 10, Adam Borowski  wrote:

> Predictability is important, thus let's actually have _predictable_
> interface names.  The kernel default, eth0 and wlan0, is good enough for
> most users, why not keep that?  Even just ignoring the issue completely
Because you cannot know how many interfaces a system has until all of 
them will have appeared.
Please stop beating this long time dead horse.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: New network interface naming scheme [was Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system]

[Adam Borowski]

On Mon, Jul 10, 2017 at 06:05:06PM +0200, Vincent Bernat wrote:
>  ❦ 10 juillet 2017 09:38 -0400, Marvin Renich  :
> 
> > The cost of a state file (/etc/udev/rules.d/70-persistent-net.rules) is
> > extremely small, even in the very worst case where a user continually
> > plugs in many, many different usb network dongles, which is a very
> > unrealistic case to begin with.
> 
> The state file solution was not perfect either. If you have two brands
> of NIC (Intel 10G additional NIC and Broadcom 1G integrated NIC for
> example), it was not uncommon to be left with an interface eth0_rename
> after boot because the target name was used by the other driver.

Because of a race with the kernel creating eth1 while you're trying to
rename eth0->eth0_rename->eth1, right?  That's trivially solvable by
inventing a new scheme, such as e0 e1 (I'm sure someone can sound a scheme
that sounds better than this).

On the other hand, I use kernel-assigned names on all my machines that don't
have multiple interfaces, thus I don't know how stable
70-persistent-net.rules is on the MAC-less machines.  I guess you guys know
more.  But even if you take those new "persistent" names as a base for the
state file, we wouldn't gain stability over kernel upgrades but the names
would be actually predictable for the user (ie, the admin would know the
only interface will be "e0").


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Adam Borowski]

On Mon, Jul 10, 2017 at 03:47:14PM +0200, Guus Sliepen wrote:
> On Mon, Jul 10, 2017 at 01:57:08PM +0200, Rene Engelhard wrote:
> 
> > eth0 will be kept on upgrades, but new installs get new interface names
> > (that is good, that removed unpredictability if you add a new network card.)
> 
> Interface names are, unfortunately, as unpredictable in stretch as they
> were in jessie, just unpredictable in a different way. Now network names
> are decided based on bus topology or MAC address. Bus topology however
> is not something that is as predictable as you might think, and some
> network cards just don't have a fixed MAC address. Bus topology might
> change if you just move a card from one slot to the next, or as I've
> experienced myself, when nothing in the hardware changes, but a BIOS
> update causes enumeration to happen differently.
> 
> At least the interface names in jessie were shorter, and you had a good
> chance that eth0 was exactly what you wanted :)

I'd say the last part is the most important one: the vast majority of
machines have exactly one Ethernet interface and at most one WiFi interface. 
Furthermore, the ones that got more either have an admin with some knowledge
(bigger servers) or come preloaded (routers).

Predictability is important, thus let's actually have _predictable_
interface names.  The kernel default, eth0 and wlan0, is good enough for
most users, why not keep that?  Even just ignoring the issue completely
is much, much better than current state.

FreeDesktop's interface naming promised stability, it did not deliver.  Even
regular non-fancy x86 machines often switch names on jessie->stretch
upgrades, not to mention arm SoCs with no MAC address at all (that EPROM
would cost a few cents, you see...).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: New network interface naming scheme [was Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system]

[Vincent Bernat]

 ❦ 10 juillet 2017 09:38 -0400, Marvin Renich  :

> The cost of a state file (/etc/udev/rules.d/70-persistent-net.rules) is
> extremely small, even in the very worst case where a user continually
> plugs in many, many different usb network dongles, which is a very
> unrealistic case to begin with.

The state file solution was not perfect either. If you have two brands
of NIC (Intel 10G additional NIC and Broadcom 1G integrated NIC for
example), it was not uncommon to be left with an interface eth0_rename
after boot because the target name was used by the other driver.
-- 
Each module should do one thing well.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Guus Sliepen]

On Mon, Jul 10, 2017 at 01:57:08PM +0200, Rene Engelhard wrote:

> eth0 will be kept on upgrades, but new installs get new interface names
> (that is good, that removed unpredictability if you add a new network card.)

Interface names are, unfortunately, as unpredictable in stretch as they
were in jessie, just unpredictable in a different way. Now network names
are decided based on bus topology or MAC address. Bus topology however
is not something that is as predictable as you might think, and some
network cards just don't have a fixed MAC address. Bus topology might
change if you just move a card from one slot to the next, or as I've
experienced myself, when nothing in the hardware changes, but a BIOS
update causes enumeration to happen differently.

At least the interface names in jessie were shorter, and you had a good
chance that eth0 was exactly what you wanted :)

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

New network interface naming scheme [was Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system]

[Marvin Renich]

First, the original thread belongs on debian-user, not debian-devel.
Please move the "how do I use the new (more than a decade old)
networking tools" user question there.

* Rene Engelhard  [170710 08:03]:
> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.de.html#new-interface-names
> 
> eth0 will be kept on upgrades, but new installs get new interface names
> (that is good, that removed unpredictability if you add a new network card.)

I do want to respond to this, though.  (I see Adam already has, as
well.)

The new interface naming scheme seemed to have two primary goals:  to
have reproducible interface names, and to avoid using a state file.
There also appeared to be a very minor goal of having short, simple
names when easily done.

I am very disappointed at the outcome, because I believe having short,
simple names in _all_ cases is more important than not using a state
file, by _at least_ an order of magnitude.

The cost of a state file (/etc/udev/rules.d/70-persistent-net.rules) is
extremely small, even in the very worst case where a user continually
plugs in many, many different usb network dongles, which is a very
unrealistic case to begin with.

On the other hand, the cost of having to deal with wlxf81a671bcfae just
because you are using a usb dongle is considerable, and this is a very
realistic and much more common case.

This is a case of misplaced design priorities that has turned out very
badly.  I would like to see /lib/udev/rules.d/80-net-setup-link.rules
moved somewhere that is not used by default (e.g.
/usr/share/udev/optional-rules/) and only used if the sysadmin
explicitly links to it in /etc/udev/rules.d/.

Thanks, Adam, for the clue about how to disable this!

...Marvin

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Maximilian Althaus]

Hi!

Thanks, but this do not help me. I have still the same error.

http://prntscr.com/ftv2uj

This is a screenshot when I start the networking service and it failed, 
because of there is no route command!


--

This is the config for (/etc/network/interfaces)

auto lo
iface lo inet loopback

auto ens18
allow-hotplug ens18
iface ens18 inet static
addressIP.V4.ADDR.ESS
netmask 255.255.255.255
broadcastIP.V4.ADDR.ESS
post-up route addROOTER.IPV4.ADDR.ESSdev ens18
post-up route add default gwROOTER.IPV4.ADDR.ESS
pre-down route delROOTER.IPV4.ADDR.ESSdev ens18
pre-down route del default gwROOTER.IPV4.ADDR.ESS

Cheers,
Maximilian

Rene Engelhard 
10. July 2017 at 1:57 PM
On Mon, Jul 10, 2017 at 01:44:00PM +0200, Maximilian Althaus wrote:

Okay, I understand! But I have the problem that the Debian 9 VM can not


No, you don't. You already got told about ip -r. "route" and "ifconfig" are not
installed per default anymore.


get an internet connection. This is because the network configuration
(/etc/network/interfaces) fail, because Debian 9.0 could not found a
device named eth0, but with Debian 8.8 with the same configuration I have


https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.de.html#new-interface-names

eth0 will be kept on upgrades, but new installs get new interface names
(that is good, that removed unpredictability if you add a new network card.)


no problem and I have an internet connection. On top of this on the Debian
9 VM it the networking service says that there is no route commend. What
can I do ? Do I need an other network configuration
(/etc/network/interfaces) 


as already said: if you want route, you need net-tools installed.
otherwise (afaicr) ip r(oute).

https://www.debian.org/releases/stable/amd64/release-notes/ch-information.de.html#iproute2

(I asume you're .de, if not, sorry and then read the english
release notes.)

Regards,

Rene
Maximilian Althaus 
10. July 2017 at 1:44 PM
Hi!

Okay, I understand! But I have the problem that the Debian 9 VM can 
not get an internet connection. This is because the network 
configuration (/etc/network/interfaces) fail, because Debian 9.0 could 
not found a device named eth0, but with Debian 8.8 with the same 
configuration I have no problem and I have an internet connection. On 
top of this on the Debian 9 VM it the networking service says that 
there is no route commend. What can I do ? Do I need an other 
network configuration (/etc/network/interfaces) 


Cheers,
Maximilian


Nicholas D Steeves 
10. July 2017 at 1:49 AM
P.S. That cheat sheet isn't nearly as nice...as I'd like it to be I
wish it was a compact printable two or three column reference with
net-tools commands in bold and the short-form iw equivalent
underneath.

eg: 'ip -r r' is more or less equivalent to 'route'
Maximilian Althaus 
10. July 2017 at 1:07 AM
Hello,

today I installed a Proxmox 5 system on a dedicated server. Then I 
want to create a VM using the netinst Debian 9 stretch image. After a 
successful installation without network access I want to add a 
network, but when I type route in the commend line debian say that 
this command is not found, but when I used Debian 8.8 jessie with the 
netinst-img without network access this commend worked. 
WHY??


On top of this when I want to add my network to the Debian 9 VM this 
failed because of the route commend is not found and with the Debian 
8.8 VM this is working. WHY??


Best wishes,
Maximilian Althaus

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Adam Borowski]

On Mon, Jul 10, 2017 at 01:57:08PM +0200, Rene Engelhard wrote:
> On Mon, Jul 10, 2017 at 01:44:00PM +0200, Maximilian Althaus wrote:
> >Okay, I understand! But I have the problem that the Debian 9 VM can not
> 
> No, you don't. You already got told about ip -r. "route" and "ifconfig" are 
> not
> installed per default anymore.

All packages shipped by Debian[1] either don't require net-tools anymore, or
pull them in via dependency.  If you wrote a custom script, you might need
to either migrate to ip or a friend (like, netstat -> ss), or install
net-tools.  The latter has been deprecated since a long, long time, so the
time to finally pull the plug had to come sooner or later.

> >get an internet connection. This is because the network configuration
> >(/etc/network/interfaces) fail, because Debian 9.0 could not found a
> >device named eth0, but with Debian 8.8 with the same configuration I have

> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.de.html#new-interface-names
> 
> eth0 will be kept on upgrades, but new installs get new interface names
> (that is good, that removed unpredictability if you add a new network card.)

Not sure how is it possible to argue that "eth0" is _less_ predictable than
ensp3 or wlxf81a671bcfae.  If you replace a network card, all your network
settings go wrong.  Same if you reconnect a removable card.  Or upgrade your
kernel.  Or, dist-upgrade.  Or, in case of a VM, use a slightly different
command line.  Or, on some hardware, on every boot.  The random number after
that "ensp" or "wlxf" can be re-rolled unexpectedly -- hope you have an
out-of-band way to reach that machine (ilo and iDrac are not really
trustworthy).

To fix this problem, you can:
ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules
update-initramfs -u

Also it's worth noting that if you do rename interfaces on your own (kind of
a must if there's more than one of its type -- both eth0 vs eth1 or ensp42
vs ensp78 require documentation that's guaranteed to be misplaced while out0
vs lan0 are self-describing even to an outsider), in jessie this overruled
the above "predictable" rule, in stretch it apparently does not.


HTH, meow!

[1]. At least popular ones -- there's a possibility something obscure has
slipped through, in which case, please install net-tools and report a bug.
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Rene Engelhard]

On Mon, Jul 10, 2017 at 01:44:00PM +0200, Maximilian Althaus wrote:
>Okay, I understand! But I have the problem that the Debian 9 VM can not

No, you don't. You already got told about ip -r. "route" and "ifconfig" are not
installed per default anymore.

>get an internet connection. This is because the network configuration
>(/etc/network/interfaces) fail, because Debian 9.0 could not found a
>device named eth0, but with Debian 8.8 with the same configuration I have

https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.de.html#new-interface-names

eth0 will be kept on upgrades, but new installs get new interface names
(that is good, that removed unpredictability if you add a new network card.)

>no problem and I have an internet connection. On top of this on the Debian
>9 VM it the networking service says that there is no route commend. What
>can I do ? Do I need an other network configuration
>(/etc/network/interfaces) 

as already said: if you want route, you need net-tools installed.
otherwise (afaicr) ip r(oute).

https://www.debian.org/releases/stable/amd64/release-notes/ch-information.de.html#iproute2

(I asume you're .de, if not, sorry and then read the english
release notes.)

Regards,

Rene

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Maximilian Althaus]

Hi!

Okay, I understand! But I have the problem that the Debian 9 VM can not 
get an internet connection. This is because the network configuration 
(/etc/network/interfaces) fail, because Debian 9.0 could not found a 
device named eth0, but with Debian 8.8 with the same configuration I 
have no problem and I have an internet connection. On top of this on the 
Debian 9 VM it the networking service says that there is no route 
commend. What can I do ? Do I need an other network configuration 
(/etc/network/interfaces) 


Cheers,
Maximilian


Nicholas D Steeves 
10. July 2017 at 1:49 AM
P.S. That cheat sheet isn't nearly as nice...as I'd like it to be I
wish it was a compact printable two or three column reference with
net-tools commands in bold and the short-form iw equivalent
underneath.

eg: 'ip -r r' is more or less equivalent to 'route'
Maximilian Althaus 
10. July 2017 at 1:07 AM
Hello,

today I installed a Proxmox 5 system on a dedicated server. Then I 
want to create a VM using the netinst Debian 9 stretch image. After a 
successful installation without network access I want to add a 
network, but when I type route in the commend line debian say that 
this command is not found, but when I used Debian 8.8 jessie with the 
netinst-img without network access this commend worked. 
WHY??


On top of this when I want to add my network to the Debian 9 VM this 
failed because of the route commend is not found and with the Debian 
8.8 VM this is working. WHY??


Best wishes,
Maximilian Althaus

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Maximilian Althaus]

Hi Nicholas!

Thanks for this information, I will change my configuration to the new one.

Cheers,
Maximilian


Nicholas D Steeves 
10. July 2017 at 1:49 AM
P.S. That cheat sheet isn't nearly as nice...as I'd like it to be I
wish it was a compact printable two or three column reference with
net-tools commands in bold and the short-form iw equivalent
underneath.

eg: 'ip -r r' is more or less equivalent to 'route'
Maximilian Althaus 
10. July 2017 at 1:07 AM
Hello,

today I installed a Proxmox 5 system on a dedicated server. Then I 
want to create a VM using the netinst Debian 9 stretch image. After a 
successful installation without network access I want to add a 
network, but when I type route in the commend line debian say that 
this command is not found, but when I used Debian 8.8 jessie with the 
netinst-img without network access this commend worked. 
WHY??


On top of this when I want to add my network to the Debian 9 VM this 
failed because of the route commend is not found and with the Debian 
8.8 VM this is working. WHY??


Best wishes,
Maximilian Althaus

P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Nicholas D Steeves]

P.S. That cheat sheet isn't nearly as nice...as I'd like it to be I
wish it was a compact printable two or three column reference with
net-tools commands in bold and the short-form iw equivalent
underneath.

eg: 'ip -r r' is more or less equivalent to 'route'


signature.asc
Description: Digital signature