hello, FYI, I just stumbled on an old topic from 2011:
--------------------------------- 8< --------------------------------- Re: cn=config replication to consumer / slave servers ________________________________ To: Christopher Strider Cook <[email protected]> Subject: Re: cn=config replication to consumer / slave servers From: Howard Chu <[email protected]> Date: Tue, 19 Apr 2011 17:27:58 -0700 Cc: Quanah Gibson-Mount <[email protected]>, [email protected] ________________________________ 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 <[email protected]>: > 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 >>> >>> -- 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
