https://bugs.openldap.org/show_bug.cgi?id=9326
--- Comment #3 from Howard Chu hyc@openldap.org --- (In reply to dar from comment #0)
After a process manager taking note of a certificate roll over, it will be convenient for such process manager to instruct the slapd daemon to set LDAP_OPT_X_TLS_NEWCTX for both client(s) and server(s) tls context through an IPC signal.
No.
Thereby servers would gain graceful support with minimal downtime for certificate rolling.
Alternatively, dn=config _can_ be put in a shape so as to receive a dummy operation that induces a config reload.
While this is possible, it is inconvenient for several reasons:
- It requires a _dummy_ op, and thereby has the notion of a workaround
It uses features already built in to slapd for dynamically changing its state. It is not a workaround.
- It triggers a reload of the entire config, instead of only renewing the
tls context (educated guess on my side)
No, it only changes what you ask it to change. In contrast, what you're requesting with a signal has no way to specify exactly what should change among a wide variety of potential changes.
- It requires the process manager to somehow gain directly or indirectly
knowledge of the ldap protocol. This increases deployment complexity. 4. It requires special handling of authC and authZ for such process manager and thereby significantly increases deployment complexity - especially authZ in the context of immutable / gitops-controlled configs. 5. Those dummy operations have to be crafted against olcGlobal for the server and any database's olcSyncRepl configuration. Therefore a helper must also read given values and dummy-replace them back in.
In particular, signal handling and threaded programs don't mix well. We cannot safely or reliably implement signal-dependent features. Any feature request of this nature will be rejected.