Discussion:
Proposal: enable stateless persistant network interface names
(too old to reply)
Martin Pitt
2015-05-08 06:06:05 UTC
Permalink
Details about [mac]
-------------------
[...]
* It requires a writable /etc/udev/rules.d/ for persistantly storing
the assignment. We don't want/have that with system-image
(touch/snappy).
Sorry, these are Ubuntu specific terms, forgot to edit. This meant to
say: we don't have that with read-only or stateless root file systems,
which become increasingly more popular. We do get bug reports in
Debian as well about stuff that breaks r/o root; it's not much of an
issue yet, so if you don't consider this a valid/sane use case just
ignore this bit of the argument (the other reasons are still strong
enough to change this anyway).

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Josh Triplett
2015-05-08 07:28:44 UTC
Permalink
Details about [ifnames]
-----------------------
This is a generic solution which extends the [biosdevname] idea and
thus applies to all practical cases and all architectures. It doesn't
need any persistant state (i. e. dynamic /etc/udev/rules.d/) and thus
applies nicely to snappy/touch, and also avoids the race condition.
The main downside is that by nature the device names are not familiar
to current admins yet. For BIOS provided names you get e. g. ens0, for
PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a
necessary price to pay (biosdevname names look similar).
As this hasn't been discussed yet, Debian and Ubuntu disable this by
default. You can opt into this by booting with "net.ifnames=1" (which
is a patch against upstream: there you disable it by booting with
net.ifnames=0 or disabling 80-net-setup-link.rules).
Proposal
--------
I propose to retire [mac], i. e. drop
/lib/udev/rules.d/75-persistent-net-generator.rules and enable
[ifnames] by default.
I have tried this just last week and have found it kind of
unsatisfactory that it doesn't work in virtualized environments. For
example, in a KVM VM with virtio ethernet, the network devices still
end up in the system as eth0, eth1, eth2.
As I understand it, that's intentional and expected, for two reasons.
First, because on a virtual machine, the network interfaces are likely
to be more stable, always showing up with the same numbers. And second,
because there's little else to go on when naming them.

- Josh Triplett
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@x
Tollef Fog Heen
2015-05-08 13:11:06 UTC
Permalink
]] Marc Haber
That would mean changing local code to _both_ handle en* and eth*,
which is (a) a surprise and (b) unsatisfying in _my_ personal opinion.
By en*, you mean emN, enN, pXpY all, right?
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@rahvafeir.err.no
Marco d'Itri
2015-05-11 02:09:45 UTC
Permalink
That would mean changing local code to _both_ handle en* and eth*,
which is (a) a surprise and (b) unsatisfying in _my_ personal opinion.
I'd rather have it fully and consistently or not at all.
"Not at all" is going to be harder and harder to support, so we need
something better.

If you just want everything to be called em* then you can drop in your
VMs a /etc/udev/rules.d/70-persistent-net.rules file containing:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth0", NAME="em0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth1", NAME="em1"
...
--
ciao,
Marco
Bernd Zeimetz
2015-05-17 18:03:54 UTC
Permalink
Post by Josh Triplett
I have tried this just last week and have found it kind of
unsatisfactory that it doesn't work in virtualized environments. For
example, in a KVM VM with virtio ethernet, the network devices still
end up in the system as eth0, eth1, eth2.
As I understand it, that's intentional and expected, for two reasons.
First, because on a virtual machine, the network interfaces are likely
to be more stable, always showing up with the same numbers. And second,
because there's little else to go on when naming them.
Unfortunately that is not true for VMware.
If you run a vm with more than three vmxnet(3) network interfaces it will depend
on the hw version of the vm in which order they appear (due to other pci ids and
different order on the pci bus!), it might happen that the 3rd or 4th interface
is ordered in front of the first interface.
Also mixing e1000 and vmxnet(3) interfaces will result in a mess.

It would be really great to fix this, as far as I can see the only way would be
using mac address based interface names as the pci bus ids will change while
upgrading hardware versions in vmware.
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@bzed.de
Josh Triplett
2015-05-17 19:28:04 UTC
Permalink
Post by Bernd Zeimetz
Post by Josh Triplett
I have tried this just last week and have found it kind of
unsatisfactory that it doesn't work in virtualized environments. For
example, in a KVM VM with virtio ethernet, the network devices still
end up in the system as eth0, eth1, eth2.
As I understand it, that's intentional and expected, for two reasons.
First, because on a virtual machine, the network interfaces are likely
to be more stable, always showing up with the same numbers. And second,
because there's little else to go on when naming them.
Unfortunately that is not true for VMware.
If you run a vm with more than three vmxnet(3) network interfaces it will depend
on the hw version of the vm in which order they appear (due to other pci ids and
different order on the pci bus!), it might happen that the 3rd or 4th interface
is ordered in front of the first interface.
Also mixing e1000 and vmxnet(3) interfaces will result in a mess.
It would be really great to fix this, as far as I can see the only way would be
using mac address based interface names as the pci bus ids will change while
upgrading hardware versions in vmware.
If that's a standard property of VMWare VMs, you could submit a udev
rule that improves the default naming on such systems. I believe there
are already some rules defining policies in that area, including
VM-specific information.

- Josh Triplett
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@x
Bernd Zeimetz
2015-05-18 20:34:29 UTC
Permalink
Post by Josh Triplett
If that's a standard property of VMWare VMs, you could submit a udev
rule that improves the default naming on such systems. I believe there
are already some rules defining policies in that area, including
VM-specific information.
the only thing I can imagine which would work is the mac based version as pci
ids and ordering will change when you press the upgrade button in the vcenter.
Or maybe have a look at the pci id of the scsi/sas controller, thats the only
way I know to figure out on which ids the ethernet controller will start....
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@bzed.de
Josh Triplett
2015-05-08 07:33:58 UTC
Permalink
Proposal
--------
I propose to retire [mac], i. e. drop
/lib/udev/rules.d/75-persistent-net-generator.rules and enable
[ifnames] by default.
This will provide the new stable interface names for all new
installations, stop the different handling of server/client, work with
system-image, and stops the woes cloud providers have with Ubuntu's
[mac].
I'm happy to ship a commented example udev rule that shows how to
configure your own names, if you want to continue using MAC based
schemas, or call your interfaces "internet" and "intranet" or the
like. This makes it easier to see how to do custom naming than having
to start from scratch.
For upgrades: As we don't know what refers to existing stable network
names, we can't ever safely remove a generated
/etc/udev/rules.d/70-persistent-net.rules. So when we do the above,
names on existing installations will *not* change (as
70-persistent-net.rules trumps [ifnames]).
So we can only let time and replacing/reinstalling machines take care
of this. /etc/udev/rules.d/70-persistent-net.rules requires zero
maintenance from us (it's just like the admin had manually set their
own rules).
Opinions?
Having spent a non-trivial amount of time fighting persistent-net.rules
on various systems, I'd very much welcome this change.

To help migrate existing systems, I'd suggest including a NEWS.Debian
file that explains the change, and recommends deleting
/etc/udev/rules.d/70-persistent-net.rules on systems that don't depend
on the exact names (for instance, systems that run NetworkManager rather
than hard-coding network configuration in ifupdown's
/etc/network/interfaces).

- Josh Triplett
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@x
Konstantin Khomoutov
2015-05-08 10:08:12 UTC
Permalink
On Fri, 8 May 2015 00:33:58 -0700
Post by Josh Triplett
I propose to retire [mac], i. e. drop
/lib/udev/rules.d/75-persistent-net-generator.rules and enable
[ifnames] by default.
[...]
Post by Josh Triplett
Having spent a non-trivial amount of time fighting
persistent-net.rules on various systems, I'd very much welcome this
change.
To help migrate existing systems, I'd suggest including a NEWS.Debian
file that explains the change, and recommends deleting
/etc/udev/rules.d/70-persistent-net.rules on systems that don't depend
on the exact names (for instance, systems that run NetworkManager
rather than hard-coding network configuration in ifupdown's
/etc/network/interfaces).
Is it possible to provide a tool (a shell script?) that would print out
the new would-be name of the interface provided by the user so that it
would be possible to migrate remote systems only accessible via SSH?
I mean, a sysadmin would then be able to determine the new name of the
network interface, reflect this change in the firewall setup and other
relevant places, delete 70-persistent-net.rules and reboot the box
(or may be perform some more involved encantation with calling ifdown /
ip link name ... / ifup while in a screen/tmux session).
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@domain007.com
Martin Pitt
2015-05-08 10:40:39 UTC
Permalink
Hello Konstantin,
Post by Konstantin Khomoutov
Is it possible to provide a tool (a shell script?) that would print out
the new would-be name of the interface provided by the user so that it
would be possible to migrate remote systems only accessible via SSH?
The closest thing to that would be something like this:

$ sudo udevadm test /sys/class/net/wlan0 |grep ID_NET_NAME_
ID_NET_NAME_MAC=wlxa44e31848d2c
ID_NET_NAME_PATH=wlp3s0

As I wrote the _MAC name isn't used by default (this has to be enabled
explicitly, and it's a bit unwieldy); the default policy is to use the
first existing variable in ID_NET_NAME_ONBOARD, ID_NET_NAME_SLOT, or
ID_NET_NAME_PATH.

Indeed it sounds useful to put that into a little shell script in
/usr/share/doc/udev/ or so which the admin can run if she wants to
migrate to the new names.
Post by Konstantin Khomoutov
I mean, a sysadmin would then be able to determine the new name of the
network interface, reflect this change in the firewall setup and other
relevant places, delete 70-persistent-net.rules and reboot the box
(or may be perform some more involved encantation with calling ifdown /
ip link name ... / ifup while in a screen/tmux session).
It's not advisable to change network names at runtime. Well, you could
stop all networking services and unload and reload the driver modules,
but that sounds about as error prone as just rebooting :-) I don't
know whether it's possible to change the name while the interface is
up and in use.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@piware.de
Timo Juhani Lindfors
2015-05-08 18:54:11 UTC
Permalink
Btw, why the <expletive> is the only way to configure this the kernel
command line and no configuration inside /etc where one would expect
it?
Maybe because udev is started from initramfs before the root filesystem
has been mounted?
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@sauna.l.org
Ben Hutchings
2015-05-08 22:26:00 UTC
Permalink
On Fri, 8 May 2015 00:33:58 -0700, Josh Triplett
Post by Josh Triplett
To help migrate existing systems, I'd suggest including a NEWS.Debian
file that explains the change, and recommends deleting
/etc/udev/rules.d/70-persistent-net.rules on systems that don't depend
on the exact names (for instance, systems that run NetworkManager rather
than hard-coding network configuration in ifupdown's
/etc/network/interfaces).
How about adding net.ifnames=0 explicitly on installation, thus
keeping the system bootable, with the documentation that the
configuration change should be (a) manually and (b) atomically?
[...]

We don't currently have a way for packages to install kernel parameters
that boot loaders should append to the command line. I think we should.

Ben.
--
Ben Hutchings
It is easier to write an incorrect program than to understand a correct one.
Josh Triplett
2015-05-08 14:47:51 UTC
Permalink
Post by Tollef Fog Heen
]] Marc Haber
That would mean changing local code to _both_ handle en* and eth*,
which is (a) a surprise and (b) unsatisfying in _my_ personal opinion.
By en*, you mean emN, enN, pXpY all, right?
Or more generally anything that enumerates as a network device. It's
entirely possible to ask "what kind of network device is this", so if
your local code is trying to find wired Ethernet devices, it should be
enumerating all devices and looking for those that are wired.

Remember way back in the day when some wireless devices showed up as
ethN too, and some things got confused when they became wlanN?

What's your local code trying to do?

- Josh Triplett
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@x
Karsten Merker
2015-05-08 16:31:07 UTC
Permalink
Quick intro to the problem: The kernel generally detects network
interfaces ("eth0", "wlan1", etc.) in an unpredictable and often
unstable order. But in order to refer to a particular one in
/etc/network/interfaces, firewall configs etc. you need to use a
stable name.
[...]
Details about [ifnames]
-----------------------
This is a generic solution which extends the [biosdevname] idea and
thus applies to all practical cases and all architectures. It doesn't
need any persistant state (i. e. dynamic /etc/udev/rules.d/) and thus
applies nicely to snappy/touch, and also avoids the race condition.
The main downside is that by nature the device names are not familiar
to current admins yet. For BIOS provided names you get e. g. ens0, for
PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a
necessary price to pay (biosdevname names look similar).
As this hasn't been discussed yet, Debian and Ubuntu disable this by
default. You can opt into this by booting with "net.ifnames=1" (which
is a patch against upstream: there you disable it by booting with
net.ifnames=0 or disabling 80-net-setup-link.rules).
[...]
Proposal
--------
I propose to retire [mac], i. e. drop
/lib/udev/rules.d/75-persistent-net-generator.rules and enable
[ifnames] by default.
Hello,

while this probably works resonably well for (semi-)fixed devices
like onboard-NICs and PCI/PCIe cards, it results in a completely
unsuitable behaviour with pluggable devices such as USB network
adapters. When using ifnames, the interface name depends on the
USB port into which the device is currently plugged and the
interface name changes when one uses a USB hub or plugs the
device into another host port. This would mean that a user would
always have to plug his USB network device into the same port
that was used during initial setup to keep it working, and
one-off use of a USB hub would require changing the network
configuration. Despite the problems of the MAC-based system
that we use currently, the ifnames method appears way worse
to me than what we have now.

Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@excalibur.cnev.de
Matthias Urlichs
2015-05-08 17:32:39 UTC
Permalink
Hi,
Post by Karsten Merker
while this probably works resonably well for (semi-)fixed devices
like onboard-NICs and PCI/PCIe cards, it results in a completely
unsuitable behaviour with pluggable devices such as USB network
adapters.
Why?

I can envision two likely scenarios for using a USB adapter.

(a) you need to test something, so you plug in a handy USB adapter and
configure it statically.

So you're root and mucking about in /etc anyway, so also adding a one-liner
to /etc/udev/rules.d/70-persistent-net.rules which names the adapter
statically should not be a problem.

(b) you're a client (e.g. you configure a new router), likely to use
NetworkManager to just run a dhcp client on the adapter or configure a
one-off RFC1918 address.

So what if the adapter gets a different name next time? Most likely you
need to configure a different device in a different '1918 subnet anyway.
Or, if you use DHCP, there's no difference either way. In all other
situations, quickly configuring a static address is no problem IMHO.
Post by Karsten Merker
Despite the problems of the MAC-based system that we use currently, the
ifnames method appears way worse to me than what we have now.
On a server, a missed rename due to interfaces showing up in exactly the
wrong order makes the system unreachable. Frankly, I cannot imagine
anything "way worse" than that. Not in this context.
--
-- Matthias Urlichs
Michael Biebl
2015-05-08 17:52:10 UTC
Permalink
Post by Karsten Merker
while this probably works resonably well for (semi-)fixed devices
like onboard-NICs and PCI/PCIe cards, it results in a completely
unsuitable behaviour with pluggable devices such as USB network
adapters. When using ifnames, the interface name depends on the
USB port into which the device is currently plugged and the
interface name changes when one uses a USB hub or plugs the
device into another host port. This would mean that a user would
always have to plug his USB network device into the same port
that was used during initial setup to keep it working, and
one-off use of a USB hub would require changing the network
configuration. Despite the problems of the MAC-based system
that we use currently, the ifnames method appears way worse
to me than what we have now.
ifnames is rather flexible.
You can also use NamePolicy=mac [1] if you prefer.

Cheers,
Michael

