5 ms·

TIL there are 14 subtly different naming schemes for network interfaces[1]. "predictable" my ass. [1] https://manpages.debian.org/testing/systemd/systemd.net-n

TIL there are 14 subtly different naming schemes for network interfaces[1]. "predictable" my ass. [1] https://manpages.debian.org/testing/systemd/systemd.net-naming-scheme.7.en.html#HISTORY https://manpages.debian.org/testing/systemd/systemd.net-nami...

tlamponi 1y ago
14 different schemes multiplied by some acting slightly different in every version. Sure you can pin it, but that fixes only their internal back and forth, is only possible via the kernel cmdline and there is no guarantee for how long the old versions will stay available, as they deprecated much more invasive things in the past (e.g., cgroupv1) I'd expect them to also drop older versions here, breaking ones naming again. And sure, one can pin interfaces to custom names, but why should anybody have to bother with such things?! I like systemd a lot, but this is one of the thing they fumbled big time and seemingly still aren't done. Pinning interfaces by their MAC to a short and usable name, would e.g. have been much more stable as doing that by PCI slot, which firmware updates, new hardware, newer kernel exposing newer features, ... changes rather often. This works well for all but virtual functions, but those are sub-devices of their parent interface anyway and can just get named with a suffix added to the parent name.
- grantla 1y ago
  > as they deprecated much more invasive things in the past (e.g., cgroupv1) I'd expect them to also drop older versions here, breaking ones naming again Note that the naming scheme is in control of systemd, not the kernel. Even if it is passed on the kernel commandline.
  - tlamponi 1y ago
    Yeah, I know, I spent more than a week into looking for options to reduce impact for all of our users. And note that cgroupv1 also still works in the kernel just fine, only the part that systemd controlled was removed from systemd. You can still boot with cgroupv1 support on, e.g., Alpine Linux and OpenRC as init 1. So not sure if that will lessen my concerns about no guarantees for older naming-scheme versions, maintaining triple digits of them sure has its cost too. And don't understand me wrong, sunsetting cgroupv1 was reasonable, but it was a lot of churn, it at least was a one time thing. The network interface naming situation is periodic churn, guaranteed to bite you every now and then just by using the defaults.
    - Scramblejams 1y ago
      Can you tell me why NamePolicy=keep doesn't do the trick? Looking myself for options to keep a Debian bare metal server I admin from going deaf and mute the next time I upgrade it... It still uses an /etc/network/interfaces file that configures a bridge for VMs to use, and the bridge_ports parameter requires an interface name which, when I upgraded to Bookworm, changed. At this rate maybe I'll write a script that runs on boot and fixes up that file with whatever interface it finds, then restarts the network.
- woleium 1y ago
  I imagine they went against mac address because it is not immutable, some folks rotate mac addresses for privacy/security reasons.
  - em-bee 1y ago
    i thought about that, but couldn't you access the hardcoded address to identify the card? but you also want to be able to change a card in a server without the device name changing. at least that used to be an issue in the past.
  - tlamponi 1y ago
    The original one is still there. Systemd knows even about that, it's differentiated as MAC vs PermanentMAC.
  - duskwuff 1y ago
    There are, unfortunately, some older devices (like some Sun systems) which use the same MAC address for every network interface on the device.
- b112 1y ago
  This worked brilliantly in Debian for more than a decade, had almost zero downside, and just did what asked. I went through 3+ dist-upgrades, for the first time in my life, without a NIC change. It was deprecated for this nonsense in systemd. Yes, there were edge cases in the Debian scheme. Yet it did work with VMs (as most VMs kept the same MAC in config files), and it was easy to maintain if you wanted 'fresh'. Just rm the pin file in the udev dir. Done. Again it worked wonderful on every VM, every bare metal system I worked with. One of the biggest problems with systemd, is it seems to be developed by people that have no real world, industrial scale admin experience. It's almost like a bunch of DEVs got together, couldn't understand why things were "so confusing", and just figured "Oh, it must be a mistake". Nope. It's called covering edge cases, ensuring things are stable for decades, because Linux and the init system are the bottom of the stack. The top of the stack changes like the wind in spring, but the bottom of the stack must be immensely stable, consensus driven, I repeat stable change. Systemd just doesn't "get" that.
  - mjg59 1y ago
    systemd's design choices here were influenced by a lot of bugs Red Hat received where failed hardware was swapped out and interface names changed as a result. Real world enterprise users wanted this, it wasn't an arbitrary design choice.
    - b112 1y ago
      That's quite the jump. Some real world users asked for a fix. They did not mean they asked specifically for this fix. There were other ways to handle this. With Debian's system, you could wipe the state files, and for example eth0/etc would be reassigned per initialization order. Worked fine. Even if you didn't like that, pre-Systemd udev allowed assigned by a variety of properties, including bus identifiers. It was merely that Redhat, as usual, was so lacking in sophistication, unlike Debian.
      - mjg59 1y ago
        It turns out that people do not love having to log into a machine after a network card swap to get the new network card to have the same name. Initialisation order is explicitly not guaranteed by the kernel and so absolutely does not work every time.
