[RHEL9] Reproducible issue: foreman-installer rewrites JAVA_HOME to Java 17 while installed Candlepin 4.8.4 requires Java 25

Problem:

I found a reproducible issue between Candlepin 4.8.4 and the configuration generated by foreman-installer.

The installed Candlepin RPM explicitly requires Java 25:

rpm -q --requires candlepin | grep java

Output:

java-25-headless >= 1:25.0.0

However, foreman-installer rewrites:

/etc/tomcat/tomcat.conf

to:

JAVA_HOME=“/usr/lib/jvm/jre-17”

After a Tomcat restart, Candlepin fails to start and hammer ping reports:

candlepin:

Status: FAIL

Server Response: Message: 404 Not Found

candlepin_auth:

Status: FAIL

Server Response: Message: Katello::Errors::CandlepinNotRunning

Tomcat logs contain:

java.lang.UnsupportedClassVersionError:

org.candlepin.guice.CandlepinContextListener has been compiled by a more recent version of the Java Runtime

class file version 69.0

this version of the Java Runtime only recognizes class file versions up to 61.0

Expected outcome:

Either:

- Candlepin 4.8.4 should run correctly with the Java version configured by foreman-installer

or

- foreman-installer should configure the Java version required by the installed Candlepin package.

I would also like to know the supported/recommended way to override candlepin::java_home if Java 25 is expected.

Foreman and Proxy versions:

Foreman 3.19.1

Integrated Smart Proxy only (no external Capsules)

Foreman and Proxy plugin versions:

Katello 4.21.1.1

Candlepin 4.8.4-1.el9

Distribution and version:

RHEL 9

Other relevant data:

Installed package:

rpm -qi candlepin

NAME=candlepin

VERSION=4.8.4

RELEASE=1.el9

VENDOR=Fedora Copr - group @theforeman

BUILDHOST=aws-x86-64-reserved-prod-15474770-20260731-131023

RPM dependency:

rpm -q --requires candlepin | grep java

java-25-headless >= 1:25.0.0

Katello manifest:

grep -R “java_home” /usr/share/foreman-installer/modules/katello

Output:

java_home => ‘/usr/lib/jvm/jre-17’

Reproduction:

1. Set:

JAVA_HOME=“/usr/lib/jvm/java-25-openjdk”

2. Restart Tomcat.

3. Verify:

hammer ping

All services are OK.

4. Save current configuration:

cp -p /etc/tomcat/tomcat.conf /root/tomcat.conf.before

5. Run:

foreman-installer

6. Observe:

diff -u /root/tomcat.conf.before /etc/tomcat/tomcat.conf

Result:

- JAVA_HOME=“/usr/lib/jvm/java-25-openjdk”

+ JAVA_HOME=“/usr/lib/jvm/jre-17”

7. Before restarting Tomcat:

hammer ping still reports all services OK.

8. Restart Tomcat:

systemctl restart tomcat

9. Result:

candlepin FAIL

candlepin_auth FAIL

10. Restore:

JAVA_HOME=“/usr/lib/jvm/java-25-openjdk”

11. Restart Tomcat again:

systemctl restart tomcat

12. Result:

hammer ping returns all services OK again.

Question:

Is Java 25 expected for candlepin-4.8.4-1.el9?

If yes, should foreman-installer configure Java 25 instead of Java 17?

Or is there another supported way to override candlepin::java_home?

Regards,

Hello,

using formatting really helps with readability of your post. To your problem.

I just installed Foreman/Katello 5.1 (dev) moments ago and this is what I see:

[vagrant@katello ~]$ rpm -q foreman-installer
foreman-installer-5.1.0-0.1.develop.20260821031116gitce617d7.el9.noarch
[vagrant@katello ~]$ grep JAVA_HOME /etc/tomcat/tomcat.conf
JAVA_HOME="/usr/lib/jvm/jre-25"

I see candlepin-4.7.5-1.el9.noarch that comes with 5.1, but you have 4.8.4.

What version of Foreman/Katello are you on? Have you upgraded Candlepin to newest version manually or something?

Hello Izap,

Thank you for testing.

My environment is:

foreman-3.19.1-1.el9.noarch

katello-4.21.1.1-1.el9.noarch

candlepin-4.8.4-1.el9.noarch

I did not manually install or upgrade Candlepin.

The package comes from the following repositories:

- Foreman 3.19 - RHEL9

- Foreman Plugins 3.19 - RHEL9

- Katello 4.21 - RHEL9

- Pulpcore 3.105 - RHEL9

- Candlepin 4.8 - RHEL9

Installed package information:

rpm -qi candlepin

Name : candlepin

Version : 4.8.4

Release : 1.el9

Vendor : Fedora Copr - group @theforeman

The package explicitly requires:

rpm -q --requires candlepin | grep java

java-25-headless >= 1:25.0.0

The issue appears after running:

foreman-installer

which rewrites:

JAVA_HOME=“/usr/lib/jvm/java-25-openjdk”

to:

JAVA_HOME=“/usr/lib/jvm/jre-17”

After restarting Tomcat, Candlepin fails with:

UnsupportedClassVersionError

class file version 69.0

Restoring Java 25 and restarting Tomcat fixes the issue immediately.

Could it be that Candlepin 4.8.4 was built requiring Java 25 while the Katello 4.21 installer still configures Java 17?

Thanks.

Hello Izap,

Thank you for testing.

I did not manually upgrade Candlepin.

I upgraded from Foreman 3.18.2 / Katello 4.20 to Foreman 3.19.1 / Katello 4.21.1.1.

During the upgrade I enabled:

- Foreman 3.19 - RHEL9

- Foreman Plugins 3.19 - RHEL9

- Katello 4.21 - RHEL9

