I manage a lab with more than a hundred machines, all doing the same things. Presently they are running Fedora 13 and are obviously sorely overdue for an upgrade. But doing an upgrade is likely to present several issues, one of which I'd like to discuss today.
The machines come from several manufactures and were purchased over a span of years. Their hardware differs substantially but all have two Ethernet interfaces. With F13, these are /always/ called eth0 and eth1. When one is implemented by an add-in card and the other is on the motherboard, the motherboard interface is /always/ eth0.
My experience with newer Fedora releases, on other machines, is that this naming reliability has gone away. The names assigned, by default, depend on the hardware configuration of the machine. Some may call the motherboard port em1, others may call it p1p4, and even more names are possible. The add-in port has similarly inconsistent names.
Note, I don't mean the names are inconsistent on the same machine. I understand the purpose of the systemd/udev naming rules and how they work, but they get in my way.
So I know that I can try to return to the old naming system using one or more techniques (http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/). And I've tried them all. But I find that, sometimes the motherboard port gets called eth0 and the add-in port is eth1, and sometimes those names get reversed. This is /not/ the old behavior even though it uses the old names.
I want to run the same software on all of these machines and having inconsistent names /between/ the machines makes that next to impossible. Using the new names means that my software has to learn all those different names and can't easily determine which name applies to the motherboard port. Using the old names means it can't predict which name will be given to which port.
There's got to be a better answer.
On May 13, 2014, at 5:33 PM, CLOSE Dave Dave.Close@us.thalesgroup.com wrote:
I want to run the same software on all of these machines and having inconsistent names /between/ the machines makes that next to impossible. Using the new names means that my software has to learn all those different names and can't easily determine which name applies to the motherboard port. Using the old names means it can't predict which name will be given to which port.
There's got to be a better answer.
... don't use Fedora?
Just kidding. Sort of.
Assuming since you're posting here that that's not an option :) You could learn to love the default udev nomenclature, or you could add rules to /etc/udev.d/rules (or whatever the equivalent is) that tie MAC addresses to specific interface names. It would require a little bit of script-fu, but assuming a competently managed key or password infrastructure, shouldn't take more than an hour or two.
Prepare for a whole lot more issues, though. Upgrading from 13 is a significant upgrade, and there's lots that will go wrong. Particularly on mongrel hardware like yours.
--Russell
On 05/13/2014 05:39 PM, Russell Miller wrote:
I want to run the same software on all of these machines and having inconsistent names /between/ the machines makes that next to impossible. Using the new names means that my software has to learn all those different names and can't easily determine which name applies to the motherboard port. Using the old names means it can't predict which name will be given to which port.
There's got to be a better answer.
... don't use Fedora?
Just kidding. Sort of.
Well, that option will certainly be considered. But it appears that nearly all of the common distributions are going to systemd/udev. Not only would I probably still have the same problem, I'd also have to learn a whole bunch of different things.
Assuming since you're posting here that that's not an option :) You could learn to love the default udev nomenclature, or you could add rules to /etc/udev.d/rules (or whatever the equivalent is) that tie MAC addresses to specific interface names. It would require a little bit of script-fu, but assuming a competently managed key or password infrastructure, shouldn't take more than an hour or two.
I've done that. The problem seems to be that what I want to do is to /exchange/ the names assigned. One of the renames works but the other fails, claiming the new name is already in use. In other circumstances, I'd use an intermediate name, orig->temp->target, but I don't know how to do that with udev, or even if it is possible.
Prepare for a whole lot more issues, though. Upgrading from 13 is a significant upgrade, and there's lots that will go wrong. Particularly on mongrel hardware like yours.
I know. It will be a "challenge".
You could learn to love the default udev nomenclature
Of course the major problem with the new "consistent" names is they keep changing the software and making the names consistently different :-).
The original biosdevname changed two or three times with the names of the ports on my machine changing each time, then the systemd fungus decided to engulf biosdevname and of course had to change the naming convention yet again.
Then there is nonsense like the new systemd rules giving totally wacky names to USB wireless dongles, names that change when you move the dongle from one USB port to another. If I had a definition of "consistent" it wouldn't including changing the name of a removeable device just because I happened to plug it into a different USB port.
In 5 or 10 years maybe the consistent names will stop changing...
On May 13, 2014, at 6:33 PM, Tom Horsley horsley1953@gmail.com wrote:
You could learn to love the default udev nomenclature
Of course the major problem with the new "consistent" names is they keep changing the software and making the names consistently different :-).
The original biosdevname changed two or three times with the names of the ports on my machine changing each time, then the systemd fungus decided to engulf biosdevname and of course had to change the naming convention yet again.
Don't get me started with systemd. That is one of the things that makes me rethink ever becoming a Linux system administrator. You'd think that otherwise intelligent people would know better, but I'm always unpleasantly surprised.
... and distros keep moving to it. The idiocy isn't just constrained to the developers, apparently.
Biggest bunch of idiocy I've ever seen in Linux since Gnome and the way KDE 4 was released.
--Russell
On Tue, May 13, 2014 at 17:59:54 -0700, CLOSE Dave Dave.Close@us.thalesgroup.com wrote:
I've done that. The problem seems to be that what I want to do is to /exchange/ the names assigned. One of the renames works but the other fails, claiming the new name is already in use. In other circumstances, I'd use an intermediate name, orig->temp->target, but I don't know how to do that with udev, or even if it is possible.
To exchange names, you need to use a temporary name and do three renames. Pretty much like swapping to values using a temporary variable.
Another thing to consider is do you really need to reference the interface names? If you use dhcp and NetworkManager, you might be able to avoid that.
On 5/13/2014 8:59 PM, CLOSE Dave wrote:
On 05/13/2014 05:39 PM, Russell Miller wrote:
I want to run the same software on all of these machines and having inconsistent names /between/ the machines makes that next to impossible. Using the new names means that my software has to learn all those different names and can't easily determine which name applies to the motherboard port. Using the old names means it can't predict which name will be given to which port.
There's got to be a better answer.
... don't use Fedora?
Just kidding. Sort of.
Well, that option will certainly be considered. But it appears that nearly all of the common distributions are going to systemd/udev. Not only would I probably still have the same problem, I'd also have to learn a whole bunch of different things.
Assuming since you're posting here that that's not an option :) You could learn to love the default udev nomenclature, or you could add rules to /etc/udev.d/rules (or whatever the equivalent is) that tie MAC addresses to specific interface names. It would require a little bit of script-fu, but assuming a competently managed key or password infrastructure, shouldn't take more than an hour or two.
I've done that. The problem seems to be that what I want to do is to /exchange/ the names assigned. One of the renames works but the other fails, claiming the new name is already in use. In other circumstances, I'd use an intermediate name, orig->temp->target, but I don't know how to do that with udev, or even if it is possible.
Prepare for a whole lot more issues, though. Upgrading from 13 is a significant upgrade, and there's lots that will go wrong. Particularly on mongrel hardware like yours.
I know. It will be a "challenge".
I abandoned ethx altogether. I picked a short mnemonic for my ISP (lan = LAN, wifi = WIFI, ccast = Comcast, ctel = Century Tel.). Seems to help with servers having more that one one internet connection: ifup lan tcpdump -i ccast blah blah etc.
Hope this helps, Bill
On 05/13/2014 06:53 PM, Bruno Wolff III wrote:
To exchange names, you need to use a temporary name and do three renames. Pretty much like swapping to values using a temporary variable.
I can't find a way to do that with udev. Please enlighten me.
Another thing to consider is do you really need to reference the interface names? If you use dhcp and NetworkManager, you might be able to avoid that.
Yes, I need to reference the names. "ip route" needs them.
====
Near as I can find online, there is no solution to this issue. According to https://bugs.freedesktop.org/show_bug.cgi?id=56929#c3,
We do no longer support renaming network interfaces in the kernel namespace. Interface names are required to use custom names that can never clash with the kernel created ones.
We do not support swapping names; we cannot win any race against the kernel creating new interfaces at the same time.
The system is broken by design.
On Wed, May 14, 2014 at 14:12:19 -0700, CLOSE Dave Dave.Close@us.thalesgroup.com wrote:
On 05/13/2014 06:53 PM, Bruno Wolff III wrote:
To exchange names, you need to use a temporary name and do three renames. Pretty much like swapping to values using a temporary variable.
I can't find a way to do that with udev. Please enlighten me.
I use "ip link set" to do that. I am not sure how you would do it with udev.
Bruno Wolff III wrote:
To exchange names, you need to use a temporary name and do three renames. Pretty much like swapping to values using a temporary variable.
I can't find a way to do that with udev. Please enlighten me.
I use "ip link set" to do that. I am not sure how you would do it with udev.
Thanks for the reference. But that can't be used after the interface is up, and my interfaces come up during boot. I think it must be udev or nothing, and nothing seems to win based on the link I posted previously. I still think the new naming system is broken /by design/.
On 05/14/2014 03:35 PM, CLOSE Dave issued this missive:
Bruno Wolff III wrote:
To exchange names, you need to use a temporary name and do three renames. Pretty much like swapping to values using a temporary variable.
I can't find a way to do that with udev. Please enlighten me.
I use "ip link set" to do that. I am not sure how you would do it with udev.
Thanks for the reference. But that can't be used after the interface is up, and my interfaces come up during boot. I think it must be udev or nothing, and nothing seems to win based on the link I posted previously. I still think the new naming system is broken /by design/.
I believe you can edit /etc/udev/rules.d/70-persistent-net.rules and add lines such as:
# Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1d:09:29:34:03", ATTR{type}=="1", NAME="eth0"
# PCI device 0x8086:0x1079 (e1000) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:08:0d:1c", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
# PCI device 0x8086:0x1079 (e1000) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:08:0d:1d", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
Each rule must be on a separate line, blank lines and those starting with "#" are ignored.
After a reboot, this should cause the NIC with the MAC address 00:1d:09:29:34:03 to be named "eth0", the one with MAC address 00:1b:21:08:0d:1c to be named "eth1" and so on. There are other attributes you can specify. I use this on F19 and F20. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - A day for firm decisions!!! Well, then again, maybe not! - ----------------------------------------------------------------------
On 05/14/2014 04:15 PM, Tom Horsley issued this missive:
On Wed, 14 May 2014 15:52:35 -0700 Rick Stevens wrote:
I believe you can edit /etc/udev/rules.d/70-persistent-net.rules and add lines such as:
Used to be able to. Maybe there is some magic to allow it, but it seems to have stopped working by default.
Do you have the systemd-udevd.service running? Dunno if that's been disabled by default or not...all my machines have been fedup'd. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - "Do you suffer from long-term memory loss?" "I don't remember" - - -- Chumbawumba, "Amnesia" (TubThumping) - ----------------------------------------------------------------------
On Wed, May 14, 2014 at 15:35:37 -0700, CLOSE Dave Dave.Close@us.thalesgroup.com wrote:
Bruno Wolff III wrote:
To exchange names, you need to use a temporary name and do three renames. Pretty much like swapping to values using a temporary variable.
I can't find a way to do that with udev. Please enlighten me.
I use "ip link set" to do that. I am not sure how you would do it with udev.
Thanks for the reference. But that can't be used after the interface is up, and my interfaces come up during boot. I think it must be udev or nothing, and nothing seems to win based on the link I posted previously. I still think the new naming system is broken /by design/.
I forgot to add that since it's been a while since I actually did it. You do have to set the link down before doing the rename. But you can use ip link to do that as well.
-
Bill Shirley -
Bruno Wolff III -
CLOSE Dave -
Rick Stevens -
Russell Miller -
Tom Horsley