making a full replica: slapd -c "rid=xxx" doesn't seem to work

[Jephte CLAIN <Jephte.Clain@univ-reunion.fr>]

hello,

I'm new on this list.
I use OpenLDAP 2.4.23 on debian squeeze

I'm currently testing full replication with the small configuration seed 
on the consumer side, but the replication is not complete.

Let me explain in details:

so, the consumer starts with no data at all (I wipe /etc/ldap/slapd.d/* 
files, and /var/lib/ldap/*)

Based on the test049, I do 'slapadd -F /etc/ldap/slapd.d -b cn=config -l 
initial.ldif' with initial.ldif as:

------------- 8< -------------
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcPidFile: /var/run/slapd/slapd.pid

dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcSyncrepl: {0}rid=0 provider="ldap://master.tld/";
  searchbase=cn=config
  bindmethod=simple binddn=cn=config credentials=password
  type=refreshAndPersist retry="60 10 300 +" schemachecking=off
------------- 8< -------------

on the provider side, cn=config is the rootdn of cn=config

so the database cn=config is replicated, except for the above objects.
Indeed, the logs says:

dn_callback : new entry is older than ours cn=config ours 
20120127114737.207735Z#000000#000#000000, new 
20120127112957.179717Z#000000#000#000000
dn_callback : new entry is older than ours 
olcDatabase={0}config,cn=config ours 
20120127114737.207985Z#000000#000#000000, new 
20120127112953.813862Z#000000#000#000000

and this makes sense. I searched the archives, and found a message from 
Howard Chu made on 19 Apr 2011:

------------- 8< -------------
>The problem I now face is that the initial cn=config entries used to do
>the first sync do not get overwritten by the data from the master. So
>the install password doesn't get replaced nor do the updated retry
>timeouts for olcSyncRepl, because, I'm assuming, the 'stub' entries
>have newer timestamps than those on the master.
>
>How can this be overcome from the perspective of the slave server.
>Updating the entries on the master triggers the update as you would
>expect. Is there a way to put the stub entries onto the slave with a
>timestamp in the past so that they get overwritten during the first
>sync? Or is there another way to trigger them to be updated?

Use slapd -c. Read the slapd(8) manpage.
------------- 8< -------------

The manpage says:

------------- 8< -------------
-c cookie
    (...) Use only the rid part to force a full reload.
------------- 8< -------------

So I tried '/usr/sbin/slapd -c "rid=0" -d 16384 ...' but I got the 
message above about the entry not overwritten because of the timestamp. 
I wonder what I am doing wrong...

I'd prefer not to have to use a more recent version, because debian 
already does a good job following the patches and keeping the whole 
thing stable :-) But If this is a known issue, what are my options?

I mean, my goal is to replicate schemas, indexes, limits, acls and Authz 
definitions. I thought that a whole replica would the easiest.

how do you guys do this?

thanks in advance for your inputs. best regards,

Jephté Clain
Direction des Systèmes d'Information
et des Usages Numériques - 2IG
Tél. 0262 93 86 31
Fax. 0262 93 81 06