Version 3.1.13p1 Yesterday I attempted to make a change on the System->Server Config->Web tab. Specifically, I entered 'client username' in the Website Auto Alias box. After saving this single change all other boxes on the page have now reverted to blanks. This morning, I noted that now every tab on the System->Server Config page is now showing up blank, with a pink area showing invalid entries on the page. Any idea what's happened and how to revert this back to the way it was? Any insight on this problem is highly appreciated. Screenshots : https://imgur.com/a/LDAiAj7
Seems as if the server config (the database record in the server table in the dbispconfig database is damaged. Do you have a backup which contains the dbispconfig database so you can restore it from there? ISPConfig makes also backups during updates, so if you ever updated ISPconfig on this server, then you'll find a backup in /var/backup/ directory.
Thank you Till, I appreciate the help! The backup did have all the missing data from the dbispconfig.server table and restoring it did seem to solve the problem. Some time later though we had reports of other client websites being down so we reverted to the VM snapshot we did before this mornings change. Is there any reason restoring that table would break all of the other websites? According to reports, it was SSL errors and wrong websites that people were receiving (I didn't get a chance to investigate before reverting to the prior snapshot.) Is there something I should have run after restoring the table? My next step will be to restore the VM to another network temporarily for testing so as to not affect clients.
No. It just might have been if someone edited his website in the time before you restored it, that this site had got a broken vhost file. editing it again and saving after the record was restored should have solved it.
Hi Till, I got a chance to try this out and test what's going on a bit more to give this a bit more context. I restored the Server table. Everything that was working still works, however I can not turn on SSL for a site still. I can enable it and it saves without error but it does nothing. Going back to the site properties shows SSL is not enabled, even after 10 mins. I can see that the cert is saved in /etc/letsencrypt/live, but not in /var/www/clients/clientxx/webxx/ssl. The vhost file in sites-enabled is also missing everything SSL related, it only has the listener for port 80. I've tried saving the client settings, modify them and re-save. Didn't make any difference to the SSL config. I've also noticed that some websites are taking me to another site altogether. I haven't inspected the vhost files to find out why yet, I had to revert back as it's a live server that can't afford much downtime.
What results do you get following this procedure: https://www.howtoforge.com/community/threads/lets-encrypt-error-faq.74179/ This can happen when the certificate is not working or when you have websites where IP Address item is inconsistently set.
Hi guys, I'm currently replicating the server to another network so we can test fixes without taking the live host down. I have a couple of notes and questions. Taleman: LetsEncrypt is installed and working, I can see several renewals going through last night and clicking the LetsEncrypt button actually gets a certificate back from LE and stored in the /etc/letsencrypt/live directory, just not in the vhost file or in the clientxx/webxx/ssl folder. That said, I've discovered that it's an older version of LetsEncrypt that doesn't update. I'll have to install a current version of Certbot. Is there a recommended process for doing this on an ISPConfig server without breaking everyone's website or is it just a matter of removing the old version and following the install process found elsewhere in the forums? Till: Would you recommend fully fixing the issue first before upgrading or just restore the server table and run an upgrade? Also, I found the Resync tool in the control panel. Should I resync Websites after recovering the Server table? Lastly, moving a copy of the server to another network and modifying a workstations hosts file will allow us to test websites, but of course we won't be able to upgrade or test LetsEncrypt because the outside world can't verify the acme challenge. Do you know of any other methods I can use to test replacing the old LetsEncrypt on the test server instead of the live one?
I would fix it before you upgrade. Otherwise you don't know if a problem is caused by the upgrade or because you did not fix it first. depends on the number of affected sites. If not too many sites are affected, then better fir it by editing a value in the site or enablöe an option and click save. By enabling the migration mode under System > server config, you can force ispconfig to skip trying to use letsencrypt to get an ssl cert. you have to copy /etc/letsencrypt with the current certs from live system though to get the certs.
Hi guys, in the middle of fixing this and I've got an issue I can't figure out. Steps taken: - restored server table - placed server into maintenance mode and turned off letsencrypt checks -Turned off single setting in the accounts Web settings (turned off Ruby support) When I visit the non-ssl version of a couple of websites they redirect to a completely different website. Here's the Curl: root@mars2:/var/backup# curl -v http://ganohkwasra.com * Rebuilt URL to: http://ganohkwasra.com/ * Trying 72.139.27.78... * Connected to ganohkwasra.com (72.139.27.78) port 80 (#0) > GET / HTTP/1.1 > Host: ganohkwasra.com > User-Agent: curl/7.47.0 > Accept: */* > < HTTP/1.1 301 Moved Permanently < Date: Sat, 03 Aug 2019 14:38:29 GMT < Server: Apache/2.4.18 (Ubuntu) < X-Pingback: http://www.synergymouldworks.com/xmlrpc.php < X-Redirect-By: WordPress < Location: http://www.synergymouldworks.com/ < Content-Length: 0 < Content-Type: text/html; charset=UTF-8Any ideas why the Synergy Wordpress install would be seeing the request for ganohkwasra.com? It would appear that going to ANY website with SSL enabled using HTTP will redirect to Synergymouldworks.com (HTTPS does work though)
Update: I fixed that issue by changing the IP in the synergy account to * (it had somehow gotten the IP address of the server) Now the only remaining issue seems to be that I can't get SSL enabled on the Synergy account. I can turn on LetsEncrypt but once I reload, only the SSL box is checked. I upgraded our old letsencrypt-auto to certbot. I can see that letsencrypt successfully created a certificate in /etc/letsencrypt/live, but nothing in /var/www/synergymouldworks.com/ssl and no 443 entry in it's vhost file. Ran server.sh and saw it go through the certificates and report that nothing needed renewal, finished without error. UPDATE: So I can turn SSL/LetsEncrypt on and off for *any* other domain on the box. I can also add a brand new domain for a new client and SSL/LE work just fine and dandy. It is just the synergymouldworks.com account that seems to be broken. I've tried comparing the web_domain table entries for synergy and other SSL sites but can't see any obvious differences. Also made sure that the /var/www/syner...com/ssl directory permissions are not preventing write. Those look good. Does LE actually install the SSL certs and update the vhost? Or does ISPConfig simply grab them from LE and do the install?
Final update: Okay so I solved the problem with the Synergy account by using 'certbot delete' and removing the existing certificates. My thought process was that maybe ISPConfig was skipping updating the vhost because there was no change in certificate. Once they were deleted I re-enabled LE in the web config for that site and everything simply started working. This was a bit hard to diagnose and fix because there is no feedback from any logs that would indicate any problems existed in any part of the process.
ISPConfig reuses existing LE certs. A new one will be requested from LE only if there is no existing cert.
