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