hello,
FYI, I just stumbled on an old topic from 2011:
--------------------------------- 8< ---------------------------------
Re: cn=config replication to consumer / slave servers
________________________________
To: Christopher Strider Cook ccook@pandora.com
Subject: Re: cn=config replication to consumer / slave servers
From: Howard Chu hyc@symas.com
Date: Tue, 19 Apr 2011 17:27:58 -0700
Cc: Quanah Gibson-Mount quanah@zimbra.com, openldap-technical@openldap.org
________________________________
Christopher Strider Cook wrote:
So, the pointer to test059 was exactly what this issue needed and
following it has lead me to an very good working setup with one puzzling
final step.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--------------------------------- 8< ---------------------------------
you always answer "use slapd -c" to this type of question, but you
_never_ mention that newer entries are never overwritten by older
entries. so _in this context_ this answer is useless
building the consumer before the provider is not an option, also _in
this context_
so the only option left is to update the master with an empty modify
ldif to force update of the timestamps
I personnaly use
--------------------------------- 8< ---------------------------------
dn: cn=config
changetype: modify
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
dn: olcDatabase={0}config,cn=config
changetype: modify
--------------------------------- 8< ---------------------------------
besides, if you do this update with a user from a different database,
e.g cn=admin,dc=my,dc=tld the seed replication fails because
modifiersName contains a non existing DN (at the time of the
replication). I consider this a bug also.
anyway, thanks for your dedicated time and effort. OpenLDAP is really
a great software. I have a lot to learn yet. so please bear with me
:-)
best regards,
2014-04-20 11:33 GMT+04:00 Jephte Clain jephte.clain@univ-reunion.fr:
hello,
thanks for your answer.
see my response below
2014-04-20 7:13 GMT+04:00 Howard Chu hyc@symas.com:
Jephte.Clain@univ-reunion.fr wrote:
Full_Name: Jephte CLAIN
Version: 2.4.39
OS: Debian 6 64bits
URL: http://jclain.fr/openldap-its/
Submission from: (NULL) (93.176.62.129)
I have scripts to test several replication scenarii, that setup the LDAP
environment then allow me to play with parameters as I see fit.
I believe that there is a bug with the "seed replication" that allow one
to
build an exact clone of a master with minimal configuration on the slave
side.
There is no bug. The syncrepl consumer is working as designed. If you want
the consumer's entries to be automatically overwritten, create the consumer
first so that its seed entries have older timestamps than the provider.
ok, it works as designed. I just didn't know what the design was :-)
quoting man slapd:
Use only the rid part to force a full reload.
I guess I didn't notice that the word "full" have a different meaning
here than usual
about creating the consumer first. you are kidding, right? in
production, the provider exists long before the consumer is set up.
the tests I do are based on the production state.
anyway, my automated scripts "touch" the provider after setting up the
slave, so this is not a problem.
It's just that I would prefer not to have wasted time wondering why
the slave was not being updated even though I asked for a "full"
reload
Thanks for your answer. It's now clearer in my mind.
I Cc the openldap-technical list, this can help others.
note: the tests below require 2 VMs, or running the two slapd instances in
chroots, because a clone replica requires the data files to be in the same
path...
That's far overkill. All you need to do is configure your test scripts to
use relative pathnames. test049 (and others) in the test suite already
operates this way.
ok thanks for pointing this out
It has been a while since I read the tests scripts. I should have paid
more attention...
Closing this ITS.
I attach two scripts to replicate the problem. they require root (they
uses
chroots)
this is with openldap 2.4.39 on debian squeeze. some paths may have to be
fixed
in the scripts below
use jclain-20140419-0start.sh to:
- create a ldap server to be served on ldap://localhost:3890
- start the master in chroot
(the logs are in /jclain-slapd-test/master.data/slapd.log)
- create a seed ldap replica to be served on ldap://localhost:3891 with
ldap://localhost:3890 as the provider
- start it in chroot with option -c rid=0
(the logs are in /jclain-slapd-test/slave.data/slapd.log)
use jclain-20140419-1stop.sh to:
- stop the servers
- umount the chroots
If I understand the manual correctly, after 0start.sh, the replica should
be
identical to the master thanks to -c rid=0
BUT, the log on the replica says:
534d5481 dn_callback : new entry is older than ours cn=config ours
20140415154713.807278Z#000000#000#000000, new
20140415154704.888204Z#000000#000#000000
and indeed, the seed entries are NOT overwritten
I have to "touch" them on the master to force the replication.
I have uploaded the scripts to http://jclain.fr/openldap-its/
thanks in advance
--
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