hello, thanks for your answer. see my response below
2014-04-20 7:13 GMT+04:00 Howard Chu <[email protected]>: > [email protected] 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
