<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 04/02/2014 03:01 PM, Nevada Sanchez
wrote:<br>
</div>
<blockquote
cite="mid:CAPUVn2tVFPvHtuFBf_Op1nUf=+Z8uqPDO1HPct8UZMR94Y36Xg@mail.gmail.com"
type="cite">
<div dir="ltr">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: <a moz-do-not-send="true"
href="http://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt"
target="_blank">https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt</a>
<div>
<br>
</div>
<div>Let me know if I should copy it into the thread instead.</div>
</div>
</blockquote>
<br>
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?<br>
<br>
<blockquote
cite="mid:CAPUVn2tVFPvHtuFBf_Op1nUf=+Z8uqPDO1HPct8UZMR94Y36Xg@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Apr 2, 2014 at 1:49 PM, Rich
Megginson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="">
<div>On 04/02/2014 11:45 AM, Nevada Sanchez wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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.<br>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
</div>
I guess the next step would be to do the
ipa-replica-install using -ddd and review the extra debug
information that comes out.
<div>
<div class="h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr"> </div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Apr 2, 2014 at
11:45 AM, Rob Crittenden <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:rcritten@redhat.com"
target="_blank">rcritten@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">Rich Megginson wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div> On 04/02/2014 09:20 AM, Nevada Sanchez
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div> Okay, we might be on to something:<br>
<br>
ipa -> ipa2<br>
================================<br>
$
LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM
ldapsearch -xLLLZZ<br>
</div>
-h <a moz-do-not-send="true"
href="http://ipa2.example.com"
target="_blank">ipa2.example.com</a>
<<a moz-do-not-send="true"
href="http://ipa2.example.com"
target="_blank">http://ipa2.example.com</a>>
-s base -b ""
<div><br>
'objectclass=*' vendorVersion<br>
dn:<br>
vendorVersion: 389-Directory/1.3.1.22.a1
B2014.073.1751<br>
================================<br>
<br>
ipa2 -> ipa<br>
================================<br>
$
LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM
ldapsearch -xLLLZZ<br>
</div>
-h <a moz-do-not-send="true"
href="http://ipa.example.com"
target="_blank">ipa.example.com</a> <<a
moz-do-not-send="true"
href="http://ipa.example.com"
target="_blank">http://ipa.example.com</a>>
-s base -b ""
<div>
<div><br>
'objectclass=*' vendorVersion<br>
ldap_start_tls: Connect error (-11)<br>
additional info: TLS error
-8172:Peer's certificate issuer has
been<br>
marked as not trusted by the user.<br>
================================<br>
<br>
The original IPA trusts the replica
(since it signed the cert, I<br>
assume), but the replica doesn't trust
the main IPA server. I guess<br>
the ZZ option would have shown me the
failure that I missed in my<br>
initial ldapsearch tests.<br>
</div>
</div>
</blockquote>
<div>
<div> -Z[Z] Issue StartTLS
(Transport Layer Security) extended<br>
operation. If<br>
you use -ZZ, the
command will require the operation to<br>
be suc-<br>
cessful.<br>
<br>
i.e. use SSL, and force a successful
handshake<br>
<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> <br>
Anyway, what's the best way to remedy
this in a way that makes IPA<br>
happy? (I've found that LDAP can have
different requirements on which<br>
certs go where).<br>
</blockquote>
<br>
I'm not sure.
ipa-server-install/ipa-replica-prepare/ipa-replica-install<br>
is supposed to take care of installing
the CA cert properly for you. If<br>
you try to hack it and install the CA
cert manually, you will probably<br>
miss something else that ipa install did
not do.<br>
<br>
I think the only way to ensure that you
have a properly configured ipa<br>
server + replicas is to get all of the
ipa commands completing successfully.<br>
<br>
Which means going back to the drawing
board and starting over from scratch.<br>
</div>
</div>
</blockquote>
<br>
You can compare the certs that each side is
using with:<br>
<br>
# certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM<br>
<br>
Did you by chance replace the SSL server certs
that IPA uses on your working master?<span><font
color="#888888"><br>
<br>
rob<br>
</font></span></blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>