openldap-technical

openldap-technical@openldap.org

3 participants
9990 discussions

Syncrepl and mmr
by Borresen, John - 0442 - MITLL 30 Jan '14

30 Jan '14

For some reason the original never made it. Not sure why. ________________________________________ From: Borresen, John - 0442 - MITLL Sent: Wednesday, January 29, 2014 4:41 PM To: openldap-technical(a)openldap.org Subject: Syncrepl -- MMR All, Troubleshooting some issues, not to mention to verify that Syncrepl are working as they should, following setting up a 2-way multi-master in our test environment. 1) I noticed that the “userPassword” attributes have all disappeared?! 2) On one of the masters I was able to add it back in (for my account, of course) and added a password (SHA). It has not propagated over to the other master. -->Here is the slapd.log from server#1: Jan 29 16:10:06 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 29 16:10:06 gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 fd=30 ACCEPT from IP=155.34.133.44:54271 (IP=0.0.0.0:389) Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=0 STARTTLS Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=0 RESULT oid= err=0 text= Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 fd=30 TLS established tls_ssf=256 ssf=256 Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128 Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0 Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=1 RESULT tag=97 err=0 text= Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 29 16:10:34 gp42-admin3 slapd[3599]: send_search_entry: conn 1216 ber write failed. Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 fd=30 closed (connection lost on write) Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 fd=31 ACCEPT from IP=172.25.91.233:36144 (IP=0.0.0.0:389) Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=0 STARTTLS Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=0 RESULT oid= err=0 text= Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 fd=31 TLS established tls_ssf=256 ssf=256 Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128 Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0 Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=1 RESULT tag=97 err=0 text= Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 29 16:11:02 gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 29 16:11:02 gp42-admin3 slapd[3599]: do_syncrepl: rid=001 rc -1 retrying Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=3 UNBIND Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 fd=31 closed Jan 29 16:11:06 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 29 16:11:06 gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 fd=30 ACCEPT from IP=155.34.133.44:54273 (IP=0.0.0.0:389) Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=0 STARTTLS Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=0 RESULT oid= err=0 text= Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 fd=30 TLS established tls_ssf=256 ssf=256 Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128 Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0 Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=1 RESULT tag=97 err=0 text= Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 29 16:11:34 gp42-admin3 slapd[3599]: send_search_entry: conn 1218 ber write failed. Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 fd=30 closed (connection lost on write) Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=27 SRCH base="cn=accesslog" scope=1 deref=3 filter="(objectClass=*)" Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=27 SRCH attr=hasSubordinates objectClass Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=27 SEARCH RESULT tag=101 err=0 nentries=36 text= Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=28 SRCH base="cn=accesslog" scope=0 deref=3 filter="(objectClass=*)" Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=28 SRCH attr=* Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=28 SEARCH RESULT tag=101 err=0 nentries=1 text= Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 fd=31 ACCEPT from IP=172.25.91.233:36146 (IP=0.0.0.0:389) Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=0 STARTTLS Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=0 RESULT oid= err=0 text= Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 fd=31 TLS established tls_ssf=256 ssf=256 Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128 Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0 Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=1 RESULT tag=97 err=0 text= Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 29 16:12:02 gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 29 16:12:02 gp42-admin3 slapd[3599]: do_syncrepl: rid=001 rc -1 retrying Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=3 UNBIND Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 fd=31 closed Jan 29 16:12:06 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 29 16:12:06 gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 fd=30 ACCEPT from IP=155.34.133.44:54275 (IP=0.0.0.0:389) Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=0 STARTTLS Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=0 RESULT oid= err=0 text= Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 fd=30 TLS established tls_ssf=256 ssf=256 Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128 Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0 Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=1 RESULT tag=97 err=0 text= Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 29 16:12:34 gp42-admin3 slapd[3599]: send_search_entry: conn 1220 ber write failed. Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 fd=30 closed (connection lost on write) Jan 29 16:13:02 gp42-admin3 slapd[3599]: conn=1221 fd=31 ACCEPT from IP=172.25.91.233:36149 (IP=0.0.0.0:389) Jan 29 16:13:02 gp42-admin3 slapd[3599]: conn=1221 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 16:13:02 gp42-admin3 slapd[3599]: conn=1221 op=0 STARTTLS Jan 29 16:13:02 gp42-admin3 slapd[3599]: conn=1221 op=0 RESULT oid= err=0 text= Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 fd=31 TLS established tls_ssf=256 ssf=256 Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128 Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0 Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=1 RESULT tag=97 err=0 text= Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 29 16:13:03 gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 29 16:13:03 gp42-admin3 slapd[3599]: do_syncrepl: rid=001 rc -1 retrying Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=3 UNBIND Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 fd=31 closed Jan 29 16:13:06 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 29 16:13:06 gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 fd=30 ACCEPT from IP=155.34.133.44:54277 (IP=0.0.0.0:389) Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=0 STARTTLS Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=0 RESULT oid= err=0 text= Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 fd=30 TLS established tls_ssf=256 ssf=256 Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128 Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0 Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=1 RESULT tag=97 err=0 text= Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=3 UNBIND Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 fd=30 closed -->Here is the log from the other server, same time frame: Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 fd=108 ACCEPT from IP=172.25.91.233:41849 (IP=0.0.0.0:389) Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=0 STARTTLS Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=0 RESULT oid= err=0 text= Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 fd=108 TLS established tls_ssf=256 ssf=256 Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128 Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0 Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=1 RESULT tag=97 err=0 text= Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 29 16:10:06 gp42-admin4 slapd[26000]: send_search_entry: conn 3232 ber write failed. Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 fd=108 closed (connection lost on write) Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 fd=109 ACCEPT from IP=155.34.133.44:38468 (IP=0.0.0.0:389) Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=0 STARTTLS Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=0 RESULT oid= err=0 text= Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 fd=109 TLS established tls_ssf=256 ssf=256 Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128 Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0 Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=1 RESULT tag=97 err=0 text= Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 29 16:10:26 gp42-admin4 slapd[26000]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 29 16:10:26 gp42-admin4 slapd[26000]: do_syncrepl: rid=002 rc -1 retrying Jan 29 16:10:26 gp42-admin4 slapd[26000]: send_search_entry: conn 3233 ber write failed. Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 fd=109 closed (connection lost on write) Jan 29 16:10:34 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 29 16:10:34 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc -1 retrying Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 fd=108 ACCEPT from IP=172.25.91.233:41852 (IP=0.0.0.0:389) Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=0 STARTTLS Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=0 RESULT oid= err=0 text= Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 fd=108 TLS established tls_ssf=256 ssf=256 Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128 Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0 Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=1 RESULT tag=97 err=0 text= Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 29 16:11:06 gp42-admin4 slapd[26000]: send_search_entry: conn 3234 ber write failed. Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 fd=108 closed (connection lost on write) Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 fd=109 ACCEPT from IP=155.34.133.44:38470 (IP=0.0.0.0:389) Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=0 STARTTLS Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=0 RESULT oid= err=0 text= Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 fd=109 TLS established tls_ssf=256 ssf=256 Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128 Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0 Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=1 RESULT tag=97 err=0 text= Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 29 16:11:26 gp42-admin4 slapd[26000]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 29 16:11:26 gp42-admin4 slapd[26000]: do_syncrepl: rid=002 rc -1 retrying Jan 29 16:11:26 gp42-admin4 slapd[26000]: send_search_entry: conn 3235 ber write failed. Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 fd=109 closed (connection lost on write) Jan 29 16:11:34 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 29 16:11:34 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc -1 retrying Jan 29 16:11:47 gp42-admin4 slapd[26000]: conn=3036 op=20 SRCH base="cn=accesslog" scope=0 deref=3 filter="(objectClass=*)" Jan 29 16:11:47 gp42-admin4 slapd[26000]: conn=3036 op=20 SRCH attr=* Jan 29 16:11:47 gp42-admin4 slapd[26000]: conn=3036 op=20 SEARCH RESULT tag=101 err=0 nentries=1 text= Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=21 SRCH base="cn=accesslog" scope=1 deref=3 filter="(objectClass=*)" Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=21 SRCH attr=hasSubordinates objectClass Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=21 SEARCH RESULT tag=101 err=4 nentries=500 text= Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=22 SRCH base="cn=accesslog" scope=0 deref=3 filter="(objectClass=*)" Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=22 SRCH attr=* Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=22 SEARCH RESULT tag=101 err=0 nentries=1 text= Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 fd=108 ACCEPT from IP=172.25.91.233:41854 (IP=0.0.0.0:389) Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=0 STARTTLS Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=0 RESULT oid= err=0 text= Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 fd=108 TLS established tls_ssf=256 ssf=256 Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128 Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0 Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=1 RESULT tag=97 err=0 text= Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 29 16:12:06 gp42-admin4 slapd[26000]: send_search_entry: conn 3236 ber write failed. Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 fd=108 closed (connection lost on write) Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=23 SRCH base="dc=group42,dc=ldap" scope=1 deref=3 filter="(objectClass=*)" Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=23 SRCH attr=hasSubordinates objectClass Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=23 SEARCH RESULT tag=101 err=0 nentries=15 text= Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=24 SRCH base="dc=group42,dc=ldap" scope=0 deref=3 filter="(objectClass=*)" Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=24 SRCH attr=* Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=24 SEARCH RESULT tag=101 err=0 nentries=1 text= Jan 29 16:12:21 gp42-admin4 slapd[26000]: conn=2702 op=25 SRCH base="ou=Users,dc=group42,dc=ldap" scope=1 deref=3 filter="(objectClass=*)" Jan 29 16:12:21 gp42-admin4 slapd[26000]: conn=2702 op=25 SRCH attr=hasSubordinates objectClass Jan 29 16:12:21 gp42-admin4 slapd[26000]: conn=2702 op=25 SEARCH RESULT tag=101 err=0 nentries=123 text= Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 fd=109 ACCEPT from IP=155.34.133.44:38472 (IP=0.0.0.0:389) Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=2702 op=26 SRCH base="uid=daveb,ou=Users,dc=group42,dc=ldap" scope=0 deref=3 filter="(objectClass=*)" Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=2702 op=26 SRCH attr=* Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=2702 op=26 SEARCH RESULT tag=101 err=0 nentries=1 text= Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=0 STARTTLS Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=0 RESULT oid= err=0 text= Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 fd=109 TLS established tls_ssf=256 ssf=256 Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128 Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0 Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=1 RESULT tag=97 err=0 text= Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 29 16:12:26 gp42-admin4 slapd[26000]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 29 16:12:26 gp42-admin4 slapd[26000]: do_syncrepl: rid=002 rc -1 retrying Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=3 UNBIND Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 fd=109 closed Jan 29 16:12:34 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 29 16:12:34 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc -1 retrying Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 fd=108 ACCEPT from IP=172.25.91.233:41857 (IP=0.0.0.0:389) Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=0 STARTTLS Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=0 RESULT oid= err=0 text= Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 fd=108 TLS established tls_ssf=256 ssf=256 Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128 Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0 Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=1 RESULT tag=97 err=0 text= Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=3 UNBIND Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 fd=108 closed Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 fd=109 ACCEPT from IP=155.34.133.44:38474 (IP=0.0.0.0:389) Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=0 STARTTLS Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=0 RESULT oid= err=0 text= Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 fd=109 TLS established tls_ssf=256 ssf=256 Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128 Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0 Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=1 RESULT tag=97 err=0 text= Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 29 16:13:26 gp42-admin4 slapd[26000]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 29 16:13:26 gp42-admin4 slapd[26000]: do_syncrepl: rid=002 rc -1 retrying Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=3 UNBIND Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 fd=109 closed Jan 29 16:13:34 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 29 16:13:34 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc -1 retrying -->When trying to get a copy of the olcDatabase={0}bdb,cn=config from server#1, I receive the following: # slapcat -s olcDatabase=\{1\}bdb,cn=config 52e97450 ldif_read_file: checksum error on "/usr/local/openldap/etc/openldap/slapd.d/cn=config.ldif" 52e97450 ldif_read_file: checksum error on "/usr/local/openldap/etc/openldap/slapd.d/cn=config.ldif" dn: olcDatabase={1}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcSuffix: dc=group42,dc=ldap olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=ldapadmin,dc=group42,dc=ldap olcRootPW:: _____________________________________= olcSyncUseSubentry: FALSE olcMonitoring: TRUE olcDbDirectory: /var/lib/openldap/openldap-data olcDbCacheSize: 1000 olcDbConfig: {0}# $OpenLDAP$ olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databas es. olcDbConfig: {2}# olcDbConfig: {3}# See the Oracle Berkeley DB documentation olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-d b/db/ref/env/db_config.html> olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics. olcDbConfig: {6}# olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl PTI+ olcDbConfig: {9}# in particular: olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075> olcDbConfig: {11} olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon re building olcDbConfig: {13}# the DB environment. olcDbConfig: {14} olcDbConfig: {15}# one 0.25 GB cache olcDbConfig: {16}set_cachesize 0 268435456 1 olcDbConfig: {17} olcDbConfig: {18}# Data Directory olcDbConfig: {19}#set_data_dir db olcDbConfig: {20} olcDbConfig: {21}# Transaction Log settings olcDbConfig: {22}set_lg_regionmax 262144 olcDbConfig: {23}set_lg_bsize 2097152 olcDbConfig: {24}#set_lg_dir logs olcDbConfig: {25} olcDbConfig: {26}# Note: special DB_CONFIG flags are no longer needed for "qui ck" olcDbConfig:: ezI3fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl aXIgLXEgb3B0aW9uKS4g olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn eq,sub olcDbIndex: uid eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: sn eq,sub olcDbIndex: mail eq,sub olcDbIndex: departmentNumber eq olcDbIndex: automountKey eq olcDbIndex: memberUid eq olcDbIndex: printerURI eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: 5a87b5f1-c445-4e0e-ba97-6d2d63093704 creatorsName: cn=config createTimestamp: 20140122200748Z olcSyncrepl: {0}rid=001 provider=ldap://gp42-admin3.group42.ldap bindmethod=si mple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interva l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog" schemach ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs= "*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/open ldap/CA/cacert.pem olcSyncrepl: {1}rid=002 provider=ldap://gp42-admin4.group42.ldap bindmethod=si mple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interva l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog" schemach ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs= "*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/open ldap/CA/cacert.pem olcMirrorMode: TRUE entryCSN: 20140129193518.096476Z#000000#001#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20140129193518Z dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE structuralObjectClass: olcSyncProvConfig entryUUID: 04afe1bf-40c7-425a-8b25-74f8687323fc creatorsName: cn=admin,cn=config createTimestamp: 20140129180447Z entryCSN: 20140129180447.701059Z#000000#001#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20140129180447Z dn: olcOverlay={1}accesslog,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig entryUUID: 54b5fa00-8244-41d3-923d-0743a10bf192 creatorsName: cn=admin,cn=config createTimestamp: 20140129180903Z entryCSN: 20140129180903.479192Z#000000#001#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20140129180903Z -->From server#2: # slapcat -s olcDatabase=\{1\}bdb,cn=config dn: olcDatabase={1}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcSuffix: dc=group42,dc=ldap olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=ldapadmin,dc=group42,dc=ldap olcRootPW:: ________________________________= olcSyncUseSubentry: FALSE olcMonitoring: TRUE olcDbDirectory: /var/lib/openldap/openldap-data olcDbCacheSize: 1000 olcDbConfig: {0}# $OpenLDAP$ olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databas es. olcDbConfig: {2}# olcDbConfig: {3}# See the Oracle Berkeley DB documentation olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-d b/db/ref/env/db_config.html> olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics. olcDbConfig: {6}# olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl PTI+ olcDbConfig: {9}# in particular: olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075> olcDbConfig: {11} olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon re building olcDbConfig: {13}# the DB environment. olcDbConfig: {14} olcDbConfig: {15}# one 0.25 GB cache olcDbConfig: {16}#set_cachesize 0 268435456 1 olcDbConfig: {17}set_cachesize 0 2147483648 1 olcDbConfig: {18} olcDbConfig: {19}# Data Directory olcDbConfig: {20}#set_data_dir db olcDbConfig: {21} olcDbConfig: {22}# Archive/deletion olcDbConfig: {23}set_flags DB_LOG_AUTOREMOVE olcDbConfig: {24} olcDbConfig: {25}# Transaction Log settings olcDbConfig: {26}set_lg_regionmax 262144 olcDbConfig: {27}set_lg_bsize 2097152 olcDbConfig: {28}#set_lg_dir logs olcDbConfig: {29} olcDbConfig: {30}# Note: special DB_CONFIG flags are no longer needed for "qui ck" olcDbConfig:: ezMxfSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl aXIgLXEgb3B0aW9uKS4g olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn eq,sub olcDbIndex: uid eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: sn eq,sub olcDbIndex: departmentNumber eq olcDbIndex: mail eq,sub olcDbIndex: automountKey eq olcDbIndex: memberUid eq olcDbIndex: printerURI eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: 94ff450b-aa70-4507-9ca6-51cdd740ea3e creatorsName: cn=config createTimestamp: 20131218155313Z olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by * none olcAccess: {1}to * by * read olcSyncrepl: {0}rid=001 provider=ldap://gp42-admin3.group42.ldap bindmethod=si mple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interva l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog" schemach ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs= "*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/open ldap/CA/cacert.pem olcSyncrepl: {1}rid=002 provider=ldap://gp42-admin4.group42.ldap bindmethod=si mple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interva l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog" schemach ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs= "*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/open ldap/CA/cacert.pem olcMirrorMode: TRUE entryCSN: 20140129193241.088847Z#000000#002#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20140129193241Z dn: olcOverlay={0}accesslog,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {0}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig entryUUID: 6e4e1508-5eb9-4372-bbd1-813f859b0acc creatorsName: cn=admin,cn=config createTimestamp: 20140129182321Z entryCSN: 20140129182321.004272Z#000000#002#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20140129182321Z dn: olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov olcSpNoPresent: TRUE structuralObjectClass: olcSyncProvConfig entryUUID: 9108e0db-ba9e-4b40-b743-4016c61582bc creatorsName: cn=admin,cn=config createTimestamp: 20140129183014Z entryCSN: 20140129183014.073365Z#000000#002#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20140129183014Z Thank you in advance, let me know if any expanding information is needed. John D. Borresen (Dave) Linux/Unix Systems Administrator MIT Lincoln Laboratory Surveillance Systems Group 244 Wood St Lexington, MA 02420 email: john.borresen(a)ll.mit.edu<mailto:john.borresen@ll.mit.edu>

