Wednesday 17 June 2015

enable stateless persistant network interface names -- landed in wily

Hello all,

With udev 220-6ubuntu2 that just landed in wily this is implemented.
As discussed, this won't affect upgrades, just fresh installations.

This will likely uncover some places that hardcodes "eth0" and the
like which haven't been triggered by biosdevname yet.

I also unseeded biosdevname from platform.wily's installer seed.

Thanks,

Martin

----- Forwarded message from Martin Pitt <martin.pitt@ubuntu.com> -----

Date: Wed, 3 Jun 2015 12:15:59 +0200
From: Martin Pitt <martin.pitt@ubuntu.com>
To: ubuntu-devel@lists.ubuntu.com
Subject: Proposal v2: enable stateless persistant network interface names
Mail-Followup-To: ubuntu-devel@lists.ubuntu.com

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.ubuntu.com/archives/ubuntu-devel/2015-May/038761.html
https://lists.debian.org/debian-devel/2015/05/msg00170.html

Based on the comments and followups (mostly on the Debian ML) I
updated the proposal.

Martin Pitt [2015-05-08 7:59 +0200]:
> 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:

15.10 (Ubuntu) / stretch (Debian)
- 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

Ubuntu 16.10 (after next LTS) / stretch+1 (or maybe +2) (Debian)
- 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-05-08 7:27 +0200]:



----- End forwarded message -----

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)