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

Re: (ITS#7840) bug with initial/seed syncrepl


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) (
>> 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"

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
> --
>   -- Howard Chu
>   CTO, Symas Corp.           http://www.symas.com
>   Director, Highland Sun     http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/

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