2 2

migrating from syncrepl to delta syncrepl
by Paul B. Henson 30 Jan '14

30 Jan '14

When we first deployed openldap a decade or so ago, we implemented regular syncrepl rather than delta syncrepl because at the time the latter did not support mirror mode. As part of a project to implement the password policy overlay, we plan to switch to delta syncrepl to make the replication of failed login attributes etc more efficient. If I understand correctly, while obviously if a provider is only configured for syncrepl a consumer can only use syncrepl, if a provider is configured for delta syncrepl, a consumer can do either? As such, my tentative deployment plan (intended to avoid downtime), is: * Update configuration on backup master to provide delta syncrepl * Cutover load balancer to backup master * Update primary master to provide delta syncrepl, and to consume changes from backup master via delta syncrepl * Cutover load balancer back to primary master * Update backup master to consume changes from primary master via delta syncrepl * One at a time, remove slaves from load balancer and update to consume changes from both masters via delta syncrepl Currently on my masters, syncrepl is configured as: ----- overlay syncprov syncprov-checkpoint 500 30 syncprov-reloadhint TRUE syncprov-sessionlog 500 ----- And consumers are configured as: ----- syncrepl rid=1 provider=ldaps://master-2.ldap.csupomona.edu/ type=refreshAndPersist retry="10 10 60 +" searchbase="dc=csupomona,dc=edu" bindmethod=simple binddn=cn=XXXX credentials=XXXXXX ----- To add delta syncrepl support to the provider, my understanding is that I need to add the access log database: ----- database mdb directory /var/lib/openldap-data/accesslog maxsize 2147483648 suffix cn=accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE ----- And update the syncrepl config on the primary database to include the accesslog overlay: ----- overlay syncprov syncprov-checkpoint 500 30 syncprov-reloadhint TRUE syncprov-sessionlog 500 overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 ----- And then on the consumer, I need to update the syncrepl configuration to include the logbase, logfilter, and syncdata elements: ----- syncrepl rid=1 provider=ldaps://master-2.ldap.csupomona.edu/ type=refreshAndPersist retry="10 10 60 +" searchbase="dc=csupomona,dc=edu" bindmethod=simple binddn=cn=XXXX credentials=XXXXXX logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog ----- Does this all seem reasonable and pass sanity check? Thanks much.

