[b112]

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]

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]

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]

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.

[b112]

Even if you didn't like that, pre-Systemd udev allowed assigned by a variety of properties, including bus identifiers.

[throw0101d]

> 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.

Under RH-based systems the ifcfg-* files had a HWADDR variable, so if you swapped a card you could get the new MAC address and plug it in there and get the same interface name. There was also udevd rules where you map names to particular hardware, including particular MACs.

> Real world enterprise users wanted this, it wasn't an arbitrary design choice.

As a real world sysadmin, working now a few of decades in this field (starting with non-EL-RH, then BSD, then Solaris, then RHEL, Debian, and now Ubuntu), I have never wanted this.

[mjg59]

Great. A tech swaps out a network card, now how do I log in to rewrite the ifcfg file when the interface wasn't brought up with the correct config because it has a different name?

[tlamponi]

> now how do I log in to rewrite the ifcfg file when the interface wasn't brought up with the correct config because it has a different name?

Unlike most desktops, basically all servers got out-of-band management (e.g. IPMI) and a NIC swap is something that needs a tech physically near the server, so even a simple serial console is easily plugged in. Or how will that new NIC work with the whole network, like any basic networking setup or firewall won't allow traffic from arbitrary MACs, so normally this needs to be coordinated already anyway in an enterprise setting, e.g. through a change management process.

And why would one optimize the whole design for network naming for the edge case and not the much more common one like simple software updates.

And the design is not even being able to guarantee it for the edge case. Plugin that NIC in a different PCI slot, or let the firmware to a blip and report it differently–all things that happened!–and you still got no network with net naming scheme. Worse, you reboot after a systemd update, and you can have no network either. Or the kernel learns that your NIC supports virtual functions, guess what, no network because the (seemingly just-in-time) predictable naming scheme now sees that information changing its previous prediction.

I never will be able to understand how one can argue for breaking the common use case, nobody argues that there isn't a real problem or that there is the One True Way™ to solve it (at least I do not intend so), but arguing for using a certainly not ideal default that optimized for an edge case feels a bit like some sunk cost fallacy to me.

Sorry for my wall of text, I would really like to care less, but at $work I am exposed to this mess directly, not only for our infra but for all users of our projects, can all be done and managed, sure, but the churn and hours I have to put in thanks to this feels unnecessary and could be used for much more useful things.

[throw0101d]

> A tech swaps out a network card, now how do I log in to rewrite the ifcfg file when the interface wasn't brought up with the correct config because it has a different name?

IPMI/iDRAC/iLO/XCC/etc.