On 2017-08-24 at 11:48, Darac Marjal wrote: > On Thu, Aug 24, 2017 at 08:30:33AM -0500, Dave Sherohman wrote: > >> On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote: >>> To the best of my awareness, the rationale for calling this >>> "predictable network interface names" is that, on a single >>> computer which has multiple network interfaces of a given type, >>> this naming scheme makes it possible to predict *from one boot to >>> the next* what the name of each one will be. On such a computer, >>> this is extremely valuable. >>> >>> By contrast, on a computer which has at most one interface of a >>> given type, this naming scheme provides - so far as I can tell - >>> no advantage at all. >>> >>> What's more, when working on *multiple* computers of that latter >>> type, this naming scheme makes it impossible to predict *from one >>> computer to the next* what the name of the sole available >>> interface will be. >>> >>> As such, IMO this naming scheme makes network-interface names >>> significantly *less* predictable in the real-world scenario which >>> is most commonly encountered. >> >> This closely parallels the move from using /dev/sdXn to UUIDs for >> referring to filesystems. Probably superior in theory and doesn't >> cause any issues as long as you're dealing with a single machine >> and unchanging hardware configuration... but then you have a drive >> failure, restore your backups onto new hardware, and you're hosed >> because the system wants to boot from a UUID that no longer exists. >> (Yes, you can recover from that situation - I know because I've had >> to do it - but it doesn't Just Work(TM) effortlessly.) > > I think you're right here and, in both cases, if you're not using > more manageable names, then you're not using the system to its > fullest. > > You wouldn't refer to a host by it's IP address, or it's MAC address > or it's Serial Number, you'd give it a name. So why not name your > drives (and then use the by-label or LABEL= system) and why not name > your interfaces (core-network0, core-network1, backup-lan, > monitoring-lan - they don't HAVE to have numbers) While that's not a bad idea... how does it help the case of "network names are not predictable from one computer to the next"? At my workplace, we have over 4,000 computers, which run Windows most of the time but are occasionally booted to a bare-bones live-CD type of Linux environment (and not a particularly customizable one) for diagnostic and/or maintenance work. We've had enough trouble with the fact that some of them come up with the interface name /dev/em1 (which I think is supplied directly by the kernel) rather than /dev/eth0; having the full multiplicity of names available under the "predictable network interface names" scheme to sort through, rather than at least being limited to only two, would be enough more of a pain that I don't want to consider it. -- 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