- Pulpcore 3.105 - RHEL9

- Candlepin 4.8 - RHEL9

The resulting package installed is:

candlepin-4.8.4-1.el9.noarch

Was Candlepin 4.8 actually the expected repository for Foreman 3.19 / Katello 4.21?

Regards,

That is what appears to have happened. The Java 25 support was merged (Update Candlepin Java requirement to Java 25 · theforeman/puppet-katello@c43b0ba · GitHub) and released as part o puppet-katello 29.0.0.

CC @jeremylenz @ogajduse

Looking at the package definition for katello, I don’t see 4.8.z foreman-packaging/packages/katello/katello-repos/katello-repos.spec at rpm/3.19 · theforeman/foreman-packaging · GitHub

I wonder how this got into your system.


Edit, now I know

Looking at the foreman-installer tar.gz for 3.19.1, I see puppet-candlepin 18.1.0, we don’t have Update Candlepin Java requirement to Java 25 · theforeman/puppet-katello@c43b0ba · GitHub there .

I did enable the Candlepin 4.8 repository explicitly.

The installed package comes from:

The_Foreman_Candlepin_4_8_-_RHEL9

Versions available in the repository:

4.8.1

4.8.2

4.8.3

4.8.4

The installed version is:

candlepin-4.8.4-1.el9

So the package was installed from the enabled Candlepin 4.8 repository and not manually.

Should Foreman 3.19.1 / Katello 4.21.1.1 use Candlepin 4.8, or should it remain on Candlepin 4.7.x?

3.19.1/4.21 should be explicitly on 4.7. That’s why we manage the .repos with the katello-release repository rpm.

1 Like

Could this be an upgrade issue? I just installed stable fresh:

dnf -y install https://yum.theforeman.org/releases/3.19/el9/x86_64/foreman-release.rpm
dnf -y install https://yum.theforeman.org/katello/4.21/katello/el9/x86_64/katello-repos-latest.rpm
dnf -y install https://yum.voxpupuli.org/openvox8-release-el-9.noarch.rpm
dnf -y install foreman-installer-katello
foreman-installer --scenario katello --tuning development -s --foreman-initial-admin-password changeme --foreman-initial-organization MyOrg --foreman-initial-location MyLoc

I see 4.7 with JRE 17:

[root@stable vagrant]# grep JAVA_HOME /etc/tomcat/tomcat.conf
JAVA_HOME="/usr/lib/jvm/jre-17"

[root@stable vagrant]# rpm -q foreman katello candlepin
foreman-3.19.1-1.el9.noarch
katello-4.21.1.1-1.el9.noarch
candlepin-4.7.5-1.el9.noarch

Thank you, that makes sense.

I think the challenge is that many enterprise environments do not consume the Foreman/Katello repositories directly and therefore do not necessarily rely on the release RPMs to determine compatible repository versions.

In my case, I operate an OpenSat environment with synchronized repositories and Content Views. We mirror repositories internally and typically do not install the release RPMs on the OpenSat server itself to discover which repositories should be enabled.

As a result, when repositories such as:

- Foreman 3.19

- Katello 4.21

- Pulpcore 3.105

- Candlepin 4.8

are available, it is difficult to determine which combinations are actually recommended without inspecting the release RPM contents.

From an administrator perspective, repository availability can easily be interpreted as repository compatibility.

This is why I think a centralized compatibility reference or matrix in the documentation would be extremely valuable, especially for:

- Enterprise environments

- Satellite-like deployments

- Internal mirrors

- Content Views

- Air-gapped infrastructures

In my case, I assumed that enabling the available Candlepin 4.8 repository was appropriate for Foreman 3.19 / Katello 4.21 because I could not find an official compatibility matrix indicating that Candlepin 4.7 was the expected version.

The release RPM approach works well for direct installations.

However, enterprises operating mirrors, Content Views, internal repositories or disconnected environments often work at the repository level and may never directly use the release RPMs.

For those administrators, a centralized compatibility reference would be extremely useful.

Thank you for clarifying the expected combination.

Thank you all for the help and for pointing me in the right direction.

I can confirm that the root cause was indeed the Candlepin version.

I had enabled the Candlepin 4.8 repository and ended up with:

candlepin-4.8.4

which requires Java 25.

After switching back to the expected repository and downgrading to:

candlepin-4.7.5

foreman-installer now correctly configures:

JAVA_HOME=“/usr/lib/jvm/jre-17”

and the environment is fully operational again.

Verification:

candlepin-4.7.5-1.el9.noarch

Requires:

java-17 >= 1:17.0.0

hammer ping:

- candlepin: OK

- candlepin_auth: OK

- pulp3: OK

- foreman_tasks: OK

I also reproduced the original issue and confirmed that it was caused by the unsupported combination of Katello 4.21 with Candlepin 4.8.

Thank you again for helping identify the root cause.

Regards,

1 Like

One additional observation:

After downgrading to candlepin-4.7.5, the service works correctly with the expected Java 17 configuration, but it also appears to run successfully with Java 25.

So the issue was not Java 25 itself.

The problematic combination was:

Katello 4.21 + Candlepin 4.8.4 + Java 17

while:

Katello 4.21 + Candlepin 4.7.5

works correctly.

This further confirms that the root cause was the unsupported Candlepin 4.8 repository rather than Java 25 itself.

1 Like

Thanks for getting back to us.

Foreman project is entirely designed for connected environments and we assume that installations have access to internet. We do not support disconnected environments, this is simply too much work for us to test. It can be achieved of course, but this is completely up to you. If you want to contribute and maintain disconnected documentation feel free - documentation is fully open source too.

It is worth nothing that both Foreman-based products Red Hat Satellite and orcharhino support disconnected installations.

1 Like