[1]
http://www.freedesktop.org/software/systemd/man/systemd.link.html#NamePolicy=
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Josh Triplett
2015-05-08 17:50:30 UTC
Permalink
Post by Karsten Merker
while this probably works resonably well for (semi-)fixed devices
like onboard-NICs and PCI/PCIe cards, it results in a completely
unsuitable behaviour with pluggable devices such as USB network
adapters. When using ifnames, the interface name depends on the
USB port into which the device is currently plugged and the
interface name changes when one uses a USB hub or plugs the
device into another host port. This would mean that a user would
always have to plug his USB network device into the same port
that was used during initial setup to keep it working, and
one-off use of a USB hub would require changing the network
configuration. Despite the problems of the MAC-based system
that we use currently, the ifnames method appears way worse
to me than what we have now.
That would only be a problem if you're using ifupdown and its hardcoded
network interface names. Other network software handles dynamic names.

Without this, you can't reliably use a system with *two* USB network
devices, because they won't consistently come up with the same names.
Or, for that matter, a system with a built-in network interface and a
USB network interface.

- Josh Triplett
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@jtriplet-mobl1
Karsten Merker
2015-05-08 19:06:25 UTC
Permalink
Post by Josh Triplett
Post by Karsten Merker
while this probably works resonably well for (semi-)fixed devices
like onboard-NICs and PCI/PCIe cards, it results in a completely
unsuitable behaviour with pluggable devices such as USB network
adapters. When using ifnames, the interface name depends on the
USB port into which the device is currently plugged and the
interface name changes when one uses a USB hub or plugs the
device into another host port. This would mean that a user would
always have to plug his USB network device into the same port
that was used during initial setup to keep it working, and
one-off use of a USB hub would require changing the network
configuration. Despite the problems of the MAC-based system
that we use currently, the ifnames method appears way worse
to me than what we have now.
That would only be a problem if you're using ifupdown and its hardcoded
network interface names. Other network software handles dynamic names.
How is for example iptables supposed to handle changing interface
names? IPtables rules often specify a specific incoming or
outgoing interface, so the interface name must be known at the
ruleset load time. This would mean that with the ifnames
mechanism and its port-based interface naming, an iptables
ruleset on a laptop with a USB network adapter would only work if
the adapter is either always plugged into the same port or the
user changes the ruleset every time he uses another USB port.
Post by Josh Triplett
Without this, you can't reliably use a system with *two* USB network
devices, because they won't consistently come up with the same names.
Or, for that matter, a system with a built-in network interface and a
USB network interface.
The current default MAC-based mechanism handles exactly this case
very well on a number of systems for me (one built-in network
interface and one or two USB network adapters). Every adapter
always gets the same interface name, regardless of the bringup
order.

Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@excalibur.cnev.de
j***@joshtriplett.org
2015-05-08 19:29:03 UTC
Permalink
Post by Karsten Merker
Post by Josh Triplett
Post by Karsten Merker
while this probably works resonably well for (semi-)fixed devices
like onboard-NICs and PCI/PCIe cards, it results in a completely
unsuitable behaviour with pluggable devices such as USB network
adapters. When using ifnames, the interface name depends on the
USB port into which the device is currently plugged and the
interface name changes when one uses a USB hub or plugs the
device into another host port. This would mean that a user would
always have to plug his USB network device into the same port
that was used during initial setup to keep it working, and
one-off use of a USB hub would require changing the network
configuration. Despite the problems of the MAC-based system
that we use currently, the ifnames method appears way worse
to me than what we have now.
That would only be a problem if you're using ifupdown and its hardcoded
network interface names. Other network software handles dynamic names.
How is for example iptables supposed to handle changing interface
names?
Associate the rules with addresses, names, or other aspects of network
topology, rather than specific interfaces.

And for servers or routers (the common case for iptables usage), ifnames
should provide quite stable names.
Post by Karsten Merker
IPtables rules often specify a specific incoming or
outgoing interface, so the interface name must be known at the
ruleset load time. This would mean that with the ifnames
mechanism and its port-based interface naming, an iptables
ruleset on a laptop with a USB network adapter would only work if
the adapter is either always plugged into the same port or the
user changes the ruleset every time he uses another USB port.
On a laptop (or anywhere else), ideally you're using a higher-level tool
than iptables. For instance, if you're trying to share connectivity
from one network and NAT it to another, that's easily done with a few
clicks these days. And it doesn't depend on which adapter
Post by Karsten Merker
Post by Josh Triplett
Without this, you can't reliably use a system with *two* USB network
devices, because they won't consistently come up with the same names.
Or, for that matter, a system with a built-in network interface and a
USB network interface.
The current default MAC-based mechanism handles exactly this case
very well on a number of systems for me (one built-in network
interface and one or two USB network adapters). Every adapter
always gets the same interface name, regardless of the bringup
order.
Answered in my other response, sorry. Yes, the MAC-based mechanism
handles this too, but it has quite a few other issues.

- Josh Triplett
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@cloud
Karsten Merker
2015-05-08 20:04:36 UTC
Permalink
Post by j***@joshtriplett.org
Post by Karsten Merker
How is for example iptables supposed to handle changing interface
names?
Associate the rules with addresses, names, or other aspects of network
topology, rather than specific interfaces.
That is often very impractical - the logical way is often to have
interface-based rules instead of address-based rules. This is
particularly the case with laptops where the network topology on
the "outside" interface changes very often and the only sensible way
to specify rules is using the interface as designator.
Post by j***@joshtriplett.org
And for servers or routers (the common case for iptables usage), ifnames
should provide quite stable names.
Well, I think that running iptables on a laptop is also an
absolutely common case, in particular as laptops are often
running in "foreign" networks.

Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@excalibur.cnev.de
j***@joshtriplett.org
2015-05-08 20:33:06 UTC
Permalink
Post by Karsten Merker
Post by j***@joshtriplett.org
Post by Karsten Merker
How is for example iptables supposed to handle changing interface
names?
Associate the rules with addresses, names, or other aspects of network
topology, rather than specific interfaces.
That is often very impractical - the logical way is often to have
interface-based rules instead of address-based rules. This is
particularly the case with laptops where the network topology on
the "outside" interface changes very often and the only sensible way
to specify rules is using the interface as designator.
So use the interface name as the designator, then. If you really want
to, you can turn on MAC-based naming with the new ifnames, with a
one-line change to a configuration file.
Post by Karsten Merker
Post by j***@joshtriplett.org
And for servers or routers (the common case for iptables usage), ifnames
should provide quite stable names.
Well, I think that running iptables on a laptop is also an
absolutely common case, in particular as laptops are often
running in "foreign" networks.
iptables the underlying technology? Sure, absolutely.

iptables directly, via fragile scripts that hard-code interface names?
There are much better alternatives for most common cases.

- Josh Triplett
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@cloud
Vincent Bernat
2015-05-08 21:38:23 UTC
Permalink
Post by j***@joshtriplett.org
There are much better alternatives for most common cases.
For example being?
firewalld works nicely nowadays. You assign different level of security
to different networks. When I dock my laptop, network manager configures
the network interface and firewalld attach it to the "work" zone. When
on the road, I am using the "public" profile for wired and wireless
connections and at home, when I connect my wireless network, I use the
"home" profile. So, I just do absolutely nothing, network-manager and
firewalld handles that transparently.

However, notice that it is still pretty young. I had in the past many
occurrences where firewalld didn't start correctly (so no firewall). It
doesn't happen anymore since quite some time.
--
Use free-form input when possible.
- The Elements of Programming Style (Kernighan & Plauger)
Karsten Merker
2015-05-11 17:24:56 UTC
Permalink
Post by Vincent Bernat
Post by j***@joshtriplett.org
There are much better alternatives for most common cases.
For example being?
firewalld works nicely nowadays.
[...]
Post by Vincent Bernat
However, notice that it is still pretty young. I had in the past many
occurrences where firewalld didn't start correctly (so no firewall).
Not particularly reassuring for a security-relevant application,
and surely nothing that would make me believe it to be the
"better alternative" to a proven-working iptables setup...

Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@excalibur.cnev.de
Jonathan Dowland
2015-05-11 08:29:21 UTC
Permalink
Post by j***@joshtriplett.org
There are much better alternatives for most common cases.
For example being?
ufw is quite nice.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@chew.redmars.org
Karsten Merker
2015-05-11 17:40:38 UTC
Permalink
Post by Jonathan Dowland
Post by j***@joshtriplett.org
There are much better alternatives for most common cases.
For example being?
ufw is quite nice.
AFAICS (please correct me if I am wrong) ufw appears to be
designed for simple "block all access from everywhere on all
interfaces and explicitly allow exceptions for a few services
from everywhere" setups, but anything more complex appears to be
out of its scope.

So while it is surely nice and useful for the use case it was
designed for, I cannot see it as a replacement for traditional
iptables scripts if your setup is even slightly more complex.

Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@excalibur.cnev.de
Jonathan Dowland
2015-05-12 08:47:14 UTC
Permalink
Post by Karsten Merker
Post by Jonathan Dowland
Post by j***@joshtriplett.org
There are much better alternatives for most common cases.
For example being?
ufw is quite nice.
AFAICS (please correct me if I am wrong) ufw appears to be
designed for simple "block all access from everywhere on all
interfaces and explicitly allow exceptions for a few services
from everywhere" setups, but anything more complex appears to be
out of its scope.
So while it is surely nice and useful for the use case it was
designed for, I cannot see it as a replacement for traditional
iptables scripts if your setup is even slightly more complex.
The thread I was replying to was 'common cases'. UFW indeed can't do
more complex things, but it is more sophisticated than your summary:
it can do rate limiting and various other things beyond simple
deny-by-default. I wasn't proposing it as a replacement for bare
iptables in all cases.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@chew.redmars.org
Josselin Mouette
2015-05-10 21:57:10 UTC
Permalink
Do we have other network software other than ifupdown,
systemd-networkd and network-manager, the latter handling dynamic
names rather ungracefully.
The NM configuration is based on MAC addresses and doesn’t care about
the interface name at all. This is the exact opposite of “handling
dynamic names ungracefully”.
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@debian.org
Ben Hutchings
2015-05-11 00:09:30 UTC
Permalink
Do we have other network software other than ifupdown,
systemd-networkd and network-manager, the latter handling dynamic
names rather ungracefully.
The NM configuration is based on MAC addresses and doesn’t care about
the interface name at all. This is the exact opposite of “handling
dynamic names ungracefully”.
Well, that's assuming hardware that has a permanent MAC address. What
does it do for virtual or cheap hardware that gets a different locally-
assigned address at each boot or hotplug?

Ben.
--
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison
Josselin Mouette
2015-05-11 10:16:46 UTC
Permalink
Post by Josselin Mouette
The NM configuration is based on MAC addresses and doesn’t care about
the interface name at all. This is the exact opposite of “handling
dynamic names ungracefully”.
Well, that's assuming hardware that has a permanent MAC address. What
does it do for virtual or cheap hardware that gets a different locally-
assigned address at each boot or hotplug?

In most situations, the default behavior (starting a DHCP connection
when the first adapter is plugged on) is what you want.

When you use manual configuration, the daemon’s default is to write
MAC-based configuration files, but you can change them to remove the
802-3-ethernet/mac-address setting and use connection/interface-name
instead.

See https://developer.gnome.org/NetworkManager/unstable/ref-settings.html
--
Joss
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@dsp0698014.postes.calibre.edf.fr
Ben Hutchings
2015-05-11 11:56:58 UTC
Permalink
Post by Ben Hutchings
The NM configuration is based on MAC addresses and doesn’t care about
the interface name at all. This is the exact opposite of “handling
dynamic names ungracefully”.
Well, that's assuming hardware that has a permanent MAC address. What
does it do for virtual or cheap hardware that gets a different locally-
assigned address at each boot or hotplug?
In most situations, the default behavior (starting a DHCP connection
when the first adapter is plugged on) is what you want.
When you use manual configuration, the daemon’s default is to write
MAC-based configuration files, but you can change them to remove the
802-3-ethernet/mac-address setting and use connection/interface-name
instead.
See https://developer.gnome.org/NetworkManager/unstable/ref-settings.html
I think you missed a point: permanent and locally-assigned MAC addresses
are distinguishable, so Network Manager can and should avoid matching on
the basis of a locally-assigned MAC address.

