On 05/10/2015 at 10:24 AM, Vincent Bernat wrote: > ❦ 10 mai 2015 08:20 -0400, The Wanderer <wanderer@fastmail.fm> : > >>>> Were you actually using ifupdown to manage the varied set of >>>> wireless networks? Because if not, then the name shouldn't >>>> matter. >>> >>> Yes, I’m using ifupdown. Besides USB NICs don’t have to be WiFi. >> >> Lots of people are, and it's inappropriate and IMO a bad idea to >> just assume that you can safely break what was once and may very >> well still be the single most widely-used method of controlling >> network interfaces under *nix. > > Do you speak about ifupdown? It's Debian only. eth* interfaces is > not *nix at all since all BSD are using per-driver naming > convention. Upon consideration, I suspect that I've been making - at least - the following three assumptions: * That ifupdown is essentially (in functionality if not in implementation) a set of wrappers around ifconfig, with a few additional scripts. * That ifconfig uses /etc/network/interfaces just as ifupdown does, and so would have the same interface-naming limitations. (I think this one was based in part on observation of real-world behavior.) * That ifconfig has been the standard way of working with network interfaces for more-or-less as long as there _has_ been a standard userspace way of doing that. If any (or all!) of those assumptions are false, then some of my conclusions may not hold. >> It has been safe to assume that wired interfaces will be named >> ethX, and wireless ones wlanX, for so long that that assumption is >> built into many existing procedures - both as implemented in code, >> and as implemented in human habits and practices. If that >> assumption is to be broken, IMO at minimum a multi-year explicit >> deprecation period (such as that used for Linux-kernel feature >> removal) would be appropriate. > > On Linux, wireless drivers have long used eth* names, except for > some out-of-tree drivers. It was the introduction fo the MAC 802.11 > soft layer (2.6.22+) that gradually switched drivers to use wlan* > names. And this change was driver by driver, at each release without > much publicity. Drivers not using the new framework to register > themselves are still using eth* names (like the Prism54 "full mac" > driver). I wasn't aware of the specifics of the shift; acknowledged. That would simply strengthen the argument for its having been safe to assume the ethX naming, though, at least as much as it weakens the argument for its having been safe to assume the wlanX naming. >>> You may switch the the naming scheme in virtual environments, >>> but only here. >>> >>> SLES is using some strange interface names like em1 or p1p2, but >>> I hate it. I prefer my eth0 name. >> >> I'll note that I've also seem some proprietary (but >> mission-critical) software which hardcodes interface names in some >> places; for example, older versions of Novell ZENworks' >> system-imaging utility would crash when attempting to multicast on >> a machine with an interface named em1 and no interface named eth0, >> reporting an inability to get the MAC address. > > This thread is about changing the default naming convention for > network interfaces. If you love to run an unmaintained version of > Novell ZENworks, you can still have an eth0 interface if you want. Where do you get "unmaintained" from? And my point was not about that one specific program; I was just using it as an example to indicate that there do exist important programs, which may not always be within the power of the people using them to modify, which are not compatible with other naming conventions. As far as "default" - I'll just say that I wouldn't be pleased to have a script break under me because of a change from 'eth0' to 'ens0' or 'enp1s1' on a system which only _has_ one network device. On desktop systems, at least, such systems are by far the most common case - and while network-device references in scripts not shipped by packages may not be terribly common on such systems, I still don't think it's a good idea to break the ones which do exist. > Actually, when rebooting your (mission-critical) server, you can have > a race condition where "eth1" is not the interface that was "eth1" on > the previous boot and "rename5" is the interface that should be > "eth1". That's what needs to be fixed. Doing nothing won't fix that. I did not advocate doing nothing. I agree that having names change under one's feet is a bad thing. I simply think that a solution to this problem which breaks the interface-naming assumptions which have been in place for so long is quite likely to be, at least in some ways, a cure worse than the disease. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature