>>> Quanah Gibson-Mount <[email protected]> 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 > <[email protected]> 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>
