User name: Peter Debik
TITLE
Upon removal of domain that uses SSL on mail SNI, the conf file is not removed leading to Dovecot fatal error
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE
Obsidian on CentOS 7.8, latest MU
PROBLEM DESCRIPTION
The customer has removed a domain from his subscription that was previously configured using an SSL certificate für the mail account for her domain. Normally a removal like that works, but in this case it did not remove the dovecot configuration file. Dovecot was now looking for the certificate file when it tried to reload, resulting in a failure and outage of Dovecot:
Jul 29 08:22:28 <servername> dovecot: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/14-plesk-sni-<domainname>.conf line 7: ssl_cert: Can't open file /usr/local/psa/var/certificates/scfIdUy7P: No such file or directory
It kind of reminds me of a still existing issue on Onyx where a very similar thing happens with web server configuration files after domain removal. Sometimes there configuration files that point to non-existent domains remain on disk so that the webserver cannot reload or restart, because some configurations are pointing to missing certificates. This has not occured on Obsidian so far, but now the same issue exists on Obsidian with the mail SNI certificates.
STEPS TO REPRODUCE
Cannot be reproduced reliably. It only occurs "sometimes" when a domain is removed.
ACTUAL RESULT
Dovecot configuration file of the domain is not removed.
EXPECTED RESULT
Dovecot configuration file of the domain is removed.
ANY ADDITIONAL INFORMATION
I have a suggestion here as the same issue occurs with web server configuration files: Upon removal or update of configurations, there should be a while...next loop after the process completes that checks whether the files are *really* removed and the certificate references are *really* correct before the system tries to restart or reload services. In that while...next loop add a delay of for example 1 second, then test again. If the test fails, make sure that files are really correct, then test again and so on ... Only continue with reloading/restarting services if the software has verified that the files are all good.
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM
Confirm bug
TITLE
Upon removal of domain that uses SSL on mail SNI, the conf file is not removed leading to Dovecot fatal error
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE
Obsidian on CentOS 7.8, latest MU
PROBLEM DESCRIPTION
The customer has removed a domain from his subscription that was previously configured using an SSL certificate für the mail account for her domain. Normally a removal like that works, but in this case it did not remove the dovecot configuration file. Dovecot was now looking for the certificate file when it tried to reload, resulting in a failure and outage of Dovecot:
Jul 29 08:22:28 <servername> dovecot: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/14-plesk-sni-<domainname>.conf line 7: ssl_cert: Can't open file /usr/local/psa/var/certificates/scfIdUy7P: No such file or directory
It kind of reminds me of a still existing issue on Onyx where a very similar thing happens with web server configuration files after domain removal. Sometimes there configuration files that point to non-existent domains remain on disk so that the webserver cannot reload or restart, because some configurations are pointing to missing certificates. This has not occured on Obsidian so far, but now the same issue exists on Obsidian with the mail SNI certificates.
STEPS TO REPRODUCE
Cannot be reproduced reliably. It only occurs "sometimes" when a domain is removed.
ACTUAL RESULT
Dovecot configuration file of the domain is not removed.
EXPECTED RESULT
Dovecot configuration file of the domain is removed.
ANY ADDITIONAL INFORMATION
I have a suggestion here as the same issue occurs with web server configuration files: Upon removal or update of configurations, there should be a while...next loop after the process completes that checks whether the files are *really* removed and the certificate references are *really* correct before the system tries to restart or reload services. In that while...next loop add a delay of for example 1 second, then test again. If the test fails, make sure that files are really correct, then test again and so on ... Only continue with reloading/restarting services if the software has verified that the files are all good.
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM
Confirm bug