diff options
author | Alexander Bokovoy <abokovoy@redhat.com> | 2015-12-23 14:57:03 +0200 |
---|---|---|
committer | Alexander Bokovoy <abokovoy@redhat.com> | 2015-12-23 14:57:03 +0200 |
commit | 38fc0024c2669006a4d71a722a75cf2aeeb3e4bf (patch) | |
tree | 73a2febd64b2647e212355f9aa2b0e26aaa61f24 /tests/test09-schema-modrdn-entry/before.sh | |
parent | da26d9595e6449009575e8d2a4c888176829a97f (diff) | |
download | slapi-nis-38fc0024c2669006a4d71a722a75cf2aeeb3e4bf.tar.gz slapi-nis-38fc0024c2669006a4d71a722a75cf2aeeb3e4bf.tar.xz slapi-nis-38fc0024c2669006a4d71a722a75cf2aeeb3e4bf.zip |
slapi-nis: populate data trees asynchronously after LDAP server startup
Currently slapi-nis design assumes the map cache is populated by
scanning the original trees on plugin start up. This has few
consequences:
- LDAP server cannot serve LDAP clients until all plugins are
initialized
- slapi-nis cannot ask SSSD to resolve external identities at
this point as SSSD will need to talk to the LDAP server which
is at this point not listening for connections. SSSD will put
whole IPA domain into offline and always will respond
with negative result
To solve these issues, schedule tree scan after LDAP server startup.
The problem here is that it is not possible to reliably detect when
389-ds starts to listen to the incoming connections. However, it is
possible to schedule an event into 389-ds event queue that will run
shortly after start of the event loop. Given that the call back function
which is registered to be called is called within the event loop thread,
one can fire off another thread and wait in the thread function some
time until the LDAP server is ready for connections.
The time interval is something that would depend on a specific
deployment profile but experiments show that having 5 seconds delay
should be enough as event queue is created just before starting the
listeners.
Diffstat (limited to 'tests/test09-schema-modrdn-entry/before.sh')
0 files changed, 0 insertions, 0 deletions