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
On 8 May 2015 at 01:59, Martin Pitt <mp...@debian.org> wrote:
> 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).
>
> Over the years several solutions have appeared:
>
> - [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
> age:
>
> * 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
> each new cloud or virtualization provider. Recent examples:
> 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
>
> If you see this via debian-devel@, please keep CC'ing pkg-systemd@,
> I'm not subscribed to d-devel@.
>
> Thanks,
>
> Martin
>
> --
> Martin Pitt | http://www.piware.de
> Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
>
_______________________________________________
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
