[ 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558c4fbe.3060...@redhat.com