Bug#925473: tomcat9: sysvinit script missing
On Tuesday 21 September 2021, Thorsten Glaser wrote: > Ondrej Zary dixit: > > >Hello, why tomcat9 still does not have an init script despite it has > >been posted here? > > > >I'm upgrading a Stretch server without systemd to Buster. Tomcat 9 is > >installed but cannot be started without an init script. > > Mostly because Emmanuel insists on using systemd’s abstraction to > create the user account, despite a working, tested, alternative I > offered to maintain and be responsible for exists. > > The “sysvinit” branch contains a working version of the package > which I update from time to time. I’m also publishing builds of > that here: > > http://www.mirbsd.org/~tg/Debs/dists/bullseye/lts/Pkgs/tomcat9/ > > This is the “wtf-lts” repo on Wouter’s extrepodata. > > The package contains the init script, the user management logic > that actually works across *all* *supported* Debian configurations > instead of just an *arbitrary* subset of those, and some instructions > for nōn-systemd users in logging.properties (the default logging is > configured for systemd) and README.Debian (specifically noting that > some of the applied hardening is systemd-specific, but compared to > stretch/sysvinit you’re not worse off, security-wise, so…). > > I have no idea why Emmanuel, the primary maintainer, has been set > so strongly against merging this patch for as long as I promise to > take care of it and deal with any related fallout (maybe some systemd > fan paid him) but this is what is, and that GR outcome is interpreted > as Emmanuel being able to block this indefinitely despite nōn-systemd > continuing to be a supported way of running Debian (albeit not without > UsrMove in bookworm/sid). Thank you. I simply put your init script manually into /etc/init.d/ Also added /usr/libexec/sysv-getjre.sh and /usr/libexec/sysv-start.sh and changed formatter in logging.properties. Now Tomcat 9 works fine. Fortunately, Debian tomcat9 package does not depend on systemd-sysv. So systemd is installed but it does no harm as it's not running. -- Ondrej Zary
Bug#925473: tomcat9: sysvinit script missing
Markus Koschany dixit: >> (maybe some systemd >> fan paid him) > >^^^ >Such malicious allegations are not helpful. You should adjust your humour detector. >> but this is what is, and that GR outcome is interpreted >> as Emmanuel being able to block this indefinitely despite nōn-systemd >> continuing to be a supported way of running Debian (albeit not without >> UsrMove in bookworm/sid). > >The GR outcome was systemd but we support exploring alternatives, not we >support systemd and sysvinit in any case. It wasn’t we desupport sysvinit either. >Systemd is far superior when it comes […] That may very well be, but OUR PRIORITIES ARE OUR USERS AND FREE SOFTWARE (Debian SC), and if the user requires to run sysvinit but wishes to run tomcat as well, it is MASSIVELY outside of the scope of the tomcat main‐ tainers to force people to switch the entire way of how the system is set up, booted and administered! The security implications are documented in the branch. This is enough. We sell rope, after all. (Or perhaps more, ahem, politely: PHP is also still packaged in Debian, despite its security history which is also not a theoretical problem. Sorry for singling you out, PHP, but I needed an example.) bye, //mirabilos -- “ah that reminds me, thanks for the stellar entertainment that you and certain other people provide on the Debian mailing lists │ sole reason I subscribed to them (I'm not using Debian anywhere) is the entertainment factor │ Debian does not strike me as a place for good humour, much less German admin-style humour”
Bug#925473: tomcat9: sysvinit script missing
Am Dienstag, dem 21.09.2021 um 16:10 + schrieb Thorsten Glaser: [...] > I have no idea why Emmanuel, the primary maintainer, has been set > so strongly against merging this patch for as long as I promise to > take care of it and deal with any related fallout > (maybe some systemd > fan paid him) ^^^ Such malicious allegations are not helpful. > but this is what is, and that GR outcome is interpreted > as Emmanuel being able to block this indefinitely despite nōn-systemd > continuing to be a supported way of running Debian (albeit not without > UsrMove in bookworm/sid). The GR outcome was systemd but we support exploring alternatives, not we support systemd and sysvinit in any case. Systemd is far superior when it comes to security features like sandboxing and limiting access to the file system. This is not a theoretical problem. Tomcat has been affected by security vulnerabilities like remote code execution and read and write access to arbitrary files in the past. Just focusing on systemd makes it simpler for us to support Tomcat for its whole life cycle which is at least five years. These are the main reasons for not supporting sysvinit. signature.asc Description: This is a digitally signed message part
Bug#925473: tomcat9: sysvinit script missing
Ondrej Zary dixit: >Hello, why tomcat9 still does not have an init script despite it has >been posted here? > >I'm upgrading a Stretch server without systemd to Buster. Tomcat 9 is >installed but cannot be started without an init script. Mostly because Emmanuel insists on using systemd’s abstraction to create the user account, despite a working, tested, alternative I offered to maintain and be responsible for exists. The “sysvinit” branch contains a working version of the package which I update from time to time. I’m also publishing builds of that here: http://www.mirbsd.org/~tg/Debs/dists/bullseye/lts/Pkgs/tomcat9/ This is the “wtf-lts” repo on Wouter’s extrepodata. The package contains the init script, the user management logic that actually works across *all* *supported* Debian configurations instead of just an *arbitrary* subset of those, and some instructions for nōn-systemd users in logging.properties (the default logging is configured for systemd) and README.Debian (specifically noting that some of the applied hardening is systemd-specific, but compared to stretch/sysvinit you’re not worse off, security-wise, so…). I have no idea why Emmanuel, the primary maintainer, has been set so strongly against merging this patch for as long as I promise to take care of it and deal with any related fallout (maybe some systemd fan paid him) but this is what is, and that GR outcome is interpreted as Emmanuel being able to block this indefinitely despite nōn-systemd continuing to be a supported way of running Debian (albeit not without UsrMove in bookworm/sid). bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#925473: tomcat9: sysvinit script missing
Hi Ondrej, Installing systemd should fix this issue. Emmanuel Bourg Le 2021-09-21 12:23, Ondrej Zary a écrit : Hello, why tomcat9 still does not have an init script despite it has been posted here? I'm upgrading a Stretch server without systemd to Buster. Tomcat 9 is installed but cannot be started without an init script.
Bug#925473: tomcat9: sysvinit script missing
Hello, why tomcat9 still does not have an init script despite it has been posted here? I'm upgrading a Stretch server without systemd to Buster. Tomcat 9 is installed but cannot be started without an init script. -- Ondrej Zary
Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)
Hi Thorsten, The issue I reported that prevented systemd-sysusers from being used without systemd as the init system has just been fixed (#926316). So in theory we should be able to use it with other init systems. But the fact that elogind conflicts with systemd creates another hurdle. If the conflict can't be lifted I can see two solutions, either elogind provides its own version of systemd-sysusers, or systemd-sysusers is extracted into an independent package that doesn't conflict with elogind (I've filed #946456 for that). Emmanuel Bourg
Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)
Dixi quod… >branch and testing it; can we please merge it into master and upload >to unstable once it has been tested (should be no problem, I already FWIW, it builds and installs (as upgrade) and starts. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)
Version: 9.0.24-1 Emmanuel, > What is the issue with the dependency on systemd? I was under the there is new data related to that: In bullseye/sid, there’s elogind as desktop/logind alternative that implements the logind API but does not otherwise try to take over the system, allowing other inits (sysvinit, openrc, runit, …) to be used, and it does not carry systemd-sysusers either. More importantly, elogind Conflicts with systemd (both to ensure it is not confused for systemd or accidentally installed and because it implements only a subset necessary for the desktop stuff and network- manager, which I’ve seen people even use for servers nowadays). This makes it even more important that tomcat9 can be used without a dependency on the systemd binary package. I’m updating the sysvinit branch and testing it; can we please merge it into master and upload to unstable once it has been tested (should be no problem, I already tested it before, and the diff to 9.0.24-1 is minimal)? This would also allow buster-backports to be used without systemd, which is better than not at all. Thanks, //mirabilos -- 13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs 13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you 13:28⎜«neurodamage:#cvs» you're a handy guy to have around for systems stuff ☺ 16:06⎜ Thank god I found you =) 20:03│«bioe007:#cvs» mira2k: ty
Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)
On Sun, 7 Apr 2019, Ivo De Decker wrote: > Also, I'm not sure adding an init script now is an approriate change > for the freeze. It is, it only touches systems on which it previously did not work. > Some other changes suggested in this bug (like changes in systemd) > certainly are not. This was discussed for later. Emmanuel agreed that, if those changes were not implemented for buster, the suggested patch to restore user creation with adduser (trivial, fits into less than an ANSI screen page, easy to audit) can go into this for buster. > This bug should not be used as an argument to force these kind of > changes for buster. Indeed, and that was never my intention. I would like to respectfully ask that this *not* be buster-ignored, and to review the attached patch, which has been tested to indeed unbreak sysvinit (and fixed some bugs detected during that). Thanks in advance, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steegdiff -Nru tomcat9-9.0.16/debian/README.Debian tomcat9-9.0.16/debian/README.Debian --- tomcat9-9.0.16/debian/README.Debian 2019-02-05 10:11:13.0 +0100 +++ tomcat9-9.0.16/debian/README.Debian 2019-04-01 16:26:55.0 +0200 @@ -54,6 +54,13 @@ systemctl daemon-reload systemctl restart tomcat9 +⚠ This is supported only when Tomcat is started with the systemd unit. + +Using Tomcat with other init systems is supported, however that will +negate the security hardening detailed above, make Tomcat not have +its own temporary directory, not drop privileges/capabilities after +start, and not be restarted on crashing. Use at your own risk. + * To run more than one Tomcat instance on your server, install the package tomcat9-user and run the tomcat9-instance-create utility. You should remove the tomcat9 package if you don't want Tomcat to diff -Nru tomcat9-9.0.16/debian/changelog tomcat9-9.0.16/debian/changelog --- tomcat9-9.0.16/debian/changelog 2019-02-26 09:31:13.0 +0100 +++ tomcat9-9.0.16/debian/changelog 2019-04-02 22:54:17.0 +0200 @@ -1,3 +1,21 @@ +tomcat9 (9.0.16-4) unstable; urgency=medium + + * Team upload. + * debian/logging.properties: Add commented-out non-systemd configuration + * Make tomcat9 installable without systemd: +- Readd logic to create the system user via adduser +- Add sysvinit script, for init independence (Closes: #925473) + * debian/README.Debian: Document non-systemd risks + * debian/libexec/tomcat-locate-java.sh: Remove shebang and make +not executable as this is only ever sourced (makes no sense otherwise) + * Make the systemd startup script honour the (renamed) $SECURITY_MANAGER + * Remove -XX:+UseG1GC from standard JAVA_OPTS; the JRE chooses +a suitable GC automatically anyway (Closes: #925928) + * Correct the ownership and permissions on the log directory: +group adm and setgid (Closes: #925929) + + -- Thorsten Glaser Tue, 02 Apr 2019 22:54:17 +0200 + tomcat9 (9.0.16-3) unstable; urgency=medium * Removed read/write access to /var/lib/solr (Closes: #923299) diff -Nru tomcat9-9.0.16/debian/control tomcat9-9.0.16/debian/control --- tomcat9-9.0.16/debian/control 2019-02-05 10:53:30.0 +0100 +++ tomcat9-9.0.16/debian/control 2019-04-01 16:26:55.0 +0200 @@ -47,7 +47,7 @@ Architecture: all Depends: lsb-base (>= 3.0-6), - systemd (>= 215), + systemd (>= 215) | adduser, tomcat9-common (>= ${source:Version}), ucf, ${misc:Depends} diff -Nru tomcat9-9.0.16/debian/copyright tomcat9-9.0.16/debian/copyright --- tomcat9-9.0.16/debian/copyright 2019-02-05 10:11:13.0 +0100 +++ tomcat9-9.0.16/debian/copyright 2019-04-01 16:26:55.0 +0200 @@ -49,6 +49,7 @@ 2013-2014, Gianfranco Costamagna 2013-2018, Emmanuel Bourg 2001-2017, Markus Koschany + 2015–2019, mirabilos License: Apache-2.0 License: Apache-2.0 diff -Nru tomcat9-9.0.16/debian/default.template tomcat9-9.0.16/debian/default.template --- tomcat9-9.0.16/debian/default.template 2019-02-05 10:11:13.0 +0100 +++ tomcat9-9.0.16/debian/default.template 2019-04-01 17:15:52.0 +0200 @@ -3,9 +3,10 @@ # OpenJDK and the Oracle JDK are tried. #JAVA_HOME=/usr/lib/jvm/java-8-openjdk -# You may pass JVM startup parameters to Java here. If unset, the default -# options will be: -Djava.awt.headless=true -XX:+UseG1GC -JAVA_OPTS="-Djava.awt.headless=true -XX:+UseG1GC" +# You may pass JVM startup parameters to Java here. If you run Tomcat with +# Java 8 instead of 9 or newer, add "-XX:+UseG1GC" to select a suitable GC. +# If unset, the default options will be: -Djava.awt.headless=true +JAVA_OPTS="-Djava.awt.headless=true" # To enable remote debugging uncomment the
Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)
Control: tags -1 buster-ignore Hi, On Wed, Apr 03, 2019 at 02:33:47PM +0200, Thorsten Glaser wrote: > On Wed, 3 Apr 2019, Emmanuel Bourg wrote: > > > > I really insist on being able to install tomcat9 without having to > > > install a whole other init system, even if it is not used. > > > > See this as a compromise? > > I don’t know… the missing initscript is an RC bug, so the compromise > would start _after_ it’s added… I'm tagging this bug buster-ignore, because we're not going to delay buster for it. Also, I'm not sure adding an init script now is an approriate change for the freeze. Some other changes suggested in this bug (like changes in systemd) certainly are not. This bug should not be used as an argument to force these kind of changes for buster. Thanks, Ivo
Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)
On Wed, 3 Apr 2019, Emmanuel Bourg wrote: > > I really insist on being able to install tomcat9 without having to > > install a whole other init system, even if it is not used. > > See this as a compromise? I don’t know… the missing initscript is an RC bug, so the compromise would start _after_ it’s added… > > systemd-sysusers is a service… does that mean the service needs to > > run in order for it to be useful? If not now, then perhaps later? > > It's a oneshot service, the command is just fired once at boot time. > There is nothing running in the background. Ah, okay. I’m a bit concerned about the need for things like dbus, which aren’t otherwise required to be run on a server (at least with the headless JRE). > Extracting systemd-sysusers into a smaller package is probably a good > idea. However it means trading an overhead for the sysvinit users only > with a small overhead for everyone, not sure the systemd maintainers > will agree. True, we’ll see. Perhaps a split package for “tools from systemd that can also be used standalone under other init systems without needing to run all those dæmons” might make more sense than a package with only systemd-sysusers. The alternative, a package reimplementing systemd- sysusers as, say shell script, for sysvinit users, is probably even less sensible, but one I’d prefer over having to install the whole thing (also, the overhead is only for the package maintainers and ftpmasters and mirrors, not the users). > > But can we keep things working for buster, please? > > If #926316 isn't fixed I don't mind using adduser temporarily. You mention the libpam-systemd alternative part. There’s work being done implementing things with elogind, but given #925489 chances that this will be usable in buster are about 0. I’d prefer if we could upload this with adduser now, considering more changes as well as changes to other packages are almost not done right now due to the freeze situation (we *are* expecting buster within $smallnum weeks now). Thanks, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)
Le 03/04/2019 à 13:39, Thorsten Glaser a écrit : > I really insist on being able to install tomcat9 without having to > install a whole other init system, even if it is not used. See this as a compromise? > I’ve seen that > systemd-sysusers is a service… does that mean the service needs to > run in order for it to be useful? If not now, then perhaps later? It's a oneshot service, the command is just fired once at boot time. There is nothing running in the background. > If we weren’t this deep into the freeze, I’d offer to write a > systemd-less replacement that parses the same configuration files > and upload it separately. Or maybe, if systemd-sysusers really has > no dependency on anything else except libsystemd0, it could become > split off into another package. Extracting systemd-sysusers into a smaller package is probably a good idea. However it means trading an overhead for the sysvinit users only with a small overhead for everyone, not sure the systemd maintainers will agree. > But can we keep things working for buster, please? If #926316 isn't fixed I don't mind using adduser temporarily. Emmanuel Bourg
Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)
On Wed, 3 Apr 2019, Emmanuel Bourg wrote: > Assuming #926316 gets fixed, I think we should focus only on providing a > usable sysvinit script as required by the policy. Supporting people I really insist on being able to install tomcat9 without having to install a whole other init system, even if it is not used. > Regarding the weight, at this point you've already installed the JRE and > Tomcat, the few extra MB for systemd are negligible. It’s also about attack surface, or other tools that assume something (such as systemd being actually run when installed). I’ve seen that systemd-sysusers is a service… does that mean the service needs to run in order for it to be useful? If not now, then perhaps later? > There is a growing consensus around the idea that imperative maintainer > scripts are a bad thing and they should be replaced with something > declarative. systemd-sysusers does exactly that for the user creation, Not all of them, but I can see this for some cases. On the other hand, user creation with adduser is *really* light. If we weren’t this deep into the freeze, I’d offer to write a systemd-less replacement that parses the same configuration files and upload it separately. Or maybe, if systemd-sysusers really has no dependency on anything else except libsystemd0, it could become split off into another package. But can we keep things working for buster, please? Thanks, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)
Le 02/04/2019 à 23:01, Thorsten Glaser a écrit : > Most people using Debian without systemd have APT pinning or other > measures in place that prevent the systemd package, which ships the > systemd-sysusers binary (and service?), from being installed, in > order to not sneakily being converted to systemd (it did happen). I did some tests in a VM with a minimal install where I switched to sysvinit with: apt install sysvinit-core cp /usr/share/sysvinit/inittab /etc/inittab reboot apt remove systemd In Stretch I can install the systemd package and it won't switch the init system as advertised. In Buster unfortunately installing systemd pulls systemd-sysv through libpam-systemd and the init system is switched. The --no-install-recommends flag has to be used to avoid that. I've filed a bug for systemd (#926316). Assuming #926316 gets fixed, I think we should focus only on providing a usable sysvinit script as required by the policy. Supporting people allergic to systemd and using APT pinning to exclude it is out of topic (they should only exclude systemd-sysv anyway, not systemd). > What is the issue with using adduser, which is the standard Debian > tool doing the same job, instead? After all, depending on systemd > just to create a system user and group is very heavy-weight. There is a growing consensus around the idea that imperative maintainer scripts are a bad thing and they should be replaced with something declarative. systemd-sysusers does exactly that for the user creation, that's why I favored it over the traditional adduser. Regarding the weight, at this point you've already installed the JRE and Tomcat, the few extra MB for systemd are negligible. > OK, removed. > > > OK, reverted. Thank you > Did you have a chance to test this on a buster/systemd Debian? > I don’t currently have such a machine existing in a meaningful > way. (Granted, I could probably cobble together some test VM, > but I’m sure you have something at hand.) I haven't checked yet. Emmanuel Bourg
Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)
Hi Emmanuel, >What is the issue with the dependency on systemd? Most people using Debian without systemd have APT pinning or other measures in place that prevent the systemd package, which ships the systemd-sysusers binary (and service?), from being installed, in order to not sneakily being converted to systemd (it did happen). I only know of the elogind case (which most likely will only be available in bullseye) as one where non-systemd init but systemd binaries will be used. What is the issue with using adduser, which is the standard Debian tool doing the same job, instead? After all, depending on systemd just to create a system user and group is very heavy-weight. >> diff --git a/debian/tomcat9.postinst b/debian/tomcat9.postinst >> index 55fb55c2..8edcfc5c 100644 >> --- a/debian/tomcat9.postinst >> +++ b/debian/tomcat9.postinst >> @@ -5,6 +5,7 @@ >> >> set -e >> >> +# Note these are no longer configurable (as of commit >> 243d00dc688ea47f4c7cde570ccaaa70efe269bf) >> TOMCAT_USER="tomcat" >> TOMCAT_GROUP="tomcat" > >The comment doesn't add much value. The non configurable user/group is >already documented in the changelog. OK, removed. >If systemd-sysusers can't be used directly I prefer an inline code to an >external file. OK, reverted. (I kept the check whether the user exists as first check, though; there’s no need to try to create it over and over on every upgrade on systemd systems either, and since its presence is needed for the non-systemd case, it can be made use of in the systemd case, too.) Did you have a chance to test this on a buster/systemd Debian? I don’t currently have such a machine existing in a meaningful way. (Granted, I could probably cobble together some test VM, but I’m sure you have something at hand.) I tried one with sysvinit, but it turns out that the software does not yet work under Tomcat 9, so I had to revert the VM to Tomcat 8; it did start and write logs with sensible ownership and permission, though. Thanks, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)
Hi Thorsten, Le 02/04/2019 à 16:54, Thorsten Glaser a écrit : > due to your objection against perceived complexity, I changed the way > I’ve implemented this. Doing this at all is required because the hard > “Depends: systemd” will not work on many non-systemd systems What is the issue with the dependency on systemd? I was under the impression systemd-sysusers could be used even on systems using sysvinit as the init system. I understand it won't work on Debian derivatives that vowed to burn any systemd related code, but that's not the matter here. > diff --git a/debian/tomcat9.postinst b/debian/tomcat9.postinst > index 55fb55c2..8edcfc5c 100644 > --- a/debian/tomcat9.postinst > +++ b/debian/tomcat9.postinst > @@ -5,6 +5,7 @@ > > set -e > > +# Note these are no longer configurable (as of commit > 243d00dc688ea47f4c7cde570ccaaa70efe269bf) > TOMCAT_USER="tomcat" > TOMCAT_GROUP="tomcat" The comment doesn't add much value. The non configurable user/group is already documented in the changelog. > > @@ -12,8 +13,8 @@ CONFFILES="tomcat-users.xml web.xml server.xml > logging.properties context.xml ca > > case "$1" in > configure) > - # Create the tomcat user as defined in /usr/lib/sysusers.d/tomcat9.conf > - systemd-sysusers > + # Create the tomcat user > + /usr/libexec/tomcat9/create-sysuser.sh If systemd-sysusers can't be used directly I prefer an inline code to an external file. Emmanuel Bourg
Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)
Hi Emmanuel, > This restores the ability to create the tomcat user without systemd. due to your objection against perceived complexity, I changed the way I’ve implemented this. Doing this at all is required because the hard “Depends: systemd” will not work on many non-systemd systems, and, as it’s only used for a tool to add a user account, is overly harsh. This now reads as follows: • The change to debian/control stays the same • The lintian override is no longer necessary • The postinst diff goes down to: diff --git a/debian/tomcat9.postinst b/debian/tomcat9.postinst index 55fb55c2..8edcfc5c 100644 --- a/debian/tomcat9.postinst +++ b/debian/tomcat9.postinst @@ -5,6 +5,7 @@ set -e +# Note these are no longer configurable (as of commit 243d00dc688ea47f4c7cde570ccaaa70efe269bf) TOMCAT_USER="tomcat" TOMCAT_GROUP="tomcat" @@ -12,8 +13,8 @@ CONFFILES="tomcat-users.xml web.xml server.xml logging.properties context.xml ca case "$1" in configure) - # Create the tomcat user as defined in /usr/lib/sysusers.d/tomcat9.conf - systemd-sysusers + # Create the tomcat user + /usr/libexec/tomcat9/create-sysuser.sh # Install the configuration files for conffile in $CONFFILES; • There is a new file, which I’ll gladly maintain as part of the init script effort, with an appropriate entry in debian/tomcat9.install: diff --git a/debian/libexec/create-sysuser.sh b/debian/libexec/create-sysuser.sh new file mode 100755 index ..3fd6dcd5 --- /dev/null +++ b/debian/libexec/create-sysuser.sh @@ -0,0 +1,22 @@ +#!/bin/sh +# +# Create the tomcat system user +# + +set -e + +if id tomcat >/dev/null 2>&1; then + # The user already exists + exit 0 +fi + +if which systemd-sysusers >/dev/null; then + # Use /usr/lib/sysusers.d/tomcat9.conf and systemd + systemd-sysusers +else + # Use adduser instead, takes care of user and group both + adduser --system --home /var/lib/tomcat9 \ + --shell /usr/sbin/nologin --no-create-home \ + --group --disabled-password --disabled-login \ + --gecos 'Apache Tomcat' tomcat +fi Do note that this is already much less complexity than it was in tomcat8, because we don’t even call addgroup but let adduser handle this part of the account creation. (I’ve also moved the check for prior existence up; no sense in calling tools if not necessary.) bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)
Hi Emmanuel, > > When it's ready please let me review the update before uploading. > > OK. Here we are, now. I’m posting the entire diff, but with comments in between. This is exactly what’s on git master right now. I’d like to merge the fixes for #925928 and #925929 and upload once you have reviewed this. diff --git a/debian/libexec/tomcat-locate-java.sh b/debian/libexec/tomcat-locate-java.sh old mode 100755 new mode 100644 index 341f9b15..b6dbb01e --- a/debian/libexec/tomcat-locate-java.sh +++ b/debian/libexec/tomcat-locate-java.sh @@ -1,4 +1,3 @@ -#!/bin/sh # # Script looking for a Java runtime suitable for running Tomcat # This script is only ever sourced, not executed, so it ought to not have a shebang and not be executable. (As it merely sets a variable, executing it makes no sense anyway.) diff --git a/debian/libexec/tomcat-start.sh b/debian/libexec/tomcat-start.sh index 31aaecf8..f22a3422 100755 --- a/debian/libexec/tomcat-start.sh +++ b/debian/libexec/tomcat-start.sh @@ -15,7 +15,7 @@ export JAVA_OPTS # Enable the Java security manager? SECURITY="" -[ "$TOMCAT_SECURITY" = "yes" ] && SECURITY="-security" +[ "$SECURITY_MANAGER" = "true" ] && SECURITY="-security" # Start Tomcat This unbreaks using the SECURITY_MANAGER parameter, which TOMCAT_SECURITY was renamed to (also yes/no → true/not true). It’s an unrelated fix discovered in the meantime. diff --git a/debian/README.Debian b/debian/README.Debian index d11fb47b..c005bb0b 100644 --- a/debian/README.Debian +++ b/debian/README.Debian @@ -54,6 +54,13 @@ Getting started systemctl daemon-reload systemctl restart tomcat9 +⚠ This is supported only when Tomcat is started with the systemd unit. + +Using Tomcat with other init systems is supported, however that will +negate the security hardening detailed above, make Tomcat not have +its own temporary directory, not drop privileges/capabilities after +start, and not be restarted on crashing. Use at your own risk. + * To run more than one Tomcat instance on your server, install the package tomcat9-user and run the tomcat9-instance-create utility. You should remove the tomcat9 package if you don't want Tomcat to diff --git a/debian/logging.properties b/debian/logging.properties index 37fa30d1..69ac42f0 100644 --- a/debian/logging.properties +++ b/debian/logging.properties @@ -33,7 +33,9 @@ handlers = 1catalina.org.apache.juli.AsyncFileHandler, 2localhost.org.apache.jul 2localhost.org.apache.juli.AsyncFileHandler.maxDays = 90 java.util.logging.ConsoleHandler.level = FINE +# use one of these depending on whether you use systemd or not, or roll your own java.util.logging.ConsoleHandler.formatter = org.apache.juli.SystemdFormatter +#java.util.logging.ConsoleHandler.formatter = org.apache.juli.OneLineFormatter These update some comments for non-systemd users and warn them off. diff --git a/debian/control b/debian/control index 41ab0f8f..a1652a93 100644 --- a/debian/control +++ b/debian/control @@ -47,7 +47,7 @@ Package: tomcat9 Architecture: all Depends: lsb-base (>= 3.0-6), - systemd (>= 215), + systemd (>= 215) | adduser, tomcat9-common (>= ${source:Version}), ucf, ${misc:Depends} diff --git a/debian/tomcat9.lintian-overrides b/debian/tomcat9.lintian-overrides new file mode 100644 index ..9b0d6593 --- /dev/null +++ b/debian/tomcat9.lintian-overrides @@ -0,0 +1,2 @@ +# handled in dependencies and maintainer script as alternative +tomcat9: maintainer-script-needs-depends-on-adduser postinst diff --git a/debian/tomcat9.postinst b/debian/tomcat9.postinst index 55fb55c2..7cd34950 100644 --- a/debian/tomcat9.postinst +++ b/debian/tomcat9.postinst @@ -5,6 +5,7 @@ set -e +# Note these are no longer configurable (as of commit 243d00dc688ea47f4c7cde570ccaaa70efe269bf) TOMCAT_USER="tomcat" TOMCAT_GROUP="tomcat" @@ -12,8 +13,18 @@ CONFFILES="tomcat-users.xml web.xml server.xml logging.properties context.xml ca case "$1" in configure) - # Create the tomcat user as defined in /usr/lib/sysusers.d/tomcat9.conf - systemd-sysusers + if which systemd-sysusers >/dev/null; then + # Create the tomcat user as defined in /usr/lib/sysusers.d/tomcat9.conf + systemd-sysusers + elif id tomcat >/dev/null 2>&1; then + : The tomcat user already exists + else + # Create the tomcat user without systemd + adduser --system --home /var/lib/tomcat9 \ + --shell /usr/sbin/nologin --no-create-home \ + --group --disabled-password --disabled-login \ + --gecos 'Apache Tomcat' tomcat + fi # Install the configuration files for conffile in $CONFFILES; This restores the ability to create the tomcat user without systemd. diff --git a/debian/libexec/sysv-getjre.sh b/debian/libexec/sysv-getjre.sh new