[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Antw: Re: Q: Multiple accesslog overlays?
>>> 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>