Hi,

Please remove the tomcat8 package from testing and unstable (not experimental).
This package has been replaced by tomcat9 for Buster.

Thank you,

Emmanuel Bourg

Please don’t, tomcat9 has no sysvinit script, and you did
not like any of my suggestions for it.

bye,
//mirabilos

Please don’t, tomcat9 has no sysvinit script, and you did
not like any of my suggestions for it.

bye,
//mirabilos

Le 25/03/2019 à 14:22, Bastian Blank a écrit :

I'd like to keep building up to date tomcat8 packages until Buster is
released with tomcat9.

Emmanuel Bourg

Why not experimental?

Regards,
Bastian

Hi Thorsten,

Le 25/03/2019 à 14:17, Thorsten Glaser a écrit :

I don't mind if tomcat8 is released with Buster, but I won't be able to
commit any time on the security fixes. Do you volunteer? The security
team might want to have a say too.

Emmanuel Bourg

We don't keep duplicate/old source packages in the archive.

If keeping it in experimental is useful for anyone, that's fine (we also
do that for openjdk-X to stage updates in stable/oldstable), but let's remove
it from unstable/testing in any case.

Cheers,
        Moritz

I’d prefer if we could amend the tomcat9 package with a sysvinit
script. (Although we currently don’t have most inhouse software
tested with Tomcat 9, that can be done.) On the other hand, by
now, also the SRM need to agree to that upload.

I’d very happily maintain the init script.


If this is not possible, I’d agree to upload fixes for tomcat8,
if I get a hold of them. I see upstream has not published an
EOL date for 8.5, and the antecessor Tomcat 7 is still supported,
so this might be feasible. I have no problem doing this in the
experimental distribution. I would, however, appreciate a ping
whenever there’s something, as I have no means to know when
something relevant were to pop up.


But somehow, I think the “let’s add a sensible init script to
tomcat9 now” is the better solution for everyone. Emmanuel, can
you please reconsider your rejection? Then we can ask SRM if
they’d allow it.

To recall the justification I posted to the list that were,
IIRC, never replied:

I will happily maintain the init script. If there’s something,
ping me. I know shell scripting very well. And even if I don’t
respond for weeks on end (unlikely) you can still remove it if
it’s RC-buggy, but I’d prefer keeping it in.

(The only sad thing is that I had ideas of creating a better
init script concept, and that was not done obviously.)

bye,
//mirabilos

Isn't one required by policy 9.11 (must is in the second paragraph of the main
part).

Scott K

clone 925454 -1
reassign -1 tomcat9
found -1 9.0.16-3
retitle -1 tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)
severity -1 serious
tags -1 = confirmed
outlook -1 working on it within the week --mirabilos
owner -1 tg@mirbsd.de
thanks

Oh, goodie. I had not realised this is, as the init system diversity GR
did not pass, still a “must”.

In this case it’s easy… I’m cloning this as RC bug against tomcat9 and
will work within the next couple of days on fixing this by providing a
proper init script, as team upload / RC squash.

Then I’ll withdraw my objection against tomcat8 removal fully.

Thanks,
//mirabilos

Le 25/03/2019 à 16:09, Thorsten Glaser a écrit :

We've got two serious security issues in the Tomcat init script in the
past. I'm not a big fan of systemd but this convinced me that a 40 lines
declarative service file was much more maintainable than a 300 lines
init script, and I'm unlikely to maintain one anymore.

systemd brought other important benefits for the tomcat9 package and I
don't want to go back on these features.

I made the suggestion to package the init script in a separate package
under your control, but you didn't follow up.

Emmanuel Bourg

Le 25/03/2019 à 16:33, Thorsten Glaser a écrit :

When it's ready please let me review the update before uploading. Not
changing the maintainer scripts nor the configuration files in the
process would be nice.

Emmanuel Bourg

You told me this. I replied by:

• I’m active and willing to maintain it
• if I don’t realise there’s a bug you can ping me
• if even that fails, you can *still* remove it

You never replied to these.

Perhaps, but thankfully Policy prescribes the existence of one.
I’ll provide one and team-upload. You need not personally maintain it,
just don’t break it. That’s what a team is for.

You don’t need to. The sysvinit script is not optional, but
systemd users need not use it.

We already realised (in that thread on d-java) that they will
most likely behave slightly differently, but that’s okay. (It
can be documented.)

I’ve replied saying that such tiny packages aren’t liked by
ftpmasters and mirror admins.

Anyway, Policy solved the issue for us, the initscript will
be in the main tomcat9 package where it belongs. (Do note that
the option of removing it (from above) is no longer pertinent,
as one is required if a startup script for another init system
is present. However, I’ll do my best, and even if that fails,
I know at least one other DD at my employer’s who’s capable
enough to maintain complex shell scripts and fixing RC bugs.)

bye,
//mirabilos

OK.

I agree; at the current point in time, this should be least-intrusive.

bye,
//mirabilos

Hi Emmanuel,

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 00000000..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 file mode 100755
index 00000000..456bdf64
--- /dev/null
+++ b/debian/libexec/sysv-getjre.sh
@@ -0,0 +1,15 @@
+#!/bin/sh
+#
+# SYSVinit script helper to determine the JRE (for start-stop-daemon)
+#
+
+. /usr/libexec/tomcat9/tomcat-locate-java.sh
+set +e
+
+. /usr/share/tomcat9/bin/setclasspath.sh
+
+if test -n "$_RUNJAVA"; then
+	printf "OK<%s>" "$_RUNJAVA"
+else
+	echo UNSET
+fi
diff --git a/debian/libexec/sysv-start.sh b/debian/libexec/sysv-start.sh
new file mode 100755
index 00000000..ac8c46e0
--- /dev/null
+++ b/debian/libexec/sysv-start.sh
@@ -0,0 +1,33 @@
+#!/bin/sh
+#
+# SYSVinit script helper to wrap the systemd startup script
+#
+
+set -e
+
+# redirect stdio
+exec </dev/null
+exec >>/var/log/tomcat9/catalina.out
+exec 2>&1
+# write an initial log entry
+echo "[$(date +'%FT%T%z')] starting..."
+
+# make sure Tomcat is started with system locale
+
+# restore LC_ALL that was (un)set at initscript startup
+case $saved_LC_ALL in
+(x*)	LC_ALL=${saved_LC_ALL#x} ;;
+(*)	unset LC_ALL ;;
+esac
+# read global locale configuration
+test -r /etc/default/locale && . /etc/default/locale
+# export all POSIX locale-relevant environment variables if set
+for v in LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY \
+    LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE \
+    LC_MEASUREMENT LC_IDENTIFICATION LC_ALL; do
+	eval "x=\${$v-x}"
+	test x"$x" = x"x" || eval export "$v"
+done
+
+# hand control to the systemd startup script we wrap
+exec /usr/libexec/tomcat9/tomcat-start.sh "$@"
diff --git a/debian/tomcat9.init b/debian/tomcat9.init
new file mode 100644
index 00000000..e948c173
--- /dev/null
+++ b/debian/tomcat9.init
@@ -0,0 +1,163 @@
+#!/bin/sh
+### BEGIN INIT INFO
+# Provides:          tomcat9
+# Required-Start:    $local_fs $remote_fs $network
+# Required-Stop:     $local_fs $remote_fs $network
+# Default-Start:     2 3 4 5
+# Default-Stop:      0 1 6
+# Short-Description: Tomcat 9
+# Description:       The Tomcat 9 servlet engine runs Java Web Archives.
+### END INIT INFO
+
+# stuff away, used later
+saved_LC_ALL=${LC_ALL+x$LC_ALL}
+export saved_LC_ALL
+
+# absolute basics
+LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin
+export LC_ALL PATH
+unset LANGUAGE
+
+# exit cleanly if disabled or not installed
+test -x /usr/libexec/tomcat9/sysv-start.sh || exit 0
+test -x /usr/libexec/tomcat9/sysv-getjre.sh || exit 0
+test -x /usr/libexec/tomcat9/tomcat-update-policy.sh || exit 0
+test -x /usr/libexec/tomcat9/tomcat-start.sh || exit 0
+
+# Debian/LSB init script foobar
+DESC='Tomcat 9 servlet engine'
+NAME=tomcat9
+readonly DESC NAME
+. /lib/init/vars.sh
+test -t 0 && VERBOSE=yes
+. /lib/lsb/init-functions
+
+# somewhat LSB-compliant exit with failure
+if test x"$1" = x"status"; then
+	exit_failure_msg() {
+		log_failure_msg "$@"
+		exit 4
+	}
+else
+	exit_failure_msg() {
+		log_failure_msg "$@"
+		exit 1
+	}
+fi
+
+# set defaults for options
+CATALINA_HOME=/usr/share/tomcat9
+CATALINA_BASE=/var/lib/tomcat9
+CATALINA_TMPDIR=/tmp/tomcat9-tmp
+export CATALINA_HOME CATALINA_BASE CATALINA_TMPDIR
+JAVA_HOME= # determined later if empty
+JAVA_OPTS=-Djava.awt.headless=true
+JSP_COMPILER= # only used if nonempty
+SECURITY_MANAGER=false
+export JAVA_HOME JAVA_OPTS JSP_COMPILER SECURITY_MANAGER
+UMASK=022
+export UMASK
+# read options
+test -r /etc/default/tomcat9 && . /etc/default/tomcat9
+
+# ensure the temporary directory exist and change to it
+rm -rf "$CATALINA_TMPDIR"
+mkdir "$CATALINA_TMPDIR" || \
+    exit_failure_msg 'could not create JVM temporary directory'
+chown -h tomcat "$CATALINA_TMPDIR"
+cd "$CATALINA_TMPDIR"
+
+# figure out the JRE executable catalina.sh will use
+# (we need it for start-stop-daemon --exec for reliability)
+_RUNJAVA=$(su tomcat -s /bin/sh -c /usr/libexec/tomcat9/sysv-getjre.sh) || \
+    _RUNJAVA="FAIL:$?"
+case $_RUNJAVA in
+('OK<'*'>')
+	_RUNJAVA=${_RUNJAVA#'OK<'}
+	_RUNJAVA=${_RUNJAVA%'>'}
+	;;
+(*)
+	exit_failure_msg "could not determine JRE: $_RUNJAVA"
+	;;
+esac
+
+# prepare for actions
+case $1 in
+(start|stop|restart|force-reload)
+	# handled below
+	;;
+(try-restart|status)
+	start-stop-daemon --status --quiet \
+	    --pidfile /var/run/tomcat9.pid \
+	    --exec "$_RUNJAVA" --user tomcat
+	rv=$?
+	# clean up stale pidfile if necessary
+	(test x"$rv" = x"1" && rm -f /var/run/tomcat9.pid || :)
+	# process status result
+	case $1 in
+	(try-restart)
+		test x"$rv" = x"0" || {
+			# service is not running, or status is unknown
+			log_success_msg "$NAME is not running"
+			exit 0
+		}
+		# service running, restart it
+		;;
+	(status)
+		case $rv in
+		(0)
+			log_success_msg "$NAME is running"
+			;;
+		(4)
+			log_failure_msg "could not access PID file for $NAME"
+			;;
+		(*)
+			log_failure_msg "$NAME is not running"
+			;;
+		esac
+		exit $rv
+		;;
+	esac
+	;;
+(reload|*)
+	# not supported
+	echo >&2 "Usage: $0 {start|stop|restart|try-restart|force-reload|status}"
+	exit 3
+	;;
+esac
+
+# handle stopping/starting
+rv=0
+
+case $1 in
+(stop|restart|try-restart|force-reload)
+	test x"$VERBOSE" = x"no" || log_daemon_msg "Stopping $DESC"
+	start-stop-daemon --stop --quiet \
+	    --retry=10 --oknodo --remove-pidfile \
+	    --pidfile /var/run/tomcat9.pid \
+	    --exec "$_RUNJAVA" --user tomcat
+	rv=$?
+	test x"$VERBOSE" = x"no" || log_end_msg $rv
+	;;
+esac
+
+test x"$rv" = x"0" || exit $rv
+
+case $1 in
+(start|restart|try-restart|force-reload)
+	/usr/libexec/tomcat9/tomcat-update-policy.sh || \
+	    exit_failure_msg 'could not regenerating catalina.policy file'
+	rm -f /var/run/tomcat9.pid
+	test x"$VERBOSE" = x"no" || log_daemon_msg "Starting $DESC"
+	start-stop-daemon --start --quiet \
+	    --chuid tomcat --umask "$UMASK" \
+	    --startas /usr/libexec/tomcat9/sysv-start.sh \
+	    --background --make-pidfile \
+	    --pidfile /var/run/tomcat9.pid \
+	    --exec "$_RUNJAVA" --user tomcat
+	rv=$?
+	test x"$VERBOSE" = x"no" || log_end_msg $rv
+	;;
+esac
+
+exit $rv
diff --git a/debian/tomcat9.install b/debian/tomcat9.install
index f9fa6756..1daa7147 100644
--- a/debian/tomcat9.install
+++ b/debian/tomcat9.install
@@ -8,5 +8,6 @@ debian/default.template    /usr/share/tomcat9/
 debian/logrotate.template  /usr/share/tomcat9/
 debian/sysusers/*.conf     /usr/lib/sysusers.d/

+debian/libexec/sysv-*                  /usr/libexec/tomcat9/
 debian/libexec/tomcat-start.sh         /usr/libexec/tomcat9/
 debian/libexec/tomcat-update-policy.sh /usr/libexec/tomcat9/

This is the initscript itself and two helper scripts.
I managed to make the sysvinit scripts just call the systemd scripts,
so there is no duplication except where necessary (e.g. the sysvinit
script creates the temporary directory manually).

diff --git a/debian/copyright b/debian/copyright
index eace6038..8d605065 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -49,6 +49,7 @@ Copyright: 2008,2011, Canonical Ltd.
            2013-2014, Gianfranco Costamagna <costamagnagianfranco@yahoo.it>
            2013-2018, Emmanuel Bourg <ebourg@apache.org>
            2001-2017, Markus Koschany <apo@debian.org>
+           2015–2019, mirabilos <t.glaser@tarent.de>
 License: Apache-2.0

 License: Apache-2.0
diff --git a/debian/changelog b/debian/changelog
index 9e1dab71..163eb8d9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+tomcat9 (9.0.16-4) UNRELEASED; 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
+
+ -- Thorsten Glaser <tg@mirbsd.de>  Mon, 01 Apr 2019 15:42:02 +0200
+
 tomcat9 (9.0.16-3) unstable; urgency=medium

   * Removed read/write access to /var/lib/solr (Closes: #923299)

Metadata update.

bye,
//mirabilos

Hi Emmanuel,

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 00000000..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

Hi Thorsten,

Le 02/04/2019 à 16:54, Thorsten Glaser a écrit :

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.

The comment doesn't add much value. The non configurable user/group is
already documented in the changelog.

If systemd-sysusers can't be used directly I prefer an inline code to an
external file.

Emmanuel Bourg

Hi Emmanuel,

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.

OK, removed.

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

Le 02/04/2019 à 23:01, Thorsten Glaser a écrit :

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).

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.

Thank you

I haven't checked yet.

Emmanuel Bourg

I really insist on being able to install tomcat9 without having to
install a whole other init system, even if it is not used.

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?

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

Le 03/04/2019 à 13:39, Thorsten Glaser a écrit :

See this as a compromise?

It's a oneshot service, the command is just fired once at boot time.
There is nothing running in the background.

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.

If #926316 isn't fixed I don't mind using adduser temporarily.

Emmanuel Bourg

I don’t know… the missing initscript is an RC bug, so the compromise
would start _after_ it’s added…

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).

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).

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

Hi,

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

It is, it only touches systems on which it previously did not work.

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.

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

We believe that the bug you reported is fixed in the latest version of
tomcat9, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 925473@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Thorsten Glaser <tg@mirbsd.de> (supplier of updated tomcat9 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 21 Jun 2019 18:38:08 +0200
Source: tomcat9
Binary: libtomcat9-embed-java libtomcat9-java tomcat9 tomcat9-admin tomcat9-common tomcat9-docs tomcat9-examples tomcat9-user
Architecture: source all
Version: 9.0.16-5
Distribution: experimental
Urgency: low
Maintainer: Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
Changed-By: Thorsten Glaser <tg@mirbsd.de>
Description:
 libtomcat9-embed-java - Apache Tomcat 9 - Servlet and JSP engine -- embed libraries
 libtomcat9-java - Apache Tomcat 9 - Servlet and JSP engine -- core libraries
 tomcat9    - Apache Tomcat 9 - Servlet and JSP engine
 tomcat9-admin - Apache Tomcat 9 - Servlet and JSP engine -- admin web application
 tomcat9-common - Apache Tomcat 9 - Servlet and JSP engine -- common files
 tomcat9-docs - Apache Tomcat 9 - Servlet and JSP engine -- documentation
 tomcat9-examples - Apache Tomcat 9 - Servlet and JSP engine -- example web applicati
 tomcat9-user - Apache Tomcat 9 - Servlet and JSP engine -- tools to create user
Closes: 925473
Changes:
 tomcat9 (9.0.16-5) experimental; urgency=low
 .
   * Team upload.
   * Upload to experimental to get wider testing and availability
   * 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
   * Do not read /etc/default/tomcat9 twice
Checksums-Sha1:
 dbd83f968f5c2d61e997d0adb155381de5d4a00f 2746 tomcat9_9.0.16-5.dsc
 4601d3bdfe2fa8133637c4169f3f9b3c879a14de 35492 tomcat9_9.0.16-5.debian.tar.xz
 41fdfa2e9691f1db919b0ea235c674250dd2a01c 4046696 libtomcat9-embed-java_9.0.16-5_all.deb
 dd380c7ae60bfd8dece908d2d150222833bf4dfb 5753904 libtomcat9-java_9.0.16-5_all.deb
 114c0443a438bbf7d36af3d6c97eba11dce87a55 33064 tomcat9-admin_9.0.16-5_all.deb
 589ae66f80db4ec6dc6399a776c946b6f2123c44 68360 tomcat9-common_9.0.16-5_all.deb
 8c731ae9b9954679da3b2b2d3d29e5a7784e1822 681880 tomcat9-docs_9.0.16-5_all.deb
 7b2f703466d37473f745b8dbb8b4f684d33f8d09 394696 tomcat9-examples_9.0.16-5_all.deb
 b42bb18d3469a2abded2326e1bc050f0b3e2c65f 40976 tomcat9-user_9.0.16-5_all.deb
 e313a764842d09fba8e3694ba7e602a9784acabe 46892 tomcat9_9.0.16-5_all.deb
 84888528feeb654ff8fcbbe645ba8f906768852d 13165 tomcat9_9.0.16-5_amd64.buildinfo
Checksums-Sha256:
 e035b0f26bcbab3d42dccf45b25d893ad0db63e31d6322f9984bb48a2009d1d9 2746 tomcat9_9.0.16-5.dsc
 91a34574d4ea9acc40f41b30e45fb23151e22f1bf663d566b7a97cca28eda072 35492 tomcat9_9.0.16-5.debian.tar.xz
 310b8a6d6f2e6e5e06a2f81f325439e2eb2ff937f1877b48c085b8bb57f3b65e 4046696 libtomcat9-embed-java_9.0.16-5_all.deb
 97d55918dd8170bc49ef74baaf789b3cce085aecbd2be3e391dea52052c6afe9 5753904 libtomcat9-java_9.0.16-5_all.deb
 2f3b97535a1250d5828f65459db08f660a896758c55c665c387a39dca9c1d3f3 33064 tomcat9-admin_9.0.16-5_all.deb
 5c087ce2a362f84d27a88b98143ccde1f686782f52b4c8c6cdd70160f5e24409 68360 tomcat9-common_9.0.16-5_all.deb
 1172cc199ddaf964aced678c33bdc4eca69924b7e8f885622f5a8eefce9abd3c 681880 tomcat9-docs_9.0.16-5_all.deb
 c593005e65c682bfa68abee81341bb7ff0d24709dbe9efd243ac23e09af6b4d3 394696 tomcat9-examples_9.0.16-5_all.deb
 a72d358f1a42de25746753d5c07e7dbe02993af7b6ac9ab2df8c22874c8c0c14 40976 tomcat9-user_9.0.16-5_all.deb
 f746a3a8c7e2197715f8168dde014987787e940d4b607ff824ca77ac485aab91 46892 tomcat9_9.0.16-5_all.deb
 6f09a3e9a80df4da6c99587b8607ad61e1a1aa07dc0a2a5698070920598c6c7f 13165 tomcat9_9.0.16-5_amd64.buildinfo
Files:
 7826bc6a91e2c6109ec4bb3c0f1bf390 2746 java optional tomcat9_9.0.16-5.dsc
 144b9418f3416d63c7554650251f6fe2 35492 java optional tomcat9_9.0.16-5.debian.tar.xz
 9be36fae7aee39eb4ae2d8950c9903b3 4046696 java optional libtomcat9-embed-java_9.0.16-5_all.deb
 e4b9fa9fc7fb0281b47dcf013f2fca3b 5753904 java optional libtomcat9-java_9.0.16-5_all.deb
 be23da8b3e3e09891491a044eff27f79 33064 java optional tomcat9-admin_9.0.16-5_all.deb
 b26b299dda0e065386dafe65839e492e 68360 java optional tomcat9-common_9.0.16-5_all.deb
 d61f1c906c45df870fe496171b03554b 681880 doc optional tomcat9-docs_9.0.16-5_all.deb
 4cf0187cb3137b2346781bc56963fd94 394696 java optional tomcat9-examples_9.0.16-5_all.deb
 d01194615c8831a85f3abec6509ed343 40976 java optional tomcat9-user_9.0.16-5_all.deb
 b96f78cd01a6ed708dfeee6cc7d4470c 46892 java optional tomcat9_9.0.16-5_all.deb
 d1266ff6886c0b702626038589c3a0d5 13165 java optional tomcat9_9.0.16-5_amd64.buildinfo
iQIcBAEBCQAGBQJdDSOEAAoJEHa1NLLpkAfgHLgP/AuyioIrap5oQLPA9MmiE5aH
o+MdnaDX9AvX18/Ty6S/Xr8HUlYoBlZklMR/CVlA/pDzDzzoTIl+MI/ftxYZvKzF
uj1u1OGAOau7hFn6NvelnKwrtkq+MaGZ+t1V+5k3OPJMPAShOEmKgvpsz5inTIw5
r53BBO2+EGLm6lI2UqpLGSzw4p1cZ95Du4KOUDGyGUlrUirsfaxl6luxBJya/As+
/+lLZpSA4K85Xvmzqr7s9uvLxu7lMNNsKZzOhPzmaoM6tG66VYJeUa42xjDUmyOr
ljMAz67r30cVPRLtqg4X8hxifwE0EkLe45MnShBXvwV2XaF4XMRCocsMD4U33q2A
JTNT1bS3YJq/yKqhW9zrNB0aRBcidXLxXqHM+E8mDtqOfqbXpaCXW/j3D7lcgjhM
mTlqQMSRr28mysZL4/Ge1ghiPlJmmU5WnUI4KR+cUN68JrBvuvCtcQC+PRPRSFfm
kNYnwBHu6mlTMU7Df+0EeAOV0LYUrw1gFgtE01N42oMLRGaS3e5KdcwNzrUt8wgm
ur0MI9Zoxw9bLHJHgAyY9iyO3Mai8CcQZeaLttcsdZjzBPi188ODKPu6j+uAa30q
LjmbQN86wttgQGLXHf9bs+CP6y88VnrAPMIsm5AZZ3BoyB9xAIBbdG95E23ucCvD
bqqmL8Va01dQeSih8BVL
=ifzB
-----END PGP SIGNATURE-----

Emmanuel,

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

Dixi quod…

FWIW, it builds and installs (as upgrade) and starts.

bye,
//mirabilos

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

[…]

Le 14/11/2020 à 18:03, Thorsten Glaser a écrit :
I think I'll rather wait for the standalone systemd-sysusers package
(#946456) and eventually the sysusers support in debhelper (#962384) to
remove the systemd-sysusers call in tomcat9.postinst.

Emmanuel Bourg

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.

Hi Ondrej,

Installing systemd should fix this issue.

Emmanuel Bourg


Le 2021-09-21 12:23, Ondrej Zary a écrit :

Ondrej Zary dixit:

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

Am Dienstag, dem 21.09.2021 um 16:10 +0000 schrieb Thorsten Glaser:
[...]

^^^
Such malicious allegations are not helpful.

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.

Markus Koschany dixit:

You should adjust your humour detector.

It wasn’t we desupport sysvinit either.
[…]

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

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.

Hello,

long discussion, apparently.

Me also is highly interested a current tomcat not relying on systemd but also working with sysvinit. Today, we're at Deb 11 Bullseye, and the issue apparently has not been sorted out.

May I kindly ask for a short summary about the state of affairs?

I don't want to engage in a heated discussion about pros and cons of init systems. But I think as long as Debian offers sysvinit, I feel that packages requiring boot services should not force the user to use a certain init system.

:wq! PoC

Patrik Schindler dixit:

I’ll update the sysvinit branch and publish a new build of the package
in my personal APT repository then (I’ve not done so for a while since
I’m currently not in a Java™ project). If that’s enough for you that
is — I can sign checksums with my Debian Developer PGP key for you to
verify.

Emmanuel blocks this because he does not like adduser, the Debian gold
standard for adding users to the system. Emmanuel is the primary pak‐
kage maintainer for tomcat9.

In bookworm AFAICT systemd-somethingd to add users has been split off
and might be usable from sysvinit, but that won’t help bullseye and
buster users. The relevant changes might be added during backporting,
but the backports policy frowns on this, and since Emmanuel blocked
testing the changes widely for so long, it might be rejected.

bye,
//mirabilos

Hello Thorsten,

Am 02.06.2022 um 16:47 schrieb Thorsten Glaser <tg@mirbsd.de>:

Thank you *very* much! Does this also resolve the packages' hard dependency on systemd?

What is your opinion about staying current with security updates for this specifically crafted package?

I see. Thanks for the explanation.

Is there some higher instance within the Debian project you can call up for probably conciliating this issue? Or might a fork to tomcat9-sysvinit be feasible? Would such a fork be accepted into the main apt archives?

Thank you!

:wq! PoC

Patrik Schindler dixit:

Yes, of course.

If I know I have users I can stay on top of other updates with this
package. For simplicity I’d probably follow uploads to unstable and
rebuild these, with the sysvinit patchset added, within bullseye; I
have successfully used the binary packages coming from that as well
on a buster system, so this should cover three releases.

One thing I have already done is to “split” the packages in my APT
repo so that those I consider “LTS” are available without pulling
in other “alternative” versions of packages, so it can safely be
added to most systems. The current set of packages for bullseye is:

• musescore-general-soundfont musescore-general-soundfont-small
  (just huge data packages)
• openjdk-8 (sid but also used in stretch-security; bullseye uses 11)
• screen (updated Unicode support)
• tomcat9
• uw-imap (add back missing binary packages)
• wtf-debian-keyring (the keyring package for this repo)

The package maintainer generally has the highest authority. There
are cases, yes, but the Debian project has voted, in a General
Resolution, that lack of support for multiple init systems cannot
be pushed like that. Or (at least) the vocal minority has while the
rest of the developers abstained from voting, looking at percentages…

No, that’s a ridiculous amount of duplication and overhead.
Besides, we’d have to had this done years ago.

bye,
//mirabilos

Instructions back to the list, in case this is of more general interest.

Dixi quod…

I’ve done that and I’ll keep up with Markus’ uploads to sid as much
as possible. (I even had to add a patch to make it buildable on
bullseye already, but then the bullseye-security upload is going to
need that exact patch, too.)

I have indeed tested the latest version on buster, and it works.
Though, my testing is (currently) really minimal as I’m not in a
Java project at the moment. Nevertheless, my employer, ⮡ tarent,
has sponsored some of my time working on this project again.

The repository is available at http://www.mirbsd.org/~tg/Debs/
though the https on that server is TLSv1 only, which your browser
may not like without reconfiguration so I’ve set up a mirror at
https://caas.mirbsd.org:444/Debs/ (actually the latter is just a
view of the main repo storage on the box, so it’ll be inconsistent
during package updates for a longer time, say an half hour or so,
instead of just for a few seconds as the first URL, but it’s good
to obtain the PGP key, for example, using https as extra trust-y
anchor; the repo/packages themselves use Secure APT via PGP anyway).

Let’s discuss enabling the repository first.

If you use the “extrepo” package, it’s as easy as enabling the
“wtf-lts” repo, if you’re on buster or bullseye. If you’re on
bookworm/testing or sid, you’ll currently need to set up the
full “wtf” repository with sid as release; since you wrote you’ll
use pinning anyway, this should not be a problem.

If you don’t use the “extrepo” package, you’ll need to first let
apt know the PGP key. The “modern” but pre-bookworm way is to get
https://caas.mirbsd.org:444/Debs/wtf-debian-keyring.gpg and
https://caas.mirbsd.org:444/Debs/wtf-debian-keyring.gpg.asc then
use the latter with my Debian Developer key to verify the former.
My DD key is shipped in the package debian-keyring, and I’m using
it to sign this message, too. You can for example do:
$ gpg --keyring /usr/share/keyrings/debian-keyring.gpg \
    wtf-debian-keyring.gpg.asc
Once verified, place wtf-debian-keyring.gpg into /etc/apt/trusted.gpg.d/
(however, see below regarding the keyring packagre) and as next step, add
an appropriate sources.list(.d) line, such as:
 deb http://www.mirbsd.org/~tg/Debs/ bullseye lts

The bookworm way is to load https://caas.mirbsd.org:444/Debs/wtf.sources
(and .asc again) instead and place that into /etc/apt/sources.list.d/
and it will replace *both* the trusted key *and* the sources.list entry
by placing the key with the entry in the new “long” format, so it’s only
used for this repository. This doesn’t yet work in bullseye, AFAIK :/

Neither will get you auto-updates for the key. See below for that.
basically, you need to pin down all packages from the repository except
the binary packages from the tomcat9 source package, which are:
 libtomcat9-embed-java deb java optional arch=all
 libtomcat9-java deb java optional arch=all
 tomcat9 deb java optional arch=all
 tomcat9-admin deb java optional arch=all
 tomcat9-common deb java optional arch=all
 tomcat9-docs deb doc optional arch=all
 tomcat9-examples deb java optional arch=all
 tomcat9-user deb java optional arch=all

I’ve not had much success with pinning myself, other than to tell apt
to never install systemd at all, and to force specific versions for
packages. But maybe you figure it out and will share it for everyone?

The repository (independent of whether you use the lts or wtf component)
uses the following identification:

Origin: The MirOS Project
Label: wtf
Suite: bullseye or sid etc…
Codename: bullseye or sid etc…

So I think you should be able to pin with o= (space might be tricky)
and l= according to apt_preferences(5)… anyway, do tell us if it works
(otherwise, we’ll need to prod at it together, until it’s going to).

You wrote:
|Keyring behavior has been changed (to be more cumbersome for an user, I
|think) on Bullseye. Does this still work?

It does. This package still uses the “oldold” way, in that apt-key(8)
is called from postinst. It warns loudly about that. (It might no longer
work on bookworm/sid though.)

I had planned on splitting this package up into old and newer flavours
and have the newer one place a file in /etc/apt/trusted.gpg.d/ as
mentioned above, but the “put the key together with the sources entry”
method really has benefits, so I’m undecided.

For now, if you want the keyring package, either get that over https
and trust that or run “apt-key add wtf-debian-keyring.gpg” instead of
placing the file in /etc/apt/trusted.gpg.d/ and then install the keyring
package using normal apt-get. (The keyring package does ensure the keys
are properly removed on purge; it will also do so when I switch the method.)

In the RPM world, there’s a concept called “release package” (e.g. you do
“yum install epel-release” to install a package which contains both the
key and the sources.list equivalent of a repository) and this *MIGHT* be
a way to do this on Debian… the /etc/ placement is tricky however, and
it’d need lots of packages and the extrepo mechanism isn’t prepared for
it either. I think I’ll need to talk to people… (>>TODO)

bye,
//mirabilos


Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine

Hello Thorsten,

a BIG and HUGE "THANK YOU" for your service to the community!


Am 12.06.2022 um 02:34 schrieb Thorsten Glaser <tg@mirbsd.de>:

Worked. Thanks!

Is there another way?

Almost the same for me. Tomcat from your repro smells newer to apt-get, so this got installed. I know I should make sure that this is enforced but I'll postpone that to a later point in time.

:wq! PoC

Patrik Schindler dixit:

You’re welcome.

Not that I know of.

The version is higher, and apt will install the highest version it will
find. You need the pinning only to prevent the other packages from the
repo to be considered. (Though for the “lts” component this is only
things I would upload to Debian myself, were it not for the stable or
oldstable-backports-sloppy (closed 1 year after stable release, i.e.
before LTS/ELTS) upload rules.)

bye,
//mirabilos

Patrik Schindler dixit:

Not (that I can see) a security update, but I’ve updated it to match
today’s (yesterday’s?) sid upload.

The repository also has an RSS feed.

bye,
//mirabilos

Hello Thorsten,

Am 21.06.2022 um 07:27 schrieb Thorsten Glaser <tg@mirbsd.de>:

Thanks! Keep up the good work!

:wq! PoC

Debian FTP Masters dixit:

I guess it’s now also the time to split up the sysvinit git branch
into stuff intended for sid with the systemd-sysusers/tmpfiles change
and stuff needed for running on buster(-backports), i.e. adduser.
I could then upload the former to experimental again, for testing,
and so Emmanuel can review and, perhaps, ACK it, since adduser was,
back then, the reason he stated to reject it.

I don’t have the time for that right now, though (some presence days
for a customer) so it’ll take me a bit.

bye,
//mirabilos

Le 2022-06-22 05:53, Thorsten Glaser a écrit :

With these changes I think it's now possible to detach the sysvinit
script
into an independent package (tomcat9-sysvinit?) enhancing tomcat9.

Hi Emmanuel,

*WHY*?

The remaining changes do not change the way it is run under systemd
AT ALL.

Having an extra binary package just for a handfull of scripts is
absolute overkill and ftpmasters from upon that, too.

*gasp*,
//mirabilos

Le 2022-06-22 19:14, Thorsten Glaser a écrit :

Because separate packages means separate responsibilities. I'd like not
to maintain again sysvinit scripts in any Java package, we don't have
the time for this (we barely keep up with the Java and toolchain
upgrades).

That said, I'm fine with applying some reasonable changes that ease the
use of sysvinit (like the logger change and the switch to the standalone
systemd-sysusers).

If the number of packages matters, I've removed several unused
lib*-java-doc
packages recently, so one more package for the Tomcat init script isn't
really
an issue, the net change for the Java packages is negative.

To avoid the proliferation of sysvinit script packages the best approach
would be to group the scripts into a common package (maybe using a
trigger
to install the script when a supported daemon is installed on the
system).
This would lift the burden of maintaining these scripts off most DDs and
delegate the work to a small set of dedicated maintainers, properly
optimizing and harmonizing these scripts.

Emmanuel Bourg

Emmanuel Bourg dixit:

It’s a *TEAM* responsibility. I joined the team at some point in the past.

I do have the time for this, because I feel it important, and I’ve offered
about four or five times already to take care of it.

This doesn’t scale, especially not to backports. There is an attempt to
do so, but it’s only used for packages with overly hostile maintainers,
and the approach doesn’t work flawlessly. I’m extremely unconvinced of this.

Why not let the dedicated maintainers take care of the scripts in their
originating packages? Especially if they are part of the team that is
listed as the package maintainer in the first place already ANYWAY?

Exasperated,
//mirabilos