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/ 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/ 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 <rmegg...@redhat.com <mailto:rmegg...@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:

    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

        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
                    ldapsearch -xLLLZZ
                    -h ipa2.example.com <http://ipa2.example.com>
                    <http://ipa2.example.com> -s base -b ""

                    'objectclass=*' vendorVersion
                    vendorVersion: 389-Directory/

                    ipa2 -> ipa
                    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-

                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.
                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?


Freeipa-users mailing list

Reply via email to