lynx97 1y ago
The "stable" interface naming scheme is a scam. And I have proof. Test upgraded a VM today, from bookworm to trixie. And guess what. Everything worked, except after reboot the network interface was unconfigured? Guess what. The name changed...
- deleted 1y ago
  [deleted]
- pferde 1y ago
  That can only happen if the emulated hardware layout presented to the VM changes. I'd look at that before calling anything a scam.
  - tlamponi 1y ago
    Scam is probably the wrong word, and it's choice might be a bit feeling fueled, but it's really not true that this only depends on the HW. systemd also changes behavior in what naming policies are the default and what it considered as input, it did that since ever but started to version that since v238 [0]. Due to that the HW can stay exactly the same but names still change. I see this in VMs that stay exactly the same, no software update, not change in how the QEMU cli gets generated, really nothing changed from the outside virtual HW POV, interface name still changes. The underlying problem was a real one, the solution seems like a bit of a sunken cost fallacy, and it added more problem dimensions than there previously exist. Besides, even if the HW would change, shouldn't a _predicatble_ naming scheme be robust to not care about that as long as the same NIC is still plugged in somewhere? Disclaimer, as stated elsewhere: I really like systemd, I'm not one that speaks out against it lightly, but the IF naming is not something they got right, but rather made worse for the default case. Being able to easily pin interface names through .link files is great, but requiring users to do that or have no network after an upgrade, especially for simple one-NIC use cases in a completely controlled environment like a VM is just bonkers. [0]: https://www.freedesktop.org/software/systemd/man/latest/systemd.net-naming-scheme.html#History https://www.freedesktop.org/software/systemd/man/latest/syst...
    - 1y ago
unethical_ban 1y ago
The best use of AI I've gotten so far is having it explain to me how to manage a Fedora Server's core infrastructure "the right way". Which files, commands, etc. to permanently or temporarily change network, firewall, DNS, NTP settings.
foresto 1y ago
I dislike systemd's Predictable Network Interface Names, so I disable them with this kernel command line option: net.ifnames=0 Welcome back, eth0. :)
- sigio 1y ago
  Yup.. use this default on all my systems. Did a bookworm->trixie upgrade today on my mailserver, and everything worked, as it still just has eth0 ;)

tlamponi 1y ago

14 different schemes multiplied by some acting slightly different in every version. Sure you can pin it, but that fixes only their internal back and forth, is only possible via the kernel cmdline and there is no guarantee for how long the old versions will stay available, as they deprecated much more invasive things in the past (e.g., cgroupv1) I'd expect them to also drop older versions here, breaking ones naming again. And sure, one can pin interfaces to custom names, but why should anybody have to bother with such things?! I like systemd a lot, but this is one of the thing they fumbled big time and seemingly still aren't done. Pinning interfaces by their MAC to a short and usable name, would e.g. have been much more stable as doing that by PCI slot, which firmware updates, new hardware, newer kernel exposing newer features, ... changes rather often. This works well for all but virtual functions, but those are sub-devices of their parent interface anyway and can just get named with a suffix added to the parent name.

grantla 1y ago
> as they deprecated much more invasive things in the past (e.g., cgroupv1) I'd expect them to also drop older versions here, breaking ones naming again Note that the naming scheme is in control of systemd, not the kernel. Even if it is passed on the kernel commandline.
- tlamponi 1y ago
  Yeah, I know, I spent more than a week into looking for options to reduce impact for all of our users. And note that cgroupv1 also still works in the kernel just fine, only the part that systemd controlled was removed from systemd. You can still boot with cgroupv1 support on, e.g., Alpine Linux and OpenRC as init 1. So not sure if that will lessen my concerns about no guarantees for older naming-scheme versions, maintaining triple digits of them sure has its cost too. And don't understand me wrong, sunsetting cgroupv1 was reasonable, but it was a lot of churn, it at least was a one time thing. The network interface naming situation is periodic churn, guaranteed to bite you every now and then just by using the defaults.
  - Scramblejams 1y ago
    Can you tell me why NamePolicy=keep doesn't do the trick? Looking myself for options to keep a Debian bare metal server I admin from going deaf and mute the next time I upgrade it... It still uses an /etc/network/interfaces file that configures a bridge for VMs to use, and the bridge_ports parameter requires an interface name which, when I upgraded to Bookworm, changed. At this rate maybe I'll write a script that runs on boot and fixes up that file with whatever interface it finds, then restarts the network.
