[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#7840) bug with initial/seed syncrepl
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
>>
>>
>
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
--
cordialement,
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