On Fri, Jan 17, 2020 at 11:07:01AM +0100, Ondřej Kuzník wrote:
On Thu, Jan 16, 2020 at 04:08:28PM +0100, Michael Ströder wrote:
HI!
I vaguely remember that it's possible that two slapd processes can access a single MDB env.
Is that supported? Any pre-cautions needed?
I think if you were to configure both of them as a syncrepl consumer, that might cause some headaches?
(reply to list this time)
Also if either of them is a syncrepl provider, probably make sure that no other server is accepting writes to this db file, I can imagine (refreshAndPersist) scenarios that might leave you unhappy otherwise.
On 1/17/20 11:12 AM, Ondřej Kuzník wrote:
On Fri, Jan 17, 2020 at 11:07:01AM +0100, Ondřej Kuzník wrote:
On Thu, Jan 16, 2020 at 04:08:28PM +0100, Michael Ströder wrote:
HI!
I vaguely remember that it's possible that two slapd processes can access a single MDB env.
Is that supported? Any pre-cautions needed?
I think if you were to configure both of them as a syncrepl consumer, that might cause some headaches?
Also if either of them is a syncrepl provider, probably make sure that no other server is accepting writes to this db file, I can imagine (refreshAndPersist) scenarios that might leave you unhappy otherwise.
I guess you mean conflicts when generating entryCSN values? Good point.
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.
Ciao, Michael.
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.
openldap-technical@openldap.org
-
Michael Ströder -
Ondřej Kuzník