Please don’t hard-code assumptions

Posted Jan 29, 2019 6:18 UTC (Tue) by akkornel (subscriber, #75292)
In reply to: Please don’t hard-code assumptions by mbiebl
Parent article: Systemd as tragedy

There are two issues that I have with the "Just recompile" response. One is that Lennart does not suggest doing so, as per https://github.com/systemd/systemd/issues/9843#issuecomme...

The other reason is, systemd is such a critical component, that I don't want to mess with the distro's packaging process.

That is one thing worth noting: I'm not talking about an individual system, where I might be willing to do `make ; make install` (or the equivalent). I need to be able to take this change and package it up for at least Debian, Ubuntu 18.04, and maybe RHEL 8 if it includes this. I need to do that because we have a substantial number of systems running those distributions of Linux.

So, that is three build infrastructures that I would have to maintain for this, along with an additional GPG key that I'll have to push out during system commissioning (because I'd want to have signed packages/repositories). I will also have to keep it in sync with each distributor's patches to systemd, and it also means that if there is a security update to systemd, I will have to rush to pull in the change and rebuild everything.

That is alot of infrastructure to maintain, and what annoys me is, I would only have to do this because the UID range assumption was hard-coded. If, for example, it was possible to specify a UID range via kernel command-line, then that would be perfectly fine with me (and would actually work really well for our diskless systems).

Please don’t hard-code assumptions

Posted Jan 29, 2019 9:28 UTC (Tue) by jani (subscriber, #74547) [Link] (1 responses)

> If, for example, it was possible to specify a UID range via kernel command-line

N.b. it's the *kernel* command-line. Not userspace command-line.

Please don’t hard-code assumptions

Posted Jan 29, 2019 15:59 UTC (Tue) by akkornel (subscriber, #75292) [Link]

Yes, but systemd already parses the kernel command-line for systemd-specific parameters. See https://www.freedesktop.org/software/systemd/man/kernel-c...

Please don’t hard-code assumptions

Posted Jan 29, 2019 16:22 UTC (Tue) by mbiebl (subscriber, #41876) [Link] (1 responses)

I was mainly commenting since you mentioned that you have no problem in rebuilding packages from source but in case of systemd you found it was somehow hard-coded deep inside the code which made this unnecessarily hard/impossible.
So I wondered if you weren't aware of those config switches which let you easily change those settings.

Please don’t hard-code assumptions

Posted Feb 5, 2019 0:15 UTC (Tue) by jccleaver (guest, #127418) [Link]

> I was mainly commenting since you mentioned that you have no problem in rebuilding packages from source but in case of systemd you found it was somehow hard-coded deep inside the code which made this unnecessarily hard/impossible.

I've regularly version-bumped upstream RPMs or added in a custom patch (if necessary) for sites I've been at, but systemd is far too complex and too central to risk something like that, which really honestly does help prove the larger point that systemd's project design is flawed.

I can't imagine there's anything I'd need to patch traditional init, or upstart on RHEL6, for, but I'd feel comfortable after a bit of testing releasing it if I had to; there's simply not very much it does, the complexity is mostly in the things it launches, like /etc/rc.sysinit. No way I'd risk that with systemd.

Please don’t hard-code assumptions

Posted Jan 31, 2019 17:10 UTC (Thu) by ermo (subscriber, #86690) [Link]

Your use case sounds legitimate, so I'm wondering if not the best thing would be to simply ask the systemd developers whether doing as you suggest would be feasible/possible?

You could even re-use the verbiage from the comments you just made?