[Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)

[Rich Megginson]

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 <rmeggins at redhat.com 
> <mailto:rmeggins at 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
>>     <rcritten at redhat.com <mailto:rcritten at 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
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140402/4771f67f/attachment.htm>