Hi, When using a filter on a replicated branch, it seems that deletion updates are still propagated... The cluster in use is a 4 nodes master-master with the following settings: olcsyncrepl: rid=4 provider="ldaps://url" type=refreshAndPersist retry="5 10 60 +" timeout=5 network-timeout=10 keepalive=60:10:5 schemachecking=off searchbase="dc=root,dc=com" scope=sub bindmethod=sasl saslmech=external tls_cacertdir=/usr/local/openldap/etc/openldap/certs tls_cert=/usr/local/openldap/etc/openldap/certs/cert.crt tls_key=/usr/local/openldap/etc/openldap/certs/cert.key tls_cipher_suite=HIGH tls_reqcert=demand filter="(!(objectclass=MyOwnClass))" The objectclass is as follow:
dn: MyOwnClass=state,ou=initials,dc=root,dc=com AF-UID: state objectClass: MyOwnClass objectClass: top STATE: UP structuralObjectClass: MyOwnClassThe replication account does not possesses any access to this element :olcAccess: to dn.exact="MyOwnClass=state,ou=initials,dc=root,dc=com" by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn.exact="cn=status,ou=serviceaccounts,dc=root,dc=com" read by dn.exact="cn=confldap,ou=serviceaccounts,dc=root,dc=com" manage by * none Yet, when MyOwnClass=state,ou=initials,dc=root,dc=com is deleted the following logs appear:
serverA : op=1 DEL dn="MyOwnClass=state,ou=initials,dc=root,dc=com" serverA : op=1 syncprov_matchops: recording uuid for dn=MyOwnClass=state,ou=initials,dc=root,dc=com on opc=0x7ff5a00157c0 serverB : op=0 syncprov_matchops: recording uuid for dn=MyOwnClass=state,ou=initials,dc=root,dc=com on opc=0x7f158c0015c8 serverB : syncrepl_del_nonpresent: rid=003 be_delete MyOwnClass=state,ou=initials,dc=root,dc=com (0) serverB : op=1 SRCH base="MyOwnClass=state,ou=initials,dc=root,dc=com" scope=2 dereIs it an expected behavior?
When updating the value or renaming the object, no replication is noticed. Have a good day,-- Pierre Marty Ingénieur Logiciel / OSSA pmarty@linagora.com (+33) 067 530 3612 ------------------ ossa@linagora.com (+33) 080 005 4689 - 3 ------------------ GROUPE LINAGORA Villa Good Tech 37 Rue Pierre Poli 92130 Issy-les-Moulineaux (+33) 097 263 9776
On Fri, Jun 28, 2024 at 09:42:56AM +0000, Pierre Marty wrote:
Hi, When using a filter on a replicated branch, it seems that deletion updates are still propagated... The cluster in use is a 4 nodes master-master with the following settings: olcsyncrepl:
serverA : op=1 DEL dn="MyOwnClass=state,ou=initials,dc=root,dc=com" serverA : op=1 syncprov_matchops: recording uuid for dn=MyOwnClass=state,ou=initials,dc=root,dc=com on opc=0x7ff5a00157c0 serverB : op=0 syncprov_matchops: recording uuid for dn=MyOwnClass=state,ou=initials,dc=root,dc=com on opc=0x7f158c0015c8 serverB : syncrepl_del_nonpresent: rid=003 be_delete MyOwnClass=state,ou=initials,dc=root,dc=com (0) serverB : op=1 SRCH base="MyOwnClass=state,ou=initials,dc=root,dc=com" scope=2 dereIs it an expected behavior?
When updating the value or renaming the object, no replication is noticed.
Hi Pierre, this is during the initial refresh: your entry was changed since your last sync and now it's "not there" (it's not visible due to ACLs), the provider doesn't know if it ever was there, so it tells the consumer the DN+entryUUID is no longer around. This is the bare minimum that needs to be disclosed to achieve a consistent copy on the replica.
During persist, each modification is checked for: - could they see it before? - can they see it now?
As both are a "no", nothing is sent. This kind of information is not available during a refresh.
Regards,
Thank you for the explanations ! Make sense now.
Have a great day,
On 6/29/24 10:59 AM, Ondřej Kuzník wrote:
On Fri, Jun 28, 2024 at 09:42:56AM +0000, Pierre Marty wrote:
Hi, When using a filter on a replicated branch, it seems that deletion updates are still propagated... The cluster in use is a 4 nodes master-master with the following settings: olcsyncrepl:
serverA : op=1 DEL dn="MyOwnClass=state,ou=initials,dc=root,dc=com" serverA : op=1 syncprov_matchops: recording uuid for dn=MyOwnClass=state,ou=initials,dc=root,dc=com on opc=0x7ff5a00157c0 serverB : op=0 syncprov_matchops: recording uuid for dn=MyOwnClass=state,ou=initials,dc=root,dc=com on opc=0x7f158c0015c8 serverB : syncrepl_del_nonpresent: rid=003 be_delete MyOwnClass=state,ou=initials,dc=root,dc=com (0) serverB : op=1 SRCH base="MyOwnClass=state,ou=initials,dc=root,dc=com" scope=2 dereIs it an expected behavior?
When updating the value or renaming the object, no replication is noticed.
Hi Pierre, this is during the initial refresh: your entry was changed since your last sync and now it's "not there" (it's not visible due to ACLs), the provider doesn't know if it ever was there, so it tells the consumer the DN+entryUUID is no longer around. This is the bare minimum that needs to be disclosed to achieve a consistent copy on the replica.
During persist, each modification is checked for:
- could they see it before?
- can they see it now?
As both are a "no", nothing is sent. This kind of information is not available during a refresh.
Regards,
openldap-technical@openldap.org
-
Ondřej Kuzník -
Pierre Marty -
Pierre MARTY