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