This update has been unpushed.
This update has been unpushed.
This issue is because of javaee -> jakartaee migration that isn't done in the app.
May 31 19:53:46 example.redhat.com server[6759]: Caused by: java.lang.ClassNotFoundException: javax.servlet.http.HttpServletResponse
The failure in the scanning is due to necessary catalina.properties changes in the PKI configurations :( The following will clear the scanner failures (but there should probably be more jars added to match the current version upstream):
--- conf/catalina.properties.orig 2024-05-31 19:45:43.846548383 -0400
+++ conf/catalina.properties 2024-05-31 19:46:22.194548383 -0400
@@ -139,7 +139,7 @@ junit.jar,junit-*.jar,hamcrest-*.jar,eas
objenesis-*.jar,ant-launcher.jar,\
cobertura-*.jar,asm-*.jar,dom4j-*.jar,icu4j-*.jar,jaxen-*.jar,jdom-*.jar,\
jetty-*.jar,oro-*.jar,servlet-api-*.jar,tagsoup-*.jar,xmlParserAPIs-*.jar,\
-xom-*.jar
+xom-*.jar,bcel*.jar,commons-compress*.jar,jakartaee-migration-*.jar
# Default list of JAR files that should be scanned that overrides the default
# jarsToSkip list above. This is typically used to include a specific JAR that
I'll reach out to the FreeIPA folks and get this sorted.
Yeah, apparently the tomcat-jakartaee-migration tool has some issues to sort out, and the tomcatjss package needs fixing to work with the new tomcat version. This build was created so the PKI folks could start building FreeIPA against the new tomcat version. We probably should have waited a bit before doing the updates...
We should only be updating tomcat-native to version 2.0.x in the latest (rawhide) branch of Fedora as it will break some instances. Tomcat Native 2.0.x does not support the APR connectors.
This update has been unpushed.
This update has been unpushed.
I think it's best to rollback those default changes for f30-f32 (and fix this like I did for RHEL) so we don't break current user environments. The work done in the freeipa project to use the secret is still valid, but after I introduce a new build it won't be broken by default.
@adamwill @abbra the breakage occurred due to changes in the defaults on the AJP Connector to mitigate CVE-2020-1938. There are two changes that likely caused issue: the default bind address for the connector changed from all interfaces to localhost and the connector will no longer start unless you define a secret. We can proceed two different ways. You can update the FreeIPA configuration to address those (add 'address' and 'secretRequired=false' to your Connector config), or I can create a patch to undo those changes (which is what I did for RHEL tomcat). The problem with the second approach is that I don't know of any mechanism to tell users that they need to review their configurations, so they likely won't do anything and remain vulnerable to exploitation. Got any tips on that?
LGTM
LGTM
LGTM
Are you sure this isn't an environmental issue? The changes committed to rebase were minimal and should not have caused this problem. Additionally, looking at the build information in koji shows that the tomcat-lib package does in fact provide "tomcat-lib = 1:8.0.53-1.fc27". I'll setup a VM to test as soon as I can, but I don't see any cause for this at first glance.
This update has been unpushed.
wfm too :)
I was under the impression that adding a new build would remove the old one, but maybe that isn't the case. I do see that this update is pending the push to testing, so maybe when that happens the old build will be removed. I'm going to wait and see what happens when this update is pushed to testing. If it doesn't resolve it, I'll try untagging the 8.0.37-3 build.
Thanks for pinning that down @abbra; I'll rebase to 8.0.38 asap.
I tested mod_cluster, mod_cluster-java, mod_cluster-java-tomcat8 with tomcat8 (1:8.0.36-2.fc25) and it works fine.
Given the issues that have shown up after this attempted upgrade we decided to open a change proposal instead to alert everyone that it's being planned. The proposal is at https://fedoraproject.org/wiki/Changes/Tomcat10ChangeProposal