Rein Tollevik wrote:

On 04/25/2010 12:49 AM, hyc@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?