Re: [Freeipa-users] IPA Replica Issues
Hi, Check your GSSAPIAuthentication settings in sshd.conf and restart sshd: GSSAPIAuthentication yes GSSAPICleanupCredentials yes Last week I had some replication problems between replicas which were fixed after re-enabling GSSAPI. Regards, Suhail Choudhury. DevOps | Recommendations Team | BSkyB From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Joseph, Matthew (EXP) [matthew.jos...@lmco.com] Sent: 28 July 2014 17:46 To: freeipa-users@redhat.com Subject: [Freeipa-users] IPA Replica Issues Hello, I’m currently running into some issues with my replica server. I noticed it wasn’t getting any updates from the master server so I tried to do a force-sync but it states that it is an “invalid password” which I know it is not the case. I tried doing an ipa-replica-manager list replica_server but it gives me the SASL(-13) authentication failure: GSSAPI Failure: gss_accept_sec_context, ‘desc’ Invalid Credentials I’ve tried doing a kdestroy and have it prompt me for the password but again, same error. Any idea what this would be? Thanks, Matt Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and Sky International AG and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA Replica Issues
Hey Suhail, Issue has been resolved; it was actually my replica server being about 10 minutes out of sync from the master which was causing the credential errors. Matt From: Choudhury, Suhail [mailto:suhail.choudh...@bskyb.com] Sent: Wednesday, July 30, 2014 9:00 AM To: Joseph, Matthew (EXP); freeipa-users@redhat.com Subject: EXTERNAL: RE: IPA Replica Issues Hi, Check your GSSAPIAuthentication settings in sshd.conf and restart sshd: GSSAPIAuthentication yes GSSAPICleanupCredentials yes Last week I had some replication problems between replicas which were fixed after re-enabling GSSAPI. Regards, Suhail Choudhury. DevOps | Recommendations Team | BSkyB From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Joseph, Matthew (EXP) [matthew.jos...@lmco.com] Sent: 28 July 2014 17:46 To: freeipa-users@redhat.com Subject: [Freeipa-users] IPA Replica Issues Hello, I'm currently running into some issues with my replica server. I noticed it wasn't getting any updates from the master server so I tried to do a force-sync but it states that it is an invalid password which I know it is not the case. I tried doing an ipa-replica-manager list replica_server but it gives me the SASL(-13) authentication failure: GSSAPI Failure: gss_accept_sec_context, 'desc' Invalid Credentials I've tried doing a kdestroy and have it prompt me for the password but again, same error. Any idea what this would be? Thanks, Matt Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and Sky International AG and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA Replica Issues
Choudhury, Suhail wrote: Hi, Check your GSSAPIAuthentication settings in sshd.conf and restart sshd: GSSAPIAuthentication yes GSSAPICleanupCredentials yes Last week I had some replication problems between replicas which were fixed after re-enabling GSSAPI. I have the feeling this was just coincidence as replication doesn't use ssh. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] IPA Replica Issues
Hello, I'm currently running into some issues with my replica server. I noticed it wasn't getting any updates from the master server so I tried to do a force-sync but it states that it is an invalid password which I know it is not the case. I tried doing an ipa-replica-manager list replica_server but it gives me the SASL(-13) authentication failure: GSSAPI Failure: gss_accept_sec_context, 'desc' Invalid Credentials I've tried doing a kdestroy and have it prompt me for the password but again, same error. Any idea what this would be? Thanks, Matt -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA Replica Issues
On 07/28/2014 12:46 PM, Joseph, Matthew (EXP) wrote: Hello, I'm currently running into some issues with my replica server. I noticed it wasn't getting any updates from the master server so I tried to do a force-sync but it states that it is an invalid password which I know it is not the case. I tried doing an ipa-replica-manager list replica_server but it gives me the SASL(-13) authentication failure: GSSAPI Failure: gss_accept_sec_context, 'desc' Invalid Credentials I've tried doing a kdestroy and have it prompt me for the password but again, same error. Any idea what this would be? Thanks, Matt Joe, Are you actually getting a valid Kerberos ticket - on the surface it would not appear so. Also, the command is 'ipa-replica-manage list': Example: # ipa-replica-manage list idm-srv1.example.com: master idm-srv2.example.com: master -m -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA Replica Issues
On 07/28/2014 02:12 PM, Mark Heslin wrote: On 07/28/2014 12:46 PM, Joseph, Matthew (EXP) wrote: Hello, I'm currently running into some issues with my replica server. I noticed it wasn't getting any updates from the master server so I tried to do a force-sync but it states that it is an invalid password which I know it is not the case. I tried doing an ipa-replica-manager list replica_server but it gives me the SASL(-13) authentication failure: GSSAPI Failure: gss_accept_sec_context, 'desc' Invalid Credentials I've tried doing a kdestroy and have it prompt me for the password but again, same error. Any idea what this would be? Thanks, Matt Joe, Are you actually getting a valid Kerberos ticket - on the surface it would not appear so. Also, the command is 'ipa-replica-manage list': Example: # ipa-replica-manage list idm-srv1.example.com: master idm-srv2.example.com: master -m Joe, I forgot to add, you should be able to do this without a Kerberos ticket but you'll need to specify the Directory Mnager password: Example: # ipa-replica-manage list Directory Manager password: idm-srv1.example.com: master idm-srv2.example.com: master # klist klist: No credentials cache found (ticket cache KEYRING:persistent:0:0) I'm runnning RHEL 7 - not sure whether or not this behavior is different on earlier versions. -m -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
Thanks. I added /var/log/messages to the gist ( https://gist.github.com/nevsan/8b6f78d7396963dc5f70)--no segfaults it seems. Any other kind of disorderly shutdowns that might happen? I'll look into creating a ticket for this. On Fri, Apr 4, 2014 at 9:16 PM, Rich Megginson rmegg...@redhat.com wrote: On 04/03/2014 10:25 PM, Nevada Sanchez wrote: I followed the instructions that would give me a core dump, and for some reason, I don't see one in /var/log/dirsrv/slapd-EXAMPLE-COM/, even though I still see the Disorderly shutdown still shows up in the logs. Hmm - check again - it should produce a core file grep -i segfault /var/log/messages I know that when I explicitly request those attributes, I get -1 Total update abortedLDAP error: Can't contact LDAP server for nds5ReplicaLastInitStatus (see below). Access logs stop completely on the replica after the time that you mentioned. Hmm - looks like a bug. Please open a ticket. == [root@ipa2 ipaserver]# ldapsearch ldaps://ipa.example.com:636 -D 'cn=Directory Manager' -w # -b 'cn=meToipa2.example.comhttp://metoipa2.example.com/,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config' '(objectClass=*)' -s base nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5ReplicaLastInitEnd # extended LDIF # # LDAPv3 # base cn=meToipa2.example.com http://metoipa2.example.com/,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config with scope baseObject # filter: (objectclass=*) # requesting: ldaps://ipa.example.com:636 (objectClass=*) nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5ReplicaLastInitEnd # # meToipa2.example.com http://metoipa2.example.com/, replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config dn: cn=meToipa2.example.com http://metoipa2.example.com/ ,cn=replica,cn=dc\3Dexample\2Cd c\3Dcom,cn=mapping tree,cn=config nsds5ReplicaLastInitStart: 20140401092800Z nsds5replicaUpdateInProgress: FALSE nsds5ReplicaLastInitStatus: -1 Total update abortedLDAP error: Can't contact L DAP server cn: meToipa2.example.com http://metoipa2.example.com/ nsds5ReplicaLastInitEnd: 20140401092804Z # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 On Thu, Apr 3, 2014 at 6:32 PM, Rich Megginson rmegg...@redhat.comwrote: On 04/03/2014 03:46 PM, Nevada Sanchez wrote: Okay, I updated the gist and extended some of the logs (ipa2-errors does stop at 20:50:21). I'll follow up when I have the debug stuff in place. https://gist.github.com/nevsan/8b6f78d7396963dc5f70 Another strange thing - it looks as if the initial replica init completes successfully. [02/Apr/2014:20:50:18 +] NSMMReplicationPlugin - Beginning total update of replica agmt=cn=meToipa2.example.com (ipa2:389). On the replica: [02/Apr/2014:20:50:18 +] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=example,dc=com is going offline; disabling replication [02/Apr/2014:20:50:18 +] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [02/Apr/2014:20:50:21 +] - import userRoot: Workers finished; cleaning up... [02/Apr/2014:20:50:21 +] - import userRoot: Workers cleaned up. [02/Apr/2014:20:50:21 +] - import userRoot: Indexing complete. Post-processing... [02/Apr/2014:20:50:21 +] - import userRoot: Generating numSubordinates complete. [02/Apr/2014:20:50:21 +] - import userRoot: Flushing caches... [02/Apr/2014:20:50:21 +] - import userRoot: Closing files... [02/Apr/2014:20:50:21 +] - import userRoot: Import complete. Processed 453 entries in 3 seconds. (151.00 entries/sec) [02/Apr/2014:20:50:21 +] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=example,dc=com is coming online; enabling replication On the master, access log: [02/Apr/2014:20:50:17 +] conn=1365 op=15 MOD dn=cn= meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config This is the operation that triggers the replica init. Then ipa-replica-install polls for agreement status: [02/Apr/2014:20:50:19 +] conn=1365 op=16 SRCH base=cn= meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config scope=0 filter=(objectClass=*) attrs=nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5replicaLastInitEnd [02/Apr/2014:20:50:19 +] conn=1365 op=16 RESULT err=0 tag=101 nentries=1 etime=0 [02/Apr/2014:20:50:20 +] conn=1365 op=17 SRCH base=cn= meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config scope=0 filter=(objectClass=*) attrs=nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn
Re: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
I followed the instructions that would give me a core dump, and for some reason, I don't see one in /var/log/dirsrv/slapd-EXAMPLE-COM/, even though I still see the Disorderly shutdown still shows up in the logs. I know that when I explicitly request those attributes, I get -1 Total update abortedLDAP error: Can't contact LDAP server for nds5ReplicaLastInitStatus (see below). Access logs stop completely on the replica after the time that you mentioned. == [root@ipa2 ipaserver]# ldapsearch ldaps://ipa.example.com:636 -D 'cn=Directory Manager' -w # -b 'cn=meToipa2.example.comhttp://metoipa2.example.com/,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config' '(objectClass=*)' -s base nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5ReplicaLastInitEnd # extended LDIF # # LDAPv3 # base cn=meToipa2.example.com http://metoipa2.example.com/,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config with scope baseObject # filter: (objectclass=*) # requesting: ldaps://ipa.example.com:636 (objectClass=*) nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5ReplicaLastInitEnd # # meToipa2.example.com http://metoipa2.example.com/, replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config dn: cn=meToipa2.example.com http://metoipa2.example.com/ ,cn=replica,cn=dc\3Dexample\2Cd c\3Dcom,cn=mapping tree,cn=config nsds5ReplicaLastInitStart: 20140401092800Z nsds5replicaUpdateInProgress: FALSE nsds5ReplicaLastInitStatus: -1 Total update abortedLDAP error: Can't contact L DAP server cn: meToipa2.example.com http://metoipa2.example.com/ nsds5ReplicaLastInitEnd: 20140401092804Z # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 On Thu, Apr 3, 2014 at 6:32 PM, Rich Megginson rmegg...@redhat.com wrote: On 04/03/2014 03:46 PM, Nevada Sanchez wrote: Okay, I updated the gist and extended some of the logs (ipa2-errors does stop at 20:50:21). I'll follow up when I have the debug stuff in place. https://gist.github.com/nevsan/8b6f78d7396963dc5f70 Another strange thing - it looks as if the initial replica init completes successfully. [02/Apr/2014:20:50:18 +] NSMMReplicationPlugin - Beginning total update of replica agmt=cn=meToipa2.example.com (ipa2:389). On the replica: [02/Apr/2014:20:50:18 +] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=example,dc=com is going offline; disabling replication [02/Apr/2014:20:50:18 +] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [02/Apr/2014:20:50:21 +] - import userRoot: Workers finished; cleaning up... [02/Apr/2014:20:50:21 +] - import userRoot: Workers cleaned up. [02/Apr/2014:20:50:21 +] - import userRoot: Indexing complete. Post-processing... [02/Apr/2014:20:50:21 +] - import userRoot: Generating numSubordinates complete. [02/Apr/2014:20:50:21 +] - import userRoot: Flushing caches... [02/Apr/2014:20:50:21 +] - import userRoot: Closing files... [02/Apr/2014:20:50:21 +] - import userRoot: Import complete. Processed 453 entries in 3 seconds. (151.00 entries/sec) [02/Apr/2014:20:50:21 +] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=example,dc=com is coming online; enabling replication On the master, access log: [02/Apr/2014:20:50:17 +] conn=1365 op=15 MOD dn=cn= meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config This is the operation that triggers the replica init. Then ipa-replica-install polls for agreement status: [02/Apr/2014:20:50:19 +] conn=1365 op=16 SRCH base=cn= meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config scope=0 filter=(objectClass=*) attrs=nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5replicaLastInitEnd [02/Apr/2014:20:50:19 +] conn=1365 op=16 RESULT err=0 tag=101 nentries=1 etime=0 [02/Apr/2014:20:50:20 +] conn=1365 op=17 SRCH base=cn= meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config scope=0 filter=(objectClass=*) attrs=nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5replicaLastInitEnd [02/Apr/2014:20:50:20 +] conn=1365 op=17 RESULT err=0 tag=101 nentries=1 etime=0 [02/Apr/2014:20:50:21 +] conn=1365 op=18 SRCH base=cn= meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config scope=0 filter=(objectClass=*) attrs=nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5replicaLastInitEnd [02/Apr/2014:20:50:21 +] conn=1365 op=18 RESULT err=0 tag=101 nentries=1 etime=0 [02/Apr/2014:20:50:22
Re: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
On 04/03/2014 03:46 PM, Nevada Sanchez wrote: Okay, I updated the gist and extended some of the logs (ipa2-errors does stop at 20:50:21). I'll follow up when I have the debug stuff in place. https://gist.github.com/nevsan/8b6f78d7396963dc5f70 Another strange thing - it looks as if the initial replica init completes successfully. [02/Apr/2014:20:50:18 +] NSMMReplicationPlugin - Beginning total update of replica agmt=cn=meToipa2.example.com (ipa2:389). On the replica: [02/Apr/2014:20:50:18 +] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=example,dc=com is going offline; disabling replication [02/Apr/2014:20:50:18 +] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [02/Apr/2014:20:50:21 +] - import userRoot: Workers finished; cleaning up... [02/Apr/2014:20:50:21 +] - import userRoot: Workers cleaned up. [02/Apr/2014:20:50:21 +] - import userRoot: Indexing complete. Post-processing... [02/Apr/2014:20:50:21 +] - import userRoot: Generating numSubordinates complete. [02/Apr/2014:20:50:21 +] - import userRoot: Flushing caches... [02/Apr/2014:20:50:21 +] - import userRoot: Closing files... [02/Apr/2014:20:50:21 +] - import userRoot: Import complete. Processed 453 entries in 3 seconds. (151.00 entries/sec) [02/Apr/2014:20:50:21 +] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=example,dc=com is coming online; enabling replication On the master, access log: [02/Apr/2014:20:50:17 +] conn=1365 op=15 MOD dn=cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config This is the operation that triggers the replica init. Then ipa-replica-install polls for agreement status: [02/Apr/2014:20:50:19 +] conn=1365 op=16 SRCH base=cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config scope=0 filter=(objectClass=*) attrs=nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5replicaLastInitEnd [02/Apr/2014:20:50:19 +] conn=1365 op=16 RESULT err=0 tag=101 nentries=1 etime=0 [02/Apr/2014:20:50:20 +] conn=1365 op=17 SRCH base=cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config scope=0 filter=(objectClass=*) attrs=nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5replicaLastInitEnd [02/Apr/2014:20:50:20 +] conn=1365 op=17 RESULT err=0 tag=101 nentries=1 etime=0 [02/Apr/2014:20:50:21 +] conn=1365 op=18 SRCH base=cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config scope=0 filter=(objectClass=*) attrs=nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5replicaLastInitEnd [02/Apr/2014:20:50:21 +] conn=1365 op=18 RESULT err=0 tag=101 nentries=1 etime=0 [02/Apr/2014:20:50:22 +] conn=1365 op=19 SRCH base=cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config scope=0 filter=(objectClass=*) attrs=nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5replicaLastInitEnd [02/Apr/2014:20:50:22 +] conn=1365 op=19 RESULT err=0 tag=101 nentries=1 etime=1 Something happens here. The replica init is done, according to the replica error log. We don't have the replica access log from around this time to see exactly when the connection was closed, but looking at the ipa code, it would appear that ipa did not see a status of Total update succeeded. Not sure why the master would not have reported that, unless there was some problem getting back the status from the replica. [02/Apr/2014:20:50:22 +] conn=1365 op=20 UNBIND [02/Apr/2014:20:50:22 +] conn=1365 op=20 fd=114 closed - U1 Then ipa-replica-install closes the connection and reports the error. On Thu, Apr 3, 2014 at 10:38 AM, Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com wrote: On 04/02/2014 09:22 PM, Nevada Sanchez wrote: Okay. Updated the gist with the additional logs: https://gist.github.com/nevsan/8b6f78d7396963dc5f70 1) Dirsrv is crashing: [02/Apr/2014:20:49:53 +] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [02/Apr/2014:20:49:54 +] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. [02/Apr/2014:20:49:54 +] - I'm resizing my cache now...cache was 710029312 and is now 800 [02/Apr/2014:20:49:54 +] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [02/Apr/2014:20:49:54 +] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [02/Apr/2014:20:49:55 +] - slapd started. Listening on All
Re: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
Okay, I updated the gist and extended some of the logs (ipa2-errors does stop at 20:50:21). I'll follow up when I have the debug stuff in place. https://gist.github.com/nevsan/8b6f78d7396963dc5f70 On Thu, Apr 3, 2014 at 10:38 AM, Rich Megginson rmegg...@redhat.com wrote: On 04/02/2014 09:22 PM, Nevada Sanchez wrote: Okay. Updated the gist with the additional logs: https://gist.github.com/nevsan/8b6f78d7396963dc5f70 1) Dirsrv is crashing: [02/Apr/2014:20:49:53 +] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [02/Apr/2014:20:49:54 +] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. [02/Apr/2014:20:49:54 +] - I'm resizing my cache now...cache was 710029312 and is now 800 [02/Apr/2014:20:49:54 +] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [02/Apr/2014:20:49:54 +] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [02/Apr/2014:20:49:55 +] - slapd started. Listening on All Interfaces port 389 for LDAP requests Please use the instructions at http://port389.org/wiki/FAQ#Debugging_Crashes to get a core dump and stack trace. 2) The first occurrence of the connection error is at [02/Apr/2014:20:52:38 +] but there isn't anything in the consumer error log after [02/Apr/2014:20:50:21 +] and in the consumer access log after [02/Apr/2014:20:50:22 +] On Wed, Apr 2, 2014 at 9:38 PM, Rich Megginson rmegg...@redhat.comwrote: On 04/02/2014 03:01 PM, Nevada Sanchez wrote: Okay, I ran it with debug on. The output is quite large. I'm not sure what the etiquette is for posting large logs, so I threw it on gist here: https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txthttp://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt Let me know if I should copy it into the thread instead. Ok. Now can you post excerpts from the dirsrv errors log from both the master replica and the replica from around the time of the failure? On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson rmegg...@redhat.comwrote: On 04/02/2014 11:45 AM, Nevada Sanchez wrote: My apologies. I mistakenly ran the failing ldapsearch from an unpriviliged user (couldn't read slapd-EXAMPLE-COM directory). Running as root, it now works just fine (same result as the one that worked). SSL seems to not be the issue. Also, I haven't change the SSL certs since I first set up the master. I have been doing the replica side things from scratch (even so far as starting with a new machine). For the master side, I have just been re-preparing the replica. I hope I don't have to start from scratch with the master replica. I guess the next step would be to do the ipa-replica-install using -ddd and review the extra debug information that comes out. On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden rcrit...@redhat.comwrote: Rich Megginson wrote: On 04/02/2014 09:20 AM, Nevada Sanchez wrote: Okay, we might be on to something: ipa - ipa2 $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa2.example.com http://ipa2.example.com -s base -b 'objectclass=*' vendorVersion dn: vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 ipa2 - ipa $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa.example.com http://ipa.example.com -s base -b 'objectclass=*' vendorVersion ldap_start_tls: Connect error (-11) additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. The original IPA trusts the replica (since it signed the cert, I assume), but the replica doesn't trust the main IPA server. I guess the ZZ option would have shown me the failure that I missed in my initial ldapsearch tests. -Z[Z] Issue StartTLS (Transport Layer Security) extended operation. If you use -ZZ, the command will require the operation to be suc- cessful. i.e. use SSL, and force a successful handshake Anyway, what's the best way to remedy this in a way that makes IPA happy? (I've found that LDAP can have different requirements on which certs go where). I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install is supposed to take care of installing the CA cert properly for you. If you try to hack it and install the CA cert manually, you will probably miss something else that ipa install did not do. I think the only way to ensure that you have a properly configured ipa server + replicas is to get all of the ipa commands completing successfully. Which means going back to the drawing board and starting over from
Re: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
Rich Megginson wrote: On 04/02/2014 09:20 AM, Nevada Sanchez wrote: Okay, we might be on to something: ipa - ipa2 $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa2.example.com http://ipa2.example.com -s base -b 'objectclass=*' vendorVersion dn: vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 ipa2 - ipa $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa.example.com http://ipa.example.com -s base -b 'objectclass=*' vendorVersion ldap_start_tls: Connect error (-11) additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. The original IPA trusts the replica (since it signed the cert, I assume), but the replica doesn't trust the main IPA server. I guess the ZZ option would have shown me the failure that I missed in my initial ldapsearch tests. -Z[Z] Issue StartTLS (Transport Layer Security) extended operation. If you use -ZZ, the command will require the operation to be suc- cessful. i.e. use SSL, and force a successful handshake Anyway, what's the best way to remedy this in a way that makes IPA happy? (I've found that LDAP can have different requirements on which certs go where). I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install is supposed to take care of installing the CA cert properly for you. If you try to hack it and install the CA cert manually, you will probably miss something else that ipa install did not do. I think the only way to ensure that you have a properly configured ipa server + replicas is to get all of the ipa commands completing successfully. Which means going back to the drawing board and starting over from scratch. You can compare the certs that each side is using with: # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM Did you by chance replace the SSL server certs that IPA uses on your working master? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
On 04/02/2014 11:45 AM, Nevada Sanchez wrote: My apologies. I mistakenly ran the failing ldapsearch from an unpriviliged user (couldn't read slapd-EXAMPLE-COM directory). Running as root, it now works just fine (same result as the one that worked). SSL seems to not be the issue. Also, I haven't change the SSL certs since I first set up the master. I have been doing the replica side things from scratch (even so far as starting with a new machine). For the master side, I have just been re-preparing the replica. I hope I don't have to start from scratch with the master replica. I guess the next step would be to do the ipa-replica-install using -ddd and review the extra debug information that comes out. On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Rich Megginson wrote: On 04/02/2014 09:20 AM, Nevada Sanchez wrote: Okay, we might be on to something: ipa - ipa2 $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa2.example.com http://ipa2.example.com http://ipa2.example.com -s base -b 'objectclass=*' vendorVersion dn: vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 ipa2 - ipa $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa.example.com http://ipa.example.com http://ipa.example.com -s base -b 'objectclass=*' vendorVersion ldap_start_tls: Connect error (-11) additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. The original IPA trusts the replica (since it signed the cert, I assume), but the replica doesn't trust the main IPA server. I guess the ZZ option would have shown me the failure that I missed in my initial ldapsearch tests. -Z[Z] Issue StartTLS (Transport Layer Security) extended operation. If you use -ZZ, the command will require the operation to be suc- cessful. i.e. use SSL, and force a successful handshake Anyway, what's the best way to remedy this in a way that makes IPA happy? (I've found that LDAP can have different requirements on which certs go where). I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install is supposed to take care of installing the CA cert properly for you. If you try to hack it and install the CA cert manually, you will probably miss something else that ipa install did not do. I think the only way to ensure that you have a properly configured ipa server + replicas is to get all of the ipa commands completing successfully. Which means going back to the drawing board and starting over from scratch. You can compare the certs that each side is using with: # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM Did you by chance replace the SSL server certs that IPA uses on your working master? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
My apologies. I mistakenly ran the failing ldapsearch from an unpriviliged user (couldn't read slapd-EXAMPLE-COM directory). Running as root, it now works just fine (same result as the one that worked). SSL seems to not be the issue. Also, I haven't change the SSL certs since I first set up the master. I have been doing the replica side things from scratch (even so far as starting with a new machine). For the master side, I have just been re-preparing the replica. I hope I don't have to start from scratch with the master replica. On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden rcrit...@redhat.com wrote: Rich Megginson wrote: On 04/02/2014 09:20 AM, Nevada Sanchez wrote: Okay, we might be on to something: ipa - ipa2 $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa2.example.com http://ipa2.example.com -s base -b 'objectclass=*' vendorVersion dn: vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 ipa2 - ipa $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa.example.com http://ipa.example.com -s base -b 'objectclass=*' vendorVersion ldap_start_tls: Connect error (-11) additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. The original IPA trusts the replica (since it signed the cert, I assume), but the replica doesn't trust the main IPA server. I guess the ZZ option would have shown me the failure that I missed in my initial ldapsearch tests. -Z[Z] Issue StartTLS (Transport Layer Security) extended operation. If you use -ZZ, the command will require the operation to be suc- cessful. i.e. use SSL, and force a successful handshake Anyway, what's the best way to remedy this in a way that makes IPA happy? (I've found that LDAP can have different requirements on which certs go where). I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install is supposed to take care of installing the CA cert properly for you. If you try to hack it and install the CA cert manually, you will probably miss something else that ipa install did not do. I think the only way to ensure that you have a properly configured ipa server + replicas is to get all of the ipa commands completing successfully. Which means going back to the drawing board and starting over from scratch. You can compare the certs that each side is using with: # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM Did you by chance replace the SSL server certs that IPA uses on your working master? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
On 04/02/2014 03:01 PM, Nevada Sanchez wrote: Okay, I ran it with debug on. The output is quite large. I'm not sure what the etiquette is for posting large logs, so I threw it on gist here: https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt http://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt Let me know if I should copy it into the thread instead. Ok. Now can you post excerpts from the dirsrv errors log from both the master replica and the replica from around the time of the failure? On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com wrote: On 04/02/2014 11:45 AM, Nevada Sanchez wrote: My apologies. I mistakenly ran the failing ldapsearch from an unpriviliged user (couldn't read slapd-EXAMPLE-COM directory). Running as root, it now works just fine (same result as the one that worked). SSL seems to not be the issue. Also, I haven't change the SSL certs since I first set up the master. I have been doing the replica side things from scratch (even so far as starting with a new machine). For the master side, I have just been re-preparing the replica. I hope I don't have to start from scratch with the master replica. I guess the next step would be to do the ipa-replica-install using -ddd and review the extra debug information that comes out. On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Rich Megginson wrote: On 04/02/2014 09:20 AM, Nevada Sanchez wrote: Okay, we might be on to something: ipa - ipa2 $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa2.example.com http://ipa2.example.com http://ipa2.example.com -s base -b 'objectclass=*' vendorVersion dn: vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 ipa2 - ipa $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa.example.com http://ipa.example.com http://ipa.example.com -s base -b 'objectclass=*' vendorVersion ldap_start_tls: Connect error (-11) additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. The original IPA trusts the replica (since it signed the cert, I assume), but the replica doesn't trust the main IPA server. I guess the ZZ option would have shown me the failure that I missed in my initial ldapsearch tests. -Z[Z] Issue StartTLS (Transport Layer Security) extended operation. If you use -ZZ, the command will require the operation to be suc- cessful. i.e. use SSL, and force a successful handshake Anyway, what's the best way to remedy this in a way that makes IPA happy? (I've found that LDAP can have different requirements on which certs go where). I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install is supposed to take care of installing the CA cert properly for you. If you try to hack it and install the CA cert manually, you will probably miss something else that ipa install did not do. I think the only way to ensure that you have a properly configured ipa server + replicas is to get all of the ipa commands completing successfully. Which means going back to the drawing board and starting over from scratch. You can compare the certs that each side is using with: # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM Did you by chance replace the SSL server certs that IPA uses on your working master? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
I've had a replica working with FreeIPA 3.2.1 for awhile. After upgrading to 3.3.4, the replica wouldn't recognize my admin login anymore. After much troubleshooting, I decided to try to redo the replica since it was quite straightforward when I first set it up (what could go wrong, right?) Unfortunately, I've spent most of my day trying to get the replica to work this time. I've tried turning off all firewalls on both machines, rebooting both machines, upgrading all packages on both machines (both are running Fedora 19), reinstalling FreeIPA packages, and several other things, but I keep getting stuck at the same step (see output below). = [root@ipa2 ipaserver]# ipa-replica-install --setup-dns --no-forwarders /var/lib/ipa/replica-info-ipa2.example.com.gpg WARNING: conflicting timedate synchronization service 'chronyd' will be disabled in favor of ntpd Run connection check to master Check connection from replica to remote master 'ipa.example.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'ipa2.example.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK 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/34]: creating directory server user [2/34]: creating directory server instance [3/34]: adding default schema [4/34]: enabling memberof plugin [5/34]: enabling winsync plugin [6/34]: configuring replication version plugin [7/34]: enabling IPA enrollment plugin [8/34]: enabling ldapi [9/34]: configuring uniqueness plugin [10/34]: configuring uuid plugin [11/34]: configuring modrdn plugin [12/34]: configuring DNS plugin [13/34]: enabling entryUSN plugin [14/34]: configuring lockout plugin [15/34]: creating indices [16/34]: enabling referential integrity plugin [17/34]: configuring ssl for ds instance [18/34]: configuring certmap.conf [19/34]: configure autobind for root [20/34]: configure new location for managed entries [21/34]: configure dirsrv ccache [22/34]: enable SASL mapping fallback [23/34]: restarting directory server [24/34]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 5 seconds elapsed [ipa.example.com] reports: Update failed! Status: [-1 Total update abortedLDAP error: Can't contact LDAP server] Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Failed to start replication = I've confirmed that I can do ldapsearch from each machine to the other one for the replica status records (through ldap and ldaps), so I know that they can communicate. Trouble is, something behind the scenes is throwing the status error (as seen in the nsds5ReplicaLastInitStatus attribute). = [root@ipa2 ipaserver]# ldapsearch ldaps://ipa.example.com:636 -D 'cn=Directory Manager' -w # -b 'cn=meToipa2.example.com,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config' '(objectClass=*)' -s base nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5ReplicaLastInitEnd # extended LDIF # # LDAPv3 # base cn=meToipa2.example.com,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config with scope baseObject # filter: (objectclass=*) # requesting: ldaps://ipa.example.com:636 (objectClass=*) nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5ReplicaLastInitEnd # # meToipa2.example.com, replica, dc\3Dexample\2Cdc\3Dcom, mapping tree, config dn: cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cd c\3Dcom,cn=mapping tree,cn=config nsds5ReplicaLastInitStart: 20140401092800Z nsds5replicaUpdateInProgress: FALSE nsds5ReplicaLastInitStatus: -1
Re: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
On 04/01/2014 03:46 AM, Nevada Sanchez wrote: I've had a replica working with FreeIPA 3.2.1 for awhile. After upgrading to 3.3.4, the replica wouldn't recognize my admin login anymore. After much troubleshooting, I decided to try to redo the replica since it was quite straightforward when I first set it up (what could go wrong, right?) What is your version of 389-ds-base? rpm -q 389-ds-base What is in your dirsrv errors log? /var/log/dirsrv/slapd-DOMAIN-TLD/errors Unfortunately, I've spent most of my day trying to get the replica to work this time. I've tried turning off all firewalls on both machines, rebooting both machines, upgrading all packages on both machines (both are running Fedora 19), reinstalling FreeIPA packages, and several other things, but I keep getting stuck at the same step (see output below). = [root@ipa2 ipaserver]# ipa-replica-install --setup-dns --no-forwarders /var/lib/ipa/replica-info-ipa2.example.com.gpg WARNING: conflicting timedate synchronization service 'chronyd' will be disabled in favor of ntpd Run connection check to master Check connection from replica to remote master 'ipa.example.com http://ipa.example.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'ipa2.example.com http://ipa2.example.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK 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/34]: creating directory server user [2/34]: creating directory server instance [3/34]: adding default schema [4/34]: enabling memberof plugin [5/34]: enabling winsync plugin [6/34]: configuring replication version plugin [7/34]: enabling IPA enrollment plugin [8/34]: enabling ldapi [9/34]: configuring uniqueness plugin [10/34]: configuring uuid plugin [11/34]: configuring modrdn plugin [12/34]: configuring DNS plugin [13/34]: enabling entryUSN plugin [14/34]: configuring lockout plugin [15/34]: creating indices [16/34]: enabling referential integrity plugin [17/34]: configuring ssl for ds instance [18/34]: configuring certmap.conf [19/34]: configure autobind for root [20/34]: configure new location for managed entries [21/34]: configure dirsrv ccache [22/34]: enable SASL mapping fallback [23/34]: restarting directory server [24/34]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 5 seconds elapsed [ipa.example.com http://ipa.example.com] reports: Update failed! Status: [-1 Total update abortedLDAP error: Can't contact LDAP server] Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Failed to start replication = I've confirmed that I can do ldapsearch from each machine to the other one for the replica status records (through ldap and ldaps), so I know that they can communicate. Trouble is, something behind the scenes is throwing the status error (as seen in the nsds5ReplicaLastInitStatus attribute). = [root@ipa2 ipaserver]# ldapsearch ldaps://ipa.example.com:636 http://ipa.example.com:636 -D 'cn=Directory Manager' -w # -b 'cn=meToipa2.example.com http://meToipa2.example.com,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config' '(objectClass=*)' -s base nsds5ReplicaLastInitStart nsds5replicaUpdateInProgress nsds5ReplicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5ReplicaLastInitEnd # extended LDIF # # LDAPv3 # base cn=meToipa2.example.com http://meToipa2.example.com,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config with scope baseObject # filter: (objectclass=*) # requesting: ldaps://ipa.example.com:636 http://ipa.example.com:636 (objectClass=*) nsds5ReplicaLastInitStart
Re: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
Rich Megginson wrote: On 04/01/2014 03:28 PM, Nevada Sanchez wrote: Okay, I just tried doing this on a FRESH fedora 19 image (applied all updates, installed freeipa, made a new replica file for the new test server, and went state to ipa-replica-insntall). Exact same errors. Anything else I should try? I don't know. Does anyone on the IPA team know what the ipa_lockout errors are about, and if they would cause replication not to work? I suspect it is a red herring. The error is not found, so it is probably that the entry doesn't exist yet. This is replication for the CA anyway. I'd be curious what the access and error logs on the existing side looks like. It may be an SSL trust problem, for example. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
