(ITS#6641) Syncrepl failure with 'overlay unique'

[andrew.findlay@skills-1st.co.uk]

Full_Name: Andrew Findlay
Version: 2.4.23
OS: SLES 10.3 x86_64
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (88.97.25.132)


The attribute uniqueness overlay can cause syncrepl to jam up.
Consider this case:

1) Configure a mirrormode pair with identical configs, including 
   'unique_attributes uid'

2) Start one server and add some data, including an entry containing a UID
value.

3) Start the second server, let it synchronise, then stop it again.

4) On the first server, delete the entry and add a new one with a different DN
   that has the same UID value.

5) Start the second server. Look in the logs, and you will see something like
this:

Sep  7 11:33:03 jupiter slapd[19407]: @(#) $OpenLDAP: slapd 2.4.23 (Sep  6 2010
19:55:47) $     andrew@jupiter:/usr/local/src/openldap-2.4.23/servers/slapd
Sep  7 11:33:03 jupiter slapd[19408]: slapd starting
Sep  7 11:33:04 jupiter slapd[19408]: conn=1000 fd=23 ACCEPT from
IP=127.0.0.1:33611 (IP=0.0.0.0:389)
Sep  7 11:33:04 jupiter slapd[19408]: conn=1000 op=0 BIND dn="" method=128
Sep  7 11:33:04 jupiter slapd[19408]: conn=1000 op=0 RESULT tag=97 err=0 text=
Sep  7 11:33:04 jupiter slapd[19408]: conn=1000 op=1 SRCH base="" scope=0
deref=0 filter="(objectClass=*)"
Sep  7 11:33:04 jupiter slapd[19408]: conn=1000 op=1 SEARCH RESULT tag=101 err=0
nentries=1 text=
Sep  7 11:33:04 jupiter slapd[19408]: conn=1000 op=2 UNBIND
Sep  7 11:33:04 jupiter slapd[19408]: conn=1000 fd=23 closed
Sep  7 11:33:04 jupiter slapd[19408]: null_callback : error code 0x13
Sep  7 11:33:04 jupiter slapd[19408]: syncrepl_entry: rid=001 be_add
uniqueIdentifier=list.6b9432f9,dc=routing,dc=mail,dc=apps,dc=nis,dc=brunel,dc=ac,dc=uk
failed (19)
Sep  7 11:33:04 jupiter slapd[19408]: do_syncrepl: rid=001 rc 19 retrying (9
retries left)
Sep  7 11:34:04 jupiter slapd[19408]: null_callback : error code 0x13
Sep  7 11:34:04 jupiter slapd[19408]: syncrepl_entry: rid=001 be_add
uniqueIdentifier=list.6b9432f9,dc=routing,dc=mail,dc=apps,dc=nis,dc=brunel,dc=ac,dc=uk
failed (19)
Sep  7 11:34:04 jupiter slapd[19408]: do_syncrepl: rid=001 rc 19 retrying (9
retries left)
Sep  7 11:35:05 jupiter slapd[19408]: null_callback : error code 0x13
Sep  7 11:35:05 jupiter slapd[19408]: syncrepl_entry: rid=001 be_add
uniqueIdentifier=list.6b9432f9,dc=routing,dc=mail,dc=apps,dc=nis,dc=brunel,dc=ac,dc=uk
failed (19)
Sep  7 11:35:05 jupiter slapd[19408]: do_syncrepl: rid=001 rc 19 retrying (9
retries left)

The problem is that syncrepl is trying to add the new entry before deleting the
old one, and the uniqueness constraint on UID is preventing it from doing so.

It is likely that other constraints on data will have the same effect.
See for example this thread:
http://www.openldap.org/lists/openldap-software/201001/msg00038.html

The obvious answer is for syncrepl to bypass all data checks, as the supplier
server should have already enforced them. The problem with that is that clients
could see data that breaks the rules if they query while syncrepl is running
(unless the refresh phase is handled as a single transaction and thus isolated
from clients until it is complete).

Andrew