2 2

Overlay ppolicy not found
by Rodrigo Coutinho 30 Jan '14

30 Jan '14

Hi, I'm new to LDAP and have searched your site and others, but have found nothing. I've installed OpenLdap 2.4.35 on a Red Hat Linux 5.9, following the instructions on this site. I've migrated the users and groups from the production database (Oracle). Now, I would like to set Password policies and have altered the slapd.conf accordingly. # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/ppolicy.schema # Load dynamic backend modules: modulepath /usr/local/libexec/openldap # moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la moduleload ppolicy.la ####################################################################### # BDB database definitions ####################################################################### overlay ppolicy ppolicy_default "cn=default,ou=pwpolicies,ou=config,dc=ifap,dc=local" However, when I execute slapd, I get the following error message: 52ea27a8 @(#) $OpenLDAP: slapd 2.4.35 (Oct 21 2013 16:37:56) $ root@abc00102:/u01/ldap/openldap-2.4.35/servers/slapd 52ea27a8 overlay "ppolicy" not found 52ea27a8 slapd stopped. 52ea27a8 connections_destroy: nothing to destroy. So, can I install the policy after installing OpenLdap or must I reinstall everything again ? Should I use the ppolicy.la or the ppolicy.so as stated in http://www.zytrax.com/books/ldap/ch6/ppolicy.html <http://www.zytrax.com/books/ldap/ch6/ppolicy.html> ? # required if the overlay is built dynamically loadmodule ppolicy.la # OR loadmodule ppolicy.so Thank you in advance Rodrigo Coutinho A transmiss�o de mensagens por e-mail n�o � absolutamente segura ou livre de erros. A mensagem pode ser intercetada, alterada, perdida, destru�da, chegar ao destinat�rio com atraso, ou mesmo com v�rus, n�o obstante o IFAP utilizar software anti-v�rus. Esta mensagem, incluindo eventuais ficheiros anexos, pode conter informa��o confidencial ou privilegiada e destina-se a uso exclusivo dos seus destinat�rios. Se n�o for o destinat�rio pretendido, informamos que a recebeu por engano, pelo que, qualquer utiliza��o, distribui��o, reencaminhamento ou outra forma de revela��o a terceiros, impress�o ou c�pia s�o expressamente proibidos. Se recebeu esta mensagem por engano, por favor contacte imediatamente o remetente por e-mail, e apague de imediato a mensagem do seu sistema inform�tico. O IFAP declina qualquer responsabilidade por erros ou omiss�es na presente mensagem e eventuais consequ�ncias, que resultem das situa��es referidas.

