openldap-technical

openldap-technical@openldap.org

9 participants
9867 discussions

RE: Syncrepl and mmr
by Quanah Gibson-Mount 31 Jan '14

31 Jan '14

--On Friday, January 31, 2014 8:54 AM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)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(a)openldap.org > Subject: RE: Syncrepl and mmr > > --On Thursday, January 30, 2014 4:51 PM -0500 "Borresen, John - 0442 - > MITLL" <John.Borresen(a)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

2 1

RE: Syncrepl and mmr
by Quanah Gibson-Mount 31 Jan '14

31 Jan '14

--On Thursday, January 30, 2014 4:51 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)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

2 1

Re: Overlay ppolicy not found
by Dieter Klünter 31 Jan '14

31 Jan '14

Am Thu, 30 Jan 2014 12:13:04 +0000 schrieb Rodrigo Coutinho <Rodrigo.Coutinho(a)ifap.pt>: > Hi again, > > Th result was: > > Included static overlays: > syncprov > Included static backends: > config > ldif > monitor > bdb > hdb > mdb > relay > > What now? Check with your OS Distribution whether there are additional dynamic loadable modules. -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

2 1

RE: Syncrepl and mmr
by Quanah Gibson-Mount 31 Jan '14

31 Jan '14

--On Thursday, January 30, 2014 4:25 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > Thanks Quanah... > > Question, about the "manage" Access Level when would that be used? > > It is not talked about at all other than Table 5.4 in section 8.3.3. The man pages are the definitive source for all information. I would suggest you read the slapd.access(5) man page. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

4 3

RE: Syncrepl and mmr
by Quanah Gibson-Mount 30 Jan '14

30 Jan '14

--On Thursday, January 30, 2014 4:51 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > All Masters in the chain have the olcServerID's and olcSynRepl for itself > and its partner? I can understand having each knowing about the others > but why itself? It's replicating to itself? It knows about itself so it knows what to ignore. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: Syncrepl and mmr
by Quanah Gibson-Mount 30 Jan '14

30 Jan '14

--On Thursday, January 30, 2014 4:35 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > Seeing the following in the logs: > > Jan 30 16:28:41 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty > syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 30 16:28:41 gp42-admin4 > slapd[26000]: do_syncrepl: rid=001 rc -1 retrying > > Jan 30 16:33:02 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 got empty > syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 30 16:33:02 gp42-admin3 > slapd[3599]: do_syncrepl: rid=002 rc -1 retrying Sounds like you managed to break your system somehow. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

RE: Syncrepl and mmr
by Quanah Gibson-Mount 30 Jan '14

30 Jan '14

--On Thursday, January 30, 2014 3:28 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > Thanks Quanah... > > Now, I'm going to ask this... > > My current ACL is: > > olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by > anonymous auth by * none olcAccess: {1}to * by * read > > Supposed this allows the user to modify their userPassword and (in so > doing) modifying the shadowLastChange, allows anonymous to authenticate > against these entries and allows others to read these entries > > Am I reading that correctly...or at least close? > > To give my syncrepl user (ldapadmin) access, my new ACL would another > olcAccess: > > olcAccess:{2}to * by cn=ldapdmin manage > > Is that correct? I would suggest you re-read the documentation on ACLs. As noted in the ACL documentation, ACL processing STOPS on the first matching ACL by default. So NO ACL is evaluated for userPassword and ShadowLastChange if they do not match the self write, anonymous auth bits. What you would want is something like: olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by replicauser read by * none olcAccess: {1}to * by * read I.e, specifically grant read access to those 2 attrs to whatever the DN is for your replication user. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical