On Mon, 2013-07-22 at 12:05 +1000, Pete Brown wrote: > On 22 July 2013 11:45, Pete Brown <[email protected]> wrote: > > On 20 July 2013 04:20, Ade Lee <[email protected]> wrote: > >> > >> On Fri, 2013-07-19 at 14:14 +1000, Pete Brown wrote: > >>> I was just trying this again and noticed there is a > >>> /var/log/pki/pki-ca-spawn.20130719140342.log file with what i assume > >>> is the logging for the attempt to create the pki. > >>> right at the end is this entry. > >>> > >>> 2013-07-19 14:04:42 pkispawn : INFO ....... unable to access > >>> security domain through REST interface. Trying old interface. 503 > >>> Server Error: Service Unavailable > >>> > >>> Does anyone know what that means and how to fix it? > >>> > >> > >> This means that the dogtag CA is trying to contact the dogtag master - > >> and is failing to do so. It may be trying to access the wrong port. > >> > >> What version do you have for : > >> rpm -q pki-ca ? > > > > on my master server. > > pki-ca-10.0.3-2.fc18.noarch > > > >> Please attach the logs for the replica CA. > >> /var/log/pki/pki-tomcat/* > > > > I just tried doing the replica install again and was tailing the > > catalina.out while is was running and I think I have discovered the > > problem. > > The jre it seems to have been upgraded and it is still using the old path. > > I shall try and work out how to fix that and will let you know if I get > > stuck. > > What you mentioned assisted with further debugging. > > this is the tail end of catalina.out from my last run > > Jul 22, 2013 11:54:39 AM org.apache.catalina.startup.HostConfig > deployDirectory > INFO: Deploying web application directory /var/lib/pki/pki-tomcat/webapps/ROOT > Jul 22, 2013 11:54:39 AM org.apache.coyote.AbstractProtocol start > INFO: Starting ProtocolHandler ["http-bio-8080"] > Jul 22, 2013 11:54:39 AM org.apache.coyote.AbstractProtocol start > INFO: Starting ProtocolHandler ["http-bio-8443"] > Jul 22, 2013 11:54:39 AM org.apache.coyote.AbstractProtocol start > INFO: Starting ProtocolHandler ["ajp-bio-8009"] > Jul 22, 2013 11:54:39 AM org.apache.catalina.startup.Catalina start > INFO: Server startup in 9498 ms > 11:57:15,198 INFO > (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) > - Deploying javax.ws.rs.core.Application: class > com.netscape.ca.CertificateAuthorityApplication > 11:57:15,218 INFO > (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) > - Adding singleton provider > com.netscape.certsrv.authentication.AuthMethodInterceptor from > Application javax.ws.rs.core.Application > 11:57:15,224 INFO > (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) > - Adding singleton provider com.netscape.certsrv.acls.ACLInterceptor > from Application javax.ws.rs.core.Application > 11:57:15,448 DEBUG (org.jboss.resteasy.core.SynchronousDispatcher:60) > - PathInfo: /securityDomain/domainInfo > AuthInterceptor: SecurityDomainResource.getDomainInfo() > AuthInterceptor: mapping name: default > AuthInterceptor: required auth methods: [*] > AuthInterceptor: anonymous access allowed > 11:57:15,798 DEBUG (org.jboss.resteasy.core.SynchronousDispatcher:60) > - PathInfo: /account/login > AuthInterceptor: AccountResource.login() > AuthInterceptor: mapping name: account > AuthInterceptor: required auth methods: [passwdUserDBAuthMgr, > certUserDBAuthMgr] > AuthInterceptor: anonymous access not allowed > > my guess would be the replica creation is attempting an anonymous bind. > I have those disabled for security reasons. > Is there any way around that without turning on anonymous binds? > I'm assuming the above is on the master. The above messages detail two different interactions between the clone CA and the master CA. That is - the clone contacts the master to ask for its domain info /securityDomain/domainInfo (which requires no auth). The auth here is CA -> CA. It has nothing to do with the database. It then tries to login and the above message indicates that it needs a password or a client auth certificate. So there is nothing in the above that indicates the error.
I really need to see the catalina.out / debug logs on both the replica and master to understand where it is failing. > > >> You are also exactly correct in creating a replica before upgrading to > >> F19. Much older dogtag instances (based on dogtag 9) will not work in > >> f19 due to tomcat6 not being available in f19. > > > > Ahh. > > Did that prompt the amalgamation of the ldap trees? > > > >> > >> Ade > >>> > >>> On 19 July 2013 12:46, Pete Brown <[email protected]> wrote: > >>> > On 18 July 2013 19:50, Petr Viktorin <[email protected]> wrote: > >>> >> On 07/18/2013 03:31 AM, Pete Brown wrote: > >>> >>> > >>> >>> I opened all the ports that seemed to be listening n the master. > >>> >>> I also ran the setup again without disabling the connection check to > >>> >>> see what else needed fixing. > >>> >>> It seems after much investigation and log dredging it seems my admin > >>> >>> password had expired. > >>> >>> I wasn't aware that was possible. > >>> >>> I reset the password and it seemed to get further. > >>> >>> This for some reason not mentioned in the documentation the replica is > >>> >>> trying to ssh into the master as admin. > >>> >>> I managed to fix that by changing my setup and ssh config files. > >>> >>> > >>> >>> Then it actually managed to start the setup process. > >>> >>> But again it fails at exactly the same point mentioned in my initial > >>> >>> email. > >>> >>> > >>> >>> After some further digging with reference to the log output below it > >>> >>> seems I have run into a bug that seems to have been fixed. > >>> >>> https://fedorahosted.org/freeipa/ticket/3213 > >>> >>> As I mentioned I am running current Fedora 18 so freeipa is > >>> >>> 3.1.5-1.fc18 is that fixed in my version? > >>> >> > >>> >> > >>> >> Yes, that bug was fixed in 3.1.0. > >>> > > >>> > Well the script is still complaining about not being able to find > >>> > dogtag_master_ds_port and the option still appears in my version of > >>> > the script. > >>> > Which from the bug seems to be what was causing the issue and the > >>> > ipareplica-install log I included below says this is the case. > >>> > It seems a bit odd because this is a fresh install of 3.1.5. > >>> > > >>> > > >>> > > >>> >>> It also seems the dogatg and IPA directories will be or have been > >>> >>> merged? > >>> >>> Which version did this happen in and will it get applied to my server? > >>> >> > >>> >> > >>> >> Also in 3.1.0; new servers installed using that version have merged > >>> >> databases. > >>> > > >>> > I still seem to have split instances. > >>> > I did the install before Fedora 18 was released because I wanted ipa 3 > >>> > and that was the only way I could get it. > >>> > Will they get merged at some point or can I do it manually? > >>> > > >>> >> > >>> >>> Can anyone suggest how I go about fixing this issue? > >>> >> > >>> >> > >>> >> Well, ipa-server-uninstall can misbehave if CA installation goes wrong > >>> >> (ticket #2796). > >>> >> So I would start by uninstalling, then running the following command > >>> >> to make > >>> >> sure CA is not left: > >>> >> sudo pkidestroy -s CA -i pki-tomcat > >>> >> then installing again. > >>> > > >>> > Ran that on my replica after the install and before the clean and it > >>> > said this. > >>> > That would make sense because it fails during the ca creation stage. > >>> > > >>> > root@ipa2 ~]# pkidestroy -s CA -i pki-tomcat > >>> > ERROR: PKI instance '/var/lib/pki/pki-tomcat' does NOT exist! > >>> > > >>> > > >>> >> > >>> >> Can you also provide logs without the --skip-conncheck flag? > >>> >> Specifically > >>> >> the /var/log/ipareplica-conncheck.log should be interesting. > >>> > > >>> > From what I can tell all the tests in the connection check passed. > >>> > > >>> >> > >>> >> > >>> >>> I wanted to create a replica so I could upgrade to fedora 19 and not > >>> >>> have to take my single instance of FreeIPA offline while that was > >>> >>> happening. > >>> >>> Will I need to upgrade to Fedora 19 to fix my issue? > >>> >> > >>> >> > >>> >> > >>> >>> For reference this is the point of failure in the > >>> >>> /var/log/ipareplica-install.log file > >>> >>> > >>> >>> 2013-07-18T01:06:16Z DEBUG Starting external process > >>> >>> 2013-07-18T01:06:16Z DEBUG args=/usr/sbin/pkispawn -s CA -f > >>> >>> /tmp/tmpFKBxMW > >>> >>> 2013-07-18T01:08:16Z DEBUG Process finished, return code=1 > >>> >>> 2013-07-18T01:08:16Z DEBUG stdout=Loading deployment configuration > >>> >>> from /tmp/tmpFKBxMW. > >>> >>> ERROR: Unable to access security domain: 503 Server Error: Service > >>> >>> Unavailable > >>> >> > >>> >> > >>> >> Please also check logs on the existing server. Is the CA available? > >>> >> Does e.g. `ipa cert-show 1` work? > >>> >> > >>> >>> 2013-07-18T01:08:16Z DEBUG stderr= > >>> >>> 2013-07-18T01:08:16Z CRITICAL failed to configure ca instance Command > >>> >>> '/usr/sbin/pkispawn -s CA -f /tmp/tmpFKBxMW' returned non-zero exit > >>> >>> status 1 > >>> >>> 2013-07-18T01:08:16Z INFO File > >>> >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > >>> >>> line 619, in run_script > >>> >>> return_value = main_function() > >>> >>> > >>> >>> File "/usr/sbin/ipa-replica-install", line 652, in main > >>> >>> (CA, cs) = cainstance.install_replica_ca(config, > >>> >>> dogtag_master_ds_port) > >>> >>> > >>> >>> File > >>> >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > >>> >>> line 1809, in install_replica_ca > >>> >>> subject_base=config.subject_base) > >>> >>> > >>> >>> File > >>> >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > >>> >>> line 625, in configure_instance > >>> >>> self.start_creation(runtime=210) > >>> >>> > >>> >>> File > >>> >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > >>> >>> line 358, in start_creation > >>> >>> method() > >>> >>> > >>> >>> File > >>> >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > >>> >>> line 744, in __spawn_instance > >>> >>> raise RuntimeError('Configuration of CA failed') > >>> >>> > >>> >>> 2013-07-18T01:08:16Z INFO The ipa-replica-install command failed, > >>> >>> exception: RuntimeError: Configuration of CA failed > >>> >>> > >>> >>> On 17 July 2013 15:52, Pete Brown <[email protected]> wrote: > >>> >>>> > >>> >>>> Hi everyone, > >>> >>>> > >>> >>>> I am attempting to create a replica of my freeipa server. > >>> >>>> I am following the docs but they are not working for me. > >>> >>>> I am getting the vague impression I am missing a step that doesn't > >>> >>>> seem to be documented. > >>> >>>> > >>> >>>> For the record all the posts listed are open and it was a clean > >>> >>>> install of Fedora 18. > >>> >>>> > >>> >>>> I thought the server may need to be a client of the master before I > >>> >>>> set it up as a replica but it just said I needed to uninstall the > >>> >>>> client setup. > >>> >>>> > >>> >>>> After running ipa-replica-prepare on the master and scping the file > >>> >>>> to > >>> >>>> the new replica. > >>> >>>> I ran this command on the new replica > >>> >>>> ipa-replica-install --setup-ca --mkhomedir --ssh-trust-dns > >>> >>>> --setup-dns > >>> >>>> --forwarder=XXX.XXX.XXX.XX --forwarder=XX.XXX.XXX.XXX > >>> >>>> /var/lib/ipa/replica-info-ipa2.domain.com.gpg > >>> >>>> > >>> >>>> The error I am seeing is from that command is this: > >>> >>>> Cannot acquire Kerberos ticket: kinit: Cannot read password while > >>> >>>> getting initial credentials > >>> >>>> > >>> >>>> Connection check failed! > >>> >>>> Please fix your network settings according to error messages above. > >>> >>>> If the check results are not valid it can be skipped with > >>> >>>> --skip-conncheck parameter. > >>> >>>> > >>> >>>> So I cleaned everything off (i think) and tried it with this command > >>> >>>> > >>> >>>> ipa-replica-install --setup-ca --mkhomedir --ssh-trust-dns > >>> >>>> --setup-dns > >>> >>>> --forwarder=61.9.211.33 --forwarder=61.9.211.1 --skip-conncheck > >>> >>>> /var/lib/ipa/replica-info-ipa2.webgatetec.com.gpg > >>> >>>> > >>> >>>> This seems to actually start the install and setup process i remember > >>> >>>> from installing the ipa server initially > >>> >>>> > >>> >>>> This it fails with this output > >>> >>>> > >>> >>>> WARNING: conflicting time&date synchronization service 'chronyd' will > >>> >>>> be disabled in favor of ntpd > >>> >>>> > >>> >>>> Directory Manager (existing master) password: > >>> >>>> > >>> >>>> Configuring NTP daemon (ntpd) > >>> >>>> [1/4]: stopping ntpd > >>> >>>> [2/4]: writing configuration > >>> >>>> [3/4]: configuring ntpd to start on boot > >>> >>>> [4/4]: starting ntpd > >>> >>>> Done configuring NTP daemon (ntpd). > >>> >>>> Configuring directory server (dirsrv): Estimated time 1 minute > >>> >>>> [1/31]: creating directory server user > >>> >>>> [2/31]: creating directory server instance > >>> >>>> [3/31]: adding default schema > >>> >>>> [4/31]: enabling memberof plugin > >>> >>>> [5/31]: enabling winsync plugin > >>> >>>> [6/31]: configuring replication version plugin > >>> >>>> [7/31]: enabling IPA enrollment plugin > >>> >>>> [8/31]: enabling ldapi > >>> >>>> [9/31]: configuring uniqueness plugin > >>> >>>> [10/31]: configuring uuid plugin > >>> >>>> [11/31]: configuring modrdn plugin > >>> >>>> [12/31]: configuring DNS plugin > >>> >>>> [13/31]: enabling entryUSN plugin > >>> >>>> [14/31]: configuring lockout plugin > >>> >>>> [15/31]: creating indices > >>> >>>> [16/31]: enabling referential integrity plugin > >>> >>>> [17/31]: configuring ssl for ds instance > >>> >>>> [18/31]: configuring certmap.conf > >>> >>>> [19/31]: configure autobind for root > >>> >>>> [20/31]: configure new location for managed entries > >>> >>>> [21/31]: restarting directory server > >>> >>>> [22/31]: setting up initial replication > >>> >>>> Starting replication, please wait until this has completed. > >>> >>>> Update in progress > >>> >>>> Update in progress > >>> >>>> Update in progress > >>> >>>> Update in progress > >>> >>>> Update succeeded > >>> >>>> [23/31]: adding replication acis > >>> >>>> [24/31]: setting Auto Member configuration > >>> >>>> [25/31]: enabling S4U2Proxy delegation > >>> >>>> [26/31]: initializing group membership > >>> >>>> [27/31]: adding master entry > >>> >>>> [28/31]: configuring Posix uid/gid generation > >>> >>>> [29/31]: enabling compatibility plugin > >>> >>>> [30/31]: tuning directory server > >>> >>>> [31/31]: configuring directory to start on boot > >>> >>>> Done configuring directory server (dirsrv). > >>> >>>> Configuring certificate server (pki-tomcatd): Estimated time 3 > >>> >>>> minutes > >>> >>>> 30 seconds > >>> >>>> [1/17]: creating certificate server user > >>> >>>> [2/17]: configuring certificate server instance > >>> >>>> ipa : CRITICAL failed to configure ca instance Command > >>> >>>> '/usr/sbin/pkispawn -s CA -f /tmp/tmptGcdgB' returned non-zero exit > >>> >>>> status 1 > >>> >>>> > >>> >>>> Your system may be partly configured. > >>> >>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. > >>> >>>> > >>> >>>> Configuration of CA failed > >>> >>>> > >>> >>>> I even tried cleaning it again at that point and made sure all the > >>> >>>> ports were open and still got the same error. > >>> >>>> > >>> >>>> I also switched selinux to permissive mode cleaned up and rebooted > >>> >>>> but > >>> >>>> that didn't help either > >>> >>>> > >>> >>>> Can someone please point out what I need to do to get this working. > >>> >>>> > >>> >>>> Thanks in advance. > >>> >>>> Pete. > >>> >>> > >>> >>> > >>> >>> _______________________________________________ > >>> >>> Freeipa-users mailing list > >>> >>> [email protected] > >>> >>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>> >>> > >>> >> > >>> >> > >>> >> -- > >>> >> Petrł > >>> > >>> _______________________________________________ > >>> Freeipa-users mailing list > >>> [email protected] > >>> https://www.redhat.com/mailman/listinfo/freeipa-users > >> > >> _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
