I’ll have to check whether I have any backups with the dupe entries. I usually only back up good stuff. Broken stuff, not so much.
Give me a few minutes.
Also, what is the path to that file in the patch? I can’t find it.
Richard
EDIT: Never mind. I found it.
/etc/dovecot/dovecot.conf
No the one for the patch was /usr/libexec/webmin/virtual-server/feature-ssl.pl
Okay, with the patch to feature-ssl.pl applied, and with the duplicate entries having been reinserted into dovecot.conf, manually renewing the cert did not remove the dupe entries, but also didn’t cause the problem with the missing closing bracket.
So in other words, there were no errors in dovecot.conf except the dupes that were already there, and Dove was able to restart successfully.
Richard
Great, very helpful. We’ll take it from here. I also suspect presence of ssl_ca directive in block is actually causing an issue.
Okay, this issue has been addressed in the patch below. We will discuss internally, if we’re keeping it this way. Nevertheless, it must work flawlessly now for any kind of configs, even broken ones.
Give it a try patching a file and restarting Webmin afterwards.
Note: Line 1834 doesn’t exist on your system, don’t look for it and don’t be surprised it’s not there.
The simple way to apply the patch, is to run the following command (from SSH console or in-built Webmin command line), for Debian/Ubuntu:
curl https://raw.githubusercontent.com/virtualmin/virtualmin-gpl/1d7306073f1f002e509ec178d41f0db39d5f2eb6/feature-ssl.pl -o /usr/share/webmin/virtual-server/feature-ssl.pl && systemctl stop webmin && systemctl start webmin
… for RHEL (CentOS/Fedora):
curl https://raw.githubusercontent.com/virtualmin/virtualmin-gpl/1d7306073f1f002e509ec178d41f0db39d5f2eb6/feature-ssl.pl -o /usr/libexec/webmin/virtual-server/feature-ssl.pl && systemctl stop webmin && systemctl start webmin
So, that mostly seemed to fix it.
However, there’s still other issues:
local_name beautiquemedspa.com {
ssl_cert = </home/beautiq/ssl.cert
ssl_key = </home/beautiq/ssl.key
ssl_ca = </home/houseofsilnyevents/ssl.ca
}
You’ll see the ssl_ca attribute is not correct. FWIW, houseofsilnyevents is a deleted account. It was deleted yesterday, and I patched the code just now.
local_name azzurecontractors.com {
ssl_cert = </home/azzurec/ssl.cert
ssl_key = </home/azzurec/ssl.key
ssl_cert = </home/azzurec/ssl.combined
ssl_key = </home/azzurec/ssl.key
ssl_cert = </home/azzurec/ssl.cert ssl_key = </home/azzurec/ssl.key ssl_ca = </home/azzurec/ssl.ca ssl_cert = </home/azzurec/ssl.combined ssl_key = </home/azzurec/ssl.key ssl_key = </home/baldini/ssl.key ssl_ca = </home/baldini/ssl.ca }
baldini is another one I deleted yesterday. Also, you’ll see there’s multiple duplicated lines for azzurec.
So while it was easier to fix the config this time, it’s still broken; just not as badly, and now it seems to be directly related to deleted vhosts.
Btw…that’s another thing I’ve noticed. The indenting or lack thereof is not consistent from one line to the next or even from one clause to the next.
The copy/paste above also looks like it’s all on one line even though it’s not because of whatever the non-printable whitespaces were.
However, there’s still other issues. You’ll see the ssl_ca attribute is not correct.
None of this is longer an issue, and for deleted accounts it will automatically remove all entries from Dovecot config. However, your case displays also an old issue when sharing certificates, which is also considered to be fixed.
Also, you’ll see there’s multiple duplicated lines for azzurec.
None of this will be an issue. Try re-requesting LE SSL certificate and see what happens (with applied patches and restarted Webmin).
The copy/paste above also looks like it’s all on one line even though it’s not because of whatever the non-printable whitespaces were.
That is not something I ever seen. It’s most likely incorrectly edited by human.
Ok, so if it’s considered to be fixed, why is it still happening?
Should I remove all local_name clauses from the dovecot.conf before re-requesting LE SSL certs (after updated patches and restarting webmin of course)?
Considering that you have applied the patch correctly, the only reason why it could be happening is completely broken config. However, missing curly brackets should be fixed only manually.
If it’s happening, share the state of dovecot.conf config file before running LE certificate request, I’d like to have a look.
Fwiw, the only time any config files have been manually edited is when things started breaking. Normally, I let virtualmin/webmin do the heavy lifting.
I will send the dovecot.conf to info@virtualmin.com so that it’s not attached to the public forum or the public ticket.
Hello all,
Just adding my woes…I’ve been having the same problems and found this thread.
I have a fully updated Pro (Ubuntu 16.04) server that I patched using the curl command above.
I manually edited /etc/dovecot/dovecot.conf:
I then manually renewed the LE SSL cert for one domain:
This was added at the bottom of /etc/dovecot/dovecot.conf:
local_name mydomain.net {
ssl_cert = </home/parentdomain/domains/mydomain.net/ssl.combined
ssl_key = </home/parentdomain/domains/mydomain.net/ssl.key
}
local_name *.mydomain.net {
ssl_cert = </home/parentdomain/domains/mydomain.net/ssl.combined
ssl_key = </home/parentdomain/domains/mydomain.net/ssl.key
}
Notes:
This stanza was now duplicated:
local_name mydomain.net {
ssl_cert = </home/parentdomain/domains/mydomain.net/ssl.combined
ssl_key = </home/parentdomain/domains/mydomain.net/ssl.key
}
A wildcard entry had been added (no wildcard cert had been requested):
local_name *.mydomain.net {
ssl_cert = </home/parentdomain/domains/mydomain.net/ssl.combined
ssl_key = </home/parentdomain/domains/mydomain.net/ssl.key
}
I think things are still broken…
This is a serious issue for production systems. My clients are now blaming me for all problems as well.
G
It looks like the patch you mentioned is not in the file at https://raw.githubusercontent.com/virtualmin/virtualmin-gpl/master/feature-ssl.pl ?
Yes, we un-rolled it for searching better solution.
i have run the latest virtualmin updates a few days ago.
Today, i notice that another domain on my system was due for, and completed, an automatic
ssl certificate update.
note the dovecot config file after the update (specifically for “www.rapidhabitat.com.au”)
virtualmin i think has again removed the closing “}” after this domain…after line 110 is where is should be!
I am not waiting to see if my server will crap itself, I am going to manually fix this (again)
Please get rid of the ssl_ca lines! I know it’s annoying, we’re working on it, but it’s been known for weeks that the ssl_ca lines are a problem (both for Dovecot and our parser/generator). There is no scenario where the ssl_ca lines should be there. When you fix it manually, you need to get rid of every mention of ssl_ca in those local_name sections.
If there are people who would like to try this new patch and see if it works with having ssl_ca in the block, please do.
The simple way to apply the patch, is to run the following command (from SSH console or in-built Webmin command line), for Debian/Ubuntu:
curl https://raw.githubusercontent.com/virtualmin/virtualmin-gpl/1d7306073f1f002e509ec178d41f0db39d5f2eb6/feature-ssl.pl -o /usr/share/webmin/virtual-server/feature-ssl.pl && systemctl stop webmin && systemctl start webmin
… for RHEL (CentOS/Fedora):
curl https://raw.githubusercontent.com/virtualmin/virtualmin-gpl/1d7306073f1f002e509ec178d41f0db39d5f2eb6/feature-ssl.pl -o /usr/libexec/webmin/virtual-server/feature-ssl.pl && systemctl stop webmin && systemctl start webmin
I’ve removed all the ssl_ca lines. Should I still apply the patch?
Richard