2 1

Re: [LMDB] Error 87 followed by MDB_PAGE_NOTFOUND
by Hallvard Breien Furuseth 29 Jan '14

29 Jan '14

On 2014-01-29 23:10, Alain wrote: > On Wed, Jan 29, 2014 at 4:36 PM, Hallvard Breien Furuseth > <h.b.furuseth(a)usit.uio.no> wrote: > >> On 2014-01-29 16:58, Alain wrote: >> >>> While running our app (which seemed to be running slow on this last >>> job), I ended up receiving an rc:87 on a commit, which my app >>> couldn't >>> recover from. I have verified that I have free disk space, free RAM. >> >> Error numbers are OS-dependent. What's errno 87? >> E.g. what does this say: perl -le '$! = 87; print $!' > > I'm running under Windows and have perl only under Cygwin, so not > sure if the results are meaningful, but I get: > $ perl -le '$! = 87; print $!' > Cannot exec a shared library directly Not meaningful, no. Google(windows error 87) says ERROR_INVALID_PARAMETER, which ought to mean a programmer error in your application. If this is code which worked previously, then maybe it lacks error checking. E.g. you're doing mdb_txn_begin() which fails and you use the resulting txn anyway. >> Which LMDB version and operating system do you use? > > I am at commit 5bda356, from 23 days ago and this is running under > Windows 7. > >> If the latest commit was bad, maybe previous one is >> OK. We need to give mdb_copy an option to make a >> backup using the oldest instead of youngest commit. >> Then you'll lose just the last commit instead of >> everything. >> >> That sounds good, as I'm thinking that this is the 2nd copy that >> Howard described during one of his presentation. Yes. -- Hallvard

