Re: top-level data entries not replicating, 2.4.15, now 2.4.17

[Brian Neu <proclivity76@yahoo.com>]

--- On Fri, 8/28/09, Quanah Gibson-Mount <quanah@zimbra.com> wrote:

> From: Quanah Gibson-Mount <quanah@zimbra.com>
> Subject: Re: top-level data entries not replicating, 2.4.15, now 2.4.17
> To: "Brian Neu" <proclivity76@yahoo.com>, openldap-technical@openldap.org
> Date: Friday, August 28, 2009, 12:18 PM
> --On Friday, August 28, 2009 8:58 AM
> -0700 Brian Neu <proclivity76@yahoo.com>
> 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

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

Appears to also work fine, see below results.
 
> 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

queried as replicator from the consumer . . . .

# extended LDIF
#
# LDAPv3
# base <cn=accesslog> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# accesslog
dn: cn=accesslog
objectClass: auditContainer
cn: accesslog

# 20090828143237.000001Z, accesslog
dn: reqStart=20090828143237.000001Z,cn=accesslog
objectClass: auditAdd
reqStart: 20090828143237.000001Z
reqEnd: 20090828143237.000002Z
reqType: add
reqSession: 1417
reqAuthzID: cn=Manager,dc=srg,dc=com
reqDN: cn=test9,dc=srg,dc=com
reqResult: 0
reqMod: objectClass:+ top
reqMod: objectClass:+ person
reqMod: userPassword:+ {MD5}blah
reqMod: sn:+ test9
reqMod: cn:+ test9
reqMod: structuralObjectClass:+ person
reqMod: entryUUID:+ bce8a427-6d66-491d-b790-e80afc6f0112
reqMod: creatorsName:+ cn=Manager,dc=srg,dc=com
reqMod: createTimestamp:+ 20090828143237Z
reqMod: entryCSN:+ 20090828143237.174926Z#000000#000#000000
reqMod: modifiersName:+ cn=Manager,dc=srg,dc=com
reqMod: modifyTimestamp:+ 20090828143237Z

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2