[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: tomcat9 using systemd specific stuff is now vendor lock-in [was: BITS from the DPL For September/October 2019]

On 10/31/19 9:56 PM, Moritz Mühlenhoff wrote:
> This isn't limited to just shipping an init script, have a look at the
> tomcat9 9.0.13-1 changelog entry which dropped the sysvinit script.
> Continuing to support an init script also means to retain on all the
> packaging boilerplate which got obsoleted by systemd config declaratives,
> forcing the least common denominator of init system features.

Ok, let's have a look.

So I saw this:

* Simplified the postinst script by using systemd-sysusers to create
the 'tomcat' user

and then investigated a little bit what systemd-sysusers is (I didn't
know it). And it's really a disaster ... at many levels!

Instead of using well understood parameters to adduser, which we've been
using for decades, and understand well the parameters, systemd provides
now a mechanism through /usr/lib/sysusers.d. Tomcat uses it by adding a
file in /usr/lib/sysusers.d/tomcat9.conf. I'm immediately questionning
myself is it wouldn't have been better in /etc/systemd/sysusers.d, so
that we get CONFFILE, but that's Red Hat tooling, so... and maybe we can
override it in /etc/systemd? Anyways...

So, this is supposed to be "more simple". Really? I'm not convinced.
Looking into the script, I now also have to look into the indirection of
that data file, and package that file.

What's for sure now, is that tomcat9 is vendor-locked-in, as in, no way
to escape systemd, otherwise the postinst will crash. I suppose the
maintainer perfectly understands it, but doesn't mind/care. [I by the
way wonder why tomcat9 runtime depends on both lsb-base *AND* systemd]

Probably, systemd-sysusers got the logic to check with getent if the
user is present before adding it and such things. So it may be useful
(hard to tell, but looking quickly at its source code, it seems doing
that, and even a lot more, to the point that it starts to get scary).
But that's not the point.

The question is, why is systemd-sysusers part of just systemd, and not
packaged / shipped somewhere else? This really looks like something that
could be taken away from systemd itself, and proposed as a separate
tool, in a general way, so that other init system could use it. To the
point that, IMO, even upstream should have separate it from systemd
itself (in another project?).

This is precisely what a distribution should do through a policy:
enforce common tooling for our maintainer scripts, so we can do things
together. Of course, that's not on the systemd agenda, where the goal
seems to be to take over everything. But maybe as a distribution, we
could be smarter than this?

Finally, this really shows we don't have enough in our policy. Indeed,
using systemd-sysusers *OR* some common Debian tooling should be
documented somewhere, and not left as a decision to the package
maintainer. I have to admin that I wrote my own tooling around adduser /
addgroup / getend / usermod, but considering how many traps there,
probably a more generic tooling should have been written and generalized
for all of Debian.

The other things I saw from the changelog are less controversial:
* Let systemd automatically create /var/log/tomcat9 and /var/cache/tomcat9

this can easily be added in the init script

* Restart the server automatically on failures

that's a nice standard systemd feature, which we don't have to enforce
on other init systems.

Did I miss something else?


Thomas Goirand (zigo)

Reply to: