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

Re: cn=config: sharing, conditionals

Gavin Henry wrote:

----- "Quanah Gibson-Mount"<quanah@zimbra.com>  wrote:

--On Tuesday, May 26, 2009 8:35 PM -0700 Howard Chu<hyc@symas.com>

For example, we may have a cluster of servers in MMR with a pool of
servers operating as slaves. We'd want the syncprov overlay active
on all
of the masters, the syncrepl consumer active on all of the servers,
the chain overlay active on all of the slaves. Setting
olcServerMatch on
the syncprov and chain overlays would allow things to behave as
without needing to create a parallel config tree just for the


I like it.  One thing we've needed to do in the past is drop the
replication configuration portions of a master (taking it to
mode).  This would allow that.  I would note it may be common (I
do so) to run the syncprov overlay on the replica as well, at least in
glue'd environment.

It sounds like it gracefully solves the ability of keeping both master
replica configurations around for the most part.  What still remains
is ACLs.  There are plenty of valid reasons for the master to have
different ACLs than the replicas do.

Agreed, it's still not a perfect solution for ACLs and such. Although you could use servermatch on the database itself, and have two separate olcDatabase entries, one for the master and one for the slave. That would also allow you to use separate indexing on the master vs the slaves.

I agree with Quanah too. Would these be a 2.5 features?

If we can get it working right away, no, I'd release it into 2.4 ASAP since we have an immediate need for this ability. Of course, it may not be a candidate for 2.4.17 - we need to focus on stability there still. (Moving the syncrepl consumer into an overlay would not happen in 2.4...)

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