On Sat, Aug 10, 2019 at 01:23:41AM +0200, Marc Roos wrote:
- updating of a newly spawned slapd instance
When the new task is launched, it is not up to date with its
database,
can I prevent connections to the slapd until it is fully synced?
This is not implemented at this time. See ITS#7616 https://openldap.org/its/?findid=7616.
Hmm interesting. Maybe we can differentiate between a recent startup and
getting up-to-date with the provider. As opposed to blocking client requests with LDAP_BUSY during a 'normal' sync
- to prevent lots of records syncing
Can I just copy the data of /var/lib/ldap of any running instance to
the
container default image?
Maybe, if they are all running identical software and configuration.
The
more robust way to do it is slapcat the database on a known-good
system,
and slapadd it on the new one you're bringing up. In current versions
it
is safe to use slapcat (but not slapadd) while slapd is running.
Yes doing this now with creating the docker image.
- doing some /var/lib/ldap cleanup
I am cleaning with db_checkpoint -1 -h /var/lib/ldap, and db_archive
-d.
Is there an option slapd can initiate this?
See https://www.openldap.org/doc/admin24/maintenance.html.
Checkpointing can be configured using the 'checkpoint' directive (with
slapd.conf, olcDbCheckpoint with slapd-config).
The DB_CONFIG flag DB_LOG_AUTOREMOVE causes transaction logs to be cleaned up automatically.
Thanks!
But please consider migrating to the LMDB backend, which does not require any such maintenance.
When I have finished migrating the centos7 vm to centos7 containers, do not want to do to many changes at once.