On 04/25/2010 12:49 AM, hyc(a)symas.com wrote:
> Also in terms of logical abstraction the current behavior is wrong; the
> frontend should of course generate the default_referral responses but
> updateref is a per-backend item and should be generated at the backend layer.
> Ideally this would all have been fixed to behave correctly by moving all
> replication support into an overlay, where it properly belongs. As an interim
> step it would be trivial to write an updateref overlay that supersedes the
> current updateref behavior.
Updateref processing should imo be kept out of any replication modules,
it is needed in databases where syncrepl isn't configured too. I'm
using it on my subordinate databases (with an artificial updatedn so
that slapd accepts it..) when syncrepl is configured on the superior
glue database without managing all of the subordinate databases. I.e,
the infamous test058...
I was having the same "chain only on some of the databases" requirement
and is using a patch that allows it. I consider this patch more of a
hack than a correct solution, which is why I haven't contributed it. A
separate updateref overlay apear to me as the best solution. But for
what it's worth, my patch is now in:
ftp://ftp.openldap.org/incoming/rein-ITS6531.patch
An advantage with this patch over a new overlay is that it should be
usable without any configuration changes (provided the chain overlay
have already been configured in the databases and found to not work as
expected there that is ... ;-).
I didn't quite follow the intended usage for this patch. Are other overlays
expected to override the default over_mod_ref() handler?
--
-- Howard Chu
CTO, Symas Corp.