Le ven. 1 nov. 2019 à 00:48, Thomas Goirand <z...@debian.org> a écrit : > > 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...
The reasons why it's not in /etc are here [1], and this is overridable, see SYSUSERS.D(5). [1] http://0pointer.de/blog/projects/stateless.html > 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? This is #925473 which was fixed in 9.0.16-5 (in experimental [2]) and lost by the upload of 9.0.22-1 to sid. Those patches should be brought back to sid, but it seems that there is not so much interest. [2]: https://tracker.debian.org/news/1041550/accepted-tomcat9-9016-5-source-all-into-experimental/ Cheers -- Mathieu Parent
