hi,

a bit late, apologies.

I found that I do have a replica, so the pressure is off, so this is nice :-). Still, if you are still willing to investigate why this happened, I am too (just curious). Otherwise we can drop this issue.

I see no dogtag-jss or dogtag-tomcat-jss packages, but I guess those are id-jss and idm-tomcatjss

This is the output in the host with problems (running alma 9.3):

root@kdc1 ~]# rpm -qa | grep -i jss
idm-jss-5.4.1-2.el9.x86_64
idm-tomcatjss-8.4.0-1.el9.noarch

And on the not yet updated replica, where it still runs (also alma 9.3):

[root@kdc2 ~]# rpm -qa | grep jss
idm-jss-5.4.1-2.el9.x86_64
idm-tomcatjss-8.4.0-1.el9.noarch

I created a third replica to have even better redundancy, and this one running alma 9.4 has this version:

idm-jss-5.5.0-1.el9.x86_64
idm-jss-tomcat-5.5.0-1.el9.x86_64

Regards,

Natxo

On Thu, May 30, 2024 at 6:13 PM Rob Crittenden <rcritten@redhat.com> wrote:

What version of dogtag-jss and dogtag-tomcat-jss are you running? I
wonder if there is some requirement that it be in sync with the rest of
the dogtag packages.

rob

Natxo Asenjo wrote:
> hi,
>
> digging further, the tomcat service does not start because the of this
> error:
>
> server[48368]: org.xml.sax.SAXParseException; systemId:
> file:/var/lib/pki/pki-tomcat/conf/server.xml; lineNumber: 86;
> columnNumber: 861; Error at line [86] column [861]: [Cannot invoke
> "Object.getClass()" because the return value of
> "org.apache.catalina.connector.Connector.getProtocolHandler()" is null]
>
> If I check the server.xml, there is no colum 861 in line 86, the last
> char is 860
>
> <Connector name="Secure" port="8443"
> protocol="org.dogtagpki.jss.tomcat.Http11NioProtocol" SSLEnabled="true"
> sslImplementationName="org.dogtagpki.jss.tomcat.JSSImplementation"
> scheme="https" secure="true" connectionTimeout="80000"
> keepAliveTimeout="300000" maxHttpHeaderSize="8192" acceptCount="100"
> maxThreads="150" minSpareThreads="25" enableLookups="false"
> disableUploadTimeout="true" enableOCSP="false"
> ocspResponderURL="http://kdc.sub.domain.tld:8080/ca/ocsp"
> ocspResponderCertNickname="ocspSigningCert cert-pki-ca"
> ocspCacheSize="1000" ocspMinCacheEntryDuration="7200"
> ocspMaxCacheEntryDuration="14400" ocspTimeout="10"
> serverCertNickFile="/var/lib/pki/pki-tomcat/conf/serverCertNick.conf"
> passwordFile="/var/lib/pki/pki-tomcat/conf/password.conf"
> passwordClass="org.dogtagpki.jss.tomcat.PlainPasswordFile"
> certdbDir="/var/lib/pki/pki-tomcat/alias">
>
>
> This line looks similar (replacying the ocsp url) to other ipa ca
> servers I manage, so I do not know where this is coming from.
>
> If I run this as root it starts but apparently not well enough, because
> then the ExecStartPost command /usr/libexec/ipa/ipa-pki-wait-running
> fails with a 404
>
> # /usr/libexec/ipa/ipa-pki-wait-running
>
> pki.client: /usr/libexec/ipa/ipa-pki-wait-running:61: The subsystem in
> PKIConnection.__init__() has been deprecated
> (https://github.com/dogtagpki/pki/wiki/PKI-10.8-Python-Changes).
> ipa-pki-wait-running: Created connection http://kdc.sub.domain.tld:8080/ca
> ipa-pki-wait-running: Request failed unexpectedly, 404 Client Error:
> for url: http://kdc.sub.domain.tld:8080/ca/admin/ca/getStatus
>
> Any clues?
>
> Regards,
>
> Natxo
>
>
>
> On Wed, May 29, 2024 at 4:06 PM Natxo Asenjo <natxo.asenjo@gmail.com
> <mailto:natxo.asenjo@gmail.com>> wrote:
>
>
>
> On Wed, May 29, 2024 at 3:03 PM Rob Crittenden <rcritten@redhat.com
> <mailto:rcritten@redhat.com>> wrote:
>
> Since it starts directly as root perhaps check for SELinux AVCs?
> Maybe a
> relabel would help (or try permissive to catch the full set).
>
> rob
>
>
>
> unfortunately selinux was already in permissive mode and no recent avcs:
> # ausearch -m avc -ts recent
> <no matches>
>
> The latest avc is from a few days agoi regarding the ipa_custodia
> which we do not use.
>
> I did a restorecon -rv / and it corrected some labels, but no
> difference so far.
>
>
>
>
>
> --
> --
> Groeten,
> natxo