[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6458) syncrepl fails if attribute has no equalty maching rule

> Full_Name: Patrick Cernko
> Version: 2.4.21
> OS: Linux
> URL:
> http://www.mpi-inf.mpg.de/~pcernko/syncrepl_fails_if_attribute_has_no_equalty_maching_rule.tar.bz2
> Submission from: (NULL) (
> Hi OpenLDAP-Programmers,
> although some related bug reports were posted in the past years, this
> issue
> still seems not to be fixed:
> OpenLDAP's syncrepl replication fails if it comes to removing one of a
> multi-value attribes of an object if this attribute does not have a
> equality
> matching rule defined in the schema. Modification works on the master
> server but
> fails to replicate to the slave(s) leaving them with the dit version just
> before
> and not replicating any other changes any more.
> I compiled a small example how to reproduce the problem with the (maybe
> "well-known") nisNetgroupTriple attribute from nis.schema as shipped with
> openldap-2.4.21:
> - extract the files from
> http://www.mpi-inf.mpg.de/~pcernko/syncrepl_fails_if_attribute_has_no_equalty_maching_rule.tar.bz2
> into an empty working directory
> - download the tarball to that working dir and configure similar to the
> just
> extracted configure.sh
> - build and install it to get an install subdir in the working dir
> - start the master using sh master.sh in the working dir
>   This will create the "master" database in your working dir, slapadd the
> dit.ldif and start a master slapd with a unix socket /tmp/master.
> - start the slave using sh slave.sh
>   This will create "slave" database in your working dir and start the
> slave
> slapd with a unix socket /tmp/slave which will immediately start syncing
> from
> the running master
> - if you want you can search the 2 servers with
>   install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL
>   resp.
>   install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL
> - use "python mod.py" to remove one of the nisNetgroupTriple attributes
> from the
> netgroup object
> - you will see a debug message from the slave server like this:
> bdb_modify_internal: delete nisNetgroupTriple
> bdb_modify_internal: 18 modify/delete: nisNetgroupTriple: no equality
> matching
> rule
> send_ldap_result: err=18 matched="" text="modify/delete:
> nisNetgroupTriple: no
> equality matching rule"
> null_callback : error code 0x12
> slap_graduate_commit_csn: removing 0x29931c0
> 20100120124712.028626Z#000000#000#000000
> syncrepl_entry: rid=001 be_modify cn=netgroup,ou=openldap (18)
> syncrepl_entry: rid=001 be_modify failed (18)
>   if not, use "python mod.py add" to re-add the removed nisNetgroupTriple
> and
> try again. Sometimes, it seems to work (race condition?).
> - you can also verify the difference with:
>   install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL
> cn=netgroup
>   install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL
> cn=netgroup
> - from now on, the slave will fail to sync any succeeding changes, as it
> continuously tries to sync the modification above first. :-(
> Now, obviously having an attribute without equality matching rule is not a
> good
> idea in the first place. However, the (official?) nis.schema comes with
> such an
> attribute which we must use like this (e.g. we would have to patch the
> Solaris
> kernel to change it for the Solaris NFS server).
> It is possible to modify a nisNetgroup object like this: according to the
> debugging output, I guess the master removes simply ALL nisNetgroupTriple
> attributes and adds only the attributes that should remain. When the
> corresponding syncrepl_entry is handled by the slave, it seems the it in
> contrast tries to really only remove the 2-be-removed attribute which does
> not
> work as it cannot identify the right one due to a missing eq-match
> operator.
> I suggest the best way to solve this issue is to try to get syncrepl do
> exactly
> the same actions (not resulting changes) as the server does.

I see the issue, and I've isolated it to the case where you're removing a
value.  In that case, in attr_cmp(), nn == 0 and no < o; the original test
for modifying an attribute without matching rule fails.  I've fixed it
according to this patch, not sure whether it's appropriate for other cases


Please test and review.  Thanks, p.