Systemd/udev and complex simple single nic cases

Posted Feb 6, 2019 18:33 UTC (Wed) by jccleaver (guest, #127418)
In reply to: Systemd/udev and complex simple single nic cases by pizza
Parent article: Systemd as tragedy

> For all your bellyaching, that feature is trivially disabled, as per the second-to-last section on that page.

I'm aware that it's disableable, and regularly do so. My original point was that "making the common use case very smooth" is risible for systemd as a whole. The most common use case for a host will be a single attached NIC, and now your options for this are:
a) a completely unpredictable in advance interface name
b) add kernel flags at install/kickstart and on your grub line to undo this

And it's not even difficult to come up with workarounds for this -- maybe a built-in alias so that "eth0" *always* means "the only NIC" on single NIC systems even if the real name is its mess, so that thing would continue to work the way they had for the last 20 years in most cases.

> So, yes, thanks Lennart, for building a mechanism that most distributions found useful enough to enable by default, documenting it heavily, and providing an easy way to configure or disable it altogether.

That's a sheer bandwagon argument, and it fails even before you get to the underlying arguments about how responsive some distributions are to either their userbases or their downstreams (hint: not always, especially if they regularly kick policy decisions over to members in the same group popping on a different hat).

Systemd/udev and complex simple single NIC cases

Posted Feb 6, 2019 22:26 UTC (Wed) by jccleaver (guest, #127418) [Link] (7 responses)

And BTW, I'm not alone in this. This is a major annoyance and impacted tons of shops to "fix" a problem that was already basically solved.

https://www.ispcolohost.com/2015/07/11/kickstarting-with-...
https://access.redhat.com/discussions/916973
https://access.redhat.com/discussions/2620221

And of course, this doesn't even address the straight-up clusterf*ck of the 7.2 to 7.3 update:

https://access.redhat.com/solutions/2592561
https://bugzilla.redhat.com/show_bug.cgi?id=1392506
https://bugzilla.redhat.com/show_bug.cgi?id=1391944
https://github.com/systemd/systemd/commit/6c1e69f9456d022...

Nor does it hit the "systemd will silently hang all boot/reboot attempts because no one tested SELinux policy application" that many of us hit while trying to address the issue: https://bugzilla.redhat.com/show_bug.cgi?id=1393505

Although this was a flat-out collapse of RedHat QA, it was precipitated by a belief by the systemd crew that it should be able to barrel over all sorts of underlying real-world behaviors blithely making assumptions no one had guaranteed and no one had agreed to. And when it inevitably breaks because of some other issue out there, their initial response is *always* "Hey, works for us. Not our problem!"

See also: UEFI bricking, usernames starting with a number, incorrect /etc/fstab entries hanging boot, flooding debug data to klogd, and God knows what else...

Systemd/udev and complex simple single NIC cases

Posted Feb 6, 2019 23:00 UTC (Wed) by johannbg (guest, #65743) [Link] (2 responses)

You used Dell right and it rings no bells that your own server manufacturer came up with biosdevname trying to solve the same problem you claim does not exist, but finally got solved in udev. ( and got dealt with in solaris decades ago )

Red Hat has a number to call for their support contract have you tried using it?

I'm pretty sure they can give you the moral support you need and even re-train you.

And you still arent critisizing systemd in an area you could arguably critisize it for but carry on throwing bricks at a dead pony...

Systemd/udev and complex simple single NIC cases

Posted Feb 9, 2019 22:46 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

So... jccleaver points out lots of examples of actual problems breaking things for real people (not just jccleaver), and your response is...

> Red Hat has a number to call for their support contract have you tried using it?
> I'm pretty sure they can give you the moral support you need and even re-train you.

I'm fairly sure this is not argument in good faith on your part. (At the very least, you are entirely ignoring your interlocutor.)

Systemd/udev and complex simple single NIC cases

Posted Feb 10, 2019 10:50 UTC (Sun) by johannbg (guest, #65743) [Link]

My poor communication skills aside, the underlying problem which is very much real despite others who have not be bitten by it, claiming it is not so, is that network interface device probing is not predictable which result in unpredictable enumeration on those device interfaces.
( this problem is not spesific to linux, they are present on bsd and solaris as well ).

This problem has existed long before udev and came to be as can be seen by historic multiple prope and pray workarounds from various upstreams and distribution ( and *nixes) trying to get it right, all the way down to administrators trying to manage that by themselves by stuffing something as simple like ifconfig $foo name $bar in /etc/rc.conf or write more complex, scripts which boiled down more or less finding the mac addr and then run ifconfig $foo on it's output.

Users can disable or hack the udev rule to their liking if they dont agree with it's implementation.

And systemd's networkd interface configuration file arent more complex than so...

/etc/systemd/network/20-wired.network

[Match]
Name=enp1s0

[Network]
Domains=<your search domains>
DNS=<your dns >
DNS=<your dns >
Address= <your ipv4 address )
Address=< your ipv6 address )
Gateway=< your gateway >

And a simple ( fallback ) dhcp configuration

/etc/systemd/network/99-wired-dhcp.network

[Match]
Name=enp1*

[Network]
DHCP=yes

And for the keen administrator eye he will notices that *both* of the networkd network files combined are atleast half the size of an single
ifcfg script.

The fact is udev is not do blame for the device naming enumiration problem nor is systemd network configuration, complex or hard to understand

So all this constant blaming udev, systemd or both for all the worlds problem approach, to me makes little to no sense.

Systemd/udev and complex simple single NIC cases

Posted Feb 13, 2019 8:44 UTC (Wed) by flussence (guest, #85566) [Link] (3 responses)

>See also: UEFI bricking, usernames starting with a number, incorrect /etc/fstab entries hanging boot, flooding debug data to klogd, and God knows what else...
The UEFI bricking vuln wasn't unique to systemd.

(and personally I'd prefer if /sbin/mount would grok GPT partition metadata so that fstab could go away, but that's neither here nor there.)

Systemd/udev and complex simple single NIC cases

Posted Feb 13, 2019 18:14 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

How is it supposed to know *where*, if at all, to mount the partition? That's a rather important part of fstab which the GPT tells you nothing about. And no, the Windows habit of "mounting" *everything* is not a good solution.

Cheers,
Wol

Systemd/udev and complex simple single NIC cases

Posted Feb 14, 2019 7:25 UTC (Thu) by zdzichu (subscriber, #17118) [Link]

There are few well-known GPT UUID↔mountpoint mappings, covering most uses (single OS on permanent storage):
https://en.wikipedia.org/wiki/GUID_Partition_Table#Partit...

I think they're utilised by systemd-gpt-mount generator.

Systemd/udev and complex simple single NIC cases

Posted Feb 14, 2019 17:51 UTC (Thu) by nix (subscriber, #2304) [Link]

Maybe it would help it go away in *some* cases, but certainly not all. My home server has 52 entries in /etc/fstab (and hundreds more mounts created by generators). Know how many could be replaced with UEFI scanning? One, and that's only because booting *requires* a UEFI partition devoted to it. Everything else is under at least md and LVM and often under more layers (bcache, LUKS, etc), or isn't a local fs at all.