[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: two slapd processes accessing one MDB env



On Fri, Jan 17, 2020 at 07:42:31PM +0100, Michael Ströder wrote:
> I guess you mean conflicts when generating entryCSN values? Good point.

It never hits the other server's overlay stack, so syncprov won't see
the modification and won't forward it to any of its active consumers.
Many other things in syncprov will break for the same reason.

> The problem to be solved:
> 
> If a back-sock listener configured as overlay also needs access to some
> LDAP entries then I have a loop in the frontend LDAP thread pool. This
> possibly blocks. So my plan was to setup a shadow slapd and access the
> database via this (separate LDAP thread pool).
> 
> In the simplest form there would only be read access. But OATH-LDAP's
> HOTP validator would also need to update some attributes.

Maybe use 'readonly on' on the database or send referrals towards the
writable slapd.

You then still have the HOTP validator send writes to the writable
replica so you are back to the original problem if all worker threads
are busy in slapo-sock already.

-- 
Ondřej Kuzník
Senior Software Engineer
Symas Corporation                       http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP