On 05/11/2015 05:53 AM, Marco d'Itri wrote: > On May 08, Martin Pitt <mp...@debian.org> wrote: > >> I propose to retire [mac], i. e. drop >> /lib/udev/rules.d/75-persistent-net-generator.rules and enable >> [ifnames] by default. > I see a large enough consensus about switching by default to ifnames,
FWIW: I don't. In this very thread, I have read many counter-arguments. > and I believe that the few people who want MAC-based names for USB > interfaces can easily set NamePolicy=mac or write a custom rule. As always (and as it was for systemd), what counts here is the default. >> 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). > Actually it requires us to keep maintaining the > Revert-udev-network-device-renaming patch as long as there will be > systems with a 70-persistent-net.rules file renaming eth* to eth*. The other solution would be to upstream that patch (maybe as a kernel option if that is relevant). > I believe that firmware-based device names work well enough in practice > since RHEL 7 uses them by default: I tend to trust a market-based > approach to maintenability more than anecdote from a very selected > population like the debian-devel@ subscribers. Oh, how nice is that... So our opinions don't count, and Red Hat is just always right! FYI, I had non-anecdotal very bad experience to report, with the ifnames from udev causing not-so-easy to fix issues deploying OpenStack on a variety of hardware. I'm talking about large deployments here (in my mind, large means more than 200 machines...). > This is the relevant documentation, which I strongly recommend everybody > interested in this issue to read: > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Device_Renaming_Procedure.html > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Predictable_Network_Interface_Device_Names.html > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html All from redhat. /me not surprised... > Maybe biosdevname would be nice to have, but: > - somebody needs to actually maintain it in Debian > - by default it only works on Dell systems > - it is not loved by the udev/systemd upstream maintainers > - it does not seem to me to provide any benefit over the firmware-based > names since in practice both would use by default an interface index > in the common case > > So I do not think that we need to care about it. > > An obvious downside is longer names for devices which do not provide > ID_NET_NAME_ONBOARD: e.g. the WiFi card in my Dell laptop does > not (wlp2s0), but the Ethernet port does (eno1). > It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on > my Allwinner-based ARM computer), which means that interfaces will get > a mac-based name like enx028909xxxxxx. Which is so convenient to type on the shell, right? :) > But if somebody cares about the aesthetic value of network interface > names then they can probably write a custom udev rule to rename them, > or keep using 75-persistent-net-generator if we can keep it around. So your proposal is: if the default is unusable (like above), then the poor user has to find a way to fix that... I'm not convince that this is what we want. I'd very much prefer a usable default. Cheers, Thomas Goirand (zigo) -- 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/558d1507.1010...@debian.org
