Hi, How about delta-syncrepl ? http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl%20replication Cheers. Le 21/08/2015 21:31, Kyle Brantley a écrit :
I'm working on a full multi-master slapd setup, where both the cn=config
database as well as the actual database are fully replicated. All access
to the slapd instances is gated with GSSAPI (the only notable exception
being the syncrepl users, which I'm working on converting over to GSSAPI
anyway).
However, I need to be able to configure olcSaslHost on a per-server
basis. Server A will have a different value for olcSaslHost than server
B will. While I want to replicate cn=config, I don't want to replicate
the olcSaslHost attribute.
I've tried two things, and neither have worked:
1) Configuring exattrs="olcSaslHost" in the olcSyncrepl statements for
cn=config.
* This allows me to configure the attribute, but as soon as there
is any other change to cn=config, it wipes the attribute out across all
of the nodes.
2) Updating the ACL for the syncrepl user to not have access to the
olcSaslHost attribute.
* Unfortunately, this has similar behavior to the above: making a
change on one node will wipe the olcSaslHost attribute out of all of the
nodes.
How best can I go about doing this? I was hoping that olcSaslRealm was
multi-value and could be configured in a manner similar to olcServerID,
but that isn't the case. I was hoping that denying access to the
attributes (via ACL or olcSynrepl config) would make the syncrepl engine
ignore the attribute, but because it can't see it on the node where the
attribute was changed, but it can see it on the downstream nodes, it
wipes the attribute out entirely.
Any help / suggestions welcome.
Thanks,
--Kyle
-- *Abdelhamid Meddeb* http://www.meddeb.net
Attachment:
smime.p7s
Description: Signature cryptographique S/MIME