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