Wednesday, 6 April 2016

Re: Call for opinions: default naming policy for USB network interfaces: MAC/path/kernel?

On Wed, Apr 6, 2016 at 6:56 PM, Martin Pitt <[email protected]> wrote:
> Hello all,
>
> last summer we discussed changing the way network interface names are
> named [1]. For the most part I think this worked out well, but I've
> heard some complaints here and there about USB devices, we had some
> ad-hoc discussions, but they weren't concluded. So let's review this
> before we release this in an LTS. I'm particularly interested in
> getting some opinions from the desktop and snappy folks, hence the
> cross-posting (this doesn't practically affect the server and cloud
> worlds). But please let's keep the discussion on [email protected]
>
> Internal (PCI etc.) ethernet and wifi devices now have either
> BIOS-assigned names based on indexes (eno1) or slots (ens2) or PCI
> path based names like "enp0s1" or "wlp0s1", i. e. they are named by
> location, and roughly match the intution of "first/second" or
> "left/right" card (which works for both physical and virtual
> interfaces, which wasn't the case for the previous MAC-based system
> and thus we didn't do any persistent naming for virtual environments).
>
> However, as there were some complaints [2][3] about location-based
> names not being appropriate for USB devices, we currently use the MAC
> address for those. I. e. they are named like "enx123456AABBCC".
>
> After having seen this in practice for a while, I wonder whether that
> was actually the right decision. There's the stylistic issue of these
> names being very long, but if you configure ifupdown or your firewall
> etc. with those, you only need to copy&paste it exactly once. The more
> important question is whether treating them as "device identity" as
> oppposed to "where do I connect it" is actually the right default.
>
> These are the options with pros (+) and cons (-):
>
> * MAC based (status quo): Emphasize the identity of the device that
> you connect
> + Works well on PCs/laptops where you want to connect your phone or
> USB 3G stick on an arbitrary USB slot.
>
> - With boards like the RasPi you usually think in terms of
> location: The left port is for the external USB ethernet card,
> the right port for something else.
>
> - You can't just take a pre-configured image and install it on a
> bunch of RasPis, as the configuration depends on the particular
> USB ethernet dongle that you plug in, so the names will be
> different on every deployed device, you can't keep a r/o
> image, and you need to adjust the configuration everywhere.
>
> * Location based (upstream default): Emphasize the location of the
> device that you connect; this has opposite pros and cons:
> + Works well on embedded boards where you more likely think in
> terms of location and USB port numbers than "did I use this or
> that USB ethernet adapter"
>
> + Is much more suitable for pre-configuring an image and deploying
> it to lots of devices.
>
> - Breaks on laptops/desktops with lots of USB ports when you tend
> to plug in your phone/USB dongle in different ports every time.
> Although there it probably doesn't matter as NetworkManager
> does not care about device names and connections are set up
> dynamically -- it's relatively unlikely that you use ifupdown or
> custom name-based firewall rules for hotpluggable USB network
> interfaces.
>

Would like to vote for this option since NM does identify the device
based on MAC (considering mostly for desktop use cases, which covers
most day-to-day usages/troubles). For human beings remembering a MAC
address is much harder than plugging in the device into certain USB
port(s) she/he is familiar with.

> * Keep the kernel name (like eth0) for USB devices
> - Does not provide any stable names if you have multiple USB
> devices at the same time (however, this doesn't appear to be a
> common case)
>
> * I. e. this requires you to manually configure names IF you need
> to refer to the names in config files (ifupdown, firewall) AND
> you need multiple USB network devices simultaneously.
>
> + If you only ever use at most one USB device (the common case),
> the name "eth0" is reasonably predictable, and pre-configured
> systems (like Raspis) with hardcoded "eth0" have a reasonably
> high chance of working out of the box.
>
> - There are no firm guarantees about the kernel actually naming the
> device "eth0" in all cases.
>
> None of those are optimal of course (this is an absurdly difficult and
> bikeshed-prone topic, thanks to Linux's "unique" way of treating
> network interfaces completely differently than all other devices), so
> I'm not sure how to do the decision in a qualified way. But let's
> please collect some opinions and see if there's some clear favorite.
>
> My gut feeling is to switch to location-based or kernel names by
> default. It shouldn't matter much on desktops as one usually uses
> dynamic configuration there (NetworkManager), and it will be a better
> default for small/embedded/snappy devices. If we don't want to change
> the default at this point, the alternative is that pre-configured
> images for Raspi and the like can ship a custom *.link file which
> changes the policy to kernel/path for USB devices.
>
> Thank you in advance,
>
> Martin
>
>
> P.S. Upgrade note: If we change the default schema, then this will of
> course only apply to new installs of Xenial, as we can't know whether
> the user already set up anything that relies on the current names. So
> systems upgraded from wily or current xenial will retain the MAC based
> names, unless you manually remove the .link file in /etc (I'll explain
> this in NEWS).
>
> [1] https://lists.ubuntu.com/archives/ubuntu-devel/2015-June/038786.html
> [2] https://lists.debian.org/debian-devel/2015/05/msg00184.html
> [3] https://lists.debian.org/debian-devel/2015/05/msg00218.html
>
> --
> Martin Pitt | http://www.piware.de
> Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
>


Regards,
Aron

--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel