Hi

Thx for a quick reply.

Yes exactly it's the ldap_tls_cert. It looks promising, I will give it a try and come back to you.

Regards Edvin

On Tue, May 28, 2019 at 10:51:50AM -0000, Edvin Norling wrote:

We tried with SIGUSR1 and SIGUSR2 but it didn't work.

Ok, I think I have an idea why it is not working, see below.

The bad thing with SIGUSR1 and SIGUSR2 is also that we will not be able to receive users even if for a very short period.

Would it be possible using SIGHUP to re-read certificates and also sssd.conf?

We are currently already using SIGHUP to rotate the logs (see man sssd). So it might be unexpected for people using SIGHUP to rotate the logs that at the same time the LDAP connection is closed and reopened (since this I think is the only way to make sure the new certificate is used). But instead of signals maybe the sssctl utility can be used as well to tell SSSD to reset the connection to an LDAP server in a single step.

Additionally, re-reading sssd.conf and reapplying the settings at run-time is quite complicated so that so far we expect that SSSD is restarted to re-read sssd.conf. Are you asking because the name of the certificate file changes as well? In this case re-starting SSSD would be the most reliable solution.

As i wrote in my first message we could possible do this but want to know that it would be of interest. We want of course work with the community to implement this functionality.

Thanks for the offer. I would suggest to get the SIGUSR1/2 scheme working first by adding some changes to the LDAP connection setup code, because as said I think you have to close and open the connection again to tell the OpenLDAP library to use a new certificate.

Currently in setup_tls_config() the TLS related options are written into a global context and later on the settings are inherited when a LDAP context for a connection is created. I think this is the reason you see no change when doing SIGUSR1/2 because the certificate file is read once into the global context at startup and that's it.

I think we did this because when writing the code we didn't found another way to make the OpenLDAP library use the options when we set them directly to the LDAP context for a given connection. The reason was then later explained by Christian Heimes e.g. in https://github.com/python-ldap/python-ldap/issues/55. When changing TLS related options for an LDAP context you have to set OPT_X_TLS_NEWCTX to reset the internal TLS context with the new options. So I would suggest to copy the code for the TLS options from setup_tls_config() to e.g. sdap_sys_connect_done() so that the options are set directly on the LDAP context state->sh->ldap and finally call

val = 0; lret = ldap_set_option(state->sh->ldap, LDAP_OPT_X_TLS_NEWCTX, &val);

With this change I would expect that the SIGUSR1/2 should work.

bye, Sumit

Regards Edvin _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.o...