Looks ok to me.  Did you set your replica up to fully resynch after making the acl changes on the master and restarting slapd on it (the master)? --Quanah

From: Quanah Gibson-Mount <quanah(a)zimbra.com&gt; Subject: Re: top-level data entries not replicating, 2.4.15, now 2.4.17 To: "Brian Neu" <proclivity76(a)yahoo.com&gt;, openldap-technical(a)openldap.org Date: Monday, August 24, 2009, 12:26 PM --On Friday, August 21, 2009 5:57 PM -0700 Brian Neu <proclivity76(a)yahoo.com&gt; wrote: > I do this: > > > [root@victory3 ldap]# /etc/init.d/ldap stop && rm -fr /var/lib/ldap/*.* > /var/lib/ldap/alock && /etc/init.d/ldap start Ok, that certainly looks like it is wiping out the database. ;) > [root@victory3 ldap]# ldapsearch -x -D "cn=Manager,dc=srg,dc=com" -w > secret -b cn=test3,dc=srg,dc=com ># extended LDIF ># ># LDAPv3 ># base <cn=test3,dc=srg,dc=com> with scope subtree ># filter: (objectclass=*) ># requesting: ALL ># > ># search result > search: 2 > result: 32 No such object > matchedDN: dc=srg,dc=com > ># numResponses: 1 Are you sure replication completed yet?  I'm guessing yes, but ... ;) > uid=user,ou=People  entries replicate fine, as well as services and > everything else that came from the migration tools.  But those test > entries and the SambaDomainName entry at the top level don't replicate. > > > Should I start the consumer with a certain debug level and look into an > error? > > I just started slapd with >    -s 205 -d 205 2>debug.txt > after letting it run for a minute, there is no "test2" or "test3" in the > resulting output, though every other entry is. > > > Should we be looking into the provider? I'm not sure why you are screwing with the syslog level.  Usually the default level is fine.  Have you completely verified that the replicator credentials can see those objects on the master? If that works, then yes, using slapd -d -1 and capturing that to a file may indicate why they aren't replicating. --Quanah

From: Quanah Gibson-Mount <quanah(a)zimbra.com&gt; Subject: Re: top-level data entries not replicating, 2.4.15, now 2.4.17 To: "Brian Neu" <proclivity76(a)yahoo.com&gt;, openldap-technical(a)openldap.org Date: Monday, August 24, 2009, 9:11 PM --On Monday, August 24, 2009 6:03 PM -0700 Brian Neu <proclivity76(a)yahoo.com&gt; wrote: >> If that works, then yes, using slapd -d -1 and capturing >> that to a file may >> indicate why they aren't replicating. >> >> --Quanah > > > From what I can tell by looking at the provider log (-1), new top-level > entries are added to the provider correctly, and to the accesslog on the > provider, but I'm not familiar enough with the OpenLDAP code to be > certain. > > Can anyone test to see if they experience the same thing? Err, sorry.  I meant run slapd -d -1 on the replica, to see why it isn't replicating those entries. --Quanah

From: Quanah Gibson-Mount <quanah(a)zimbra.com&gt; Subject: Re: top-level data entries not replicating, 2.4.15, now 2.4.17 To: "Brian Neu" <proclivity76(a)yahoo.com&gt;, openldap-technical(a)openldap.org Date: Monday, August 24, 2009, 9:34 PM --On Monday, August 24, 2009 6:28 PM -0700 Brian Neu <proclivity76(a)yahoo.com&gt; wrote: > Unfortunately, not until tomorrow eve, EST.  The consumer server > (victory3) is temporarily in someone's office before it goes to a colo, > and was turned off due to the fan noise for the biz day.  It SHOULD have > been powered back on, but someone forgot. > > Aren't there a couple of virtual servers somewhere that serve as testing > grounds for the project?  That, or does someone have a provider->consumer > set-up in production that can test a benign top-level data entry and see > if it replicates? This sort of setup works for me, and hundreds of others, no problem.  Which is why figuring out why it isn't working for you is non-trivial.  I still suspect it is a configuration issue that is non-obvious. --Quanah

From: Quanah Gibson-Mount <quanah(a)zimbra.com&gt; Subject: Re: top-level data entries not replicating, 2.4.15, now 2.4.17 To: "Brian Neu" <proclivity76(a)yahoo.com&gt;, openldap-technical(a)openldap.org Date: Friday, August 28, 2009, 12:18 PM --On Friday, August 28, 2009 8:58 AM -0700 Brian Neu <proclivity76(a)yahoo.com&gt; wrote: > On the consumer, victory3, I'm running this: > /etc/init.d/ldap stop && rm -fr /var/lib/ldap/*.* /var/lib/ldap/alock && > /etc/init.d/ldap start 2>/var/lib/ldap/debug-trace.txt > > Then on the provider, I'm running an ldapadd on this file: > <test9.ldif> > dn:cn=test9,dc=srg,dc=com > objectclass: top > objectclass: person > userpassword:{MD5}HaaaTaaaaaaaaaaaaaJzaaaaaMg== > sn:test9 > cn:test9 > > > Then back to the consumer, I <CTRL+C> to stop slapd.  I vim > /var/lib/ldap/debug-trace.txt  and /test9  .  No instance of test9 in the > file.  No instance of any of the top-level data entries, though it's a > 643MB file. > > I'm at a loss. Can you please bind as the replicator credentials to the master, and verify it can see these entries? I.e., ldapsearch -x -H ldap://victory2.srg.com:389 -D "cn=replicator,dc=srg,dc=com" -W -b "dc=srg,dc=com" cn=test9

Also, search the accesslog db: ldapsearch -x -H ldap://victory2.srg.com:389 -D "cn=replicator,dc=srg,dc=com" -W -b "cn=accesslog"

And see if it can see the add operation for that entry in there too. Also, make sure the add operation for that entry exists in the accesslog db either way (using the rootdn credentials if you can't see it with the replicator ones). --Quanah