[Date Prev][Date Next]
(ITS#5443) Multiple identical attibutes break syncrepl process fatally?
Full_Name: Marian Eichholz
Submission from: (NULL) (22.214.171.124)
We use openldap as mail service directory with some 8 Mio objects on several
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
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
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,
- 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).