Quanah Gibson-Mount quanah@symas.com schrieb am 22.08.2019 um 20:22 in
Nachricht <A04BCE7561957BE4FFD75F7C@[192.168.1.144]>:
‑‑On Thursday, August 22, 2019 9:09 PM +0200 Geert Hendrickx geert@hendrickx.be wrote:
On Thu, Aug 22, 2019 at 08:07:53 ‑0700, Quanah Gibson‑Mount wrote:
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.
Can that really happen between unique and accesslog overlays? The unique overlay doesn't write any data itself, it will only reject certain writes?
The actual write to the underlying mdb database will only occur after it passed through the entire overlay chain, or am I misunderstanding how it works?
I believe you're fine with unique, it's other ones like ppolicy and memberOf where they have to be after accesslog IIRC.
So this would be the wrong order (this is not real syntax, but just the file names from a config dump, the LDIF files defining the corresponding overlay)? olcOverlay={0}syncprov.ldif olcOverlay={1}accesslog.ldif olcOverlay={2}ppolicy.ldif
Regards, Ulrich
‑‑Quanah
‑‑
Quanah Gibson‑Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com