Re: [PATCH] Reload SSL certificates on SIGHUP
От | Michael Paquier |
---|---|
Тема | Re: [PATCH] Reload SSL certificates on SIGHUP |
Дата | |
Msg-id | CAB7nPqQcttyXYuRAyDNqDOjPDKjgOyg4DVvns9cof4MjbxP_-w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Reload SSL certificates on SIGHUP (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [PATCH] Reload SSL certificates on SIGHUP
|
Список | pgsql-hackers |
On Wed, Aug 26, 2015 at 12:24 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Wed, Aug 26, 2015 at 10:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> [...] >> So I think the way to move this forward is to investigate how to hold >> the SSL config constant until SIGHUP in an EXEC_BACKEND build. If we >> find out that that's unreasonably difficult, maybe we'll decide that >> we can live without it; but I'd like to see the question investigated >> rather than ignored. > > You have a point here. > > In EXEC_BACKEND, parameter updated via SIGHUP are only taken into > account by newly-started backends, right? Oops. I mistook with PGC_BACKEND here. Sorry for the noise. > Hence, a way to do what we > want is to actually copy the data needed to initialize the SSL context > into alternate file(s). When postmaster starts up, or when SIGHUP > shows up those alternate files are upserted by the postmaster. > be-secure-openssl.c needs also to be changed such as with EXEC_BACKEND > the context needs to be loaded from those alternate files. At quick > glance this seems doable. Still, this idea would be to use a set of alternate files in global/ to set the context, basically something like config_exec_ssl_cert_file, config_exec_ssl_key_file and config_exec_ssl_ca_file. It does not seem to be necessary to manipulate [read|write]_nondefault_variables() as the use of this metadata should be made only when SSL context is initialized on backend. Other thoughts welcome. -- Michael
В списке pgsql-hackers по дате отправления: