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

Thu Apr 3 21:46:41 UTC 2014

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 <rmeggins at 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 +0000] - 389-Directory/1.3.1.22.a1 B2014.073.1751
> starting up
> [02/Apr/2014:20:49:54 +0000] - 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 +0000] - I'm resizing my cache now...cache was
> 710029312 and is now 8000000
> [02/Apr/2014:20:49:54 +0000] - 389-Directory/1.3.1.22.a1 B2014.073.1751
> starting up
> [02/Apr/2014:20:49:54 +0000] - Detected Disorderly Shutdown last time
> Directory Server was running, recovering database.
> [02/Apr/2014:20:49:55 +0000] - 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 +0000] but there isn't anything in the consumer error
> log after [02/Apr/2014:20:50:21 +0000] and in the consumer access log after
> [02/Apr/2014:20:50:22 +0000]
>
>
>   On Wed, Apr 2, 2014 at 9:38 PM, Rich Megginson <rmeggins at redhat.com>wrote:
>
>>  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>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>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
>>>>
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140403/f3ea4445/attachment.htm>