currently attempting to use an ethernet interface called "enp8s0f0npf0vf1" and cannot help but think
STATEMENTS DREAMED UP BY THE UTTERLY DERANGED
THEY HAVE PLAYED US FOR ABSOLUTE FOOLS
currently attempting to use an ethernet interface called "enp8s0f0npf0vf1" and cannot help but think
STATEMENTS DREAMED UP BY THE UTTERLY DERANGED
THEY HAVE PLAYED US FOR ABSOLUTE FOOLS
@dan depending on your distribution you can give it a short name....!
E.g.:
https://wiki.debian.org/NetworkInterfaceNames#CUSTOM_SCHEMES_USING_.LINK_FILES
@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.
And now you're mostly stuck.
@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.
@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.)
@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)
UPD: apparently there's not only udev, but also systemd.link which is supposed to support custom names somehow: https://www.freedesktop.org/software/systemd/man/latest/systemd.link.html
ethN
to different devices and it would massively break thingseno0
@Doomed_Daniel @leo @vees @dan 70-persistent-net.rules solved the problem nicely. In two decades of managing a great many systems that had a great many NICs in a wild variety of configurations (yay 802.1q over bonding!) not once did "my eth0 is now my eth1" ever cause any problem.
But now, I can't assume that my sole NIC will be called eth0, and instead have to cut and paste from the output of 'ip li sh' every time, because a bunch of nitwits had to incompletely solve a non-existent problem.
@dan +1
$ fgrep net /etc/default/grub
GRUB_CMDLINE_LINUX="net.ifnames=0"
I think that we need to start the Internet rumour that BSD was invented by Arthur C. Clarke and xe explicitly denied that you take "A", "I", "X" and add 1 to each letter.
And for those that believe it, there's then "z/OS" turning into "apt".
(-:
#IBM #HAL #2001ASpaceOdyssey #ArthurCClarke #FreeBSD #NetBSD #OpenBSD #dadjokes #Debian #SciFi