3 ms·

I've just heard from people claiming the absurd way NIC are named in systemd is good for server fleet types and the like. Because it's obviously terrible for hu

I've just heard from people claiming the absurd way NIC are named in systemd is good for server fleet types and the like. Because it's obviously terrible for human people with desktop computers. I guess I just assumed the bad design decisions had some purpose.

freedomben 4y ago
I miss the old NIC names, but for systems with multiple NICs the old way would name them differently based on the winner of the init race. It often felt deterministic, but was not. I've had critical systems fail on reboot because the NICs swapped names so WAN port got configured as LAN and vice versa. That can also create a terrifying security problem too
- deleted 4y ago
  [deleted]
- fragmede 4y ago
  Some distros wrote config files so the assignment would remain stable. Which also was wrong when switching hardware around, but that's a different issue.
bravetraveler 4y ago
It provides predictability in the device names. enp1s0f0 looks cryptic but it tells you the exact slot location of the card eth0 tells you the first ethernet class interface that was activated that boot. Not particularly helpful. I feel like if you need to care about these names as a user... the distribution has failed to provide effective wrappers. This is window dressing.
- placatedmayhem 4y ago
  Yes. When we got a shipment of 1000+ servers that are all supposed to be cabled the same way, both internally and externally, the device naming made it easy to see when something got messed up. This allowed us to hold the system builder accountable, simplify our configuration management, and reduce the amount of configuration discovery a engineer needed to do during an incident.
  - bravetraveler 4y ago
    Very good examples of the practicality! While sure, I would like shorter device names, the fact is... the only time I need to use them is when ambiguity is something I/we can't really afford. So, I'm thankful for the cryptic-yet-specific names. Everyone else (read: desktop people) can use whatever DHCP'd.

freedomben 4y ago

I miss the old NIC names, but for systems with multiple NICs the old way would name them differently based on the winner of the init race. It often felt deterministic, but was not. I've had critical systems fail on reboot because the NICs swapped names so WAN port got configured as LAN and vice versa. That can also create a terrifying security problem too

deleted 4y ago
[deleted]
fragmede 4y ago
Some distros wrote config files so the assignment would remain stable. Which also was wrong when switching hardware around, but that's a different issue.

bravetraveler 4y ago

It provides predictability in the device names. enp1s0f0 looks cryptic but it tells you the exact slot location of the card eth0 tells you the first ethernet class interface that was activated that boot. Not particularly helpful. I feel like if you need to care about these names as a user... the distribution has failed to provide effective wrappers. This is window dressing.

placatedmayhem 4y ago
Yes. When we got a shipment of 1000+ servers that are all supposed to be cabled the same way, both internally and externally, the device naming made it easy to see when something got messed up. This allowed us to hold the system builder accountable, simplify our configuration management, and reduce the amount of configuration discovery a engineer needed to do during an incident.
- bravetraveler 4y ago
  Very good examples of the practicality! While sure, I would like shorter device names, the fact is... the only time I need to use them is when ambiguity is something I/we can't really afford. So, I'm thankful for the cryptic-yet-specific names. Everyone else (read: desktop people) can use whatever DHCP'd.