@dan Beats the hell out of “I hope card 1 gets picked up in the remote reboot order before card 2 so it becomes eth0 and my firewall inside doesn’t become my firewall outside.”
@vees@dan
if only there had been ways to identify a network card and store its ethX name from first boot and keep on using that unless the user explicitly changes the name(s) - must've been impossible.
clearly easier to generate a name that's "predictable" (by some definition of predictable) and, depending on the naming scheme used, hard to impossible to remember -_-
@vees@dan
however, it seems like "ip link" from iproute2 has a new-ish feature that allows setting an additional alternative name, like
$ sudo ip link property add dev enp8s0f0npf0vf1 altname eth0
and afterwards you can address the device as both enp7s0 and eth0. not sure if this works at every place you can set a name, though (like server configs for binding to an interface or whatever)
@Doomed_Daniel@vees@dan The extra challenge round is that people want to be able to pull a network card, replace it with an identical spare one, and get the same interface names rather than new ones (or swap system disks into a new set of identical hardware, for motherboard ports). This makes MACs and other serial numbers bad. Unfortunately PCIe enumeration isn't stable if there are any hardware changes (not just the network card), for reasons.
@cks@vees@dan
so the problem isn't solved (because PCIe enumeration isn't stable), but everything is changed anyway - hooray.
Also, would it be that hard to write the new mac address into some config before or after replacing the NIC?
And if you have a more complex network, don't you have to register the new mac address somewhere anyway, like at a DHCP server, possibly managed switches, routers, firewalls, whatever?
@Doomed_Daniel@vees@dan Server environments don't necessarily do MAC registration, and not all DHCP environments do authentication by MAC (but a machine may still want to keep a stable NIC name for eg its own firewall config).
Broadly: writing the new MAC somewhere is doable but it makes a stressful situation (hardware failure and replacement) worse. I once ran systems that needed this and it was a pain in the rear.
@Doomed_Daniel@vees@dan If you burn the MAC into the network device name, every system has a different name for its network interface, even on the same hardware, which is a sysadmin pain in the rear. If you freeze a simple network name based on the MAC and add a new network name if you see a new MAC, systems can wind up with network names depending on their history; reinstalling the system will give it different network names (because old MACs won't be claiming the good ones any more).
@cks@vees@dan
> If you burn the MAC into the network device name, every system has a different name for its network interface, even on the same hardware
incidentally, systemd also does that - I've seen it for USB NICs, but with a quick search I couldn't find out when exactly that enxMACADDRESS scheme is used..
(at least they seem to be less naive about the path stability of USB than PCIe…)
> reinstalling the system …
yeah, you'd have to keep the mapping file for reinstall
@Doomed_Daniel@vees@dan In many situations you don't want to keep the mapping file, because it creates differences between identical hardware based on the history of a particular server. One out of your eight hardware-identical fileservers having a different network name because you had to move it to the spare chassis (or swap its add-on network card) at one point is a special sort of hell.
(Also, not all reinstalls are planned in advance. Sometimes the disk blows up.)
@cks@vees@dan
Yeah, but what does systemd solve here?
If the NIC names aren't stable because adding a PCIe device (like a NVME SSD, I guess?), or maybe a BIOS setting or update, can change the PCIe topology, it's as shit as before
@Doomed_Daniel@vees@dan I believe systemd creates aliases, or at least lets you set naming policies for devices, so if you want to use MAC-based names you can fairly easily. And the default PCIe based names are mostly stable, and sometimes systemd can actually detect that a network port is a motherboard port and give it a truly stable name.
(This depends on vendors getting various BIOS data right, which is rather variable.)
AFAIK their approach for custom names is "write an UDEV rule to name the device, you can match the MAC or whatever there", which IIRC was already possible before systemd
(which means that you also could've written UDEV rules to get stable names based on PCIe paths for identical hardware)
@Doomed_Daniel@vees@dan according to systemd docs they briefly did this but stopped because it turned out that in some cases the kernel and udev could race to assign the same ethN to different devices and it would massively break things
(and also apparently there's a surprising amount of systems where the MAC address is randomized on each boot?)
@Doomed_Daniel@vees@dan i think they also just wanted something stateless. fwiw if your firmware lists the onboard network adapters in SMBIOS (and almost nothing does bc windows doesn't care lol) they'll have names like eno0
i have some questionable code that does this via an EFI driver: https://gitlab.com/vriska/smbios_patch/-/blob/main/src/main.rs
@leo@vees@dan
yeah, I've never seen a network device like eno0, always enpXsY (or the wl-equivalent) or, apparently for USB NICs, enxMACADDRESS which definitely is impossible to remember, unless you have a very special brain..
Add comment