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

Re: replicated cn=config





--On Monday, November 21, 2005 11:15 PM -0800 Quanah Gibson-Mount <quanah@stanford.edu> wrote:



--On Monday, November 21, 2005 10:42 PM -0800 Quanah Gibson-Mount
<quanah@stanford.edu> wrote:

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.

Which won't fork for a few reasons:

1) No indexing in back-ldif
2) database config does not support operations required for syncrepl

So at this time it is entirely impossible to do a replicated cn=config on the replica side (Howard said it was probably possible by doing rewrites on the master side with back-ldif... blah) because back-relay and slapo-rwm don't support back-config at this time.


Hopefully the various bits of 2.3 will support back-config enough to make it worthwhile to use someday soon, because right now every time I go to use it, I'm stymied by unsupported pieces. I'd be happy to convert things over, and have even done some attempts at this, but my C skills are very rusty, and I'm still trying to figure out the *_cf_func pieces.

-Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html