woleium 1y ago
I imagine they went against mac address because it is not immutable, some folks rotate mac addresses for privacy/security reasons.
- em-bee 1y ago
  i thought about that, but couldn't you access the hardcoded address to identify the card? but you also want to be able to change a card in a server without the device name changing. at least that used to be an issue in the past.
- tlamponi 1y ago
  The original one is still there. Systemd knows even about that, it's differentiated as MAC vs PermanentMAC.
- duskwuff 1y ago
  There are, unfortunately, some older devices (like some Sun systems) which use the same MAC address for every network interface on the device.
b112 1y ago
This worked brilliantly in Debian for more than a decade, had almost zero downside, and just did what asked. I went through 3+ dist-upgrades, for the first time in my life, without a NIC change. It was deprecated for this nonsense in systemd. Yes, there were edge cases in the Debian scheme. Yet it did work with VMs (as most VMs kept the same MAC in config files), and it was easy to maintain if you wanted 'fresh'. Just rm the pin file in the udev dir. Done. Again it worked wonderful on every VM, every bare metal system I worked with. One of the biggest problems with systemd, is it seems to be developed by people that have no real world, industrial scale admin experience. It's almost like a bunch of DEVs got together, couldn't understand why things were "so confusing", and just figured "Oh, it must be a mistake". Nope. It's called covering edge cases, ensuring things are stable for decades, because Linux and the init system are the bottom of the stack. The top of the stack changes like the wind in spring, but the bottom of the stack must be immensely stable, consensus driven, I repeat stable change. Systemd just doesn't "get" that.
- mjg59 1y ago
  systemd's design choices here were influenced by a lot of bugs Red Hat received where failed hardware was swapped out and interface names changed as a result. Real world enterprise users wanted this, it wasn't an arbitrary design choice.
  - b112 1y ago
    That's quite the jump. Some real world users asked for a fix. They did not mean they asked specifically for this fix. There were other ways to handle this. With Debian's system, you could wipe the state files, and for example eth0/etc would be reassigned per initialization order. Worked fine. Even if you didn't like that, pre-Systemd udev allowed assigned by a variety of properties, including bus identifiers. It was merely that Redhat, as usual, was so lacking in sophistication, unlike Debian.
    - mjg59 1y ago
      It turns out that people do not love having to log into a machine after a network card swap to get the new network card to have the same name. Initialisation order is explicitly not guaranteed by the kernel and so absolutely does not work every time.

lynx97 1y ago

The "stable" interface naming scheme is a scam. And I have proof. Test upgraded a VM today, from bookworm to trixie. And guess what. Everything worked, except after reboot the network interface was unconfigured? Guess what. The name changed...

deleted 1y ago
[deleted]
pferde 1y ago
That can only happen if the emulated hardware layout presented to the VM changes. I'd look at that before calling anything a scam.
- tlamponi 1y ago
  Scam is probably the wrong word, and it's choice might be a bit feeling fueled, but it's really not true that this only depends on the HW. systemd also changes behavior in what naming policies are the default and what it considered as input, it did that since ever but started to version that since v238 [0]. Due to that the HW can stay exactly the same but names still change. I see this in VMs that stay exactly the same, no software update, not change in how the QEMU cli gets generated, really nothing changed from the outside virtual HW POV, interface name still changes. The underlying problem was a real one, the solution seems like a bit of a sunken cost fallacy, and it added more problem dimensions than there previously exist. Besides, even if the HW would change, shouldn't a _predicatble_ naming scheme be robust to not care about that as long as the same NIC is still plugged in somewhere? Disclaimer, as stated elsewhere: I really like systemd, I'm not one that speaks out against it lightly, but the IF naming is not something they got right, but rather made worse for the default case. Being able to easily pin interface names through .link files is great, but requiring users to do that or have no network after an upgrade, especially for simple one-NIC use cases in a completely controlled environment like a VM is just bonkers. [0]: https://www.freedesktop.org/software/systemd/man/latest/systemd.net-naming-scheme.html#History https://www.freedesktop.org/software/systemd/man/latest/syst...
  - 1y ago

unethical_ban 1y ago

The best use of AI I've gotten so far is having it explain to me how to manage a Fedora Server's core infrastructure "the right way". Which files, commands, etc. to permanently or temporarily change network, firewall, DNS, NTP settings.

foresto 1y ago

I dislike systemd's Predictable Network Interface Names, so I disable them with this kernel command line option: net.ifnames=0 Welcome back, eth0. :)

sigio 1y ago
Yup.. use this default on all my systems. Did a bookworm->trixie upgrade today on my mailserver, and everything worked, as it still just has eth0 ;)