Ben.
--
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison
Josh Triplett
2015-05-08 18:36:44 UTC
Permalink
On Fri, 8 May 2015 10:50:30 -0700, Josh Triplett
Post by Josh Triplett
Post by Karsten Merker
while this probably works resonably well for (semi-)fixed devices
like onboard-NICs and PCI/PCIe cards, it results in a completely
unsuitable behaviour with pluggable devices such as USB network
adapters. When using ifnames, the interface name depends on the
USB port into which the device is currently plugged and the
interface name changes when one uses a USB hub or plugs the
device into another host port. This would mean that a user would
always have to plug his USB network device into the same port
that was used during initial setup to keep it working, and
one-off use of a USB hub would require changing the network
configuration. Despite the problems of the MAC-based system
that we use currently, the ifnames method appears way worse
to me than what we have now.
That would only be a problem if you're using ifupdown and its hardcoded
network interface names. Other network software handles dynamic names.
Do we have other network software other than ifupdown,
systemd-networkd and network-manager, the latter handling dynamic
names rather ungracefully.
wicd (to the best of my knowledge; I haven't used it), connman...

Pretty much everything other than ifupdown and tools built on or integrating
with ifupdown doesn't care what you name your network interfaces.

Also, what do you mean by NetworkManager handling dynamic names "ungracefully"?
Every time I've used it, it seems to handle any device I throw at it just fine.
I can plug in a wired or wireless network device it has never seen before, and
a few seconds later have a connection through that device. (This isn't meant
as a "works for me, not a bug"; I'd like to know what issue you've observed.)

The only case I can think of where NetworkManager might not DTRT would be if
it's hamstrung by the ifupdown plugin and some statically defined networks in
/etc/network/interfaces.
Post by Josh Triplett
Without this, you can't reliably use a system with *two* USB network
devices, because they won't consistently come up with the same names.
Or, for that matter, a system with a built-in network interface and a
USB network interface.
The current, purely udev-based method with persistent net generator
foo will note the MAC address of the USB interface and make sure that
it always gets the same ethX name. It is even possible to hand-edit
70-persistent-net.rules and make it come up as usbeth0, regardles of
the port it is being plugged in.
You're right, sorry. I was comparing ifnames to a lack of persistent
naming. However, MAC-based persistent naming has many problems of its
own. For instance, I've replaced USB network devices on headless
systems and found the new one ignored (and had to log in at the console
to disable MAC-based persistent naming). I've moved USB drives between
systems, and had to disable MAC-based persistent naming on them.

ifnames also makes it possible to use a truly read-only, stateless root
filesystem shared between many systems, without requiring differences
due to network MAC addresses.

- Josh Triplett
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@jtriplet-mobl1
Joel Wirāmu Pauling
2015-05-08 18:37:51 UTC
Permalink
Just my 0.02$ against using the BIOS method.

I have and Do see inconsistent bios vendor naming used from release to
release of their Firmware updates. I have had to fix HP Propliants servers
numerous time due to a firmware update changing the number and/or order of
SATA ports, PCI and other things.


So I for one dislike using bios provided info for any sort of userland
namespace mapping method due to the above issues caused.



-Joel
Hello Debianists,
Quick intro to the problem: The kernel generally detects network
interfaces ("eth0", "wlan1", etc.) in an unpredictable and often
unstable order. But in order to refer to a particular one in
/etc/network/interfaces, firewall configs etc. you need to use a
stable name.
The general schema for this is to have an udev rule which does some
matches to identify a particular interface, and assigns a NAME="foo"
to it. Interfaces with an explicit NAME= property get that name, and
others just get a kernel driver default, usually ethN, wlanN, or
sometimes others (some wifi drivers have their own naming schemas).
- [mac] For many many years our we have installed an udev rule
/lib/udev/rules.d/75-persistent-net-generator.rules which on first
boot creates a MAC address → current name mapping and writes
/etc/udev/rules.d/70-persistent-net.rules.
- [biosdevname] is a package originally written by Dell (IIRC),
which reads port/index/slot names from the BIOS and sets them in
/lib/udev/rules.d/71-biosdevname.rules.
- [ifnames] For about two years (since 197) upstream's udev has a
builtin persistant name generator which checks firmware/BIOS
provided index numbers or slot names (like biosdevname), falls back
to slot names (PCI numbers, etc., in the spirit of
/dev/disks/by-path/), and then optionally (not done by default)
falls back to MAC address (similar to [mac]). This happens in
/lib/udev/rules.d/80-net-setup-link.rules.
Note that these solutions can, and do get combined: The first rule
which sets a name wins, i. e. currently [biosdevname] beats [mac]
beats [ifnames].
Details about [mac]
-------------------
This is our current solution which applies to most hardware out there.
It was an useful hack almost a decade ago, but it really shows its
* It's subject to inherent race conditions (detecting a new device
vs. renaming an existing one), which sometimes leads to devices
being called "renameX" and breaking your boot.
* It requires a writable /etc/udev/rules.d/ for persistantly storing
the assignment. We don't want/have that with system-image
(touch/snappy).
* It's incompatible with how cloud images operate, as the "physical"
(emulated from the VM host) devices can change between boots.
Hence we maintain an ever-growing blacklist in
75-persistent-net-generator.rules which causes bugs and pain with
LP #1437375, #1367883, #1361272, #1317776, #1274348, #1099278.
Support for [mac] got dropped in upstream udev two years ago, and
since then we have maintained it on the Debian/Ubuntu side.
Details about [biosdevname]
---------------------------
This is a very good approach in principle, but unfortunately most
desktop and laptop BIOSes out there don't actually set this kind of
information, and of course none of the non-x86 machines do. I don't
know how pervasive it is on dedicated server hardware. So this only
actually helps for a small minority of cases, and currently falls back
to [mac].
biosdevname isn't packaged in Debian, so it's not much of a concern in
a Debian context. Some people might have installed the package from
Dell or Ubuntu.
Details about [ifnames]
-----------------------
This is a generic solution which extends the [biosdevname] idea and
thus applies to all practical cases and all architectures. It doesn't
need any persistant state (i. e. dynamic /etc/udev/rules.d/) and thus
applies nicely to snappy/touch, and also avoids the race condition.
The main downside is that by nature the device names are not familiar
to current admins yet. For BIOS provided names you get e. g. ens0, for
PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a
necessary price to pay (biosdevname names look similar).
As this hasn't been discussed yet, Debian and Ubuntu disable this by
default. You can opt into this by booting with "net.ifnames=1" (which
is a patch against upstream: there you disable it by booting with
net.ifnames=0 or disabling 80-net-setup-link.rules).
Proposal
--------
I propose to retire [mac], i. e. drop
/lib/udev/rules.d/75-persistent-net-generator.rules and enable
[ifnames] by default.
This will provide the new stable interface names for all new
installations, stop the different handling of server/client, work with
system-image, and stops the woes cloud providers have with Ubuntu's
[mac].
I'm happy to ship a commented example udev rule that shows how to
configure your own names, if you want to continue using MAC based
schemas, or call your interfaces "internet" and "intranet" or the
like. This makes it easier to see how to do custom naming than having
to start from scratch.
For upgrades: As we don't know what refers to existing stable network
names, we can't ever safely remove a generated
/etc/udev/rules.d/70-persistent-net.rules. So when we do the above,
names on existing installations will *not* change (as
70-persistent-net.rules trumps [ifnames]).
So we can only let time and replacing/reinstalling machines take care
of this. /etc/udev/rules.d/70-persistent-net.rules requires zero
maintenance from us (it's just like the admin had manually set their
own rules).
Opinions?
FTR, I also posted a similar mail to
https://lists.ubuntu.com/archives/ubuntu-devel/2015-May/038761.html
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
peter green
2015-05-09 07:49:35 UTC
Permalink
The main downside is that by nature the device names are not familiar
to current admins yet. For BIOS provided names you get e. g. ens0, for
PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a
necessary price to pay (biosdevname names look similar).
The stability of these names appears to be an illusion.

The "path based names" use the PCI bus number as their "root". PCI bus
numbers are dynamically allocated as the bios enumerates the busses.
Other than the root PCI bus they aren't a fundamental chactertistic of
the hardware. Installing or removing an expansion card can add or remove
"PCI busses" from the system and hence risks changing bus numbers. I'm
sure I even recall one case of a laptop with switchable graphics where
switching graphics setup changed the PCI bus numbers.

Someone else has raised concerns about the stability of bios based names
over bios updates.

I feel this change is likely to make things better for companies that
want to deploy images to loads of identical machines and rarely modify a
system but worse for those of us with more ad-hoc hardware arrangements.
The current system really works quite well for individual machines with
ad-hoc changes, my interfaces have consistent easy to remember names
regardless of where I plug them in and if I do have to replace an
interface card it's easy enough to open the persistent net rules file
and give the replacement interface the number of the interface it replaced.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@p10link.net
D. Jared Dominguez
2015-05-13 21:20:08 UTC
Permalink
Post by peter green
The main downside is that by nature the device names are not familiar
to current admins yet. For BIOS provided names you get e. g. ens0, for
PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a
necessary price to pay (biosdevname names look similar).
The stability of these names appears to be an illusion.
The "path based names" use the PCI bus number as their "root". PCI bus
numbers are dynamically allocated as the bios enumerates the busses.
Note that biosdevname uses slot numbers, not PCI bus numbers.

The following provides technical details on how biosdevname enumerates:
http://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf
--
Jared Domínguez
Infrastructure Software Engineering
Dell | Enterprise Solutions Group
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@dell.com
Paul Wise
2015-05-09 08:15:49 UTC
Permalink
Is there a tool to list interfaces based on their characteristics?
Right now at $work our initial setup code does glob eth* in
/sys/class/net in order to setup a bond interface using all NICs, so
network works no matter which NIC one plugs a cable into. It sounds
like this proposal would break that, so we would need a way to list
all Ethernet interfaces but not the bond interface and not any USB
network interfaces etc.
--
bye,
pabs

https://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/CAKTje6H9WPNm-OwDqA3a7UGkbJzobjr-y=***@mail.gmail.com
Martin Pitt
2015-05-09 09:44:47 UTC
Permalink
Hey Paul,
Post by Paul Wise
Is there a tool to list interfaces based on their characteristics?
Right now at $work our initial setup code does glob eth* in
/sys/class/net in order to setup a bond interface using all NICs, so
network works no matter which NIC one plugs a cable into. It sounds
like this proposal would break that, so we would need a way to list
all Ethernet interfaces but not the bond interface and not any USB
network interfaces etc.
en* should be the equivalent with ifnames (but not with biosdevname!).
Wifis are called wl*, and virtual interfaces like vlans, bridges,
bonds, etc. are assigned by the admin (or at least not by the kernel
and udev) anyway.

However, I don't know how USB ethernet interfaces look like (neither
in the kernel driver nor with ifnames).

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@piware.de
Martin Pitt
2015-05-09 09:26:14 UTC
Permalink
PCI buses can be and are hotplugged, similar to network devices.
Yes, that's certainly a valid point. It's not unanimously clear how
you define the "identity" of an interface, whether it's more like "by
location" or "by MAC address". There are pros and cons for either POV.
while this probably works resonably well for (semi-)fixed devices
like onboard-NICs and PCI/PCIe cards, it results in a completely
unsuitable behaviour with pluggable devices such as USB network
adapters.
TBH, hotpluggable USB network adapters which change all the time sound
like a corner case in a server world where you have hand-written
config files referring to interface names. They are of course common
on the client side, but there stable interface names don't matter at
all. But see below.
The "path based names" use the PCI bus number as their "root". PCI bus
numbers are dynamically allocated as the bios enumerates the busses.
PCI bus and slot numbers are stable across reboots, unless of course
you physically change the cards (what Bjørn raised above).

So, there's obviously two schools of thoughts here. Some people think
in terms of MAC addresses, which breaks if you replace a broken or
outdated card with a new one. Some people think in terms of location,
like "the left port goes to the internet, the right port to the
intranet", and there is absolutely nothing wrong with that either; in
that scenario you can replace a network card, but keep the cables
etc, and everything will still work.

I don't want to get down into philosophical questions whether
rearranging the hardware in your server should or shouldn't be
considered an identical configuration still, as that's just
bikeshedding and we'll never find 100% consensus there.

Neither MAC or location based stable names are flawless; the above
show pitfalls of location based ones, the whole cloud story (or
replacing faulty hardware) shows that MAC addresses are totally
unsuitable in common situations.

But what I do want to get rid of is the current
70-persistent-net-names.rules which have the inherent race condition
and have no configurability at all; and it provides no stable
interface names for any virtualized environment.

With ifnames you can always choose your own policy (see man
systemd.link), and e. g. say "NamePolicy=onboard mac" if you so
prefer. We can even discuss preferring "mac" over "slot" by default
(although I personally think that would be a worse default).
One could even default to "mac" for USB based hardware and the default
(kernel database onboard slot path) for others [1].

Martin

[1] I don't have USB-ethernet devices myself; if you have one, please
get in touch with me, I'd like to investigate how they look like in
udev, and what "udevadm test /sys/class/net/<iface> |grep NAME" says
about these.
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@piware.de
Marvin Renich
2015-05-09 20:35:42 UTC
Permalink
Post by Martin Pitt
TBH, hotpluggable USB network adapters which change all the time sound
like a corner case in a server world where you have hand-written
config files referring to interface names. They are of course common
on the client side, but there stable interface names don't matter at
all. But see below.
I disagree that stable interface names do not matter for USB adaptors
for consumer laptops. I have owned two laptops where the on-board WiFi
adaptor was too new to have reliable Linux drivers until 6-12 months
after I purchased them. While waiting for the Linux drivers, I used a
USB WiFi dongle that has good kernel support. I have plugged the
adaptor into different USB ports based on where my laptop was situated
wrt varied surroundings. I suspect (with no real data to back it up)
that the biggest use of USB WiFi dongles on consumer machines is when
the on-board WiFi doesn't work for some reason (too new or broken). In
this case, it is often the main internet connection and a stable name is
important.

To address the statement about swapping a new adaptor for a broken
adaptor (in server or client desktop), this happens so rarely and
already requires a significant effort (opening the machine, etc.) that
editing the udev persistent network rules is not an issue. This does
not make MAC-based names less usable in that context.

I'm not sure what the correct solution is, but from what I have seen in
this thread, I have become convinced that [ifnames] is not it. (That is
a change from my initial perception.) I would like to discourage the
proposed change. Perhaps some compromise where ifnames is used for
PCI-based devices and MAC is used for USB devices might work; I'm not
sure.

I have no problem with learning a new naming convention for the devices.
Note that the naming convention makes no difference for programmatic
use; any programmatic use should query the specific properties of the
device that are important to the program. The naming convention is only
relevant to the sysadmin, where it helps to identify properties in which
the sysadmin might be interested (e.g. wired vs wireless).

...Marvin
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@basil.wdw
Karsten Merker
2015-05-11 18:22:40 UTC
Permalink
Post by Martin Pitt
PCI buses can be and are hotplugged, similar to network devices.
Yes, that's certainly a valid point. It's not unanimously clear how
you define the "identity" of an interface, whether it's more like "by
location" or "by MAC address". There are pros and cons for either POV.
while this probably works resonably well for (semi-)fixed devices
like onboard-NICs and PCI/PCIe cards, it results in a completely
unsuitable behaviour with pluggable devices such as USB network
adapters.
TBH, hotpluggable USB network adapters which change all the time sound
like a corner case in a server world where you have hand-written
config files referring to interface names. They are of course common
on the client side, but there stable interface names don't matter at
all.
I am sorry but I have to disagree. IMHO stable interface names do
matter on clients - I have not yet seen any proof to the contrary.
Yes, there are some simple setups in which one can get along
without them, but introducing a new naming scheme that breaks
existing setups and fully legit use-cases by only taking simple
setups into account appears simply wrong to me.
Post by Martin Pitt
But see below.
The "path based names" use the PCI bus number as their "root". PCI bus
numbers are dynamically allocated as the bios enumerates the busses.
PCI bus and slot numbers are stable across reboots, unless of course
you physically change the cards (what Bjørn raised above).
As Peter Green has described in <***@p10link.net>
this assumption appears to be false at least on some laptops with
dual graphics, where simply enabling the "high power" graphics
chip in the BIOS can change the bus numbering.
Post by Martin Pitt
But what I do want to get rid of is the current
70-persistent-net-names.rules which have the inherent race condition
and have no configurability at all; and it provides no stable
interface names for any virtualized environment.
From what Ben Hutchings has described in
<***@decadent.org.uk>, the race condition
could easily be avoided with the current codebase by simply not
using "eth" as the prefix, but e.g. "en".

Could you explain why the existing code does not provide stable
names in virtual machines? As long as the virtual ethernet
controller keeps the same MAC address over time (which I believe
to be the normal case), I see no reason why the existing codebase
should not provide stable names in a VM in the same way it does
on physical hardware.
Post by Martin Pitt
With ifnames you can always choose your own policy (see man
systemd.link), and e. g. say "NamePolicy=onboard mac" if you so
prefer. We can even discuss preferring "mac" over "slot" by default
(although I personally think that would be a worse default).
One could even default to "mac" for USB based hardware and the default
(kernel database onboard slot path) for others [1].
As "slot" has been shown to be not really stable for a number of
use cases (even for PCI, see above), I think that "mac" is the
only way that works for all cases.
Post by Martin Pitt
[1] I don't have USB-ethernet devices myself; if you have one, please
get in touch with me, I'd like to investigate how they look like in
udev, and what "udevadm test /sys/class/net/<iface> |grep NAME" says
about these.
Directly plugged into a host port:
ID_NET_NAME_MAC=enx00606e123456
ID_NET_NAME_PATH=enp0s19f2u6

Plugged into a hub plugged into the same host port:
ID_NET_NAME_MAC=enx00606e123456
ID_NET_NAME_PATH=enp0s19f2u6u2

Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@excalibur.cnev.de
Martin Pitt
2015-05-12 04:12:37 UTC
Permalink
Hello,
Post by Karsten Merker
Post by Martin Pitt
From what Ben Hutchings has described in
could easily be avoided with the current codebase by simply not
using "eth" as the prefix, but e.g. "en".
Right, that would solve one problem, but not the others.
Post by Karsten Merker
Could you explain why the existing code does not provide stable
names in virtual machines? As long as the virtual ethernet
controller keeps the same MAC address over time (which I believe
to be the normal case), I see no reason why the existing codebase
should not provide stable names in a VM in the same way it does
on physical hardware.
I'm afraid you have to ask folks more familiar with clouds about the
"why", but it seems MAC addresses change all the time there as with
every new instance or even boot you get a different virtual ethernet
card assigned. See all the reports that we are getting about adding
entries to the blacklist.
Post by Karsten Merker
As "slot" has been shown to be not really stable for a number of
use cases (even for PCI, see above), I think that "mac" is the
only way that works for all cases.
It clearly doesn't work for "all cases", like replacing network cards
(in physical servers, but this is what by and large happens in clouds
too), or where you have to rely on the location of cards instead of
their MACs (like running the same config on a rack of servers, where
what you see, wire, and configure are port locations).

Anyway, I do see that we want to use MAC addresses by default for at
least USB.

Thanks,

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@piware.de
Josh Triplett
2015-05-09 21:36:30 UTC
Permalink
Post by Marvin Renich
Post by Martin Pitt
TBH, hotpluggable USB network adapters which change all the time sound
like a corner case in a server world where you have hand-written
config files referring to interface names. They are of course common
on the client side, but there stable interface names don't matter at
all. But see below.
I disagree that stable interface names do not matter for USB adaptors
for consumer laptops. I have owned two laptops where the on-board WiFi
adaptor was too new to have reliable Linux drivers until 6-12 months
after I purchased them. While waiting for the Linux drivers, I used a
USB WiFi dongle that has good kernel support. I have plugged the
adaptor into different USB ports based on where my laptop was situated
wrt varied surroundings. I suspect (with no real data to back it up)
that the biggest use of USB WiFi dongles on consumer machines is when
the on-board WiFi doesn't work for some reason (too new or broken). In
this case, it is often the main internet connection and a stable name is
important.
Why? What does a stable name matter in the case you mentioned?

Were you actually using ifupdown to manage the varied set of wireless
networks? Because if not, then the name shouldn't matter.

It doesn't seem that difficult to change the NamePolicy for that case.

- Josh Triplett
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@x
Marvin Renich
2015-05-10 00:35:57 UTC
Permalink
Post by Josh Triplett
Post by Marvin Renich
I disagree that stable interface names do not matter for USB adaptors
for consumer laptops. I have owned two laptops where the on-board WiFi
adaptor was too new to have reliable Linux drivers until 6-12 months
after I purchased them. While waiting for the Linux drivers, I used a
USB WiFi dongle that has good kernel support. I have plugged the
adaptor into different USB ports based on where my laptop was situated
wrt varied surroundings. I suspect (with no real data to back it up)
that the biggest use of USB WiFi dongles on consumer machines is when
the on-board WiFi doesn't work for some reason (too new or broken). In
this case, it is often the main internet connection and a stable name is
important.
Why? What does a stable name matter in the case you mentioned?
Were you actually using ifupdown to manage the varied set of wireless
networks? Because if not, then the name shouldn't matter.
It doesn't seem that difficult to change the NamePolicy for that case.
Yes, I use ifupdown and wpasupplicant. Based on some of the threads on
this list there are many people who love Network Manager and many who
dislike it. I am one of the ones who dislike it. Given the fact that
it is (or at least was recently) clearly controversial, choosing a path
that relies on its use seems detrimental to me, regardless of whether it
is the default or not.

...Marvin
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@basil.wdw
Cameron Norman
2015-05-10 00:55:36 UTC
Permalink
Post by Josh Triplett
Post by Marvin Renich
Post by Martin Pitt
TBH, hotpluggable USB network adapters which change all the time sound
like a corner case in a server world where you have hand-written
config files referring to interface names. They are of course common
on the client side, but there stable interface names don't matter at
all. But see below.
I disagree that stable interface names do not matter for USB adaptors
for consumer laptops. I have owned two laptops where the on-board WiFi
adaptor was too new to have reliable Linux drivers until 6-12 months
after I purchased them. While waiting for the Linux drivers, I used a
USB WiFi dongle that has good kernel support. I have plugged the
adaptor into different USB ports based on where my laptop was situated
wrt varied surroundings. I suspect (with no real data to back it up)
that the biggest use of USB WiFi dongles on consumer machines is when
the on-board WiFi doesn't work for some reason (too new or broken). In
this case, it is often the main internet connection and a stable name is
important.
Why? What does a stable name matter in the case you mentioned?
Were you actually using ifupdown to manage the varied set of wireless
networks? Because if not, then the name shouldn't matter.
Does networkd handle this situation well?

--
Cameron Norman
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/CALZWFR+xO1f7iiRx67r51XWSJwiVAHdOOPBRQewQQ2zWhHs+***@mail.gmail.com
Josh Triplett
2015-05-10 18:06:52 UTC
Permalink
Post by Cameron Norman
Post by Josh Triplett
Post by Marvin Renich
Post by Martin Pitt
TBH, hotpluggable USB network adapters which change all the time sound
like a corner case in a server world where you have hand-written
config files referring to interface names. They are of course common
on the client side, but there stable interface names don't matter at
all. But see below.
I disagree that stable interface names do not matter for USB adaptors
for consumer laptops. I have owned two laptops where the on-board WiFi
adaptor was too new to have reliable Linux drivers until 6-12 months
after I purchased them. While waiting for the Linux drivers, I used a
USB WiFi dongle that has good kernel support. I have plugged the
adaptor into different USB ports based on where my laptop was situated
wrt varied surroundings. I suspect (with no real data to back it up)
that the biggest use of USB WiFi dongles on consumer machines is when
the on-board WiFi doesn't work for some reason (too new or broken). In
this case, it is often the main internet connection and a stable name is
important.
Why? What does a stable name matter in the case you mentioned?
Were you actually using ifupdown to manage the varied set of wireless
networks? Because if not, then the name shouldn't matter.
Does networkd handle this situation well?
Yes. It has an arbitrary matching mechanism based on various attributes
of interfaces and networks. While you *can* match the interface name,
you don't need to, and you have many other options.

- Josh Triplett
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@x
Stephan Seitz
2015-05-10 11:36:08 UTC
Permalink
Post by Josh Triplett
Why? What does a stable name matter in the case you mentioned?
Because I don’t want to look up the interface name of the day when I use
wireshark/tshark? Because I don’t want to change my iptables scripts
which is working very well the way it is?
Post by Josh Triplett
Were you actually using ifupdown to manage the varied set of wireless
networks? Because if not, then the name shouldn't matter.
Yes, I’m using ifupdown. Besides USB NICs don’t have to be WiFi.

You may switch the the naming scheme in virtual environments, but only
here.

SLES is using some strange interface names like em1 or p1p2, but I hate
it. I prefer my eth0 name.

Shade and sweet water!

Stephan
--
| Stephan Seitz E-Mail: ***@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
The Wanderer
2015-05-10 12:20:11 UTC
Permalink
Post by Stephan Seitz
Post by Josh Triplett
Why? What does a stable name matter in the case you mentioned?
Because I don’t want to look up the interface name of the day when I
use wireshark/tshark? Because I don’t want to change my iptables
scripts which is working very well the way it is?
Post by Josh Triplett
Were you actually using ifupdown to manage the varied set of
wireless networks? Because if not, then the name shouldn't
matter.
Yes, I’m using ifupdown. Besides USB NICs don’t have to be WiFi.
Lots of people are, and it's inappropriate and IMO a bad idea to just
assume that you can safely break what was once and may very well still
be the single most widely-used method of controlling network interfaces
under *nix.

It has been safe to assume that wired interfaces will be named ethX, and
wireless ones wlanX, for so long that that assumption is built into many
existing procedures - both as implemented in code, and as implemented in
human habits and practices. If that assumption is to be broken, IMO at
minimum a multi-year explicit deprecation period (such as that used for
Linux-kernel feature removal) would be appropriate.
Post by Stephan Seitz
You may switch the the naming scheme in virtual environments, but
only here.
SLES is using some strange interface names like em1 or p1p2, but I
hate it. I prefer my eth0 name.
I'll note that I've also seem some proprietary (but mission-critical)
software which hardcodes interface names in some places; for example,
older versions of Novell ZENworks' system-imaging utility would crash
when attempting to multicast on a machine with an interface named em1
and no interface named eth0, reporting an inability to get the MAC
address.

That's been fixed in more recent versions, but I don't know whether it
was fixed by adding em* to the list of names to check or by adding logic
to enumerate all available interfaces without making assumptions about
their names - though the former seems more likely.

Now, ZENworks by default uses a custom LiveCD/initrd environment, and is
not based on Debian - but it's entirely possible to either build custom
versions of that environment (I've done it) or pull out the imaging
utility and run it in a different environment, and in any case there's
no way to be sure this is the only such example of important software
with this sort of problem.

(I can't check right now, but I actually suspect that at least one of
the custom wireless-network-connection-management scripts I've written
for that environment also relies on being able to assume the name
wlan0... and trying to implement properly robust parse-sysfs logic to
identify all available network adapters and distinguish wireless ones
from wired ones would be considerably more than I'd want to do in bash.)
--
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
Vincent Bernat
2015-05-10 14:24:31 UTC
Permalink
Post by The Wanderer
Post by Stephan Seitz
Post by Josh Triplett
Were you actually using ifupdown to manage the varied set of
wireless networks? Because if not, then the name shouldn't
matter.
Yes, I’m using ifupdown. Besides USB NICs don’t have to be WiFi.
Lots of people are, and it's inappropriate and IMO a bad idea to just
assume that you can safely break what was once and may very well still
be the single most widely-used method of controlling network interfaces
under *nix.
Do you speak about ifupdown? It's Debian only. eth* interfaces is not
*nix at all since all BSD are using per-driver naming convention.
Post by The Wanderer
It has been safe to assume that wired interfaces will be named ethX, and
wireless ones wlanX, for so long that that assumption is built into many
existing procedures - both as implemented in code, and as implemented in
human habits and practices. If that assumption is to be broken, IMO at
minimum a multi-year explicit deprecation period (such as that used for
Linux-kernel feature removal) would be appropriate.
On Linux, wireless drivers have long used eth* names, except for some
out-of-tree drivers. It was the introduction fo the MAC 802.11 soft
layer (2.6.22+) that gradually switched drivers to use wlan* names. And
this change was driver by driver, at each release without much
publicity. Drivers not using the new framework to register themselves
are still using eth* names (like the Prism54 "full mac" driver).
Post by The Wanderer
Post by Stephan Seitz
You may switch the the naming scheme in virtual environments, but
only here.
SLES is using some strange interface names like em1 or p1p2, but I
hate it. I prefer my eth0 name.
I'll note that I've also seem some proprietary (but mission-critical)
software which hardcodes interface names in some places; for example,
older versions of Novell ZENworks' system-imaging utility would crash
when attempting to multicast on a machine with an interface named em1
and no interface named eth0, reporting an inability to get the MAC
address.
This thread is about changing the default naming convention for network
interfaces. If you love to run an unmaintained version of Novell
ZENworks, you can still have an eth0 interface if you want.

Actually, when rebooting your (mission-critical) server, you can have a
race condition where "eth1" is not the interface that was "eth1" on the
previous boot and "rename5" is the interface that should be
"eth1". That's what needs to be fixed. Doing nothing won't fix that.
--
Make your program read from top to bottom.
- The Elements of Programming Style (Kernighan & Plauger)
The Wanderer
2015-05-10 14:45:37 UTC
Permalink
Post by Vincent Bernat
Post by The Wanderer
Post by Stephan Seitz
Post by Josh Triplett
Were you actually using ifupdown to manage the varied set of
wireless networks? Because if not, then the name shouldn't
matter.
Yes, I’m using ifupdown. Besides USB NICs don’t have to be WiFi.
Lots of people are, and it's inappropriate and IMO a bad idea to
just assume that you can safely break what was once and may very
well still be the single most widely-used method of controlling
network interfaces under *nix.
Do you speak about ifupdown? It's Debian only. eth* interfaces is
not *nix at all since all BSD are using per-driver naming
convention.
Upon consideration, I suspect that I've been making - at least - the
following three assumptions:

* That ifupdown is essentially (in functionality if not in
implementation) a set of wrappers around ifconfig, with a few additional
scripts.

* That ifconfig uses /etc/network/interfaces just as ifupdown does, and
so would have the same interface-naming limitations. (I think this one
was based in part on observation of real-world behavior.)

* That ifconfig has been the standard way of working with network
interfaces for more-or-less as long as there _has_ been a standard
userspace way of doing that.

If any (or all!) of those assumptions are false, then some of my
conclusions may not hold.
Post by Vincent Bernat
Post by The Wanderer
It has been safe to assume that wired interfaces will be named
ethX, and wireless ones wlanX, for so long that that assumption is
built into many existing procedures - both as implemented in code,
and as implemented in human habits and practices. If that
assumption is to be broken, IMO at minimum a multi-year explicit
deprecation period (such as that used for Linux-kernel feature
removal) would be appropriate.
On Linux, wireless drivers have long used eth* names, except for
some out-of-tree drivers. It was the introduction fo the MAC 802.11
soft layer (2.6.22+) that gradually switched drivers to use wlan*
names. And this change was driver by driver, at each release without
much publicity. Drivers not using the new framework to register
themselves are still using eth* names (like the Prism54 "full mac"
driver).
I wasn't aware of the specifics of the shift; acknowledged. That would
simply strengthen the argument for its having been safe to assume the
ethX naming, though, at least as much as it weakens the argument for its
having been safe to assume the wlanX naming.
Post by Vincent Bernat
Post by The Wanderer
Post by Stephan Seitz
You may switch the the naming scheme in virtual environments,
but only here.
SLES is using some strange interface names like em1 or p1p2, but
I hate it. I prefer my eth0 name.
I'll note that I've also seem some proprietary (but
mission-critical) software which hardcodes interface names in some
places; for example, older versions of Novell ZENworks'
system-imaging utility would crash when attempting to multicast on
a machine with an interface named em1 and no interface named eth0,
reporting an inability to get the MAC address.
This thread is about changing the default naming convention for
network interfaces. If you love to run an unmaintained version of
Novell ZENworks, you can still have an eth0 interface if you want.
Where do you get "unmaintained" from?

And my point was not about that one specific program; I was just using
it as an example to indicate that there do exist important programs,
which may not always be within the power of the people using them to
modify, which are not compatible with other naming conventions.

As far as "default" - I'll just say that I wouldn't be pleased to have a
script break under me because of a change from 'eth0' to 'ens0' or
'enp1s1' on a system which only _has_ one network device. On desktop
systems, at least, such systems are by far the most common case - and
while network-device references in scripts not shipped by packages may
not be terribly common on such systems, I still don't think it's a good
idea to break the ones which do exist.
Post by Vincent Bernat
Actually, when rebooting your (mission-critical) server, you can have
a race condition where "eth1" is not the interface that was "eth1" on
the previous boot and "rename5" is the interface that should be
"eth1". That's what needs to be fixed. Doing nothing won't fix that.
I did not advocate doing nothing. I agree that having names change under
one's feet is a bad thing.

I simply think that a solution to this problem which breaks the
interface-naming assumptions which have been in place for so long is
quite likely to be, at least in some ways, a cure worse than the
disease.
--
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
Vincent Bernat
2015-05-10 15:11:03 UTC
Permalink
Post by The Wanderer
Post by Vincent Bernat
Do you speak about ifupdown? It's Debian only. eth* interfaces is
not *nix at all since all BSD are using per-driver naming
convention.
Upon consideration, I suspect that I've been making - at least - the
* That ifupdown is essentially (in functionality if not in
implementation) a set of wrappers around ifconfig, with a few additional
scripts.
Why not.
Post by The Wanderer
* That ifconfig uses /etc/network/interfaces just as ifupdown does, and
so would have the same interface-naming limitations. (I think this one
was based in part on observation of real-world behavior.)
ifconfig doesn't use /etc/network/interfaces. As far as I know, ifconfig
doesn't use any configuration file.
Post by The Wanderer
* That ifconfig has been the standard way of working with network
interfaces for more-or-less as long as there _has_ been a standard
userspace way of doing that.
ifconfig is mostly unmaintained. The standard way to work with network
interfaces on Linux is "ip" (unlike most *nix). Also ifconfig isn't able
to see all IP addresses on a given interface.
Post by The Wanderer
Post by Vincent Bernat
Post by The Wanderer
It has been safe to assume that wired interfaces will be named
ethX, and wireless ones wlanX, for so long that that assumption is
built into many existing procedures - both as implemented in code,
and as implemented in human habits and practices. If that
assumption is to be broken, IMO at minimum a multi-year explicit
deprecation period (such as that used for Linux-kernel feature
removal) would be appropriate.
On Linux, wireless drivers have long used eth* names, except for
some out-of-tree drivers. It was the introduction fo the MAC 802.11
soft layer (2.6.22+) that gradually switched drivers to use wlan*
names. And this change was driver by driver, at each release without
much publicity. Drivers not using the new framework to register
themselves are still using eth* names (like the Prism54 "full mac"
driver).
I wasn't aware of the specifics of the shift; acknowledged. That would
simply strengthen the argument for its having been safe to assume the
ethX naming, though, at least as much as it weakens the argument for its
having been safe to assume the wlanX naming.
The point is that Linux did change the prefix without any prior
warning. The world is still running despite this change.
Post by The Wanderer
Post by Vincent Bernat
Post by The Wanderer
I'll note that I've also seem some proprietary (but
mission-critical) software which hardcodes interface names in some
places; for example, older versions of Novell ZENworks'
system-imaging utility would crash when attempting to multicast on
a machine with an interface named em1 and no interface named eth0,
reporting an inability to get the MAC address.
This thread is about changing the default naming convention for
network interfaces. If you love to run an unmaintained version of
Novell ZENworks, you can still have an eth0 interface if you want.
Where do you get "unmaintained" from?
And my point was not about that one specific program; I was just using
it as an example to indicate that there do exist important programs,
which may not always be within the power of the people using them to
modify, which are not compatible with other naming conventions.
Your key example is an old version of a proprietary software
that nobody ever heard of. Great example.
Post by The Wanderer
Post by Vincent Bernat
Actually, when rebooting your (mission-critical) server, you can have
a race condition where "eth1" is not the interface that was "eth1" on
the previous boot and "rename5" is the interface that should be
"eth1". That's what needs to be fixed. Doing nothing won't fix that.
I did not advocate doing nothing. I agree that having names change under
one's feet is a bad thing.
I simply think that a solution to this problem which breaks the
interface-naming assumptions which have been in place for so long is
quite likely to be, at least in some ways, a cure worse than the
disease.
The disease is that actual servers running actual free software can
break at each boot because we cannot have both a persistent naming
scheme and use the eth* prefix is worse that the cure because old
versions of Novell ZENworks may stop to work on upgrade?

Seriously.
--
Terminate input by end-of-file or marker, not by count.
- The Elements of Programming Style (Kernighan & Plauger)
Stephan Seitz
2015-05-10 19:04:23 UTC
Permalink
Post by Vincent Bernat
The disease is that actual servers running actual free software can
break at each boot because we cannot have both a persistent naming
scheme and use the eth* prefix is worse
Just for the record, an unexpected interface name change hasn't
happened in my professional career in more than ten years. Plugging
persistent network naming with -this- imminent danger destroys the
pro-faction's credibility.
Same here. I have never seen unexpected interface changes.

Shade and sweet water!

Stephan
--
| Stephan Seitz E-Mail: ***@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
Jonathan Dowland
2015-05-11 08:34:32 UTC
Permalink
Post by Stephan Seitz
Just for the record, an unexpected interface name change hasn't
happened in my professional career in more than ten years.
Same here. I have never seen unexpected interface changes.
I have, during my 10 year tenure as a systems administrator.
Post by Stephan Seitz
Shade and sweet water!
Still on the wrong side of your signature separator...
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@chew.redmars.org
Russell Stuart
2015-05-11 00:18:18 UTC
Permalink
Post by Vincent Bernat
The disease is that actual servers running actual free software can
break at each boot because we cannot have both a persistent naming
scheme and use the eth* prefix is worse that the cure because old
versions of Novell ZENworks may stop to work on upgrade?
Speaking as someone who runs Debian on his servers and laptop, I don't
care about what you guys choose.

I don't care on the laptop mostly because of the reasons Josh Triplet
pointed out earlier. I manage the network through GUI interfaces, and
it doesn't care what the interfaces are called.

For servers the interfaces are all assigned fixed, well known names.
The reason is their configuration is completely automated through 100's
of scripts. In all instances I've seen it done like this well known
interface names are used. It's not difficult to understand why if
you've done it - you can sort out what NIC is supposed to be doing at
install or boot up and rename it accordingly, or you can do it in every
script that deals with the network. The choice is obvious.

You have the "disease" wrong. These scripts have been around for over a
decade. In that time various fashions in interface naming have come and
gone. This is yet another one. The disease isn't the kernel choosing
different names on boot up, it's people inventing new interface naming
schemes every few years, just as being done here. Everyone who has had
to support many servers over a long period gets sick of this and writes
yet another script that does in the renaming in the way they want, in a
way that will be stable forever more. Thus they don't care what choice
is made here - as they have already given up relying on Debian to do it,
because Debian isn't stable enough.

That said when writing our own scripts most of us long ago came to the
conclusion the bus path to the interface was the most useful way to
identify it. Again the reason is straight forward - if you have an
image tuned for a piece of hardware that you have deployed en-masse the
one thing that is the same on all of them is the paths to the NIC's.
Note that when, long ago, the kernels actually managed to repeatability
name the NIC's eth0, eth1 etc, it was because the buses were enumerated
in a repeatable order so the NIC's got seen in a repeatable order. So
in effect the name was determined by the bus path. Ergo, nothing has
changed in 20 years.

I get the distinct feeling some people posting here consider ifup/down
"old fashioned". Granted it doesn't have a nice GUI, but from the point
of view of someone who deploys lots of similar machines a GUI of any
sort is a negative, and it has a far nicer property - it is easily
scriptable. In fact underneath the hood it's driven by scripts. If
there is a network configuration it isn't capable of setting up, I
haven't seen it. In my very brief look at networkd it didn't provide
anything like the same amount of flexibility.
Russell Stuart
2015-05-11 12:37:40 UTC
Permalink
For example, it doesn't know dependencies between Interfaces, which is
rather common for a server jockey (consider a VLAN on a bridge which
is connected to the network via a bonding device)
I haven't had to solve that example, but I have had a problem again
involving bridges that sounds similar. It was solvable with ifup/down -
by calling ifup in the /etc/network/interfaces pre-up. I'll grant you
it's not pretty, but I've only had to do it once so I forgive aj.
[ifupdown] it doesn't handle IP addresses that come and go
at run time (as it is to be expected on IPv6 networks).
Could you explain when IPv6 addresses come and go? You are talking to a
IPv6 neophyte here. In the IPv4 world addresses handed out by DHCP do
come and go. It's true that isn't handled by ifupdown, but that's not a
problem because if you want to do something about it, you do it in the
dhclient hook. It seems the right place to me.

That aside, I don't see anything in "man systemd.network" that allows
you to watch for IPv6 addresses coming and going, or for that matter
anything else coming and going except devices.
And, when it comes to scriptability and flexiblity, systemd-networkd
is vastly superior. It was made with a server in mind.
This para is the real reason I'm responding. I must be missing
something, because nowhere in "man systemd.network" do I see to a way to
run a script of any sort. For me the acid test is "can it do totally
manual configuration", ie the equivalent of ifupdown's "manual" method.
(I occasionally use manual - it's a great way of ensuring there are no
surprises.) systemd.network's [Match] section combined with the sort of
demonstrated by ifupdown's manual method would be a match made in
heaven. But if it exists I've missed it. You could perhaps emulate it
if it were possible to make a systemd.service depend on a
systemd.network, but that appears to be right out of scope. As it
stands, networkd looks to be one of the least scriptable networking
configuration options I've seen since ... oh redhat 7.0 or so.
Otoh, it is much harder to debug, extend and modify than ifupdown,
which has a _very_ flexible script interface.
Up until recently I thought the systemd mob had solved the "visibility"
problem by logging everything written to stdout and stderr with
journald. I was disabused of that notion just this weekend, when
apache2 failed to start after an apt-get dist-upgrade. journalctl -xn
helpfully told me:

$ ssu journalctl -xn
-- Logs begin at Mon 2015-05-11 21:16:17 AEST, end at Mon 2015-05-11 22:22:42 AEST. --
May 11 22:21:43 russell-laptop systemd[1]: apache2.service: control process exited, code=exited stat
May 11 22:21:43 russell-laptop systemd[1]: Failed to start LSB: Apache2 web server.
-- Subject: Unit apache2.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit apache2.service has failed.
--
-- The result is failed.

Which is about as useful as a hip pocket in a singlet. In the end this
told me what was going on:

$ _SYSTEMCTL_SKIP_REDIRECT=true /etc/init.d/apache2 start
[FAIL] Starting web server: apache2 failed!
[warn] The apache2 configtest failed. ... (warning).
Output of config test was:
apache2: Syntax error on line 141 of /etc/apache2/apache2.conf: Could not open configuration file /etc/apache2/mods-enabled/php5_cgi.conf: No such file or directory
Action 'configtest' failed.
The Apache error log may have more information.

Having to troll through scripts in /var/lib/lsb in order to figure out
how to disable the systemd redirect in order to see the error message
the sysV init script sent to stdout is NOT an improvement. (The Apache
error log was empty.)

If debugging networkd stuff is harder, then ... *shudder*.
Vincent Lefevre
2015-05-12 15:08:33 UTC
Permalink
In IPv6, routers advertise prefixes. If a new prefix comes, end
systems configured for SLAAC will allocate an IP address in this
prefix and begin to use it.
On this subject, end systems under Debian are configured for SLAAC
by default. :-(
--
Vincent Lefèvre <***@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@ypig.lip.ens-lyon.fr
Vincent Lefevre
2015-05-13 15:16:07 UTC
Permalink
On Tue, 12 May 2015 17:08:33 +0200, Vincent Lefevre
Post by Vincent Lefevre
In IPv6, routers advertise prefixes. If a new prefix comes, end
systems configured for SLAAC will allocate an IP address in this
prefix and begin to use it.
On this subject, end systems under Debian are configured for SLAAC
by default. :-(
I consider that a feature.
Well, having some of the network traffic (more precisely, connections
to machines that have an IPv6 address) re-routed to some unknown
machine on the local network is not a nice feature.

IMHO, such a feature should be enabled only by the network management
system, not by default at the kernel level.
--
Vincent Lefèvre <***@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@xvii.vinc17.org
Russell Stuart
2015-05-13 23:07:16 UTC
Permalink
Post by Vincent Lefevre
Well, having some of the network traffic (more precisely, connections
to machines that have an IPv6 address) re-routed to some unknown
machine on the local network is not a nice feature.
IMHO, such a feature should be enabled only by the network management
system, not by default at the kernel level.
Now I've looked up what Marc is referring to in an earlier reply, SLAAC
and DHCP look pretty similar to me. Both have the "re-route your NIC to
some unknown machine" feature. I'm sure everybody here will be the
victim of a rouge router sending NDP responses, just as everybody has
already been the victim of a rouge DHCP server.

Not having the "automatically make my NIC usable on bootup" feature
enabled by default would seem like a major omission to me.

The one difference between the two right now is dhclient make it easy
for the client to watch for changes using scripts. AFAICT, there is no
off the shelf way of doing it for SLAAC. It's easy enough to do - just
have a daemon listen to kernel netlink messages and fire off a script.
The right place to put that now would be in systemd, but if they are
opposed to scripts as Marc says that ain't going to happen. Sigh.
Vincent Danjean
2015-05-10 20:23:50 UTC
Permalink
Post by Vincent Bernat
Actually, when rebooting your (mission-critical) server, you can have a
race condition where "eth1" is not the interface that was "eth1" on the
previous boot and "rename5" is the interface that should be
"eth1". That's what needs to be fixed. Doing nothing won't fix that.
Can someone confirms that the race condition comes from the fact that
both the initial-kernel name and the udev-setup name both use the
'ethX' template ?
Would we still have a race condition if
/etc/udev/rules.d/70-persistent-net.rules was stting up other names
(such as renethX or any other template different from the default
kernel name) ?

If the answer of the last question is "no", whatever the default
that will be chosen, I will configure my systems to use MAC-based
names but with a different template (enX for example).

Regards,
Vincent
--
Vincent Danjean GPG key ID 0xD17897FA ***@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@free.fr
Ben Hutchings
2015-05-10 21:55:33 UTC
Permalink
Post by Vincent Danjean
Post by Vincent Bernat
Actually, when rebooting your (mission-critical) server, you can have a
race condition where "eth1" is not the interface that was "eth1" on the
previous boot and "rename5" is the interface that should be
"eth1". That's what needs to be fixed. Doing nothing won't fix that.
Can someone confirms that the race condition comes from the fact that
both the initial-kernel name and the udev-setup name both use the
'ethX' template ?
Yes, that's it.
Post by Vincent Danjean
Would we still have a race condition if
/etc/udev/rules.d/70-persistent-net.rules was stting up other names
(such as renethX or any other template different from the default
kernel name) ?
Not since systemd 215-14. Previously there was another race condition
in updating that file (#765577).
Post by Vincent Danjean
If the answer of the last question is "no", whatever the default
that will be chosen, I will configure my systems to use MAC-based
names but with a different template (enX for example).
Ben.
--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson
Marco d'Itri
2015-05-11 03:53:53 UTC
Permalink
I propose to retire [mac], i. e. drop
/lib/udev/rules.d/75-persistent-net-generator.rules and enable
[ifnames] by default.
I see a large enough consensus about switching by default to ifnames,
and I believe that the few people who want MAC-based names for USB
interfaces can easily set NamePolicy=mac or write a custom rule.

I am not sure that we really need to retire 75-persistent-net-generator
right now: the annoying part to maintain is the kernel patch which we
will need anyway for at least a couple of releases, and once we make it
use em* or eno* instead of eth* then it should be robust.
It is trivial to make it opt-in by setting something like net.ifnames=0
(or even a different and specific value), and we can revisit this
decision when we will be closer to the release.
So we can only let time and replacing/reinstalling machines take care
of this. /etc/udev/rules.d/70-persistent-net.rules requires zero
maintenance from us (it's just like the admin had manually set their
own rules).
Actually it requires us to keep maintaining the
Revert-udev-network-device-renaming patch as long as there will be
systems with a 70-persistent-net.rules file renaming eth* to eth*.


I believe that firmware-based device names work well enough in practice
since RHEL 7 uses them by default: I tend to trust a market-based
approach to maintenability more than anecdote from a very selected
population like the debian-devel@ subscribers.
This is the relevant documentation, which I strongly recommend everybody
interested in this issue to read:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Device_Renaming_Procedure.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Predictable_Network_Interface_Device_Names.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html

Maybe biosdevname would be nice to have, but:
- somebody needs to actually maintain it in Debian
- by default it only works on Dell systems
- it is not loved by the udev/systemd upstream maintainers
- it does not seem to me to provide any benefit over the firmware-based
names since in practice both would use by default an interface index
in the common case

So I do not think that we need to care about it.

An obvious downside is longer names for devices which do not provide
ID_NET_NAME_ONBOARD: e.g. the WiFi card in my Dell laptop does
not (wlp2s0), but the Ethernet port does (eno1).
It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on
my Allwinner-based ARM computer), which means that interfaces will get
a mac-based name like enx028909xxxxxx.
But if somebody cares about the aesthetic value of network interface
names then they can probably write a custom udev rule to rename them,
or keep using 75-persistent-net-generator if we can keep it around.

(I believe that it would be a good idea for the ARM porters to have
a look at which values are exported by their network drivers, because
probably nobody else is going to work on this any time soon.)

FWIW, I did a quick survey of my hardware:
- HP G8: OK
- HP G8 + add-on Intel card: OK (but obviously no index)
- HP G8 + FlexFabric: OK
- HP Gen9 + FlexFabric: stupid but will work (the SMBIOS indexes start
from 49 instead of 1!)
- Cisco UCS: OK
- IBM BladeCenter + Emulex CNA: very broken (only eth0 has an index!
I only checked biosdevname but it should not matter)
- IBM Flex + Emulex CNA: broken like the BladeCenter
- Some Intel-based Supermicro: OK

(If any of the HP people here can find out who is responsible to fix
the Gen9 BIOS then I can have my HP account manager make a business case
for it. Submitting a support case would be time consuming for me and
unnecessarily cruel for the support people...)
--
ciao,
Marco
Martin Pitt
2015-05-11 05:00:05 UTC
Permalink
Hey Marco,
Post by Marco d'Itri
I am not sure that we really need to retire 75-persistent-net-generator
right now: the annoying part to maintain is the kernel patch which we
will need anyway for at least a couple of releases
Which kernel patch? I think all of this ought to work on a vanilla
kernel.
Post by Marco d'Itri
It is trivial to make it opt-in by setting something like
net.ifnames=0 (or even a different and specific value), and we can
revisit this decision when we will be closer to the release.
Yes, that will be the case once we drop the Debian specific
Make-net.ifnames-opt-in-instead-of-opt-out.patch .
Post by Marco d'Itri
Actually it requires us to keep maintaining the
Revert-udev-network-device-renaming patch as long as there will be
systems with a 70-persistent-net.rules file renaming eth* to eth*.
Argh, that's true. I. e. another decade or so :/
Post by Marco d'Itri
[...]
So I do not think that we need to care about it.
Full ack. ifnames does everything biosdevname does and is both more
universal and also more flexible to configure, so there is absolutely
zero reason to introduce biosdevname now. It's mostly a backwards
compatibility problem for systems which already have it installed (i.
e. not pure Debian).
Post by Marco d'Itri
An obvious downside is longer names for devices which do not provide
ID_NET_NAME_ONBOARD: e.g. the WiFi card in my Dell laptop does
not (wlp2s0), but the Ethernet port does (eno1).
It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on
my Allwinner-based ARM computer), which means that interfaces will get
a mac-based name like enx028909xxxxxx.
Remember, MAC based names aren't used with the default policy, you
have to opt-in. Although it might happen that we do configure this by
default for USB devices in the Debian policy, see the other parts of
the thread.

Thanks!

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Marvin Renich
2015-05-11 11:19:23 UTC
Permalink
Post by Marco d'Itri
I see a large enough consensus about switching by default to ifnames,
and I believe that the few people who want MAC-based names for USB
interfaces can easily set NamePolicy=mac or write a custom rule.
Huh? This thread seems to have lots of opinions on both sides with no
consensus at all. I don't see how you can make this assertion with a
straight face.

...Marvin
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@basil.wdw
Marco d'Itri
2015-05-11 14:27:15 UTC
Permalink
Post by Marvin Renich
Post by Marco d'Itri
I see a large enough consensus about switching by default to ifnames,
and I believe that the few people who want MAC-based names for USB
interfaces can easily set NamePolicy=mac or write a custom rule.
Huh? This thread seems to have lots of opinions on both sides with no
consensus at all. I don't see how you can make this assertion with a
straight face.
I see some concerns about using firmware-derived names for USB devices,
but not significant objections for the general case.
Consensus does not mean that there is no disagreement at all, but that
all objections have been addressed.
--
ciao,
Marco
Ben Hutchings
2015-05-11 11:51:25 UTC
Permalink
On Mon, 2015-05-11 at 05:53 +0200, Marco d'Itri wrote:
[...]
Post by Marco d'Itri
It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on
my Allwinner-based ARM computer), which means that interfaces will get
a mac-based name like enx028909xxxxxx.
[...]

For ARM (and any other architecture using Device Tree) the on-board
indices should be specified as aliases 'ethernet0', 'ethernet1', etc.
The aliases will be listed in the uevent as OF_ALIAS_0 (or OF_ALIAS_1,
etc., as a device can have multiple aliases).

Ben.
--
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison
Marco d'Itri
2015-05-11 18:21:21 UTC
Permalink
Post by Ben Hutchings
For ARM (and any other architecture using Device Tree) the on-board
indices should be specified as aliases 'ethernet0', 'ethernet1', etc.
Is this something that I can experiment on by patching just the device
tree definition or does it happen in the driver?
Do you have an example that I can look at?
Post by Ben Hutchings
The aliases will be listed in the uevent as OF_ALIAS_0 (or OF_ALIAS_1,
etc., as a device can have multiple aliases).
udev does not know about this variable, so unless the index will also
appear somewhere else it will not be enough.
--
ciao,
Marco
Karsten Merker
2015-05-11 18:34:25 UTC
Permalink
Post by Marco d'Itri
I believe that firmware-based device names work well enough in practice
since RHEL 7 uses them by default: I tend to trust a market-based
approach to maintenability more than anecdote from a very selected
RHEL itself targets only a "very selected population" - corporate
server setups with usually very uniform datacenter-grade
hardware. Debian has an a lot more diverse userbase and caters
for many users outside the corporate server world, so what might
be a proper solution for RHEL does not have to be a proper
solution for Debian.

Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@excalibur.cnev.de
D. Jared Dominguez
2015-05-13 21:29:31 UTC
Permalink
Post by Marco d'Itri
- somebody needs to actually maintain it in Debian
I actually had it ready to upload, but then given the approach RHEL 7
took and the general trend towards systemd-based approaches, I held off.
If there is interest, though, I'm happy to maintain biosdevname for
Debian (and also work on the same team as the biosdevname maintainer).
Post by Marco d'Itri
- by default it only works on Dell systems
That's not entirely true. It's more the case that we make sure our BIOS
people don't mess things up so that biosdevname stops working correctly
on our hardware. Having consistent interface naming is important for us.
(We also have started caring about consistent enumeration for storage.)
The end result is the same, though.
Post by Marco d'Itri
- it does not seem to me to provide any benefit over the firmware-based
names since in practice both would use by default an interface index
in the common case
Firmware based in what sense? From the biosdevname readme, biosdevname
uses:
PCI Configuration Space
PCI IRQ Routing Table ($PIR)
PCMCIA Card Information Structure
SMBIOS 2.6 Type 9, Type 41, and HP OEM-specific types

--Jared
--
Jared Domínguez
Infrastructure Software Engineering
Dell | Enterprise Solutions Group
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@dell.com
Marco d'Itri
2015-05-14 02:07:54 UTC
Permalink
Post by D. Jared Dominguez
Post by Marco d'Itri
- it does not seem to me to provide any benefit over the firmware-based
names since in practice both would use by default an interface index
in the common case
PCI Configuration Space
PCI IRQ Routing Table ($PIR)
PCMCIA Card Information Structure
SMBIOS 2.6 Type 9, Type 41, and HP OEM-specific types
Yes, but how often in practice it is able to provide an emN name while
at the same time udev is unable to provide an enoN name?
--
ciao,
Marco
Thomas Goirand
2015-06-26 09:01:59 UTC
Permalink
Post by Marco d'Itri
I propose to retire [mac], i. e. drop
/lib/udev/rules.d/75-persistent-net-generator.rules and enable
[ifnames] by default.
I see a large enough consensus about switching by default to ifnames,
FWIW: I don't. In this very thread, I have read many counter-arguments.
Post by Marco d'Itri
and I believe that the few people who want MAC-based names for USB
interfaces can easily set NamePolicy=mac or write a custom rule.
As always (and as it was for systemd), what counts here is the default.
Post by Marco d'Itri
So we can only let time and replacing/reinstalling machines take care
of this. /etc/udev/rules.d/70-persistent-net.rules requires zero
maintenance from us (it's just like the admin had manually set their
own rules).
Actually it requires us to keep maintaining the
Revert-udev-network-device-renaming patch as long as there will be
systems with a 70-persistent-net.rules file renaming eth* to eth*.
The other solution would be to upstream that patch (maybe as a kernel
option if that is relevant).
Post by Marco d'Itri
I believe that firmware-based device names work well enough in practice
since RHEL 7 uses them by default: I tend to trust a market-based
approach to maintenability more than anecdote from a very selected
Oh, how nice is that... So our opinions don't count, and Red Hat is just
always right!

FYI, I had non-anecdotal very bad experience to report, with the ifnames
from udev causing not-so-easy to fix issues deploying OpenStack on a
variety of hardware. I'm talking about large deployments here (in my
mind, large means more than 200 machines...).
Post by Marco d'Itri
This is the relevant documentation, which I strongly recommend everybody
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Device_Renaming_Procedure.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Predictable_Network_Interface_Device_Names.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html
All from redhat. /me not surprised...
Post by Marco d'Itri
- somebody needs to actually maintain it in Debian
- by default it only works on Dell systems
- it is not loved by the udev/systemd upstream maintainers
- it does not seem to me to provide any benefit over the firmware-based
names since in practice both would use by default an interface index
in the common case
So I do not think that we need to care about it.
An obvious downside is longer names for devices which do not provide
ID_NET_NAME_ONBOARD: e.g. the WiFi card in my Dell laptop does
not (wlp2s0), but the Ethernet port does (eno1).
It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on
my Allwinner-based ARM computer), which means that interfaces will get
a mac-based name like enx028909xxxxxx.
Which is so convenient to type on the shell, right? :)
Post by Marco d'Itri
But if somebody cares about the aesthetic value of network interface
names then they can probably write a custom udev rule to rename them,
or keep using 75-persistent-net-generator if we can keep it around.
So your proposal is: if the default is unusable (like above), then the
poor user has to find a way to fix that... I'm not convince that this is
what we want. I'd very much prefer a usable default.

