Re: Syncrepl not replicating entire tree

[Saket Sathe <saket@cc.iitb.ac.in>]

Hi,

Pierangelo Masarati wrote:

> > > My other question is: since you counted the DNs in both slapcats, can you
> > > check if any of the entries you cannot see has "glue" objectClass?
> > >
> > >
> > >      
> > Yes, they do. Considering the same ex.:  'dn:
> > ou=EE,ou=People,dc=iitb,dc=ac,dc=in' on my consumer has a "glue"
> > objectClass.
> > [ldif]
> > dn: ou=EE,ou=People,dc=iitb,dc=ac,dc=in
> > structuralObjectClass: glue
> > objectClass: top
> > objectClass: glue
> > [\ldif]
> >
> > But the same entry on the provider does not have a "glue" objectClass.
> > [ldif]
> > dn: ou=EE,ou=People,dc=iitb,dc=ac,dc=in
> > ou: EE
> > objectClass: top
> > objectClass: organizationalUnit
> > structuralObjectClass: organizationalUnit
> > entryUUID: 9ea7320a-ec3b-1028-8a25-eb9297806c56
> > creatorsName: cn=Manager,dc=iitb,dc=ac,dc=in
> > createTimestamp: 20041227101255Z
> > entryCSN: 20041227101255Z#00000a#00#000000
> > modifiersName: cn=Manager,dc=iitb,dc=ac,dc=in
> > modifyTimestamp: 20041227101255Z
> > [\ldif]
> >    
>
> OK, that's the issue.  I do not know the reason, but your consumer is
> receiving the children before the parent; as such, it's creating the
> parent as a "glue" entry, i.e. a placeholder for the real object in case
> it comes in.  Usually, this only happens if some entries are intentionally
> not replicated (e.g. by specifying a filter in the syncrepl directive, or
> by means of ACLs, or because a sizelimit was hit and the entries, for some
> reason, were returned in a non-consecutive manner or so).  In any case,
> you should investigate in that direction.  Do entries listed by slapcat
> appear in a consecutive manner (e.g. parents before children)?
Yes, entries listed by slapcat appear in a consecutive manner ( i.e. 
parents before children).

[ldif]
dn: dc=iitb,dc=ac,dc=in
dc: iitb
objectClass: dcObject
objectClass: organizationalUnit
ou: IITB ac dot in
structuralObjectClass: organizationalUnit
entryUUID: ba1bcb1c-b645-1028-951e-9b2b1e4d8c22
creatorsName: cn=manager,dc=iitb,dc=ac,dc=in
modifiersName: cn=manager,dc=iitb,dc=ac,dc=in
createTimestamp: 20041019180913Z
modifyTimestamp: 20041019180913Z
entryCSN: 2004101918:09:13Z#0x0001#0#0000
contextCSN: 20050807195433Z#000001#00#000000

dn: ou=Groups,dc=iitb,dc=ac,dc=in
ou: Groups
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: 9e9008a0-ec3b-1028-8a1e-eb9297806c56
creatorsName: cn=Manager,dc=iitb,dc=ac,dc=in
createTimestamp: 20041227101255Z
entryCSN: 20041227101255Z#000003#00#000000
modifiersName: cn=Manager,dc=iitb,dc=ac,dc=in
modifyTimestamp: 20041227101255Z

dn: ou=People,dc=iitb,dc=ac,dc=in
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: 9e93db74-ec3b-1028-8a1f-eb9297806c56
creatorsName: cn=Manager,dc=iitb,dc=ac,dc=in
createTimestamp: 20041227101255Z
ou: People
entryCSN: 20050107144457Z#000001#00#000000
modifiersName: cn=Manager,dc=iitb,dc=ac,dc=in
modifyTimestamp: 20050107144457Z

dn: ou=EE,ou=People,dc=iitb,dc=ac,dc=in
ou: EE
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: 9ea7320a-ec3b-1028-8a25-eb9297806c56
creatorsName: cn=Manager,dc=iitb,dc=ac,dc=in
createTimestamp: 20041227101255Z
entryCSN: 20041227101255Z#00000a#00#000000
modifiersName: cn=Manager,dc=iitb,dc=ac,dc=in
modifyTimestamp: 20041227101255Z                    

.....

dn: ou=RS,ou=EE,ou=People,dc=iitb,dc=ac,dc=in
ou: RS
description: PhD all categories
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: 9fec023a-ec3b-1028-8a52-eb9297806c56
creatorsName: cn=Manager,dc=iitb,dc=ac,dc=in
createTimestamp: 20041227101257Z
entryCSN: 20041227101257Z#000009#00#000000
modifiersName: cn=Manager,dc=iitb,dc=ac,dc=in
modifyTimestamp: 20041227101257Z

.....

dn: uid=someuser,ou=RS,ou=EE,ou=People,dc=iitb,dc=ac,dc=in
accountStatus: active
objectClass: qmailUser
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: sambaAccount
objectClass: top
objectClass: webUser

......

[\ldif]

What could be the problem ? Would prepopulating the consumer help ?

--
Saket