I am specifying the operating system as "other" because the menu will not let me select multiple operating systems. This problem is generic in the design of Virtualmin. I have experienced it on a number of different OSes, including CentOS 7 and Ubuntu 18.04. Observed in both Virtualmin GPL and Virtualmin Pro.
Virtualmin configures Apache and Dovecot to rely on SSL-related files in a user's home directory. There are two fatal consequences to this.
If there is a bug somewhere (e.g.: https://www.virtualmin.com/node/64984) and if as a result there is a mismatch between the Dovecot or Apache configuration on the one hand and the user's home directory on the other (which I observed while adding and deleting virtualhosts for testing), then Dovecot or Apache (or both) may fail to restart.
If a careless or naive user accidentally (or maliciously) deletes/moves/edits their SSL files, then Dovecot or Apache (or both) may fail to restart.
The consequences of Dovecot or Apache failing to restart are serious. ALL websites hosted on the server, or ALL mailboxes hosted on the server, become inaccessible.
A single user's actions as in 2 above, or the misconfiguration of a single virtual server as in 1 above, should not take down all websites or all mailboxes.
Please note that 1 and 2 are different types of bugs. I'm not able to give you enough details to fix 1, but fixing 2 doesn't need any more details from me.
Maybe fixing 2 should be a paid feature. In an informal setting where somebody is hosting a few websites for family and friends this is not so serious a problem. In a commercial hosting environment it's a fatal shortcoming.
I did look to see if there's already a solution to 2 somewhere, either within Virtualmin's menus or on the forums here, and didn't find one. Apologies if I overlooked a solution that has already been provided.
Comments
Submitted by andromeda on Sun, 05/19/2019 - 04:36 Comment #1
Submitted by JamieCameron on Sun, 05/19/2019 - 19:15 Comment #2
Yes, this is a known and long-standing bug - because the SSL certs for each domain are stored in that domain's home dir, a user can break the entire service by deleting those files. The only fix, which we haven't implemented yet, would be to stored them elsewhere.
Submitted by andromeda on Mon, 05/20/2019 - 05:21 Comment #3
I feel that this deserves a help page on your website, documenting the issue and preferably discussing possible workarounds. And maybe including an ETA for a fix.
Submitted by JEMEDIACORP on Mon, 05/20/2019 - 10:53 Pro Licensee Comment #4
I agree and feel that a resolution to this issue is greatly needed. There have been multiple occasions where I've gone and deleted a virtual server (from my Virtualmin 6.06 Pro CentOS 7 system) that had SSL and Dovecot enabled, and Dovecot would fail to restart because Virtualmin never removed the entry for the domain from Dovecot's configuration files but Dovecot could not find the SSL certificate for that domain because the virtual server had just been removed, kind of a catch-22 situation. This has brought Dovecot down and prevented users from accessing their mailboxes.