[Date Prev][Date Next] [Chronological] [Thread] [Top]

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


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/";
  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