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).