1 0

[LMDB] Error 87 followed by MDB_PAGE_NOTFOUND
by Alain 29 Jan '14

29 Jan '14

While running our app (which seemed to be running slow on this last job), I ended up receiving an rc:87 on a commit, which my app couldn't recover from. I have verified that I have free disk space, free RAM. Upon restart, after the db was opened, the first process started and quickly reported an MDB_PAGE_NOTFOUND on a call to mdb_cursor_get For your info, here the db info as reported during the restart: Env Stats:{ms_branch_pages=0, ms_psize=4096, ms_depth=1, ms_leaf_pages=1, ms_overflow_pages=0, ms_entries=23} Info:{me_last_pgno=678442, me_mapaddr=0, me_mapsize=4194304000, me_last_txnid=112652, me_maxreaders=300, me_numreaders=0} Data Db Stats:{ms_branch_pages=315, ms_psize=4096, ms_depth=4, ms_leaf_pages=71375, ms_overflow_pages=25, ms_entries=7768832} Primitive Db Stats:{ms_branch_pages=990, ms_psize=4096, ms_depth=4, ms_leaf_pages=183396, ms_overflow_pages=17263, ms_entries=3537190} Incidence Db Stats:{ms_branch_pages=516, ms_psize=4096, ms_depth=4, ms_leaf_pages=86349, ms_overflow_pages=0, ms_entries=11534223} % Full:66.254105% 1- What could have caused this error 87, which seems to be related to some arguments issue? 2- More importantly, what can be done to avoid getting a db in a state like this which seems to me to be corrupted (and that's also what the doc says)? I am keeping the db should it be required for forensic analysis. Thanks Alain

