| |||||||||||||
Domsch: Consistent Network Device Naming coming to Fedora 15Domsch: Consistent Network Device Naming coming to Fedora 15Posted Jan 26, 2011 20:20 UTC (Wed) by foom (subscriber, #14868)In reply to: Domsch: Consistent Network Device Naming coming to Fedora 15 by sturmflut Parent article: Domsch: Consistent Network Device Naming coming to Fedora 15
> I'd rather have my device names bound to MAC addresses than bus IDs
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.
(Log in to post comments)
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 26, 2011 21:37 UTC (Wed) by ballombe (subscriber, #9523) [Link]
It is rather trivial to change the MAC adress in 70-persistent-net-rules.net so that your new interface get the number you want.
On the other hand, hard-coding the bus ID in the interface name require you to update all references to the interface name if the bus ID ever change.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 26, 2011 21:55 UTC (Wed) by tetromino (subscriber, #33846) [Link]
Sure, that works if you are talking about one machine. Now imagine that you have 100 identical servers, each with 4 network ports. Think of the administrative overhead (every single one of those 100 machines will require a different 70-persistent-net-rules.net) and the chance of making silly mistakes.
With Fedora's approach, you will only need to write one config per hardware platform, which is vastly more manageable for large organizations.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 26, 2011 23:28 UTC (Wed) by rahvin (subscriber, #16953) [Link]
Isn't this a prime example of it's hard to be everything for everybody? This is a single use case dictating a naming style that's different than the entire history of Linux and every other deployed distribution. I won't argue that it probably improves things for this single use case of a rack of systems with all the same hardware, but what's the expense to everyone else? Are we making management for everyone else more complicated and confusing to help a single use case? (might be a LOT of people/servers configured like this)
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.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 26, 2011 23:59 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
If you are using the udev rules files and want to stick to it, you can even in Fedora. This only affects some server class hardware and that too it is completely optional. Also, Fedora is adopting it first but there is consensus between distributions and other distributions would be following on this in their upcoming releases.
Painting the bike shed Posted Jan 27, 2011 0:58 UTC (Thu) by cesarb (subscriber, #6266) [Link]
Sorry for picking your comment to reply to, but the level of drama for such a minor change is getting ridiculous.
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?).
Painting the bike shed Posted Jan 27, 2011 1:23 UTC (Thu) by tzafrir (subscriber, #11501) [Link]
Actually, an interface name with '#' in it? That's a nice stressing for various scripts around. Not everybody uses NetworkManager.
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.
Painting the bike shed Posted Jan 27, 2011 7:21 UTC (Thu) by joib (guest, #8541) [Link] And consider the nice things that happen when you copy over your config to a new system that has the network adapter plugged elsewhere.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.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 28, 2011 22:30 UTC (Fri) by Tet (subscriber, #5433) [Link] It's always bothered me that from my point of view the direction and development of Linux is driven by the server use case.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.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 11:22 UTC (Thu) by djzort (guest, #57189) [Link]
"Sure, that works if you are talking about one machine. Now imagine that you have 100 identical servers, each with 4 network ports. Think of the administrative overhead (every single one of those 100 machines will require a different 70-persistent-net-rules.net) and the chance of making silly mistakes.
With Fedora's approach, you will only need to write one config per hardware platform, which is vastly more manageable for large organizations."
Youve heard of scripts right? Tools like puppet or cfengine? Why are you managing 100 hand and custom built servers?
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 17:39 UTC (Thu) by jeremiah (subscriber, #1221) [Link]
My understanding of this issue, is that exists BEFORE you have the chance to get puppet or cfengine up and running. If you're doing a new image of 100 machines, your image doesn't necessarily have access to the cfengine or puppet server. Esp if the ethX might have different names. After things are up and running and you know which net dev to connect through then you can apply cfengine or whatnot to the problem, and get the 'details' of the system setup. In a lot of ways this problem probably has more to do with initrd, BusyBox, and nash more than anything else. As someone who has to do this, building complex initrd scripts is a pain in the butt, esp when it's figuring out which fracking net dev is the right one to connect through. It's not the script that's hard, it's the image->cpio->take a guess at fix->cpio->image->boot->rinse repeat that's a pain. And the less guess work taken out of that the better.
</rant></ramble>
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 26, 2011 23:20 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
I agree, that's why I have this disabled on all my debian systems.
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.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 28, 2011 12:37 UTC (Fri) by nix (subscriber, #2304) [Link]
What problem has tying to a MAC address given you? It should only cause problems if you change MACs all the time, and who does that?
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 30, 2011 15:47 UTC (Sun) by rwmj (subscriber, #5474) [Link]
Welcome to the world of virtualization :-)
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.
Rich.
|
|||||||||||||