Uzor Ide wrote:
Anybody with idea why my replication setup is hanging at stage 4 of the
11 stage process.
#########################################################
Configuring directory server for the CA: Estimated time 30 seconds
[1/3]: creating directory server user
[2/3]: creating directory server instance
[3/3]: restarting directory server
done configuring pkids.
Configuring certificate server: Estimated time 6 minutes
[1/11]: creating certificate server user
[2/11]: creating pki-ca instance
[3/11]: restarting certificate server
[4/11]: configuring certificate server instance
###############################################################
When I checked the pki-ca debug log, everything is okay until it gets to
the this stage and it keeps repeating the last entry.
####################################################################
[06/Jun/2011:16:00:13][http-9445-1]: DatabasePanel initializeConsumer:
initializeConsumer host: company.domain.com <http://company.domain.com>
port: 7389
[06/Jun/2011:16:00:13][http-9445-1]: DatabasePanel initializeConsumer:
start modifying
[06/Jun/2011:16:00:14][http-9445-1]: DatabasePanel initializeConsumer:
Finish modification.
[06/Jun/2011:16:00:14][http-9445-1]: DatabasePanel initializeConsumer:
thread sleeping for 5 seconds.
[06/Jun/2011:16:00:19][http-9445-1]: DatabasePanel initializeConsumer:
finish sleeping.
[06/Jun/2011:16:00:19][http-9445-1]: DatabasePanel initializeConsumer:
Successfully initialize consumer
[06/Jun/2011:16:00:19][http-9445-1]: DatabasePanel
comparetAndWaitEntries checking ou=people,o=ipaca
[06/Jun/2011:16:00:30][http-9445-1]: DatabasePanel
comparetAndWaitEntries ou=people,o=ipaca not found, let's wait!
[06/Jun/2011:16:00:35][http-9445-1]: DatabasePanel
comparetAndWaitEntries checking ou=people,o=ipaca
[06/Jun/2011:16:00:35][http-9445-1]: DatabasePanel
comparetAndWaitEntries ou=people,o=ipaca not found, let's wait!
########################################################################
Can you reproduce this again and while it is looping like this telnet
from the master to your replica on port 9445? Perhaps it is something
else in the network, but something is preventing replication from
proceeding. The 389-ds access and error logs on the master may hold some
clues as well.
If leave for hours, it will continue will keep repeating the last entry.
In the catalina.out log, I get the following java execption
###########################################################################
INFO: Deploying web application directory ca
Jun 6, 2011 3:58:36 PM org.apache.catalina.startup.Catalina stopServer
SEVERE: Catalina.stop:
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)
at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
at java.net.Socket.connect(Socket.java:546)
at java.net.Socket.connect(Socket.java:495)
at java.net.Socket.<init>(Socket.java:392)
at java.net.Socket.<init>(Socket.java:206)
at
org.apache.catalina.startup.Catalina.stopServer(Catalina.java:412)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:338)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:416)
32-bit osutil library loaded
32-bit osutil library loaded
CMS Warning: FAILURE: Cannot build CA chain. Error
java.security.cert.CertificateException: Certificate is not a PKCS #11
certificate|FAILURE: authz instance DirAclAuthz initialization failed
and skipped, error=Property internaldb.ldapconn.port missing value|
Server is started.
Jun 6, 2011 3:58:44 PM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory ROOT
#############################################################
While this points to connection failure, I don't know why that is so
because there is not firewall running on the two boxes, also I disabled
selinux just to make sure but it did not make any difference.
The backtrace is just tomcat being tomcat. If you ask tomcat to stop
itself and it isn't running it throws this big scary message.
This is not likely to be an SELinux issue, if it were you would see lots
of AVCs in /var/log/audit/audit.log if you want to check.
There is a bug number 643449 with this exception thrown here in bugzilla
but that issue was supposed to be caused by missing
xalan-j2-serializer.jar file in the tomcat5. This is tomcat6.
Please any help will be appreciated.
Thanks
__Ide
On Fri, Jun 3, 2011 at 2:32 PM, Uzor Ide <[email protected]
<mailto:[email protected]>> wrote:
I have corrected the problem with the ipa server, from the broken
tomcat/pki-ca;
The problem comes a sym link that was created during the setup of
pki-ca from PKI-HOME for
jakarta-commons-collections.jar to
/usr/share/java/jakarta-commons-collections.jar.
This file is a member of jakarta-commons-collections rpm package in
fc14. In fc15 jakarta-commons-collections package appears to have
been renamed to apache-commons-collections and an equivalent file
apache-commons-collections.jar is contained.
However when you upgrade, at least in my own case using preupgrade,
it leaves
/var/lib/pki-ca/webapps/ca/WEB-INF/lib/jakarta-commons-collections.jar
link orphaned. recreating the sym link to
/usr/share/java/apache-commons-collections.jar fixes the problem.
I have create a new replica package and I see that it contained the
dogtagcert.p12 file.
I will try to install the replica and see how it goes.
Thanks
__Ide
On Fri, Jun 3, 2011 at 10:28 AM, Uzor Ide <[email protected]
<mailto:[email protected]>> wrote:
The IPA server is version 2.0.0 R3 which is supposed to install
on fc14 with some packages from updates-testing repo, while the
replica install is on server 2.0.1
Yes, there is no dogtagcert.p12 file; here are the files contained:
realm_info/httpcert.p12
realm_info/cacert.p12
realm_info/ldappwd
realm_info/ra.p12
realm_info/http_pin.txt
realm_info/realm_info
realm_info/configure.jar
realm_info/dscert.p12
realm_info/dirsrv_pin.txt
realm_info/pwdfile.txt.ori
realm_info/pwdfile.txt
realm_info/kpasswd.keytab
realm_info/preferences.htm
realm_info/ca.crt
I have upgraded the IPA box to fc15 and freeipa-2.0.1 in the
quest to get a correct replica package but that seems to have
created another problem as it has broken the tomcat and thus pki-ca.
Jun 3, 2011 10:09:29 AM org.apache.catalina.loader.WebappLoader
start
SEVERE: LifecycleException
java.io.IOException: Failed to access resource
/WEB-INF/lib/jakarta-commons-collections.jar
at
org.apache.catalina.loader.WebappLoader.setRepositories(WebappLoader.java:1050)
at
org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:681)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4541)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:546)
at
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
at
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
at
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1061)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:785)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463)
at
org.apache.catalina.core.StandardService.start(StandardService.java:525)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:701)
at
org.apache.catalina.startup.Catalina.start(Catalina.java:585)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
Caused by: javax.naming.NamingException: Resource
jakarta-commons-collections.jar not found
at
org.apache.naming.resources.FileDirContext.lookup(FileDirContext.java:209)
at
org.apache.catalina.loader.WebappLoader.setRepositories(WebappLoader.java:1048)
... 24 more
It seems to me that it is looking for
jakarta-commons-collections.jar which exist but is a package
from the old tomcat6-6.0.26.
Thanks
__Ide
On Thu, Jun 2, 2011 at 11:08 AM, Rob Crittenden
<[email protected] <mailto:[email protected]>> wrote:
Uzor Ide wrote:
Thanks Rob
I did run the certutil -L -d /etc/dirsrv/slapd-PKI-IPA
command; the
nssdb is empty
If the CA cert is supposed to exist there at that stage
of install,
then that would be the problem.
Both the slapd-PKI-IPA error and access does not contain
much. I
attached them herein with the ipareplica-install.log.
How old is the prepared replica file, and was it created
with an older version of IPA?
In one of the last release candidates we started creating a
separate SSL certificate for the 389-ds instance used by
dogtag. I get the feeling that doesn't exist which would
explain why SSL is failing.
You can check by doing something like:
# gpg -d replica-info-<your-server>.gpg | tar tvf -
The file you're looking for is dogtagcert.p12
rob
thanks
Ide
On Wed, Jun 1, 2011 at 11:40 AM, Rob Crittenden
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
Uzor Ide wrote:
Hi all
We are trying to setup a backup IPA server and
decided to toe that
replication route.
The box is a fedora 14 with freeipa-2.0-RC2
which I upgraded to
fedora
15 and freeipa 2.0.1.
Note we first did ipa-server-install --uninstall
before
upgrading the
freeipa packages so as to make sure that the
server is
relatively clean.
However when I run that ipa-replica-install
command, I end up
with the
following error in the ipareplica-install.log
2011-05-31 23:54:33,352 DEBUG args=/sbin/service
dirsrv restart
PKI-IPA
2011-05-31 23:54:33,353 DEBUG stdout=Shutting
down dirsrv:
PKI-IPA...[ OK ]
Starting dirsrv:
PKI-IPA...[FAILED]
*** Warning: 1 instance(s) failed to start
2011-05-31 23:54:33,354 DEBUG
stderr=[31/May/2011:23:54:23
-0400] - SSL
alert: Security Initialization: Unable to
authenticate (Netscape
Portable Runtime error -8192 - An I/O error
occurred during security
authorization.)
[31/May/2011:23:54:23 -0400] - ERROR: SSL
Initialization Failed.
2011-05-31 23:54:33,497 DEBUG args=/sbin/service
dirsrv status
2011-05-31 23:54:33,500 DEBUG stdout=dirsrv
PKI-IPA is stopped
2011-05-31 23:54:33,501 DEBUG stderr=
2011-05-31 23:54:33,502 CRITICAL Failed to
restart the directory
server.
See the installation log for details.
This are the tomcat rpms on the server
tomcat5-servlet-2.4-api-5.5.31-3.fc15.noarch
tomcat6-jsp-2.1-api-6.0.30-6.fc15.noarch
tomcat6-6.0.30-6.fc15.noarch
tomcat6-servlet-2.5-api-6.0.30-6.fc15.noarch
tomcat6-lib-6.0.30-6.fc15.noarch
tomcat6-el-2.1-api-6.0.30-6.fc15.noarch
tomcatjss-2.1.1-1.fc15.noarch
So the tomcat6 version is definitely greater
than tomcat6-6-0.30-5.
The /var/log/dirsrv/slapd-PKI-IPA/errors logs
does not show any
other
thing different from same,
[31/May/2011:23:54:23 -0400] - SSL alert:
Security Initialization:
Unable to authenticate (Netscape Portable
Runtime error -8192 -
An I/O
error occurred during security authorization.)
[31/May/2011:23:54:23 -0400] - ERROR: SSL
Initialization Failed
Any help will be greatly appreciated
Ide
I think we need more context. Can you compress and send
/var/log/ipareplica-install.log ?
I'd also suggest looking at
/var/log/dirsrv/PKI-IPA/access and
errors to see if there is anything interesting there.
And can you provide the output for:
certutil -L -d /etc/dirsrv/slapd-PKI-IPA
It would seem that your 389-ds instance is missing a
copy of the CA
cert.
thanks
rob
_______________________________________________
Freeipa-users mailing list
[email protected] <mailto:[email protected]>
https://www.redhat.com/mailman/listinfo/freeipa-users
_______________________________________________
Freeipa-users mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-users