2 1

MDB_BAD_VALSIZE error
by Chris Card 29 Jan '14

29 Jan '14

Hi All, I'm running openldap 2.4.36 on centos 6.3, 64 bit. I'm finally trying out MDB as a replacement for BDB in our openldap setup, and I've noticed that I'm getting MDB_BAD_VALSIZE errors when adding some DNs, which could be added without error when using BDB as the backend: 52e9170b <= mdb_dn2id_add 0x5da55e: -30781 52e9170b mdb_add: dn2id_add failed: MDB_BAD_VALSIZE: Too big key/data, key is empty, or wrong DUPFIXED size (-30781) Looking at the code, it seems that this error happens when MDB_MAXKEYSIZE is exceeded and MDB_MAXKEYSIZE is set to 511 as far as I can see. The DNs which are giving this error are between 232 and 255 characters long. Does the MDB backend have an implicit limit on the length of valid DNs? Can this be increased (by changing MDB_MAXKEYSIZE) and if so, what is the longest DN which can be supported by the MDB backend? Chris

3 5

Ldapdelete
by Borresen, John - 0442 - MITLL 28 Jan '14

28 Jan '14

All, Attempting to backtrack a bit by deleting an overlay using the following (have tried both with & without the escape character with the same error "Invalid DN": # ldapdelete -W -x -ZZ -D cn=admin,cn=config -v -d 9 "olcOverlay=\{0\}syncprov,olcDatabase=\{0\}config,cn=config" And receiving the following error: ... read1msg: ld 0xb749c40 0 new referrals read1msg: mark request completed, ld 0xb749c40 msgid 3 request done: ld 0xb749c40 msgid 3 res_errno: 34, res_error: <invalid DN>, res_matched: <> ldap_free_request (origid 3, msgid 3) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_delete: Invalid DN syntax (34) additional info: invalid DN ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 TLS trace: SSL3 alert write:warning:close notify ldap_free_connection: actually freed Here is a slapcat of that "olcDatabase". # slapcat -s olcDatabase=\{0\}config,cn=config dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=admin,cn=config olcRootPW:: _________________________________= olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 4354a8b6-8a36-4804-81f8-14a8550aef74 creatorsName: cn=config createTimestamp: 20131218155313Z entryCSN: 20131218155313.477459Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20131218155313Z dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncProvConfig olcOverlay: {0}syncprov structuralObjectClass: olcSyncProvConfig entryUUID: 644d3984-d125-446e-aae2-1ddc541f4661 creatorsName: cn=admin,cn=config createTimestamp: 20140121191314Z entryCSN: 20140121191314.076259Z#000000#004#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20140121191314Z Thanks in advance John D. Borresen (Dave) Linux/Unix Systems Administrator MIT Lincoln Laboratory Surveillance Systems Group 244 Wood St Lexington, MA 02420 Email: john.borresen(a)ll.mit.edu<mailto:john.borresen@ll.mit.edu>

1 0

indexing warning considered harmful
by Michael Ströder 27 Jan '14

27 Jan '14

HI! We all know the following messages in syslog (loglevel stats): mdb_equality_candidates: (foo) not indexed At first glance this seems helpful to find indexing issues. But IMO 1. this is somewhat mis-leading. regarding performance tuning and 2. if internal searches are conducted (e.g. by set-based ACLs) the amount of the very same indexing warnings is really annoying and costs performance due to excessive logging. AFAIK a set of search candidates is derived from filter assertions by first searching the indexed attributes. Then the non-indexed assertions are tested but only on the search candidate set. Is this correct? If yes, then indexing an attribute which is present in many entries can lead to large search candidate set even though the amount of final search results are small. Consider the following simple example: (&(objectClass=posixAccount)(uid=foo)) With lots of user accounts this would lead to two search candidate sets, one very large and one with one entry (assuming uid values are unique). Not indexing objectClass would one result in *one* search candidate. So indexing objectClass might not be very wise. What do you think about this? Ciao, Michael.

3 4

slapadd question
by Mundry, Marvin 27 Jan '14

27 Jan '14

hi, when I use slapadd to setup cn=config I get > slapadd: warning, missing attrs entryUUID,entryCSN from entry dn="olcDatabase=bdb,cn=config" warnings (one for each database and overlay that is configured) as soon as I add an olcSyncrepl attribute to "dn: olcDatabase=config,cn=config" should I be worried about these warnings? what I am doing: slapadd -S 1 -bcn=config -l slapd.ldif -F slapd.d/ with slapd.ldif having the following content: dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /usr/local/openldap/var/run/slapd.args olcPidFile: /usr/local/openldap/var/run/slapd.pid dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/local/openldap/libexec/openldap olcModuleload: back_bdb.la dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///usr/local/openldap/etc/openldap/schema/core.ldif dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: frontend dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config olcRootDN: cn=admin,cn=config olcRootPW:: e1NTSEF9L1Q1US9ibUl0V3pYRnpOUG9iajdsbk5IVVJmS2E5Ykk= olcSyncrepl: rid=001 provider=ldap://someldapserver/ binddn="cn=acme" credentials=secret bindmethod=simple searchbase="cn=config" type=refreshAndPersist dn: olcDatabase=bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: bdb olcSuffix: dc=my-domain,dc=com olcRootDN: cn=Manager,dc=my-domain,dc=com olcRootPW: secret olcDbDirectory: /usr/local/openldap/var/openldap-data Best regards, Marvin

2 1

Ldap Autofs Connection Issue
by Borresen, John - 0442 - MITLL 27 Jan '14

27 Jan '14

All, Here is an interesting dilemma that we are trying to figure out. server1.example.ldap server2.example.ldap client1.example.ldap All running 2.4.38, this is a test environment. Server1 is a client to itself, server2 is a client to itself, and client1 is a client to server2. client1's LDAP Autofs (in the /etc/nsswitch.conf) is pointing to server2...and it works fine. In the /etc/sysconfig/autofs file on the client (client1) the URI entry indicates: "ldap://server2.example.ldap"; and the /etc/nsswitch.conf file shows "ldap" On both server1 and server2, for now -- because if fails otherwise, the URI in the /etc/sysconfig/autofs shows "ldaps://server1.production.ldap"; and the /etc/nsswitch.conf file shows "ldap". As you can see, the production server is using port 636 (SSL), the test environment is using TLS over port 389. Neither test environment server holds the production certificates, and the production side is not holding the test environment certs. Another interesting tidbit, is all the Automount/NFS servers are NetApp filers and they hold certs for the Production Environment, except one which is a Test Filer (in the Test Environment). Sorry if this sounds like an old "Abbott & Costello" routine from the 30's... If anyone can shed some light on what to look for. That would be great. By the way, permission is not an issue. I can explicitly mount all mountpoints to all three in the test environment. The issue is LDAP and Autofs in the Test environment. Thanks, in advance. -----Original Message----- From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter Klünter Sent: Friday, January 24, 2014 4:09 PM To: openldap-technical(a)openldap.org Subject: Re: Ldap Connection Issue Am Fri, 24 Jan 2014 14:45:25 -0500 schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > All, > > Very similar issue that Warron was/is having. > > Server1: # ldapsearch -W -x -ZZ -b cn=config -v -D cn=admin,cn=config > Server1: # ldapsearch -W -x -ZZ -H ldap://server2.example.ldap -b > cn=config -v -D cn=admin,cn=config > > These commands work (they returns the dbase as expect & desired), both > servers are clients to themselves and the other server (using > self-signed wildcard certificates) Both ldap.confs are identical, the > one on server1 was used on server2. The URI directive looks like: > > uri ldap://server1.example.ldap ldap://server1.<FQDN> > ldap://server2.example.ldap ldap://server2.<FQDN> > > Server2: > > a) # ldapsearch -W -x -ZZ -b cn=config -v -D cn=admin,cn=config > Fails with: > ldap_initialize( <DEFAULT> ) > ldap_start_tls: Connect error (-11) > > > b) # ldapsearch -W -x -ZZ -H ldap://server2.example.ldap -b > cn=config -v -D cn=admin,cn=config > > ldap_initialize( ldap://server2.example.ldap:389/??base ) > > ldap_start_tls: Connect error (-11) > > > c) # ldapsearch -W -x -ZZ -h ldap://server1.example.ldap -b > cn=config -v -D cn=admin,cn=config > > d) ldap_initialize( ldap://ldap:%2F%2Fserver1.example.ldap) > > e) Could not create LDAP session handle for > URI=ldap://ldap:%2F%2Fgp42-admin4.llan.ll.mit.edu (-9): Bad parameter > to an ldap routine > > There is one other client that like server1 can search the dbase(s) on > both servers (it too is a client of both servers). > > Any ideas at what to look for? read on ldapsearch(1) and distinction of -h and -H parameters. furthermore read on LDAP URL and escape sequences (RFC-4516). -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical