(ITS#5443) Multiple identical attibutes break syncrepl process fatally?

[marian.eichholz@freenet.ag]

Full_Name: Marian Eichholz
Version: 2.4.8
OS: Linux
URL: 
Submission from: (NULL) (194.97.7.65)


We use openldap as mail service directory with some 8 Mio objects on several
replicas.
For openldap 2.4.x we have to migrate from slurpd to syncrepl.
We got a working syncrepl provider als slurpd consumer (slapadd -q, 36 hrs)

So I try to get a blank DB up by syncrepl only (yes, it is not at all
performant, but informative)

The process kind of breaks after a couple of minutes and some 44.000 objects
(8.000.000 expected). Tracing it on the consumer side (-d 16384), I see
something like this after an entry:

syncrepl_message_to_entry: rid=001 mods check (forwardto: value #4 provided more
than once)

Indeed, the entry to come has three "forwardto:" Attributes with the same value
(and other forwardto-attributes, too). This makes no greate sense at the
application level, but until now it has been perfectly OK for the directory, and
the LDAP-API did not complain about the attribute modification, neither did the
slurpd.

This leads to some questions and suggestions:

- the provider does not log anything with -d 16384, no error, no nothing. Could
it do some useful logging about successful and failing replication sessions?

- the consumer does not log anything that can explain, why the remaining objects
are not read, either. A bit of warning/logging could help the hopeful admin,
probably.

- why is one problematic object lethal for the whole rest of the objects, since
future modifications keep to be incorporated? Is this lack of robustness more a
bug or a feature?

- are identical attributes really forbidden with LDAP?

- what could one do, to prevent unskillful "editors" of the master node to kill
the replication processes for the whole replication cluster? Besides adding a
checking/filtering API layer, of course.

Thank You in advance. Please let me know, if I can provide You with something
useful information about our issue(s).