I can see how ramping up diagnosis capabilities on a running piece of software is an outstanding feature, that unfortunately not a lot programs have out there.
My mental model of gitops certainly doesn't aim at blocking diagnostic capabilities, it does however seek to keep critical knobs under a general, unified and well established approval and auditing process across the entire system components zoo.
I suggest writing an overlay for this, whose only function is to schedule
a periodic task that does all of the refreshing you want to have happen.
I understand why signalling is not considered a valid solution. In fact it's not the cleanest one. Given the security aware user base of OpenLDAP, I'd predic that a generic solution to certificate rolling will spark some interest.
Times where such a roll is done once in a few years are fading. In my case, the default with spiffe is every 5 minutes, but short lived certificates are a general trend in software.
Wouldn't we be able to conceive an acceptable patch that doesn't introduce (too much) runtime penalties which gracefully reloads TLS context on expiry exactly once?
Assuming that the proclaimed trend towards short lived certificates pervails, such patch adds value to OpenLDAP's user community as it - by default - lowers the barrier to adoption of more secure practices.
Best Regards, David A.
El sábado, 22 de agosto de 2020, Howard Chu hyc@symas.com escribió:
David Arnold wrote:
However, for realoding rolled certs this is a bit unfortunante.
Alternatively, would it be possible rather than using
a SIGNAL to gracefully fall back to reload the TLS context once if the
current certs appear expired?
I predict I'm not gonna be the last person with this issue...
I suggest writing an overlay for this, whose only function is to schedule a periodic task that does all of the refreshing you want to have happen.
Best Regards, David A.
On Fri, Aug 21, 2020 at 15:36, Quanah Gibson-Mount quanah@symas.com
wrote:
--On Friday, August 21, 2020 5:53 PM -0500 David Arnold
<dar@xoe.solutions mailto:dar@xoe.solutions> wrote:
Cool, I'm getting there! Unfortunately and for good reasons thecreator of ae-dir.com has restricted modifying access for config (in order to tightly
control runtime config state). SASL/EXTERNAL authentication started SASL username:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
Did you actually add an authz-regexp to your config that maps this DN
to the cn=config rootdn? Otherwise I'd expect it to fail. Not sure this is really an
AEDir thing.
Furthermore, would this dummy change also reload the certificatesthat are configured for the syncrepls?
No, you'd need to do a replace op on the olcSyncrepl attribute for that
database as well. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas
Corporation Packaged, certified, and supported LDAP solutions powered
by OpenLDAP: http://www.symas.com
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/