https://bugs.openldap.org/show_bug.cgi?id=9326

--- Comment #1 from dar@xoe.solutions ---

Thereby servers would gain graceful support with minimal downtime for certificate rolling.

As an alternative, the slpad server would gain the capability to detect file changes on cert-related files and internally trigger LDAP_OPT_X_TLS_NEWCTX.

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:

1. 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.

2. 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.

3. 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.

https://bugs.openldap.org/show_bug.cgi?id=9326

Quanah Gibson-Mount quanah@openldap.org changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED