Re: Q: Multiple accesslog overlays?

[Quanah Gibson-Mount <quanah@symas.com>]

--On Thursday, August 22, 2019 4:37 PM +0200 Geert Hendrickx 
<geert@hendrickx.be> wrote:

> On Thu, Aug 22, 2019 at 06:32:53 -0700, Quanah Gibson-Mount wrote:
> > > Turns out that writes failed by an overlay (slapo-unique in our case)
> > > are only logged to the accesslog, if this overlay is defined in the
> > > config BEFORE the accesslog overlay (as overlays are loaded on a
> > > stack, see topic 12.18 in the admin guide).  So we now put the
> > > accesslog overlay as last instead of first.
> >
> > Hm, which is against best practices because it can cause other issues,
> > IIRC (which is why it's advised to have syncprov followed by accesslog,
> > as the first 2 overlays in the stack).  This is something that needs
> > redoing for 2.5.
>
>
> What sort of issues Quanah?  Do you advise to rollback?
>
> We currently have the following order: syncprov, unique, accesslog.
>
> Before it was: syncprov, accesslog unique.
>
> Are these best practices you mention documented somewhere?

As you noted, overlays can intercept write operations.  The problem is when 
an overlay intercepts a write op, where the write op occurs in the primary 
DB, but returns before accesslog is called, meaning that accesslog does not 
record the write op.  This then breaks consistency between the servers. 
Since you're logging failures, you hit a different case, which generally 
underscores why this entire processing stack needs rewriting for 2.5.

I don't believe this is currently documented as an issue (we don't have any 
document really addressing overlay ordering at all that I can find).

--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>