[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
making a full replica: slapd -c "rid=xxx" doesn't seem to work
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