[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: openldap syncrepl issue
> Chris Card wrote:
> Michael Ströder wrote:
>> Chris Card wrote:
>>> Howard Chu wrote:
>>>> Michael Ströder wrote:
>>>>> Chris Card wrote:
>>>>>> I am running openldap 2.4.36 with BDB for my main backend db, and
>>>> multi-master replication setup using delta-syncrepl with MDB for the
>>>> cn=accesslog db.
>>>>>>
>>>>>> I monitor the contextCSN to check that replication is in sync, but I've
>>>> noticed what looks like a bug:
>>>>>>
>>>>>> If I try to delete a non-existent DN from the main db on machine A, I
>>>>>> see
>>>> the delete attempt in the cn=accesslog db on machine A with status 32, but the
>>>> contextCSN of the main db is not changed, as expected.
>>>>>>
>>>>>> On machine B the contextCSN of the main db is updated, as if the delete
>>>>>> had
>>>> succeeded, and then machine A appears to be behind machine B according to the
>>>> contextCSN values.
>>>>
>>>>>> Is this a known bug?
>>>>
>>>> In delta-syncrepl the consumer is supposed to be configured to only receive
>>>> updates from the log whose reqResult=0. Otherwise the consumer shouldn't
>>>> receive anything at all.
>>> I can't see anything in the syncrepl configuration, but I see that slapo-accesslog can be configured with logsuccess set to TRUE:
>>>
>>> logsuccess TRUE | FALSE
>>> If set to TRUE then log records will only be generated for successful requests, i.e., requests that produce a result code of 0 (LDAP_SUCCESS). If FALSE, log records are generated for all requests whether they succeed or not. The default is FALSE.
>>>
>>> Is that what you mean?
>>
>> You probably missed parameter 'logfilter' for the 'syncrepl' statement.
> I do have logfilter set correctly as far as I can see (though I forgot about it in my previous reply):
>
> olcSyncrepl: {1}rid=*** provider="ldap://****:389"; binddn="***************" bindmethod=simple credentials=******* searchbase="**********" type=refreshAndPersist retry="5 5 300 5" timeout=1 logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog
>
> Setting logsuccess to TRUE for the accesslog overlay does work round the problem, but it still feels like a bug to me.
I have just tested this with openldap 2.4.38 and see the same thing: the contextCSN of the main db is updated on machine B when I attempt to delete a non-existent object on machine A. I will raise an ITS.
Chris