Kyle Brantley wrote:
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:
- 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.
This would be the "correct" approach, but currently it's not implemented. There's already an ITS#8148 for this issue.
- 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.
This is the expected behavior. If syncrepl sees an attribute on the local DB but doesn't see it from the provider, it assumes the attribute was deleted on the provider and therefore deletes it locally as well.
How best can I go about doing this?
I don't see any workaround at the moment.
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