On Fri, Jan 17, 2020 at 07:42:31PM +0100, Michael Ströder wrote:
I guess you mean conflicts when generating entryCSN values? Good
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
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.
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP