Set up a pair of Ubuntu 18.04 servers following this guide: https://www.howtoforge.com/tutorial...ase-cluster-on-debian-8.4-with-ispconfig-3/5/ about 7 months ago. All I had to do in addition to that link was create a cron job to sync /etc/letsencrypt. Has been working fine since then, until last week when it was brought to my attention that the slave server wasn't serving any pages for one of the sites. MySQL is synced fine, site files and SSL certs are synced fine. Logged in to ISPconfig web interface on master and slave, compared settings for this site and they are identical on both. When I tested the site via the slave server, I got a cert error and so I compared the .vhost file on each server. They had similar timestamps but master server copy of the .vhost file has SSL* entries in it, slave doesn't, so when accessing the site via that server I get an SSL error because it's just serving the default cert not the site's proper cert. I turned up debugging on the slave server, made a trivial change to the site settings [ticked 'Perl'] in ISPconfig on the master server, waited a minute and I could see in /var/log/ispconfig/cron.log that it re-wrote the .vhost file on the slave: Code: 30.07.2019-16:05 - DEBUG - Calling function 'ssl' from plugin 'apache2_plugin' raised by event 'web_domain_update'. 30.07.2019-16:05 - DEBUG - Calling function 'update' from plugin 'apache2_plugin' raised by event 'web_domain_update'. 30.07.2019-16:05 - DEBUG - Add server alias: customer-domain.com 30.07.2019-16:05 - DEBUG - Creating fastcgi starter script: /var/www/php-fcgi-scripts/web12/.php-fcgi-starter 30.07.2019-16:05 - DEBUG - Enable SSL for: customer-domain.co.uk 30.07.2019-16:05 - DEBUG - Writing the vhost file: /etc/apache2/sites-available/customer-domain.co.uk.vhost 30.07.2019-16:05 - DEBUG - Apache status is: running 30.07.2019-16:05 - DEBUG - Calling function 'restartHttpd' from module 'web_module'. 30.07.2019-16:05 - DEBUG - Restarting httpd: systemctl restart apache2.service 30.07.2019-16:05 - DEBUG - Apache restart return value is: 0 30.07.2019-16:05 - DEBUG - Apache online status after restart is: running 30.07.2019-16:05 - DEBUG - Processed datalog_id 753 30.07.2019-16:05 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock finished. boom, site is working on slave server now. vhost file is identical on master and slave. ISPconfig version is 3.1.13. So, how can I prevent this happening in the future? Is it worth syncing these files with rsync?
The question is why did it happen. As this normally does not happen. Did you check the ispconfig.log on the slave for errors? No.
Changes don't happen very often on these servers. As such, the only ispconfig.logs which have anything in are todays and yesterdays. ispconfig.log.2.gz to ispconfig.log.9.gz are empty and that's only 8 days. I can't find anything in /etc/logrotate.d for this but would be happy to have them rotated weekly rather than daily. Is there something I can to do force a write of all the vhost files even if ISPconfig doesn't think anything has changed? Right now I can see one vhost file on the master is dated January and the same .vhost file on the slave is dated May, one is 5kB and the other is 11kB [although that site works fine via the slave].
Tools > Resync It might just be that someone, or another tool that you installed on the master, has edited the config file outside of ISPConfig. ISPConfig uses a transaction queue and as long as mirroring is enabled and both servers are connected, a config transaction is processed on all mirror servers.
Did a resync with Websites ticked and now all of the .vhost files match on both servers. Can this be automated from cron?
The only hope of catching this I have is from the logging. I can see that log rotation is controlled by log_retention, where is this set?
