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

Re: replicated cn=config



Quanah Gibson-Mount wrote:



--On Friday, April 29, 2005 1:31 PM -0700 Howard Chu <hyc@symas.com> wrote:

Quanah posed this question about how to set up a bunch of replica servers
that all use configurations replicated from the master as well. It wasn't
perfectly obvious at first, so I'm posting this note to suggest an
approach and get some reactions. I haven't tested this yet.


First of all, you cannot just replicate cn=config straight from a master
to a slave server, because the slave will wind up with an identical copy
of the master's configuration (and will then cease to be a slave). This
means you must use some alternate tree, and map it into the slave's
cn=config.

So here's a possible approach - on the master

    database ldif
    directory /some/path
    suffix cn=replica-config

On each slave
    database relay
    suffix cn=replica-config
    relay cn=config massage

Then either slurpd or syncrepl can be used to keep the slaves'
configurations up to date.


Unfortunately, I've found a problem with doing this, which is bothersome to me, because I really need to be able to do this.

With syncrepl:


binddn="cn=HOSTNAME,cn=ldap,cn=operational,dc=stanford,dc=edu" authcId=ldap/HOSTNAME.stanford.edu@stanford.edu

binddn's are irrelevant in SASL binds. As Luke mentioned, the authcID is extracted from the Kerberos ticket automatically, so neither of these two parameters are needed.


With both slurpd and syncrepl:

sasl-host HOSTNAME.stanford.edu

I've never needed to configure the sasl-host on any of my machines.


-- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support