Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
Domsch: Consistent Network Device Naming coming to Fedora 15
Posted Jan 26, 2011 20:07 UTC (Wed) by Pc5Y9sbv (guest, #41328)
Udev doesn't help if you you're trying to classify and use specific ethernet ports during anaconda kickstarts on brand-new hardware, for example. You may need to know which ethernet port(s) are on a management LAN, the production LAN, and the iSCSI SAN just to get the headless nodes to boot far enough to be provisioned and managed by someone.
Posted Jan 26, 2011 20:20 UTC (Wed) by foom (subscriber, #14868)
I sure don't -- I hate that method of device naming. I've had numerous situations where *everything breaks* when I replace a motherboard or a PCI ethernet card with the exact same model, because of Debian's MAC addr ethernet-port naming. And even in a simple autoconfig situations where the port name doesn't matter a whit, after I've gone through a few pieces of hardware, my ethernet port is now named "eth5" instead of "eth0", which is, though not broken, confusing.
Posted Jan 26, 2011 21:37 UTC (Wed) by ballombe (subscriber, #9523)
Posted Jan 26, 2011 21:55 UTC (Wed) by tetromino (subscriber, #33846)
Posted Jan 26, 2011 23:28 UTC (Wed) by rahvin (subscriber, #16953)
It's always bothered me that from my point of view the direction and development of Linux is driven by the server use case. Understandably that's where the money is that's paying to develop Linux but I think in the long run this single minded focus on servers at the expense of everything else damages the ecosystem.
Posted Jan 26, 2011 23:59 UTC (Wed) by rahulsundaram (subscriber, #21946)
Painting the bike shed
Posted Jan 27, 2011 0:58 UTC (Thu) by cesarb (subscriber, #6266)
Most people will not even notice, beyond the change of a label on NetworkManager's notification area menu. For most of those who notice, it will be nothing more than a change in a name they have to type. And in a few years, everyone will have gotten used to the new scheme, ethn being used only for old machines and wired USB connections. It is not like this is the first time there is a change to something everybody was used to on a Linux system.
On the other hand, for those who are the target group for this feature, it is a big change, for the better. These are the ones with things like 4 onboard Ethernet ports, which have to be correctly connected to completely separated networks (one management network, one storage network, one internal network, one external network...). Having the number in the interface name match the number printed on the outside of the chassis can make things a lot easier, even when configuring a single server (ok, I have eth0... which of the 4 physical ports it is, without having to test each one? And months later, when troubleshooting this server, can I at a glance tell which network eth3 is supposed to be connected to?).
Posted Jan 27, 2011 1:23 UTC (Thu) by tzafrir (subscriber, #11501)
And consider the nice things that happen when you copy over your config to a new system that has the network adapter plugged elsewhere.
So yes, this does break some existing use cases. It better be worth it.
Posted Jan 27, 2011 7:21 UTC (Thu) by joib (guest, #8541)
How is that any worse than the current default which depends on MAC addressed stored on the disk? The new system won't have the same MAC addresses, and hence you get some random ethX numbers which don't reflect the config.
Posted Jan 28, 2011 22:30 UTC (Fri) by Tet (subscriber, #5433)
You're kidding, right? For me, by far the biggest problem with modern Linux is that the direction is nearly all driven by the desktop use case.
Posted Jan 27, 2011 11:22 UTC (Thu) by djzort (guest, #57189)
Youve heard of scripts right? Tools like puppet or cfengine? Why are you managing 100 hand and custom built servers?
Posted Jan 27, 2011 17:39 UTC (Thu) by jeremiah (subscriber, #1221)
Posted Jan 26, 2011 23:20 UTC (Wed) by dlang (✭ supporter ✭, #313)
just using the ports in detection order has proven to be _ar_ more reliable over time. the only thing I have to do is when I deploy a new kernel, I have to test it on a lab box first to make sure it didn't reorder anything (and guess what, I have to do that anyway to make sure that there aren't other problems with the kernel). I've been through a few cases where the order has changed, and it hasn't been nearly the problem that I've had with the 'tie to a MAC address' approach.
Posted Jan 28, 2011 12:37 UTC (Fri) by nix (subscriber, #2304)
Posted Jan 30, 2011 15:47 UTC (Sun) by rwmj (subscriber, #5474)
70-persistent-net.rules is a constant source of trouble when V2V-ing, migrating and cloning virtual machines.
In any case, the change mentioned in this article has nothing to do with udev's persistent naming, and all to do with how the network interfaces are named when you first install an OS. It's a reasonably sensible change, although given that this driven from the BIOS, there is plenty of room for BIOS vendors to fsck things up as they normally do.
Posted Jan 27, 2011 12:15 UTC (Thu) by nim-nim (subscriber, #34454)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds