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(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-leave(a)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.fedorahoste...