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:[email protected]] Sent: Friday, January 31, 2014 12:07 PM To: Borresen, John - 0442 - MITLL; [email protected] Subject: RE: Syncrepl and mmr --On Friday, January 31, 2014 8:54 AM -0500 "Borresen, John - 0442 - MITLL" <[email protected]> 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:[email protected]] > Sent: Thursday, January 30, 2014 5:10 PM > To: Borresen, John - 0442 - MITLL; [email protected] > Subject: RE: Syncrepl and mmr > > --On Thursday, January 30, 2014 4:51 PM -0500 "Borresen, John - 0442 - > MITLL" <[email protected]> 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
