Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl

[quanah@zimbra.com]

--On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati 
<ando@sys-net.it> wrote:

> Quanah Gibson-Mount wrote:
>> --On Tuesday, September 09, 2008 8:50 PM +0200 Pierangelo Masarati
>> <ando@sys-net.it> wrote:
>>
>>> I thuink the issue is related to the fact that slapadd -w uses
>>> bi_tool_entry_modify() and bi_tool_sync().  However, slapo-accesslog(5)
>>> does not implement those hooks.  As a consequence, any modification to
>>> the context entry is not reflected in slapo-accesslog(5).
>>>
>>> However, I don't see how this should affect replication, since a
>>> consistent database, after slapcatt'ing, should generate a ldif with the
>>> correct contextCSN.  However, if you slapcat before stopping the
>>> producer, the resulting ldif will not contain the contextCSN, because
>>> after a fresh slapadd without -w it's kept in memory until the producer
>>> is stopped.  You should try

Just to be clear here, I'm slapcating a provider while it is running, then 
stopping the provider and the replica, wiping both their dbs, then using 
slapadd -w to reload the *provider* and syncrepl to load the consumer. 
Thus I don't see whether or not the CSN is in memory at the time on the 
*provider* matters much.  Particularly given that if I stop the reloaded 
provider and restart it (i.e., flushing the context CSN), I still get the 
same behavior problems on the replica.  I.e., the replica has never been 
loaded via slapadd, only the provider, and the provider has been stopped 
started since the slapadd.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration