On 20/07/2023 21:14, Viktor Dukhovni via Postfix-users wrote:
On Thu, Jul 20, 2023 at 07:11:41PM +0200, lejeczek via Postfix-users wrote:

I use what I believe is pretty much vanilla-common setup - snis.map I
had to restart the deamon/server in order for _postix_ to notice new
certs - naturally located in same one place - reload did not do.
What is "snis.map", and how is it used in your configuration?
tls_server_sni_maps = hash:/etc/postfix/snis.map


What evidence of failing to "pick up" new settings did you collect?
clients complaining/warning about expired certificates, validated with other tools, certs/files were not the current ones.
My question - is this some kind of a glitch? I'd not think
'postfix' would behave this way intentionally, but..
..if it is intentional, or rather(hopefully) a matter of
configuration and it's possible to have 'postfix' not to
store/cache those or simply, alternatively notice new
files/certs and collect them - what config bits those are?
None of the long-lived services in Postfix care about certificates,
so you typically don't even need a reload.

Only master(8) persists across reload, all the other services restart
shortly after.

-> $ postfix reload # did not work, new certs/files where only picked up with "full" restart, with "systemd" in this case.

and when done, then server-postifx supplied new certs immediately - clients where happy.

I was thinking "glitch" for perhaps SElinux labels and the files prevented access to 'postfix' - I noticed my Nginx were not good for those labels, at that time - but then I'd think 'postfix' would error out, also then how & where would it cache older certs making it available to itself.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Reply via email to