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

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

To: Howard Chu <hyc@symas.com>
Subject: Re: (ITS#7840) bug with initial/seed syncrepl
From: Jephte Clain <jephte.clain@univ-reunion.fr>
Date: Tue, 22 Apr 2014 08:07:03 -0000
Cc: openldap-its@openldap.org, openldap-technical@openldap.org
In-reply-to: <CAPas2jSgd8CmaGTBAsbfFWqkaOJUm8tcy7_-SS=kKjskwE6q3Q@mail.gmail.com>
References: <CAPas2jSgd8CmaGTBAsbfFWqkaOJUm8tcy7_-SS=kKjskwE6q3Q@mail.gmail.com>

hello,

FYI, I just stumbled on an old topic from 2011:

--------------------------------- 8< ---------------------------------
Re: cn=config replication to consumer / slave servers
________________________________
To: Christopher Strider Cook <ccook@pandora.com>
Subject: Re: cn=config replication to consumer / slave servers
From: Howard Chu <hyc@symas.com>
Date: Tue, 19 Apr 2011 17:27:58 -0700
Cc: Quanah Gibson-Mount <quanah@zimbra.com>, openldap-technical@openldap.org
________________________________

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 <jephte.clain@univ-reunion.fr>:
> 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
>>>
>>>

-- 
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

References:
- Re: (ITS#7840) bug with initial/seed syncrepl
  - From: Jephte Clain <jephte.clain@univ-reunion.fr>

Prev by Date: Re: (ITS#7840) bug with initial/seed syncrepl
Next by Date: Re: What is the option '-e ppolicy' ?
Index(es):
- Chronological
- Thread