Cheers,

Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@debian.org
Marco d'Itri
2015-06-26 09:14:47 UTC
Permalink
Post by Thomas Goirand
Post by Marco d'Itri
Actually it requires us to keep maintaining the
Revert-udev-network-device-renaming patch as long as there will be
systems with a 70-persistent-net.rules file renaming eth* to eth*.
The other solution would be to upstream that patch (maybe as a kernel
option if that is relevant).
This cannot happen since the patch actually reverts an upstream change.
Post by Thomas Goirand
Post by Marco d'Itri
I believe that firmware-based device names work well enough in practice
since RHEL 7 uses them by default: I tend to trust a market-based
approach to maintenability more than anecdote from a very selected
Oh, how nice is that... So our opinions don't count, and Red Hat is just
always right!
Opinions do not make a statistic, indeed.
And you have not been paying attention, because right here I have
expressed many times disagreement with some Red Hat decisions.
Post by Thomas Goirand
All from redhat. /me not surprised...
Yes, at this point it is not a surprise that they produce good
documentation and we do not.
Post by Thomas Goirand
So your proposal is: if the default is unusable (like above), then the
poor user has to find a way to fix that... I'm not convince that this is
what we want. I'd very much prefer a usable default.
Me too, but there is none that we can use.
--
ciao,
Marco
Thomas Goirand
2015-06-29 20:29:44 UTC
Permalink
Post by Marco d'Itri
Post by Thomas Goirand
Post by Marco d'Itri
I believe that firmware-based device names work well enough in practice
since RHEL 7 uses them by default: I tend to trust a market-based
approach to maintenability more than anecdote from a very selected
Oh, how nice is that... So our opinions don't count, and Red Hat is just
always right!
Opinions do not make a statistic, indeed.
I'm sure you will agree that (computer) science is *not* about
statistics anyway. I also tend to feel uncomfortable when I read
"market-based" next to "[technical] approach", it's too marketing-ish,
and I like to think that marketing isn't what influences Debian's
technical decision (let's hope I'm not wrong here...).
Post by Marco d'Itri
And you have not been paying attention, because right here I have
expressed many times disagreement with some Red Hat decisions.
Well, we don't have to follow all of what they do!
Post by Marco d'Itri
Post by Thomas Goirand
All from redhat. /me not surprised...
Yes, at this point it is not a surprise that they produce good
documentation and we do not.
I was trying to make the point that all of this ifname renaming cruft
comes from Red Hat, and from systemd guys. Do we *have* to do it, just
because they do? I'm really not convinced, as I saw how much trouble it
can bring. For a single desktop machine, it's manageable. For a large
cloud deployment with (very) heterogeneous hardware and multiple ifaces
on each node, it can be hell to get the deployment right.
Post by Marco d'Itri
Post by Thomas Goirand
So your proposal is: if the default is unusable (like above), then the
poor user has to find a way to fix that... I'm not convince that this is
what we want. I'd very much prefer a usable default.
Me too, but there is none that we can use.
Sure there is: keep the good old ethX naming, which has always worked
for many, many years. Now, expecting someone will raise the fact that
sometimes, we get a different order of the ifaces. Well, there's many
ways around that, the persistent naming file is one solution (which I
don't like, as I think it shouldn't be written by default, it should be
the user's decision to write it if he wants to, but hey, let's not
discuss that...).

Cheers,

Thomas
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@debian.org
Vincent Bernat
2015-06-29 22:14:35 UTC
Permalink
Post by Thomas Goirand
Post by Marco d'Itri
Post by Thomas Goirand
So your proposal is: if the default is unusable (like above), then the
poor user has to find a way to fix that... I'm not convince that this is
what we want. I'd very much prefer a usable default.
Me too, but there is none that we can use.
Sure there is: keep the good old ethX naming, which has always worked
for many, many years. Now, expecting someone will raise the fact that
sometimes, we get a different order of the ifaces. Well, there's many
ways around that, the persistent naming file is one solution (which I
don't like, as I think it shouldn't be written by default, it should be
the user's decision to write it if he wants to, but hey, let's not
discuss that...).
It has worked for many many years as long as the drivers were loaded
synchronously. This is not the case anymore. When you have two brands of
network card (for example bnx2 and e1000, quite common on HP servers),
at each boot, you can get something different. And while the persistent
naming file is a solution that worked almost all the time, there was
some time where an interface were renamed to "renameXX" due to a naming
conflict with the kernel.

An alternative would be to use something like "emX". Only the first boot
would be "random" which might prove complex when deploying on a large
cluster of identical nodes.

This has already been explained in this very same thread.
--
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)
Thomas Goirand
2015-06-30 21:46:06 UTC
Permalink
Post by Vincent Bernat
Post by Thomas Goirand
Post by Marco d'Itri
Post by Thomas Goirand
So your proposal is: if the default is unusable (like above), then the
poor user has to find a way to fix that... I'm not convince that this is
what we want. I'd very much prefer a usable default.
Me too, but there is none that we can use.
Sure there is: keep the good old ethX naming, which has always worked
for many, many years. Now, expecting someone will raise the fact that
sometimes, we get a different order of the ifaces. Well, there's many
ways around that, the persistent naming file is one solution (which I
don't like, as I think it shouldn't be written by default, it should be
the user's decision to write it if he wants to, but hey, let's not
discuss that...).
It has worked for many many years as long as the drivers were loaded
synchronously. This is not the case anymore. When you have two brands of
network card (for example bnx2 and e1000, quite common on HP servers),
at each boot, you can get something different. And while the persistent
naming file is a solution that worked almost all the time, there was
some time where an interface were renamed to "renameXX" due to a naming
conflict with the kernel.
An alternative would be to use something like "emX". Only the first boot
would be "random" which might prove complex when deploying on a large
cluster of identical nodes.
This has already been explained in this very same thread.
Thanks for explaining it again. I have to admit I didn't have time to
read the (huge) thread entirely.

Cheers,

