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/