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? Cheers, Thomas Goirand (zigo)
