Re: slurpd and back-config

[Howard Chu <hyc@symas.com>]

Kurt D. Zeilenga wrote:

> I note that one aspect of slurpd architecture is that one can
> insert a replog rewriting agent between slapd(8) and slurpd(8).
> If we move all the provider side into an overlay, we'd lose
> this.
>  
True. Although one could write additional overlays to do the rewriting 
instead.

> Maybe it is better to simply say that slurpd users cannot
> use back-config?
I guess that's OK for now, but eventually we need to provide a 
dynamically configurable slurpd replacement.

I think we can already handle this right now using a separate slapd 
process configured with a syncrepl consumer on a back-ldap database. If 
the consumer operates in persist mode then updates from the master will 
be propagated in realtime to the remote slave through back-ldap. If the 
back-ldap target becomes unreachable, we just have to abandon the 
persistent search until the remote comes back online, and then the 
syncrepl refresh will bring the remote back up to date without any 
replogs or intervention required. There are some retry details that have 
to be covered before this will work in the current code, but overall 
this should be no problem to work up.

The only real coding effort required here is if we want to condense the 
replicator into the main slapd process (and avoid the need to run a 
second slapd instance). In that case, we need the functionality of both 
the syncrepl provider and consumer in a single module.

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