I agree with that. But at the same time, systemd makes assumptions that I don’t think it should.
Case in point: I deal with several clusters that use Stanford Central LDAP for account info, and our UID numbers have gotten pretty high. So much so that it overlaps the range systemd uses for dynamic service UIDs.
The biggest annoyance is that the UID range is hard-coded, so I can’t provide an alternate range.
For an open source Free software project, I find it really strange pottering says this:
"We don't recommend people to recompile their RPMs, the same way as we don't recommend changing the UID ranges..."
From the perspective of a software author, I am not at all surprised.
If you are a user reporting a bug, and you say "I am using the RPM package of systemd from CentOS 7.4", then I know which RPM to download to get exactly the software you are using.
But, if you say "I am using the RPM package of systemd from CentOS 7.4, plus my own patch", then things will be harder for me. Not only would I need to get your patch, to be completely safe, I would need to get your build environment. For example, which compiler you are using, and which version of the compiler.
Working off of a common set of pre-built packages makes problem reproduction alot easier.
Do you remember when systemd would take usernames it couldn't parse (due to undocumented restrictions on valid usernames) in unit files and just translate them to uid 0?
Thank you for that! It did take an hour+ to research it and write it up. And it’s kindof depressing that there’s been no movement, but I do understand that I’m not really able to contribute anything on the development side.
What you're dealing with fits in the crux of my problem with systemd. They've made a series of assumptions about how things will be on a system, and if that doesn't match your reality, well terribly sorry, adjust your reality, even if it's not possible, or realistic.
Unfortunately, unlike before, you can't easily just cut systemd out of the mix.
I'd hate it less if it were more modular, such that I could swap out distinct pieces when and if needed.
I don't even understand the rationale for some of the integration. Like systemd-resolve. Why did it need to suck in the resolver? Now I can't edit resolv.conf because it overwrites it.
I can't even find a reasonable list of everything it does. Init, mounts, login, pluggable hardware, nspawn containers, logging, and...whatever else I'm forgetting.
systemd-resolvd is, like many of the systemd components, optional.
If you're using it, it is either because you setup it yourself or your distro set up it to you or you're using a NetworkManager with systemd-resolvd as your DNS resolver (and even them, it is configurable and not the default at all).
Case in point: I deal with several clusters that use Stanford Central LDAP for account info, and our UID numbers have gotten pretty high. So much so that it overlaps the range systemd uses for dynamic service UIDs.
The biggest annoyance is that the UID range is hard-coded, so I can’t provide an alternate range.
More details: https://github.com/systemd/systemd/issues/9843 (but please don’t spam the GitHub issue!)