Re: Integration with systemd
On 11/1/19 3:16 AM, Russ Allbery wrote:
> Thomas Goirand <zigo@debian.org> writes:
>
>> ...the bigger question is: why systemd-sysusers is part of systemd, and
>> not a standalone thing, which we could make an essential package. If we
>> want it to be part of a package standard toolkit, it means systemd
>> becomes an essential package, which isn't really what we want (we don't
>> need an init system in a chroot, as you know). For that reason alone,
>> it's probably a bad idea to recommend systemd-sysusers everywhere.
>
> I don't claim to know the full answer to this question, but if I had to
> guess, it's not particularly exciting: (a) the people who wrote it decided
> to include it in the systemd project for watever reason, probably because
> it was convenient and they were systemd developers, and (b) in the absence
> of any particular reason to break parts of systemd off into separate
> packages, the systemd maintainers have quite rationally minimized their
> work and packaging complexity.
>
> Note that upstream is probably not interested in promising
> systemd-sysusers will always run under non-systemd init systems. I don't
> know if there's any current or future reason why it wouldn't (maybe the %b
> or %m specifiers use some systemd library, although maybe they don't; I
> have done precisely zero investigation), but I doubt they'd make such a
> guarantee. Folks may with some reason think they're wrong for not caring
> about that, but they're of course entitled to care and not care about
> whatever they want. It therefore might be as simple as just making a new
> binary package, or it might not, and even if it is now, it might not
> always be.
>
> On my side, what I find interesting is the declarative syntax and
> therefore the configuration files. I don't really care if we use the
> systemd-sysusers program or something else (although obviously it's easier
> to use the thing that's already written and that someone else is
> maintaining for us). I do (mildly) care that we use the same syntax and
> features as systemd because I think there's value in convergence between
> Debian, Red Hat, and other distributions. The divergence between Debian
> and Red Hat and the correspondingly large differences in how you
> administered systems used to be really irritating; reducing gratuitous
> difference where neither approach is better, just different ways of doing
> the same thing, is a feature to me.
>
> What I want out of a GR is to decide the deeper meta question of just how
> much effort the project wants to put into problems like this. The
> *easiest* approach for Debian (assuming you agree with me about moving to
> a declarative syntax) would be to just say sysusers.d is now supported and
> preferred (except possibly in edge cases where it won't work; places where
> adduser is a pre-dependency will require special handling), and use the
> existing implementation and move on. This would obviously break sysvinit
> until someone wrote an equivalent program.
>
> A more moderate approach would be to say that once that alternative
> implementation was written, or alternately we've established that
> systemd-sysuers will work on sysvinit systems and we're at least somewhat
> committed to keeping it that way or writing something new if it doesn't,
> *then* we can start using sysusers.d, but until then it's not allowed (and
> there's a bug in the tomcat9 package).
>
> Yet another option would be to say that we like adduser and maintainers
> are still required to use adduser, and systemd-sysusers is not supported
> and not allowed.
>
> Of course, we shouldn't use a GR to decide this for systemd-sysusers
> specifically. That's way too detailed for a GR. But the point of many of
> us in the thread is that pretty much exactly this same set of alternatives
> are present for something like ten different facilities (if not more). I
> don't think we actually want to make separate conflicting decisions about
> each one; I'm pretty sure that there is a general *philosophy* that we
> want to apply here, which is roughly somewhere on a spectrum between
> "let's start using systemd native services whenever they're available,
> stable, and solve some Debian problem, regardless of whether that breaks
> sysvinit" to "all this systemd stuff is unappealing and inferior to what
> we can do ourselves; let's decide to not use it and stick with our
> facilities."
>
> (Note that there is another option, which is "let's go all in on systemd
> and use the systemd-native way of doing *everything*, right away." I'm
> fairly sure that at most a tiny minority of folks in Debian want to do
> that; I'm pretty sure not even the systemd maintainers want that. Rather,
> the most aggressive option I expect anyone to support in significant
> numbers still implies some sort of Policy vetting of a new facility to
> make sure it solves a real problem and that we've given some thought to
> how to integrate with it before we just start using it. For instance, we
> would want to make sure that systemd-sysusers honors our system UID ranges
> and naming rules.)
>
> I truly don't know where on that spectrum the *project* wants to be. I
> know where a lot of individual vocal members of the project want to be,
> but that's not at all the same thing.
>
> One advantage of a GR is that you can express an opinion without being
> required to dig through and interact with large and somewhat contentious
> debian-devel threads.
Russ,
It's well possible that I'm getting slowly convinced by your set or
arguments. Thanks for taking the time to explain your view.
Cheers,
Thomas Goirand (zigo)
Reply to: