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