Hello,
I've a openldap master and numerous sync replica servers running. I'm suspect my master contain mail attributes that aren't unique. My idea was to build an other sync replica with unique overlay enabled. The 'empty' sync replica will fetch data from master and complain about values that aren't unique. I would discard that replica, correct the master database and start replication again until replication succeed.
But then there was reality :-/ I placed an deliberately none-unique value in my database but replication did not fail. The replica did contain two DNs with "mail=none-unique@example.test".
syncrepl.conf:
moduleload mdb.la moduleload unique.la
database mdb suffix ou=test ...
overlay unique uniqiue_uri ldap:///ou=test?mail?sub?
index ... limits ...
syncrepl rid=1 privider=ldap://master.example ...
access ...
Q: is this setup wrong? Q: is replication the right way to enforce uniqueness? Looks like the answer is "no" Q: what is "the" better way?
Andreas
On 5/14/19 8:03 PM, A. Schulze wrote:
I've a openldap master and numerous sync replica servers running. I'm suspect my master contain mail attributes that aren't unique. My idea was to build an other sync replica with unique overlay enabled. The 'empty' sync replica will fetch data from master and complain about values that aren't unique. I would discard that replica, correct the master database and start replication again until replication succeed.> But then there was reality :-/ I placed an deliberately none-unique value in my database but replication did not fail. The replica did contain two DNs with "mail=none-unique@example.test".
IIRC slapo-unique and slapo-constraint are not triggered for replicated operations.
BTW: IMHO your approach is much too heavy-weight anyway. A simple Python script running locally on your OpenLDAP server is not much work and consumes less ressources.
Ciao, Michael.
openldap-technical@openldap.org
-
A. Schulze -
Michael Ströder