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?

Chris Card wrote: > I am running openldap 2.4.36 with BDB for my main backend db, and

> > I monitor the contextCSN to check that replication is in sync, but I've

> > If I try to delete a non-existent DN from the main db on machine A, I > see

> > On machine B the contextCSN of the main db is updated, as if the delete > had

> Is this a known bug?

Are you using slapo-memberof or slapo-refint? If yes, you're probably hitting ITS#7710 which was fixed recently in OpenLDAP 2.4.37: http://www.openldap.org/its/index.cgi?findid=7710 Ciao, Michael.

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?

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.