gateway - run the georchestra gateway with a Java runtime 21 (fixes geor/geor#4285)

[pmauduit]

Hopefully a JRE 21 will be available in the next debian release, but waiting for it, we can set up a temurin-21-jre from adoptium, see georchestra/georchestra#4285

Tests:

• rspec ok after having installed exim4-base and relaunched the DF
• runtime tests ok: weird redirection to CAS, but able to log in by hitting /login directly (through the georchestra gateway).

[landryb]

there's another reference to the default java version in the df:
roles/georchestra/templates/datafeeder/datafeeder.service.j2:ExecStart=/usr/bin/java

installing temurin 21 will change the default java version .. no ? does the df backend work with java 11 ? 17 ? 21 ? any of them ?

[pmauduit]

installing temurin 21 will change the default java version .. no ?

Hmm, right :-/

vagrant@bookworm:~$ java -version
openjdk version "21.0.4" 2024-07-16 LTS
OpenJDK Runtime Environment Temurin-21.0.4+7 (build 21.0.4+7-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.4+7 (build 21.0.4+7-LTS, mixed mode, sharing)

I think we should avoid the update-alternatives step here, and I'd like to only affect the gateway, not the other apps.

[pmauduit]

does the df backend work with java 11 ? 17 ? 21 ?

it works with both java 17 & 21 in my vagrant.

[pmauduit]

I checked if there was a way to avoid temurin-21 to become the default jre, but the postinst script does not allow it, so maybe playing with the alternatives ansible module after having setting it up ? e.g.:
https://docs.ansible.com/ansible/latest/collections/community/general/alternatives_module.html

For the record, here is the postinst provided by the temurin package:

#!/bin/sh
set -eu

priority="2111"
jdk_base_dir="/usr/lib/jvm/temurin-21-jdk-amd64"
tools="jar jarsigner java javac javadoc javap jcmd jconsole jdb jdeprscan jdeps jfr jhsdb jimage jinfo jlink jmap jmod jpackage jps jrunscript jshell jstack jstat jstatd jwebserver keytool rmiregistry serialver jexec jspawnhelper"

case "$1" in
configure)
	for tool in $tools; do
		for tool_path in "$jdk_base_dir/bin/$tool" "$jdk_base_dir/lib/$tool"; do
			if [ ! -e "$tool_path" ]; then
				continue
			fi

			slave=""
			tool_man_path="$jdk_base_dir/man/man1/$tool.1"
			if [ -e "$tool_man_path" ]; then
				slave="--slave /usr/share/man/man1/$tool.1 $tool.1 $tool_man_path"
			fi

			update-alternatives \
				--install \
				"/usr/bin/$tool" \
				"$tool" \
				"$tool_path" \
				"$priority" \
				$slave
		done
	done
	;;

abort-upgrade | abort-remove | abort-deconfigure)
	# Nothing to do
	;;
*)
	echo "postinst called with unknown argument \`$1'" >&2
	exit 1
	;;
esac

exit 0

[landryb]

i'm totally fine with using the alternatives module, i have that somewhere:

- name: Default to temurin jdk
  community.general.alternatives:
    name: java
    path: /usr/lib/jvm/temurin-11-jdk-amd64/bin/java

the only question left is 'should this be done for all binaries provided by the jre/jdk'...

[pmauduit]

the only question left is 'should this be done for all binaries provided by the jre/jdk'...

I guess so, my fear was to have more tools from one side or another (between java21 vs java17).

[landryb]

there doesnt seem to be a dpkg/apt option to avoid running postinst scripts...

[pmauduit]

there doesnt seem to be a dpkg/apt option to avoid running postinst scripts...

I have seen a hackish solution on stackoverflow, but I did not want to go in that direction (exit 0 in a /etc/apt/something.d directory where you can put hooks)