[Pki-users] Cannot write to MasterCRL at CA startup
Marc Sauton
msauton at redhat.com
Tue Oct 21 18:20:46 UTC 2008
Adewumi, Julius-p99373 wrote:
> Marc,
> I saw the publishOnStart flag and to my surprise yesterday it was
> already "false".
>
So the ca is likely trying to publish the crl after the instance started.
> Below are the logs in CA:logs/system, logs/debug.
> This morning I restarted RH-DS and the rhpki-ca. DS stayed up after I
> started CA, however the CA console will not start just like it was doing
> throughout yesterday.
>
The internal db must run before the ca instance starts.
> Here are the logs. This is a test pki system so I am going to
> re-install the pki system
> But I need to know what I am doing/not-doing wrong.
> The Dirsrv is on separate node from the CA.
>
You should also have redhat-ds installed on the CA for the internal db.
The publishing directory can be a remote system, assuming tcp
connections are available as well as reliable network connection.
> For RH -DS versions:
>
> Redhat-idm-console-1.0.0-21.el4idm
> Redhat-admin-console-8.0.0.9.el4dsrv
> Java-1.4.2-ibm-javacomm-1.4.2.10-1jpp.2.el4
> Java-1.6.0-ibm-plugin-1.6.0.1-1jpp.2.el4
>
You may want to verify with a:
/usr/sbin/alternatives --config java
For DogTag the 1.6 JRE is ok as per
http://pki.fedoraproject.org/wiki/PKI_Runtime_Environments
But it seem like you are using RHCS, so I would expect to see a 1.5 JRE:
http://www.redhat.com/docs/manuals/cert-system/7.3/html/Administration_Guide/Administration_Guide-Installation_and_Configuration-Prerequisites.html#Administration_Guide-Prerequisites-Required_Programs_and_Dependencies
"
/Java™ 1.5.0 Java Runtime Environment (JRE)./ Certificate System does
not support earlier versions of the JRE. This JRE is required for
running Tomcat, among other applications for the Certificate System.
"
> From rhpki-ca : (This is version 7.3 with the downloaded fixes)
>
> rhpki-native-tools-7.3.0-5.el4
> rhpki-kra-7.3.0-8.el4
> rhpki-ocsp-7.3.0-8.el4
> rhpki-manage-7.3.0-12.el4
> rhpki-util-7.3.0-11.el4
> rhpki-java-tools-7.3.0-9.el4
> rhpki-console-7.3.0-10.el4
> rhpki-migrate-7.3.0-9.el4
> rhpki-common-7.3.0-16.el4
> rhpki-ca-7.3.0-9.el4
> rhpki-tks-7.3.0-9.el4
> rhpki-tps-7.3.0-15.el4
>
>
This is RHCS, not DogTag.
Note you are behind several errata's from RHN, there are newer rpms.
> Here are the logs:
>
> # tail system
> 7020.CRLIssuingPoint-MasterCRL - [20/Oct/2008:16:48:35 MST] [3] [3]
> CRLIssuingPoint MasterCRL - Failed to sign or store CRL LDAP operation
> failure - cn=MasterCRL,ou=crlIssuingPoints, ou=ca,
> dc=tf1-tve-spki001.-rhpki-ca netscape.ldap.LDAPException: failed to
> connect to server ldap://tf1-tve-qpki001:389 (91)
> 7020.main - [20/Oct/2008:16:48:35 MST] [8] [3] In Ldap (bound)
> connection pool t o host tf1-tve-qpki001 port 389, Cannot connect to
> LDAP server. E rror: netscape.ldap.LDAPException: failed to connect to
> server ldap://tf1-tve-qpki001:389 (91)
> 7020.CRLIssuingPoint-MasterCRL - [20/Oct/2008:16:48:35 MST] [3] [3]
> CRLIssuingPoint MasterCRL - Cannot update CRL. Error: Failed
> constructing CRL : LDAP operation failure -
> cn=MasterCRL,ou=crlIssuingPoints, ou=ca, dc=tf1-tve-spki001.-rhpki-ca
> netscape.ldap.LDAPException: failed to connect to server
> ldap://tf1-tve-qpki001:389 (91)
> 7020.main - [20/Oct/2008:16:48:35 MST] [3] [3] CRLIssuingPoint MasterCRL
> - Cannot store the CRL cache in the internaldb. Error LDAP operation
> failure - cn=MasterCRL,ou=crlIssuingPoints, ou=ca,
> dc=tf1-tve-spki001.-rhpki-ca netscape.ldap.LDAPException: failed to
> connect to server ldap://tf1-tve-qpki001:389 (91)
> 7980.main - [20/Oct/2008:16:52:35 MST] [8] [3] In Ldap (bound)
> connection pool t o host tf1-tve-qpki001. port 389, Cannot connect to
> LDAP server. E rror: netscape.ldap.LDAPException: failed to connect to
> server ldap://tf1-tve-qpki001:389 (91)
> 7980.CertStatusUpdateThread - [20/Oct/2008:16:52:35 MST] [5] [3]
> Operation Error - netscape.ldap.LDAPException: failed to connect to
> server ldap://tf1-tve-qpki001:389 (91)
> 7980.CertStatusUpdateThread - [20/Oct/2008:16:52:35 MST] [5] [3] Null
> response c ontrol
> 7980.CRLIssuingPoint-MasterCRL - [20/Oct/2008:16:52:35 MST] [3] [3]
> CRLIssuingPoint MasterCRL - Failed to sign or store CRL LDAP operation
> failure - cn=MasterCRL,ou=crlIssuingPoints, ou=ca,
> dc=tf1-tve-spki001-rhpki-ca netscape.ldap.LDAPException: failed to
> connect to server ldap://tf1-tve-qpki001:389 (91)
> 7980.CRLIssuingPoint-MasterCRL - [20/Oct/2008:16:52:35 MST] [3] [3]
> CRLIssuingPoint MasterCRL - Cannot update CRL. Error: Failed
> constructing CRL : LDAP operation failure -
> cn=MasterCRL,ou=crlIssuingPoints, ou=ca, dc=tf1-tve-spki001.-rhpki-ca
> netscape.ldap.LDAPException: failed to connect to server
> ldap://tf1-tve-qpki001:389 (91)
> 7980.main - [20/Oct/2008:16:52:35 MST] [3] [3] CRLIssuingPoint MasterCRL
> - Cannot store the CRL cache in the internaldb. Error LDAP operation
> failure - cn=MasterCRL,ou=crlIssuingPoints, ou=ca,
> dc=tf1-tve-spki001-rhpki-ca netscape.ldap.LDAPException: failed to
> connect to server ldap://tf1-tve-qpki001:389 (91)
>
>
>
error 91 is:
91 CONNECT_ERROR
Can the system running the ca instance reach the publishing directory on
its tcp port?
> #
>
> #tail localhost.2008-10-20.log
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
> :105)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526
> )
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
> java:107)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1
> 48)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:85
> 6)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC
> onnection(Http11Protocol.java:744)
> at
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint
> .java:527)
> at
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollow
> erWorkerThread.java:80)
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
> .java:684)
> at java.lang.Thread.run(Thread.java:810)
>
>
>
> ##########################################
> # Re-do today "service rhpki-ca restart"
> # after "service dirsrv restart"
> ##########################################
>
>
> # tail system
> 7980.CertStatusUpdateThread - [21/Oct/2008:09:02:43 MST] [5] [3]
> Operation Error - netscape.ldap.LDAPException: not connected (80)
> 7980.CertStatusUpdateThread - [21/Oct/2008:09:02:43 MST] [5] [3] Null
> response control
> 7980.CertStatusUpdateThread - [21/Oct/2008:09:02:43 MST] [5] [3]
> Operation Error - netscape.ldap.LDAPException: not connected (80)
> 7980.CertStatusUpdateThread - [21/Oct/2008:09:02:43 MST] [5] [3] Null
> response control
> 7980.CertStatusUpdateThread - [21/Oct/2008:09:12:43 MST] [5] [3]
> Operation Error - netscape.ldap.LDAPException: not connected (80)
> 7980.CertStatusUpdateThread - [21/Oct/2008:09:12:43 MST] [5] [3] Null
> response control
> 7980.CertStatusUpdateThread - [21/Oct/2008:09:12:43 MST] [5] [3]
> Operation Error - netscape.ldap.LDAPException: not connected (80)
> 7980.CertStatusUpdateThread - [21/Oct/2008:09:12:43 MST] [5] [3] Null
> response control
> 7980.CertStatusUpdateThread - [21/Oct/2008:09:12:43 MST] [5] [3]
> Operation Error - netscape.ldap.LDAPException: not connected (80)
> 7980.CertStatusUpdateThread - [21/Oct/2008:09:12:43 MST] [5] [3] Null
> response control
>
>
> # tail debug
> at
> org.apache.catalina.core.StandardService.start(StandardService.java:450)
> at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:683)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:537)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a:79)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:618)
> at
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:271)
> at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:409)
> [21/Oct/2008:09:24:57][main]: CMSEngine.shutdown()
>
> #
>
>
> Why is CA console not coming up?
>
>
>
Probably the internal db was not running at that moment.
>
> -----Original Message-----
> From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com]
> On Behalf Of Marc Sauton
> Sent: Monday, October 20, 2008 7:04 PM
> To: Adewumi, Julius-p99373
> Cc: pki-users at redhat.com
> Subject: Re: [Pki-users] Cannot write to MasterCRL at CA startup
>
> You can also have a statement to not publish your master crl at start
> time in your CS.cfg:
> ca.crl.MasterCRL.publishOnStart=false
> M.
>
> Marc Sauton wrote:
>
>> Adewumi, Julius-p99373 wrote:
>>
>>> Is anyone familiar with this problem: I configured Ldap-Publishing
>>> on Friday and after the weekend, Whenever the CA attempts to publish
>>> into tne MasterCRL it couldn't and also The Directory Server dies.
>>>
>>>
>> I will assume the "The Directory Server" is an external publishing
>> directory server for your ca instance.
>> If for any reasons the publishing directory is not running, you should
>>
>
>
>> see some error messages in the ca debug or system logs.
>> Could you provide with exact platform info, rpm versions for jre,
>> rhpki-ca and redhat-ds, and some sanitized ca system and debug logs
>> along with matching publishing rhds error logs just before the
>> publishing directory shuts down, or contact off list?
>> Thx,
>> M.
>>
>>> This is Redhat Dirsrv. Anyone aware of a fix for this?
>>>
>>> Julius
>>>
>>> ---------------------------------------------------------------------
>>> ---
>>>
>>> _______________________________________________
>>> Pki-users mailing list
>>> Pki-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pki-users
>>>
>>>
>> _______________________________________________
>> Pki-users mailing list
>> Pki-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-users
>>
>
> _______________________________________________
> Pki-users mailing list
> Pki-users at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-users
>
More information about the Pki-users
mailing list