Re: (ITS#4626) "glue" objectclass in syncrepl consumer

[ahasenack@terra.com.br]

On Mon, Jul 31, 2006 at 07:40:47PM +0000, ahasenack@terra.com.br wrote:
> > > a) syncrepl provider for the whole database: dc=example,dc=com
> > > 
> > > b) Two databases:
> > > - ou=global,dc=example,dc=com: consumer from (a)
> > > - dc=example,dc=com: provider
> > > Both are glued together.
> > > 
> > > c) One database, pulling everything from (b)
> > > 
> > > Config files for (a), (b) and (c) are below. I can also submit the sample
> > > databases I'm using if needed.
> > 
> > With this same setup, replication of "ou=global" from (b) to (c) isn't working.
> > No change is detected when I alter ou=global in server (a).
> > 
> > I'll try to draw it:
> > 
> > (a) one database, one syncprov:
> > 
> >              + dc=example,dc=com
> >             / \
> >          ...   + ou=global
> >               / \
> >            ...   ...
> > 
> > 
> > (b)
> >              + dc=example,dc=com
> >             / \
> >          ...   + ou=global (pulled from (a) via syncrepl)
> >               / \
> >            ...   ...
> > 
> > This is two databases glued together: one for dc=example,dc=com and another for
> > ou=global, which is pulled from (a) using ou=global,dc=example,dc=com as the
> > base. I tried with one syncprov in dc=example,dc=com loaded after glue, and
> > with two syncprov (one for each database).
> > 
> > 
> > (c)
> > 
> >               + dc=example,dc=com
> >              / \
> >           ...   + ou=global
> >                / \
> >             ...   ...
> > 
> > This one is a single database and a consumer from (b). The syncrepl base is
> > dc=example,dc=com. It's a backup server for (b).
> > 
> > This server doesn't get changes done to ou=global, and it also has the issue
> > where the ou=global entry itself gets mangled.
> 
> As I keep testing this scenario, I noticed these error messages in (b)'s log:
> Entry ou=Global,dc=example,dc=com CSN 20060731190352Z#000000#00#000000 greater than snapshot 20060731182950Z#000000#00#000000
> Entry cn=newgroup,ou=Group,ou=Global,dc=example,dc=com CSN 20060731190352Z#000000#00#000000 greater than snapshot 20060731182950Z#000000#00#000000
> 

I re-ran this test today with 2.3.26 and I have collected the CSNs from the
servers.  My guess is that the leaf server (c) gets into trouble because it
searches the whole tree of its producer which consists of two databases with
unrelated CSNs. So, following the drawing above (a -> b -> c), these are the
numbers for today's run:

a) entryCSN = 20060817204825Z#000006#00#000000
   (no contextCSN)

b) ou=global database:
   entryCSN   = 20060817204828Z#000000#00#000000
   contextCSN = 20060817204828Z#000000#00#000000

   dc=example,dc=com database:
   entryCSN   = 20060817201110Z#000000#00#000000
   contextCSN = 20060817201110Z#000005#00#000000

c) entryCSN   = 20060817201110Z#000005#00#000000
   contextCSN = 20060817201110Z#000005#00#000000

In this scenario, these are the logs from (b) when I start its consumer (c)
fresh with no database:
Entry ou=Global,dc=example,dc=com CSN 20060817204828Z#000000#00#000000 greater than snapshot 20060817201110Z#000005#00#000000
Entry ou=People,ou=Global,dc=example,dc=com CSN 20060817204825Z#000007#00#000000 greater than snapshot 20060817201110Z#000005#00#000000
Entry ou=Group,ou=Global,dc=example,dc=com CSN 20060817204825Z#000008#00#000000 greater than snapshot 20060817201110Z#000005#00#000000
Entry ou=System Accounts,ou=global,dc=example,dc=com CSN 20060817204825Z#000009#00#000000 greater than snapshot 20060817201110Z#000005#00#000000
Entry ou=System Groups,ou=global,dc=example,dc=com CSN 20060817204825Z#00000a#00#000000 greater than snapshot 20060817201110Z#000005#00#000000
Entry uid=global-testuser1,ou=People,ou=Global,dc=example,dc=com CSN 20060817204825Z#00000b#00#000000 greater than snapshot 20060817201110Z#000005#00#000000
Entry cn=global-testgroup1,ou=Group,ou=Global,dc=example,dc=com CSN 20060817204825Z#00000c#00#000000 greater than snapshot 20060817201110Z#000005#00#000000
Entry cn=LDAP Replicators,ou=System Groups,ou=global,dc=example,dc=com CSN 20060817204825Z#00000d#00#000000 greater than snapshot 20060817201110Z#000005#00#000000
Entry cn=LDAP Admins,ou=System Groups,ou=global,dc=example,dc=com CSN 20060817204825Z#00000e#00#000000 greater than snapshot 20060817201110Z#000005#00#000000
Entry uid=LDAP Replicator,ou=System Accounts,ou=global,dc=example,dc=com CSN 20060817204825Z#00000f#00#000000 greater than snapshot 20060817201110Z#000005#00#000000
Entry uid=LDAP Admin,ou=System Accounts,ou=global,dc=example,dc=com CSN 20060817204825Z#000010#00#000000 greater than snapshot 20060817201110Z#000005#00#000000

The consumer (c) is not getting the ou=Global part of the tree and logs this:
slapd starting
request done: ld 0x820f240 msgid 1
syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
syncrepl_entry: be_search (32)
syncrepl_entry: dc=example,dc=com
is_entry_objectclass("", "2.5.17.0") no objectClass attribute
is_entry_objectclass("", "2.5.6.1") no objectClass attribute
is_entry_objectclass("", "2.16.840.1.113730.3.2.6") no objectClass attribute
syncrepl_entry: be_add (0)
syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
syncrepl_entry: be_search (0)
syncrepl_entry: ou=remote1,dc=example,dc=com
syncrepl_entry: be_add (0)
syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
syncrepl_entry: be_search (0)
syncrepl_entry: ou=People,ou=remote1,dc=example,dc=com
syncrepl_entry: be_add (0)
syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
syncrepl_entry: be_search (0)
syncrepl_entry: ou=Group,ou=remote1,dc=example,dc=com
syncrepl_entry: be_add (0)
syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
syncrepl_entry: be_search (0)
syncrepl_entry: uid=remote1-testuser1,ou=People,ou=remote1,dc=example,dc=com
syncrepl_entry: be_add (0)
syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
syncrepl_entry: be_search (0)
syncrepl_entry: cn=remote1-testgroup1,ou=Group,ou=remote1,dc=example,dc=com
syncrepl_entry: be_add (0)
do_syncrep2: LDAP_RES_INTERMEDIATE - REFRESH_PRESENT

Hope this helps.