[Date Prev][Date Next]
Re: replicated cn=config
- To: openldap-devel@OpenLDAP.org
- Subject: Re: replicated cn=config
- From: Quanah Gibson-Mount <firstname.lastname@example.org>
- Date: Mon, 21 Nov 2005 22:42:50 -0800
- Content-disposition: inline
- In-reply-to: <427299A2.email@example.com>
- References: <427299A2.firstname.lastname@example.org>
--On Friday, April 29, 2005 1:31 PM -0700 Howard Chu <email@example.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
So here's a possible approach - on the master
On each slave
relay cn=config massage
Then either slurpd or syncrepl can be used to keep the slaves'
configurations up to date.
To follow up on this, it is impossible to do this with slurpd unless you
are using simple binds with the same password on all the database backends
on the replica and master, as slurpd can only store one way to bind to a
slave (i.e., I cannot have it bind to the slave using SASL/GSSAPI for
dc=stanford,dc=edu, and simple binds for cn=config). And cn=config does
not support binding to it with anything other than simple mechs (at least
until ITS#4192 is addressed).
I guess I'll have to try delta-syncrepl instead.
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html