Hi All,
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
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?
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.
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?
Are you using slapo-memberof or slapo-refint?
No, just slapo-sssvlv, slapo-accesslog and slapo-syncprov.
If yes, you're probably hitting ITS#7710 which was fixed recently in OpenLDAP 2.4.37:
Chris
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.
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?
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.
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.
Ciao, Michael.
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.
Chris
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
openldap-technical@openldap.org
-
Chris Card -
Howard Chu -
Michael Ströder