[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Multi-master syncrepl config: excluding olcSaslHost from replication



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:

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.

This would be the "correct" approach, but currently it's not implemented. There's already an ITS#8148 for this issue.

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.

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




--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/