[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Syncrepl and mmr

To: Quanah Gibson-Mount <quanah@zimbra.com>, "openldap-technical@openldap.org" <openldap-technical@openldap.org>
Subject: RE: Syncrepl and mmr
From: "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>
Date: Fri, 31 Jan 2014 13:20:36 -0500
Accept-language: en-US
Acceptlanguage: en-US
Content-language: en-US
In-reply-to: <8B2D174F182D2F00973C48E7@[192.168.1.2]>
References: <1BB724A73E57084D89F6F28ED9E651920AD3170DFB@LLE2K7-BE02.mitll.ad.local> <201401301252.s0UCqYiG032646@boole.openldap.org> <BB8429D49E4807C586371E61@[192.168.1.2]> <20140130202839.1351AA624A@edge02.zimbra.com> <2B630E28DF38ECE010CBD25A@[192.168.1.2]> <20140130212629.B2597A6250@edge02.zimbra.com> <DB1FEF6327E2B46EC94F873B@[192.168.1.2]> <20140130213534.84D20A6263@edge02.zimbra.com> <395A5E98A0BA923103457A7D@[192.168.1.2]> <20140130215154.21246A6250@edge02.zimbra.com> <E05E339BB9E6991AE1EE9034@[192.168.1.2]> <20140131135522.883144425D@edge01.zimbra.com> <8B2D174F182D2F00973C48E7@[192.168.1.2]>
Thread-index: Ac8ept0RkWXVJjm5Qj2XZqp9sHJMzQAAMRFg
Thread-topic: Syncrepl and mmr

Thanks, Quanah

Not sure what you meant by " Well, it may not have been this issue, but it definite would become an issue then."

Was what I did a good thing or not?  Curious minds want to know. <lol>

MM Server1:
# ldapsearch -H ldap://mm-server1.example.ldap -d 256 -x -D cn=admin,cn=config -W -ZZ -b olcDatabase=\{1\}bdb,cn=config  olcSyncrepl
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <olcDatabase={1}bdb,cn=config> with scope subtree
# filter: (objectclass=*)
# requesting: olcSyncrepl 
#

# {1}bdb, config
dn: olcDatabase={1}bdb,cn=config
olcSyncrepl: {0}rid=002 provider=ldap://mm-server2.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=example,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs="*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/openldap/CA/cacert.pem
olcSyncrepl: {1}rid=001 provider=ldap://mm-server1.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=example,dc=ldap" credentials=<password> interva
 l=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=
 "*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/openldap/CA/cacert.pem

# {0}syncprov, {1}bdb, config
dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config

# {1}accesslog, {1}bdb, config
dn: olcOverlay={1}accesslog,olcDatabase={1}bdb,cn=config

# search result
search: 3
result: 0 Success

# numResponses: 4
# numEntries: 3


MM Server2:
# ldapsearch -H ldap://mm-server2.example.ldap -d 256 -x -D cn=admin,cn=config -W -ZZ -b olcDatabase=\{1\}bdb,cn=config  olcSyncrepl
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <olcDatabase={1}bdb,cn=config> with scope subtree
# filter: (objectclass=*)
# requesting: olcSyncrepl 
#

# {1}bdb, config
dn: olcDatabase={1}bdb,cn=config
olcSyncrepl: {0}rid=001 provider=ldap://mm-server1.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=example,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=
 "*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/openldap/CA/cacert.pem
olcSyncrepl: {1}rid=002 provider=ldap://mm-server2.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=example,dc=ldap" credentials=<password> interva
 l=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=
 "*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/openldap/CA/cacert.pem

# {0}accesslog, {1}bdb, config
dn: olcOverlay={0}accesslog,olcDatabase={1}bdb,cn=config

# {1}syncprov, {1}bdb, config
dn: olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config

# search result
search: 3
result: 0 Success

# numResponses: 4
# numEntries: 3


I modified, the "starttls" statement (just to test) to no.  and now receiving the following
>From MM-Server2:

Jan 31 12:39:15 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc 13 retrying
Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 fd=101 ACCEPT from IP=<mm-server1-ip>:48899 (IP=0.0.0.0:389)
Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 op=0 BIND dn="cn=ldapadmin,dc=example,dc=ldap" method=128
Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 op=0 RESULT tag=97 err=13 text=TLS confidentiality required
Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 op=1 UNBIND
Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 fd=101 closed
Jan 31 12:40:15 gp42-admin4 slapd[26000]: conn=8616 fd=106 ACCEPT from IP=<mm-server2-ip>:43431 (IP=0.0.0.0:389)
Jan 31 12:40:15 gp42-admin4 slapd[26000]: conn=8616 op=0 BIND dn="cn=ldapadmin,dc=example,dc=ldap" method=128
Jan 31 12:40:15 gp42-admin4 slapd[26000]: conn=8616 op=0 RESULT tag=97 err=13 text=TLS confidentiality required
Jan 31 12:40:15 gp42-admin4 slapd[26000]: slap_client_connect: URI=ldap://mm-server2.example.ldap DN="cn=ldapadmin,dc=example,dc=ldap" ldap_sasl_bind_s failed (13)

Very similar on MM-Server1.

I am at a loss.  The TLS configuration, files, are exactly as they are in the standard client configuration...as far as I can tell.  Three other SysAdmins, for sanity sake, have checked that the paths are identical between the various files.

I turned on a flood of debugging (-1) and on "mm-server1 and 2", seeing:
tls_write: want=810 error=Broken pipe
ldap_write: want=732 error=Broken pipe
52ebe8e0 ber_flush2 failed errno=32 reason="Broken pipe"

and

TLS trace: SSL3 alert write:warning:close notify
ldap_free_connection: actually freed
tls_read: want=5 error=Bad file descriptor

Thanks in advance



-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] 
Sent: Friday, January 31, 2014 12:07 PM
To: Borresen, John - 0442 - MITLL; openldap-technical@openldap.org
Subject: RE: Syncrepl and mmr

--On Friday, January 31, 2014 8:54 AM -0500 "Borresen, John - 0442 - MITLL" 
<John.Borresen@ll.mit.edu> wrote:

> Thanks Quanah
>
> I'm sure it isn't 100% correct, but I added the following ACL to my 
> accesslog DB on both MM servers:
>
> olcAccess: to * by dn="cn=ldapadmin,dc=group42,dc=ldap" read by * none

Well, it may not have been this issue, but it definite would become an issue then. ;)

> I'm still seeing
> gp42-admin3 (MM server1)
> Jan 31 08:25:17 gp42-admin3 slapd[3599]: conn=5551 op=2 SRCH 
> base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 31
> 08:25:17 gp42-admin3 slapd[3599]: conn=5551 op=2 SRCH attr=reqDN 
> reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 
> 31 08:25:17
> gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with 
> LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:17 gp42-admin3 slapd[3599]:
> do_syncrepl: rid=001 rc -1 retrying Jan 31 08:25:17 gp42-admin3
> slapd[3599]: send_search_entry: conn 5551  ber write failed. Jan 31
> 08:25:17 gp42-admin3 slapd[3599]: conn=5551 fd=32 closed (connection 
> lost on write) Jan 31 08:25:17 gp42-admin3 slapd[3599]: do_syncrep2: 
> rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 31 
> 08:25:17
> gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying

Your masters are unable to talk to each other.  You need to determine why. 
This will take debugging on your part, as I've never seen anything like this before.

> gp42-admin4 (MM server2)
> Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 fd=101 ACCEPT from
> IP=155.34.133.73:10446 (IP=0.0.0.0:389) Jan 31 08:25:19 gp42-admin4
> slapd[26000]: conn=8050 op=0 BIND dn="dc=group42,dc=ldap" method=163 
> Jan
> 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 op=0 RESULT tag=97 
> err=13 text=TLS confidentiality required Jan 31 08:25:19 gp42-admin4
> slapd[26000]: conn=8050 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap"
> method=128 Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 op=1 
> RESULT tag=97 err=13 text=TLS confidentiality required Jan 31 08:25:19
> gp42-admin4 slapd[26000]: conn=8050 op=2 UNBIND Jan 31 08:25:19 
> gp42-admin4 slapd[26000]: conn=8050 fd=101 closed Jan 31 08:25:51 
> gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty syncUUID with 
> LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:51 gp42-admin4
> slapd[26000]: do_syncrepl: rid=001 rc -1 retrying

This says that your consumer is connecting without sending a startTLS, while you've configured the master to require startTLS.  Clearly you need to either enable startTLS in the syncrepl statement, or not require starttls on your master.

--Quanah



> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
> Sent: Thursday, January 30, 2014 5:10 PM
> To: Borresen, John - 0442 - MITLL; openldap-technical@openldap.org
> Subject: RE: Syncrepl and mmr
>
> --On Thursday, January 30, 2014 4:51 PM -0500 "Borresen, John - 0442 - 
> MITLL" <John.Borresen@ll.mit.edu> wrote:
>
>> Well, that was helpful -- lol
>
>
> Looking at your previously supplied configuration, it is clearly 
> apparent that you provided your replication user no ACLs to read the 
> accesslog DB, so the error you see makes sense.  It can't read the 
> data out of accesslog, so it throws an error stating that fact.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Architect - Server
> Zimbra, Inc.
> --------------------
> Zimbra ::  the leader in open source messaging and collaboration



--

Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration

References:
- Syncrepl and mmr
  - From: "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>
- Re: Syncrepl and mmr
  - From: Quanah Gibson-Mount <quanah@zimbra.com>
- RE: Syncrepl and mmr
  - From: Quanah Gibson-Mount <quanah@zimbra.com>
- RE: Syncrepl and mmr
  - From: Quanah Gibson-Mount <quanah@zimbra.com>
- RE: Syncrepl and mmr
  - From: Quanah Gibson-Mount <quanah@zimbra.com>
- RE: Syncrepl and mmr
  - From: Quanah Gibson-Mount <quanah@zimbra.com>
- RE: Syncrepl and mmr
  - From: Quanah Gibson-Mount <quanah@zimbra.com>

Prev by Date: RE: Syncrepl and mmr
Next by Date: RE: Syncrepl and mmr
Index(es):
- Chronological
- Thread