--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