Rein Tollevik wrote: > On 04/25/2010 12:49 AM, [email protected] 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. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
