Hi- Please feel free to punt me off to the main OpenLDAP list with this one, but I thought I would start here because my issue seems to have started when I switched to using the Debian LTB package (under Ubuntu) after previously using the Symas build. (BTW, Many thanks to the people responsible for providing those packages, it makes things so much easier for everyone.). This configuration seemed to work fine under the other build so I'm at a bit of a loss as to what could be failing for me now. It is entirely possible that is just something stupid that I'm not seeing.
Here's the short story: I'm in the process of setting up an MMR delta-syncrepl cluster with four hosts. The behavior I am seeing is all of the hosts are constantly pounding each other with queries that look like this (I've selected the log lines generated by one peer): Jul 29 10:40:46 eadrax slapd[3800]: [OK] OpenLDAP stopped after 1 seconds Jul 29 10:40:46 eadrax slapd[3801]: [INFO] No data backup done Jul 29 10:40:46 eadrax slapd[3811]: [INFO] No db_recover done Jul 29 10:40:46 eadrax slapd[3812]: [INFO] Launching OpenLDAP... Jul 29 10:40:46 eadrax slapd[3813]: [OK] File descriptor limit set to 1024 Jul 29 10:40:46 eadrax slapd[3814]: @(#) $OpenLDAP: slapd 2.4.39 (Mar 27 2014 15:44:53) $#012#011root@debian-7:/opt/paquet-openldap-debian/openldap-ltb-2.4.39/servers/slapd Jul 29 10:40:46 eadrax slapd[3815]: slapd starting Jul 29 10:40:47 eadrax slapd[3824]: [OK] OpenLDAP started Jul 29 10:40:55 eadrax slapd[3815]: conn=1000 fd=20 ACCEPT from IP=X.X.X.X :48794 (IP=0.0.0.0:636) Jul 29 10:40:55 eadrax slapd[3815]: conn=1000 fd=20 TLS established tls_ssf=256 ssf=256 Jul 29 10:40:55 eadrax slapd[3815]: conn=1000 op=0 BIND dn="" method=163 Jul 29 10:40:55 eadrax slapd[3815]: conn=1000 op=0 BIND authcid="XXX" authzid="XXX" Jul 29 10:40:55 eadrax slapd[3815]: conn=1000 op=0 BIND dn="cn=replicator,dc=ccs,dc=neu,dc=edu" mech=EXTERNAL sasl_ssf=0 ssf=256 Jul 29 10:40:55 eadrax slapd[3815]: conn=1000 op=0 RESULT tag=97 err=0 text= Jul 29 10:40:55 eadrax slapd[3815]: conn=1001 fd=21 TLS established tls_ssf=256 ssf=256 Jul 29 10:40:55 eadrax slapd[3815]: conn=1000 op=1 SRCH base="dc=ccs,dc=neu,dc=edu" scope=2 deref=0 filter="(objectClass=*)" Jul 29 10:40:55 eadrax slapd[3815]: conn=1000 op=1 SRCH attr=* + Jul 29 10:40:56 eadrax slapd[3815]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=16551 text= Jul 29 10:40:56 eadrax slapd[3815]: conn=1000 op=2 SRCH base="dc=ccs,dc=neu,dc=edu" scope=2 deref=0 filter="(objectClass=*)" Jul 29 10:40:56 eadrax slapd[3815]: conn=1000 op=2 SRCH attr=* + Jul 29 10:40:58 eadrax slapd[3815]: conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=16551 text= Jul 29 10:40:58 eadrax slapd[3815]: conn=1000 op=3 SRCH base="dc=ccs,dc=neu,dc=edu" scope=2 deref=0 filter="(objectClass=*)" Jul 29 10:40:58 eadrax slapd[3815]: conn=1000 op=3 SRCH attr=* + Jul 29 10:41:00 eadrax slapd[3815]: conn=1000 op=3 SEARCH RESULT tag=101 err=0 nentries=16551 text= This repeats over and over again. My first step was to check for the contextCSN attributes, and that's where things got peculiar. I don't seem to have any: # ldapsearch -x -W -LLL -H ldap://localhost -s base -b 'dc=ccs,dc=neu,dc=edu' -D '{rootdn}' '*' '+' Enter LDAP Password: dn: dc=ccs,dc=neu,dc=edu objectClass: domain dc: ccs structuralObjectClass: domain entryUUID: 68f6ddb4-7b00-1033-9992-01dfe5a99447 creatorsName: dc=ccs,dc=neu,dc=edu createTimestamp: 20140528220857Z entryCSN: 20140528220857.846801Z#000000#000#000000 modifiersName: dc=ccs,dc=neu,dc=edu modifyTimestamp: 20140528220857Z entryDN: dc=ccs,dc=neu,dc=edu subschemaSubentry: cn=Subschema auditContext: cn=accesslog hasSubordinates: TRUE I have confirmed with cn=monitor that the syncprov and syncrepl overlays are indeed loaded. I'm happy to provide a full dump of my configs, but before I clutter your inbox any more, does anyone have any theories on how this could be the case? Thanks! -- dNb _______________________________________________ ltb-users mailing list ltb-users@lists.ltb-project.org http://lists.ltb-project.org/listinfo/ltb-users
