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

[pcernko+openldap@mpi-sws.org]

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) (139.19.3.67)


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.