How Debian managed the systemd transition [LWN.net]

How Debian managed the systemd transition

Posted Sep 18, 2015 13:31 UTC (Fri) by epa (subscriber, #39769)
In reply to: How Debian managed the systemd transition by dlang
Parent article: How Debian managed the systemd transition

Maybe a halfway house would be device name 'eth_only' when there is exactly one card in the machine (a fairly common case). It would never change as long as there is only one. If you installed a second Ethernet adaptor then you would be forced to switch over to the funky udev names or else use eth0 and eth1 with some risk that they might be reordered for some random reason.

to post comments

How Debian managed the systemd transition

Posted Sep 18, 2015 17:26 UTC (Fri) by kreijack (guest, #43513) [Link] (11 responses)

I think that a more reasonable solution is to still provide the ethN interface name as alias of the new name. The ethN interfaces may depend by the discovery order, but for the common case (a pc with only one ethernet) it avoids the problem.

BTW I never seen a swap of the ethernet cards; may be that I use only PVI ones ?

How Debian managed the systemd transition

Posted Sep 18, 2015 18:13 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

> I think that a more reasonable solution is to still provide the ethN interface name as alias of the new name.
Network code doesn't support it and network devices have always been a 'special case' in Linux. Notice how there are no '/dev/ethX' files.

How Debian managed the systemd transition

Posted Sep 19, 2015 14:34 UTC (Sat) by cortana (subscriber, #24596) [Link] (3 responses)

I wonder why no one has ever looked into increasing the maximum network interface name length, and adding a new kind of 'n' device node that network interfaces can use, so that they can show up in /dev just like other devices.

Then we could have /dev/net/by-{index,slot,path,mac} symlinks pointing to the original /dev/eth0 and friends. Both the original names and the predictable names would be there for those who use them, and all names would be usable simultaneously.

That way, so you no longer have to worry about a network interface having its name changed from eth0 to enp0s3 when you reboot with a newer version of udev, as happened to me last week.

You would also be able to pick and choose which name you want to use depending on your use case, just as how, with disks, it's sometimes useful to use the symlink in /dev/disk/by-path for a disk that is commonly hot-swapped (such as a backup disk you change every week) but at the same time it is useful to use /dev/disk/by-uuid for a permanently-mounted filesystem, such as / or /home.

How Debian managed the systemd transition

Posted Sep 19, 2015 20:40 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> I wonder why no one has ever looked into increasing the maximum network interface name length, and adding a new kind of 'n' device node that network interfaces can use, so that they can show up in /dev just like other devices.
As usual - legacy. The interface name is limited by IFNAMSIZ value which is used in multiple contexts, so you can not use long strings like '/dev/ethN' for interface names. And also there are no provisions for multiple interface names in getifaddrs() calls or similar functions.

Adding new functions that work with regular device nodes is certainly possible, but probably nobody cares too much about it.

How Debian managed the systemd transition

Posted Sep 20, 2015 0:02 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

if they can do eth<mac> then /dev/ethN isn't unreasonably long

How Debian managed the systemd transition

Posted Sep 20, 2015 7:37 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

IFNAMSIZ is equal to 16, so you only have 15 letters for the full path.

And the second problem is that you don't actually _need_ your devices to be mounted at '/dev'. A device node can be anywhere on the system.

It doesn't even require anything exotic - a host might simply with to get info about a TAP/TUN device in a container.

The correct way to fix it would be by creating a new API that uses file descriptors instead of interface names.

How Debian managed the systemd transition

Posted Sep 20, 2015 10:29 UTC (Sun) by kreijack (guest, #43513) [Link]

> > I think that a more reasonable solution is to still provide the ethN interface name as alias of the new name.
> Network code doesn't support it and network devices have always been a 'special case' in Linux.
> Notice how there are no '/dev/ethX' files.

May be that *now* doesn't exist a technical solution for doing that. But I don't see any reason which prevent us to implement it.
Let me to rephrase my sentence: my suggestion could be cause of some problem, or today it is impossible because nobody had coded that solution.
The former may/is a stop, the latter could be solved by some hours of coding (and several days of testing :-) )

How Debian managed the systemd transition

Posted Sep 19, 2015 1:34 UTC (Sat) by dlang (guest, #313) [Link] (4 responses)

> BTW I never seen a swap of the ethernet cards;

a swap can happen if you have cards that use different drivers and the driver load order changes (either from driver renaming if the drivers are statically linked, or the device discovery order if they are modules)

a swap can also happen if the bus the cards are on does not have an order and orders based on the order devices respond. I'm told that USB can detect the physical location of a device, but asaik, all the drivers ignore this and rely on which device responds first to device probing.

But if the device has a MAC address as part of the device, the existing tools can keep the ordering consistant.

If there is no such identifier built into the card, I don't believe that the new process is really any more reliable.

How Debian managed the systemd transition

Posted Sep 20, 2015 10:22 UTC (Sun) by kreijack (guest, #43513) [Link] (3 responses)

> a swap can happen if you have cards..
What you are saying is correct.... But I repeat in my (very limited) experience I never seen that.
What I see is that the ethernet name change from eth0 to eth1 when I moved from a disk image from one host to another, and that cause me more headache then the fact that I have more ethernet device of different hardware...

What I mean is that linking the ethernet name to the hardware is useful in some contexts, but in others not; and I suspect that these "others" are more common than the former...

How Debian managed the systemd transition

Posted Sep 20, 2015 10:52 UTC (Sun) by dlang (guest, #313) [Link]

I agree, I always disable that on my systems. But I can see that if someone was dealing with multiple USB interfaces, or wants to do async module loading (with all the ordering race conditions it introduces) in search of faster boot times, I can see why it could be useful.

How Debian managed the systemd transition

Posted Sep 25, 2015 20:16 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> What I mean is that linking the ethernet name to the hardware is useful in some contexts

You mean, like in a firewall, for instance ...

I saw a comment somewhere where eth0 and eth1 got swapped. In other words, until someone noticed, the firewall's soft, unprotected, meant for the internal network, interface was the interface to the hostile outside world ...

Cue major panic, lan disconnected from the internet, rebuild the firewall from scratch, ...

At the end of the day, unpredictable behaviour is a security risk. What I think happened was that the system had always been booted from cold, and had always been predictable. Then for some reason, one day it did a warm-start, and came back with the interfaces swapped over ... oops ...

Cheers,
Wol

How Debian managed the systemd transition

Posted Sep 25, 2015 20:36 UTC (Fri) by dlang (guest, #313) [Link]

actually, if the firewall interfaces get swapped, it's not going to talk to anything, because it is going to send the reply packets out the wrong interface (unless you also have dynamic routing)

Yes, it is possible to configure a system so that it's IPs and routes will swap with the interface changes, but the firewall rules won't, but that's getting into rather contrived territory.