Thomas
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@debian.org
Martin Wuertele
2015-07-02 14:17:32 UTC
Permalink
Post by Marco d'Itri
I propose to retire [mac], i. e. drop
/lib/udev/rules.d/75-persistent-net-generator.rules and enable
[ifnames] by default.
I see a large enough consensus about switching by default to ifnames,
and I believe that the few people who want MAC-based names for USB
interfaces can easily set NamePolicy=mac or write a custom rule.
I'm not sure we had consensus at that time, however after the discussion
has pretty much ended now it seems, at least to me, that your proposal
is the best way to go forward.
Post by Marco d'Itri
I am not sure that we really need to retire 75-persistent-net-generator
right now: the annoying part to maintain is the kernel patch which we
will need anyway for at least a couple of releases, and once we make it
use em* or eno* instead of eth* then it should be robust.
It is trivial to make it opt-in by setting something like net.ifnames=0
(or even a different and specific value), and we can revisit this
decision when we will be closer to the release.
So we can only let time and replacing/reinstalling machines take care
of this. /etc/udev/rules.d/70-persistent-net.rules requires zero
maintenance from us (it's just like the admin had manually set their
own rules).
Actually it requires us to keep maintaining the
Revert-udev-network-device-renaming patch as long as there will be
systems with a 70-persistent-net.rules file renaming eth* to eth*.
Does it make sense to stop shipping it on new installations rsn, provide
legacy support in stretch but disable it (and remove support) with the
following release? Or do you see the necessity to already do a hard-way
upgrade for stretch, disabling 70-persistent-net.rules but giving the
local admin a manual way to reenable it or a sample udev file to
reenable its functionality?

yours Martin
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@anguilla.debian.or.at
Jonathan Dowland
2015-05-11 08:26:32 UTC
Permalink
Just a quick observation: a lot of the problems people have experienced with
network interface naming is a combination of two things: both whatever
persistence scheme is in place (or not), but also the fact they *need to know a
network interface name at all*.

Many times I've wanted to express "launch DHCPd on the only network device you
see or are going to see" with something like ifupdown, the actual network
device name is irrelevant, but I'm forced to use it because ifupdown is
old-aged. (This in particularly with VMs that might be cloned or moved around
a lot).

I think it's important to consider the state of our networking tools and what
we want to see there going forward in concert with device naming considerations,
and not make decisions based on the false premise that the way we do things now
is how we want to do them Tomorrow.
--
Jonathan Dowland
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@chew.redmars.org
Josh Triplett
2015-05-13 20:23:47 UTC
Permalink
Post by Marvin Renich
Yes, I use ifupdown and wpasupplicant. Based on some of the threads on
this list there are many people who love Network Manager and many who
dislike it. I am one of the ones who dislike it. Given the fact that
it is (or at least was recently) clearly controversial, choosing a path
that relies on its use seems detrimental to me, regardless of whether it
is the default or not.
I'm not suggesting that we mandate the use of NetworkManager in
particular. I'm suggesting that it's fine to have a solution that
assumes the use of *some* modern network stack that doesn't inherently
care about interface names, at least by default. (That doesn't make it
impossible to match on interface names for the cases where that's
appropriate; for instance, networkd lets you match on interface name
*or* MAC *or* a variety of other properties.)

In general, any new approach to networking should not be constrained by
the limitations of ifupdown, which is effectively in eternal maintenance
mode, and unlikely to ever gain the features current network management
tools already have.

All that said, I don't strongly care *which* policy we use, as long as
we use a policy that's actually supported upstream, which the current
MAC-based persistent naming is not. Given that I'm in favor of
tools that don't care what you name the interfaces, I don't particularly
care what the interfaces end up named.

- Josh Triplett
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@jtriplet-mobl1
Martin Pitt
2015-06-03 10:01:34 UTC
Permalink
Hello all,

some 4 weeks ago I sent a first proposal to change persistent network
interface naming away from our current
/lib/udev/rules.d/75-persistent-net-generator.rules (which is
inherently racy and doesn't apply to all virtualized environments) to
udev's "net.ifnames":

https://lists.debian.org/debian-devel/2015/05/msg00170.html

Thanks to the comments and followups! Based on that I updated the
proposal. (Sorry for the delay..)
Details about [ifnames]
-----------------------
This is a generic solution which extends the [biosdevname] idea and
thus applies to all practical cases and all architectures. It doesn't
need any persistant state (i. e. dynamic /etc/udev/rules.d/) and thus
applies nicely to snappy/touch, and also avoids the race condition.
The main downside is that by nature the device names are not familiar
to current admins yet. For BIOS provided names you get e. g. ens0, for
PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a
necessary price to pay (biosdevname names look similar).
The main objection in the discussion was that path based names aren't
appropriate for USB based devices. I agree, so I change my proposal to
use MAC based names for anything USB based. The names will look even
worse as they include the MAC in hex (enx112233445566), but the two
goals "use MAC for these devices", "don't maintain state files in
/etc", and "avoid any collisions" don't leave room for much else.

However, on a desktop you don't ever care about the device names, and
higher-level firewall tools will also hide this. After all, we
survived the step from /dev/sda1 to UUID=112233DEADBEEF... as well :-)
Proposal
--------
I propose to retire [mac], i. e. drop
/lib/udev/rules.d/75-persistent-net-generator.rules and enable
[ifnames] by default.
Amendment:

... and ship a naming policy by default which uses MAC based names
for USB.

FYI, this will look like

| $ cat /lib/systemd/network/01-mac-for-usb.link
| [Match]
| Path=*-usb-*
|
| [Link]
| NamePolicy=kernel database mac onboard slot path
| MACAddressPolicy=persistent

It's easy enough to override/customize, see man systemd.link. (Despite
the name, this is all udev; it doesn't depend on using systemd or
networkd). This will of course also be included in the documentation.
For upgrades: As we don't know what refers to existing stable network
names, we can't ever safely remove a generated
/etc/udev/rules.d/70-persistent-net.rules. So when we do the above,
names on existing installations will *not* change (as
70-persistent-net.rules trumps [ifnames]).
So we can only let time and replacing/reinstalling machines take care
of this.
Michael Biebl and I discussed that the other day. We plan to do that
in steps:

stretch:
- Enable ifnames for new installations
- Drop [mac] generator
- Point out the transition/documentation in NEWS
- Ship example rules to show how to use your own custom names

stretch+1 (or maybe +2):
- Check existance/non-emptiness of
/etc/udev/rules.d/70-persistent-net.rules in udev.preinst,
Show critical debconf note, and refuse to upgrade
- Drop our hack to retry renames for a while (to mitigate the race)

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Martin Pitt
2015-06-03 10:42:46 UTC
Permalink
Post by Martin Pitt
| $ cat /lib/systemd/network/01-mac-for-usb.link
| [Match]
| Path=*-usb-*
|
| [Link]
| NamePolicy=kernel database mac onboard slot path
| MACAddressPolicy=persistent
Sorry, that was an old version. We want this:

NamePolicy=kernel database onboard mac

I. e. prefer onboard names over mac, and never use slot/path based
names for USB; the latter will hardly make a practical difference, but
it's cleaner that way.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Vincent Danjean
2015-06-03 10:43:50 UTC
Permalink
Post by Martin Pitt
- Check existance/non-emptiness of
/etc/udev/rules.d/70-persistent-net.rules in udev.preinst,
Show critical debconf note, and refuse to upgrade
No. It is always a real pain when a preinst script fails.
It is (nearly) ok when you upgrade only one package. But if you
upgrade lots of packages, when the preinst script will fail, other
packages will be in non-canonical state (unpacked but unconfigurated,
etc.) and recovering from such a state is always really problematic.
"apt-get install -f" can help but, I observed several times, the
resolution is not necessarily the same as the one tried before,
leading to new packages installed and, more problematic, other
packages to be removed even if not expected initially.

So, you can show a debconf note, try (or not) to migrate the file
automatically, remove (or comment-out) the 70-persistent-net.rules,
or ... but, please, do not write a preinst script that fails
because the admin did not update its config before upgrading.

One "good" solution would probably a new kind of scripts run
by dpkg and apt *prior to any other things* (for all involved
packages) to decide if the upgrade can run or not. But that
would involve lots of change in apt/dpkg and I'm sure I do not
oversee all the implications of such a proposal.

Regards,
Vincent
Post by Martin Pitt
- Drop our hack to retry renames for a while (to mitigate the race)
Martin
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@free.fr
Marco d'Itri
2015-06-03 10:59:30 UTC
Permalink
Post by Vincent Danjean
Post by Martin Pitt
- Check existance/non-emptiness of
/etc/udev/rules.d/70-persistent-net.rules in udev.preinst,
Show critical debconf note, and refuse to upgrade
No. It is always a real pain when a preinst script fails.
So, you can show a debconf note, try (or not) to migrate the file
automatically, remove (or comment-out) the 70-persistent-net.rules,
or ... but, please, do not write a preinst script that fails
because the admin did not update its config before upgrading.
None of these solutions is applicable: either the upgrade can continue
or the network interfaces names will change with unpredictable
consequences.
Post by Vincent Danjean
One "good" solution would probably a new kind of scripts run
by dpkg and apt *prior to any other things* (for all involved
packages) to decide if the upgrade can run or not. But that
This is more or less what apt does when apt-extracttemplates from
apt-utils is available.
--
ciao,
Marco
Michael Biebl
2015-06-03 11:11:19 UTC
Permalink
Post by Marco d'Itri
Post by Vincent Danjean
Post by Martin Pitt
- Check existance/non-emptiness of
/etc/udev/rules.d/70-persistent-net.rules in udev.preinst,
Show critical debconf note, and refuse to upgrade
No. It is always a real pain when a preinst script fails.
So, you can show a debconf note, try (or not) to migrate the file
automatically, remove (or comment-out) the 70-persistent-net.rules,
or ... but, please, do not write a preinst script that fails
because the admin did not update its config before upgrading.
None of these solutions is applicable: either the upgrade can continue
or the network interfaces names will change with unpredictable
consequences.
Does anyone remember how linux-base handled this when there was the
/dev/hd* to /dev/sd* transition. Did it bail out if it failed to do the
conversion?
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Ben Hutchings
2015-06-03 14:00:03 UTC
Permalink
Post by Michael Biebl
Post by Marco d'Itri
Post by Vincent Danjean
Post by Martin Pitt
- Check existance/non-emptiness of
/etc/udev/rules.d/70-persistent-net.rules in udev.preinst,
Show critical debconf note, and refuse to upgrade
No. It is always a real pain when a preinst script fails.
So, you can show a debconf note, try (or not) to migrate the file
automatically, remove (or comment-out) the 70-persistent-net.rules,
or ... but, please, do not write a preinst script that fails
because the admin did not update its config before upgrading.
None of these solutions is applicable: either the upgrade can continue
or the network interfaces names will change with unpredictable
consequences.
Does anyone remember how linux-base handled this when there was the
/dev/hd* to /dev/sd* transition. Did it bail out if it failed to do the
conversion?
It gave the option to retry conversion (assuming you manually fix
something before answering) or to continue without automatic conversion.
In that case the old kernel version would generally still be available
as a fallback, whereas this is of course not true with udev.

Ben.
--
Ben Hutchings
Editing code like this is akin to sticking plasters on the bleeding stump
of a severed limb. - me, 29 June 1999
Vincent Danjean
2015-06-03 18:50:49 UTC
Permalink
Post by Marco d'Itri
Post by Vincent Danjean
Post by Martin Pitt
- Check existance/non-emptiness of
/etc/udev/rules.d/70-persistent-net.rules in udev.preinst,
Show critical debconf note, and refuse to upgrade
No. It is always a real pain when a preinst script fails.
All is negotiable. It is a matter of what is less problematics.
Post by Marco d'Itri
Post by Vincent Danjean
So, you can show a debconf note, try (or not) to migrate the file
automatically, remove (or comment-out) the 70-persistent-net.rules,
or ... but, please, do not write a preinst script that fails
because the admin did not update its config before upgrading.
None of these solutions is applicable: either the upgrade can continue
or the network interfaces names will change with unpredictable
consequences.
I would *largely* prefer a debconf notice + question asked to
retry (admin can fix in-between) or continue (admin will have to
leave with consequence of interface rename) than having a
dist-upgrade aborted in the middle of its way.
I remember upgrades aborted due to dependencies between udev
and the running kernel. It was really a mess when I forgot to
upgrade the kernel at first (until, if I remember correctly,
the abort was modified to big debconf warnings).
Post by Marco d'Itri
Post by Vincent Danjean
One "good" solution would probably a new kind of scripts run
by dpkg and apt *prior to any other things* (for all involved
packages) to decide if the upgrade can run or not. But that
This is more or less what apt does when apt-extracttemplates from
apt-utils is available.
You would have to ensure that the apt hook is available *before*
dist-upgrade is run. To my knowledge, no dependency can ensure this.
So, this hook would have to be imposed in strech so that strech+1
can use it. Anyway, I will be very pleased if you find a way to
abort the upgrade before its begining (and not just before udev
upgrade)

Regards,
Vincent
--
Vincent Danjean GPG key ID 0xD17897FA ***@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@free.fr
Martin Pitt
2015-06-04 09:37:01 UTC
Permalink
Post by Vincent Danjean
So, you can show a debconf note, try (or not) to migrate the file
automatically, remove (or comment-out) the 70-persistent-net.rules,
or ... but, please, do not write a preinst script that fails
because the admin did not update its config before upgrading.
Fair enough. We can just point out that this is an unsupported
configuration in stretch+2. There is no way we can reliably migrate
the whole system.
Post by Vincent Danjean
One "good" solution would probably a new kind of scripts run
by dpkg and apt *prior to any other things* (for all involved
packages) to decide if the upgrade can run or not. But that
would involve lots of change in apt/dpkg and I'm sure I do not
oversee all the implications of such a proposal.
Indeed, and this should probably also happen at a higher level (like
Ubuntu's release-upgrader, which has extra pre/post hooks).

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@piware.de
Stephan Seitz
2015-06-03 15:11:08 UTC
Permalink
Post by Martin Pitt
However, on a desktop you don't ever care about the device names, and
Of course you do. How will you use tcpdump or tshark without the device
names? In most desktop setups a „tcpdump -i eth0” is the right command.
Post by Martin Pitt
higher-level firewall tools will also hide this. After all, we
survived the step from /dev/sda1 to UUID=112233DEADBEEF... as well :-)
Well, but /dev/sda1 is still available. And I prefer /dev/sdaX because
I have far less problems with it than with UUID=XXX.

Shade and sweet water!

Stephan
--
| Stephan Seitz E-Mail: ***@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
Tollef Fog Heen
2015-06-04 06:05:36 UTC
Permalink
]] Stephan Seitz
Post by Stephan Seitz
Post by Martin Pitt
However, on a desktop you don't ever care about the device names, and
Of course you do. How will you use tcpdump or tshark without the
device names? In most desktop setups a „tcpdump -i eth0” is the right
command.
`-i any` is quite often just as easy.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@xoog.err.no
Jeroen Dekkers
2015-06-04 07:36:37 UTC
Permalink
At Wed, 3 Jun 2015 17:11:08 +0200,
Post by Stephan Seitz
Post by Martin Pitt
However, on a desktop you don't ever care about the device names, and
Of course you do. How will you use tcpdump or tshark without the
device names? In most desktop setups a „tcpdump -i eth0” is the right
command.
I think people who know how to use tcpdump will also be able to type
in "ip addr" to look up the device name they want to dump.


Jeroen Dekkers
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/874mmnzzzu.wl-***@dekkers.ch
Josselin Mouette
2015-06-04 08:10:37 UTC
Permalink
Hi,

Martin Pitt <***@debian.org> wrote:
The main objection in the discussion was that path based names aren't
appropriate for USB based devices. I agree, so I change my proposal to
use MAC based names for anything USB based. The names will look even
worse as they include the MAC in hex (enx112233445566), but the two
goals "use MAC for these devices", "don't maintain state files in
/etc", and "avoid any collisions" don't leave room for much else.

How about using only the last 3 bytes of the MAC?

The probability of using, on the same system, *two or more* controllers
from *different brands* with a collision in the last 3 bytes is
nonexistent in practice.

The clear benefit would be that 3 bytes / 6 hex digits are easy enough
to remember in the short term memory when you need to type a command. 6
hex digits are also regularly used as short git references for that same
reason.
--
Joss
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@dsp0698014.postes.calibre.edf.fr
Michael Biebl
2015-06-04 17:41:12 UTC
Permalink
Post by Josselin Mouette
How about using only the last 3 bytes of the MAC?
The probability of using, on the same system, *two or more* controllers
from *different brands* with a collision in the last 3 bytes is
nonexistent in practice.
The clear benefit would be that 3 bytes / 6 hex digits are easy enough
to remember in the short term memory when you need to type a command. 6
hex digits are also regularly used as short git references for that same
reason.
That's an interesting idea.I don't think though we should change the
existing mac NamePolicy. After all, this naming policy could already be
in use. Maybe introduce a new type, say mac-short ?
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Milan P. Stanic
2015-06-05 08:57:41 UTC
Permalink
Post by Michael Biebl
Post by Josselin Mouette
How about using only the last 3 bytes of the MAC?
The probability of using, on the same system, *two or more* controllers
from *different brands* with a collision in the last 3 bytes is
nonexistent in practice.
The clear benefit would be that 3 bytes / 6 hex digits are easy enough
to remember in the short term memory when you need to type a command. 6
hex digits are also regularly used as short git references for that same
reason.
That's an interesting idea.I don't think though we should change the
existing mac NamePolicy. After all, this naming policy could already be
in use. Maybe introduce a new type, say mac-short ?
Maybe I have unusual configuration but look at this:

arya:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000
link/ether 14:da:e9:ab:a4:e9 brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 14:da:e9:ab:a4:e9 brd ff:ff:ff:ff:ff:ff
10: kvm0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN mode DEFAULT group default qlen 500
link/ether 4a:f9:f8:e1:5a:7a brd ff:ff:ff:ff:ff:ff

MAC address for lan and br0 are the same.
lan is physical Ethernet interface and br0 is bridge interface.

When I plug USB Ethernet adapter I have the next:

arya:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000
link/ether 14:da:e9:ab:a4:e9 brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 00:60:6e:00:48:1a brd ff:ff:ff:ff:ff:ff
10: kvm0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN mode DEFAULT group default qlen 500
link/ether 4a:f9:f8:e1:5a:7a brd ff:ff:ff:ff:ff:ff
16: usb: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000
link/ether 00:60:6e:00:48:1a brd ff:ff:ff:ff:ff:ff

Now, USB Ethernet interface (usb) and bridge (br0) have the same MAC.

I know that I made unusual config but anyway I think that the naming
interface by using MAC (or part of it) is not good idea.

Or I still live in the time when the interfaces have had real (i.e.
human readable and easy to remember) names.
--
Best regards
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@arvanta.net
Marco d'Itri
2015-06-05 14:25:17 UTC
Permalink
Post by Milan P. Stanic
Now, USB Ethernet interface (usb) and bridge (br0) have the same MAC.
This is not relevant, because virtual interfaces like br0 are not
subject to renaming.
--
ciao,
Marco
Steve McIntyre
2015-06-04 10:33:36 UTC
Permalink
Post by Josselin Mouette
How about using only the last 3 bytes of the MAC?
The probability of using, on the same system, *two or more* controllers
from *different brands* with a collision in the last 3 bytes is
nonexistent in practice.
The clear benefit would be that 3 bytes / 6 hex digits are easy enough
to remember in the short term memory when you need to type a command. 6
hex digits are also regularly used as short git references for that same
reason.
Good suggestion, yes. :-)
--
Steve McIntyre, Cambridge, UK. ***@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
whether they're being malicious or incompetent. Capital letters are forecast."
Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/E1Z0SSu-0007Ry-***@mail.einval.com
Benjamin Drung
2015-06-25 10:44:30 UTC
Permalink
Post by Martin Pitt
The main objection in the discussion was that path based names aren't
appropriate for USB based devices. I agree, so I change my proposal to
use MAC based names for anything USB based. The names will look even
worse as they include the MAC in hex (enx112233445566), but the two
goals "use MAC for these devices", "don't maintain state files in
/etc", and "avoid any collisions" don't leave room for much else.
However, on a desktop you don't ever care about the device names, and
higher-level firewall tools will also hide this. After all, we
survived the step from /dev/sda1 to UUID=112233DEADBEEF... as well :-)
How about adding a easy-to-type symlink for MAC named devices? Would
that work? Then users could refer to a device by the persistent MAC name
enx112233445566, but also could use a short name like eth2 (which might
not be persistent).

It would be similar to hard drives. I used UUIDs in /etc/fstab, but
short names like /dev/sdb3 when calling mount on the command line.
--
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: ***@profitbricks.com
URL: http://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
GeschÀftsfÌhrer: Andreas Gauger, Achim Weiss.
Martin Pitt
2015-06-25 10:49:55 UTC
Permalink
Hey Benjamin,
Post by Benjamin Drung
How about adding a easy-to-type symlink for MAC named devices? Would
that work? Then users could refer to a device by the persistent MAC name
enx112233445566, but also could use a short name like eth2 (which might
not be persistent).
It would be similar to hard drives. I used UUIDs in /etc/fstab, but
short names like /dev/sdb3 when calling mount on the command line.
Unlike /dev nodes, network interfaces can't have aliases as far as I
know. Am I missing anything?

Thanks,

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Marco d'Itri
2015-06-25 11:26:54 UTC
Permalink
Post by Martin Pitt
Unlike /dev nodes, network interfaces can't have aliases as far as I
know. Am I missing anything?
No. As is usual with udev, the people who do not understand how it works
are always ready to propose solutions.
--
ciao,
Marco
Marvin Renich
2015-06-25 12:16:12 UTC
Permalink
Post by Marco d'Itri
Post by Martin Pitt
Unlike /dev nodes, network interfaces can't have aliases as far as I
know. Am I missing anything?
No. As is usual with udev, the people who do not understand how it works
are always ready to propose solutions.
--
ciao,
Marco
I think what some people are missing in this discussion is the relative
importance of two design goals. In the original message, one of the
stated design goals was to eliminate the state file in /etc (or /var,
which might be a better place for it). The obfuscated interface names
are a direct result of attempting to achieve that goal.

The goal that wasn't on the list, but should have been, was to have
interface names that a human sysadmin could easily recognize,
distinguish, and type _on the command line_. This goal is at least an
order of magnitude (I think two orders of magnitude) more important than
eliminating the state file.

Think about it. Any program can deal with any name or naming
convention. It doesn't matter whether the name is obfuscated or not. A
human sysadmin, however, has a much easier time using eth2 than
enx3c52ca. Binary ids are for programs; short, easy-to-use names are
for humans.

If the priority of the goals is realigned to make sense, then we must
eliminate any solution that satisfies the no-state-file goal if it does
not also satisfy the human-usable goal. If this brings us back to where
we currently are, so be it. But please do not add significant cognitive
burden on the humans who must use the interface names just to get rid of
a state file. Eliminating the state file is not worth it.

(I'm not saying that a solution that satisfies both can't be found, and
if it is found, that's great. But the current proposal absolutely fails
the human-usable goal.)

...Marvin
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@basil.wdw
Marco d'Itri
2015-06-25 16:43:07 UTC
Permalink
Post by Marvin Renich
If the priority of the goals is realigned to make sense, then we must
eliminate any solution that satisfies the no-state-file goal if it does
not also satisfy the human-usable goal. If this brings us back to where
we currently are, so be it. But please do not add significant cognitive
burden on the humans who must use the interface names just to get rid of
a state file. Eliminating the state file is not worth it.
Please read the precedent thread which explained why we cannot continue
supporting the old mechanism.
If the new names trouble you then you can just manually configure new
ones.
--
ciao,
Marco
Philipp Kern
2015-06-25 22:14:37 UTC
Permalink
Post by Marvin Renich
Think about it. Any program can deal with any name or naming
convention. It doesn't matter whether the name is obfuscated or not. A
human sysadmin, however, has a much easier time using eth2 than
enx3c52ca. Binary ids are for programs; short, easy-to-use names are
for humans.
While I agree that including the complete hex ID of a network interface
isn't very user friendly, I also can't extract any value out of "eth2"
or "em1" if there is more than one interface and (especially) more than
one machine. So I usually resort to the MAC address in "ip link". In
which case not including part of the identifier makes for an additional
roundtrip. On the other hand I'm more of a fan of actually naming
interfaces by their purpose or external labeling. Makes for even less
mental gymnastics. \-:

Kind regards
Philipp Kern
Simon McVittie
2015-06-26 09:11:05 UTC
Permalink
Post by Philipp Kern
On the other hand I'm more of a fan of actually naming
interfaces by their purpose or external labeling. Makes for even less
You can still do this via manual configuration; as far as I understand
it, nobody is proposing to take away the ability to rename interfaces to
"lan" and "wan", or whatever, selected on the basis of path, MAC
address, driver or any other udev attribute, via udev rules analogous to
those written out by persistent-net-generator.

However, in the absence of manual configuration, *something* needs to
happen, one of:

* the kernel defaults (eth0, ... in arbitrary order)
* the current Debian-specific persistent-net-generator scheme
* one of the various ifnames schemes
* different ifnames schemes depending on device type
(as implemented in systemd >= 220-5, which uses MAC-based IDs
for USB and path-based for PCI)

and there are some additional considerations that might not be obvious
to some readers of this thread:

* the default setup cannot use /var because that might be remote
* the udev maintainers do not want the default to involve
writing to /etc
* each network device has exactly one name, and no aliases
(kernel limitation)
* renaming to ethN or wlanN, where N is a small integer, cannot
work reliably regardless (because it can race with the kernel
assigning the same ethN/wlanN name to different hardware; this
is why ifnames never assigns names in that form)

To some extent, all of this complexity is because network devices aren't
device nodes in /dev, so they can't have aliases (symlinks) but must
instead have precisely one name. udev has been able to introduce new
disk naming schemes without breaking old ones, precisely because
symlinks to disk device nodes work fine.

S
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@debian.org
Thorsten Glaser
2015-07-21 20:32:55 UTC
Permalink
Post by Simon McVittie
You can still do this via manual configuration; as far as I understand
Yes, but=E2=80=A6
Post by Simon McVittie
* the current Debian-specific persistent-net-generator scheme
pitti wants to drop this; however, this is where we usually
do the manual renaming when needed.

By all means, do your new thing, but don=E2=80=99t break things for
the people who wish to continue using persistent-net-generator
and for whom it works and who don=E2=80=99t have any problems with
the problems it has you outlined a few weeks ago.

(Heh. I sound like I=E2=80=99m repeating myself every year now=E2=80=A6)

tl;dr: Just keep persistent-net-generator, even discourage
people from using it who don=E2=80=99t know what they=E2=80=99re doing,
but don=E2=80=99t remove it.

Thanks,
//mirabilos
--=20
Post by Simon McVittie
emacs als auch vi zum Kotzen finde (joe rules) und pine f=C3=BCr den einz=
ig
Post by Simon McVittie
bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert).=
;)
Hallooooo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
=2E.. pine-User, und das auch noch gewohnheitsm=C3=A4=C3=9Fig ("Oooooooohhh=
"). [aus dasr]
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@herc.mirbsd.org
Jiri Jaburek
2015-06-25 19:00:14 UTC
Permalink
[ sorry for replying late, I wasn't subscribed, but I read both threads
and I hope I got the In-Reply-To / References right ]

As someone with decent experience deploying RHEL/Centos and Debian on
anything from ARM boards, through x86 desktops/servers (HP/IBM/Dell),
IBM POWER, to IBM System Z (s390), I thought I'd share some thoughts.

Please stop calling ifnames "predictable" or "persistent", they are
neither - the logic upon which the name changes is different, but
that's it - in my experience, they're far less "persistent" than
static udev rules.
Also, don't assume everyone has access to a mouse to easily copy-paste
the 12-character interface names, things like z/VM (x3270 term) don't
even have screen clear support and typing the interface manually for the
tenth time is very ... CAPTCHA-like.

It doesn't matter how many excuses you make or how many managers you
layer on top, interface names are a *frontend* and critical for any
slightly complex network firewall setup (xtables/nftables) - think of
a multihomed 30-VLAN-using VM host with 64 bridges, various containers,
openvswitch, ... in a HA setup. You can't rely just on IP addresses and
rp_filter, using interface names also vastly simplifies things, not
mentioning ebtables.


About the actual persistence or which approach is the best - the thing
is that every setup is different. While the idea of biosdevname is nice
and it mostly works, there are cases where it doesn't, so it's
an invalid choice by design.

Amongst others:

* regular desktops are fine with PCI, BIOS or MAC addr
* x86/ppc servers you service - MAC addr (more stable on reboots or
network-unrelated hw changes)
* servers you don't - PCI or MAC addr (depending on the person
servicing it)
* USB NICs - MAC addr
* QEMU VMs - MAC addr (libvirt/cmdline assigns a static one)
or PCI (specified on cmdline or in libvirt XML)
* "containers" (Linux namespaces) - none (veth generates random MACs)
or MAC addr (depending on management software)
* simple ARM boards - MAC addr or none
* z/VM - qeth ccwgroup magic (ifnames: enccw0.0.4100)
* ...

It kind of becomes clear that any consensus on PCI bus/slot/function/dev
or MAC addr based numbering cannot be universally reached.

The "none" above means "don't mess with it" - leave the kernel specified
device name. This may sound crazy, but is actually the most universal
and in a lot of cases the most user-friendly thing to do, especially
on systems that change HW every time (live distros - "dhclient eth0"
is so much easier than ifnames) and/or systems that have just one NIC
(simple ARM boards, most VMs, most "containers", a lot of mass-deployed
virtual cluster nodes, ...).
In fact, I found that removing the generator when provisioning hundreds
of identical single-NIC virtual systems simplified things a lot - the
virtual hardware could be diverse & changed over time and "eth0" was
always "eth0" (no biosdevname-enforcing drivers, fortunately).

Which kind of leaves us where we are now (in Debian) - the best
persistence is achieved though udev rules, where you can even use
multiple rules per one interface name to express OR relationships,
with the generator creating a stable enough template until the sysadmin
changes the iface names.


None of the above is made impossible with ifnames, which are simply
a new default for device names, but my issue is that *they aren't any
better than the old system* in terms of persistence, they are actually
worse in my experience. If you want static /etc, sure, use
/var/lib/udev for the generated rules. If you find $setup with variable
MAC addresses, but some persistent property, you can at least use it in
the generator, whereas with ifnames, you don't (AFAIK) have much choice.

The usability issue is not in using some generator (and fixing the
race), but in the default names being *easy to use* for the user and
the rename an optional operation whereas with
enpff5d605a-c543-43fd-9777-0989f3879a2e it's pretty much mandatory.
Disk (filesystem) UUIDs worked, because people could still use
/dev/sda for fdisk.

Not denying that ifnames can be useful in some scenarios (I can imagine
a few), but should they be opt-out rather than opt-in?
If you decide to use ifnames as default, please at least make renaming
interfaces easier, like providing commented-out examples in the .rules
file (in /etc or /usr/share/doc).


Just my .. err, $2.
Thanks for reading.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@redhat.com
Continue reading on narkive:
Loading...