On 05/10/2015 at 07:36 AM, Stephan Seitz wrote: > On Sat, May 09, 2015 at 02:36:30PM -0700, Josh Triplett wrote: > >> Why? What does a stable name matter in the case you mentioned? > > Because I don’t want to look up the interface name of the day when I > use wireshark/tshark? Because I don’t want to change my iptables > scripts which is working very well the way it is? > >> 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. 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. > 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. That's been fixed in more recent versions, but I don't know whether it was fixed by adding em* to the list of names to check or by adding logic to enumerate all available interfaces without making assumptions about their names - though the former seems more likely. Now, ZENworks by default uses a custom LiveCD/initrd environment, and is not based on Debian - but it's entirely possible to either build custom versions of that environment (I've done it) or pull out the imaging utility and run it in a different environment, and in any case there's no way to be sure this is the only such example of important software with this sort of problem. (I can't check right now, but I actually suspect that at least one of the custom wireless-network-connection-management scripts I've written for that environment also relies on being able to assume the name wlan0... and trying to implement properly robust parse-sysfs logic to identify all available network adapters and distinguish wireless ones from wired ones would be considerably more than I'd want to do in bash.) -- 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