I updated 2 servers from 3.0.5.4p9 using ispconfig_update.sh and choose not to reconfigure services as using my own SSL cert locations It has installed 3.1.1p1, services seem to work fine except logs ( eg. mail and fail2ban ) are not updating , last logs are from the time of update tail -f /var/log/mail.log works fine I now see it was not the correct way to update to 3.1 Any help what I should do to get logs refreshing again will be appreciated
When you say that the logs "are not updating", are you referring to their display within the ISPConfig graphical interface? Or are you referring to the log files on the filesystem, e.g., /var/log/fail2ban.log?
I mean the logs within the ISPConfig graphical interface, can log in to the GUI fine, shows new updated 3.1.1 look , just all the log files on the left menu are stuck on the time server was updated , all mail and websites working
You need to reconfigure services after you update, just grab the update tarball, untar it and run update.php from the install directory .. answer yes to reconfigure services.
I Followed the following prompt from old version at home screen : There is a new Version of ISPConfig 3 available!This Version: 3.0.5.4p9New Version : 3.1.1p1See more... When I clicked See more link, it takes you to ISP config download page with ( Which afterwards I see was not the correct way to update from 3.0.5.4p9 or nor sure why monitor logs have crashed ) Update Instructions To install the latest ISPConfig update, run this command on the shell of the server as root user: ispconfig_update.sh
Yes, I believe it will. So, you may not want to do that. Why are you convinced that running "ispconfig_update.sh" was not the correct way to upgrade from 3.0.4.9 to 3.1.1? As far as I know, it's perfectly fine to do that. Pretty sure I did the same. Did you read somewhere that the normal update script is not appropriate for this specific upgrade? As to the logs not refreshing in the ISPConfig interface, I'm not sure that the logs, as displayed in ISPConfig, are real-time. Have you checked them again today? Are they still stuck? Edit to add: If there's something in your vhost file(s) that will be wiped-out when ISPConfig is reconfigured, then I strongly suggest reworking those configuration directives so that they are applied properly through an ISPConfig template and you don't have to worry about that risk.
Ok thank you , I have reconfigured the one servers services and all works fine in ISPConfig web interface, the second server I am hoping to find a solution for as there are multiple websites with SSL certs that I dont point to ISP configs standard cert position Its logs are still stuck on November the 4th immediately after upgrade , its a Debian Wheezy setup if that helps
I would advise you to either copy/paste all of those SSL certificates into the ISPConfig interface, so that they are handled through ISPConfig and no longer a concern, or if that simply isn't an option for some reason, create symbolic links that point from the locations that ISPConfig uses to your custom certificate location. The second option is riskier because if you are using the same SSL certificate for several services (and not just the web-server), then there is the possibility that ISPConfig deletes or otherwise modifies the certificate (usually due to some action the admin is taking, whether intentionally or not), upon which some other service (like mail stack) relies. You don't want to be looking over your shoulder every time you need to reconfigure services or upgrade ISPConfig, wondering what non-standard configuration is going to break. I don't have any other suggestions as to what you might try, short of running Tools -> Resync, but that will pave-over your custom SSL certificate locations.
Another thought: is log rotation functioning normally on the server in question? What is the output from (executed as root): Code: cat /var/lib/logrotate/status
Thanks for help so far cat /var/lib/logrotate/status logrotate state -- version 2 "/var/log/aptitude" 2014-2-12 "/var/log/suphp/*.log" 2014-1-14 "/var/log/mailman/digest" 2014-1-14 "/var/log/fail2ban.log" 2016-11-6 "/var/log/mysql/mysql-slow.log" 2014-1-14 "/var/log/mailman/error" 2016-11-6 "/var/log/apt/history.log" 2016-11-1 "/var/log/rkhunter.log" 2016-11-6 "/var/log/munin/munin-update.log" 2016-11-7 "/var/log/mailman/locks" 2014-1-14 "/var/log/auth.log" 2016-11-6 "/var/log/clamav/clamav.log" 2016-11-6 "/var/log/denyhosts" 2016-11-6 "/var/log/messages" 2016-11-6 "/var/log/munin/munin-limits.log" 2016-11-7 "/var/log/mail.err" 2016-11-6 "/var/log/syslog" 2016-11-7 "/var/log/munin/munin-cgi-graph.log" 2014-2-12 "/var/log/wtmp" 2016-11-1 "/var/log/exim4/mainlog" 2012-9-14 "/var/log/alternatives.log" 2016-11-5 "/var/log/apache2/access.log" 2016-11-6 "/var/log/apache2/suexec.log" 2016-11-6 "/var/log/mysql/mysql.log" 2014-1-14 "/var/log/exim4/rejectlog" 2012-9-13 "/var/log/apt/term.log" 2016-11-1 "/var/log/mailman/smtp-failure" 2014-2-25 "/var/log/mailman/qrunner" 2016-11-7 "/var/log/mailman/bounce" 2014-1-14 "/var/log/clamav/freshclam.log" 2016-11-6 "/var/log/mail.log" 2016-11-6 "/var/log/daemon.log" 2016-11-6 "/var/log/kern.log" 2016-11-6 "/var/log/mailman/fromusenet" 2014-1-14 "/var/log/mysql.log" 2016-11-7 "/var/log/munin/munin-graph.log" 2016-11-7 "/var/log/debug" 2016-11-4 "/var/log/pure-ftpd/transfer.log" 2014-4-29 "/var/log/mailman/smtp" 2014-2-25 "/var/log/mailman/mischief" 2014-1-14 "/var/ossec/logs/active-responses.log" 2016-9-15 "/var/log/mailman/post" 2014-2-1 "/var/log/exim4/paniclog" 2012-9-13 "/var/log/munin/munin-node.log" 2016-11-7 "/var/ossec/logs/ossec.log" 2016-11-6 "/var/log/mail.info" 2016-11-6 "/var/log/lpr.log" 2012-9-13 "/var/log/dpkg.log" 2016-11-1 "/var/log/apache2/error.log" 2016-11-6 "/var/log/mail.warn" 2016-11-6 "/var/log/munin/munin-html.log" 2016-11-7 "/var/log/mailman/subscribe" 2014-1-14 "/var/log/btmp" 2016-11-1 "/var/log/user.log" 2014-3-2 "/var/log/mailman/vette" 2014-1-14 "/var/log/php5-fpm.log" 2016-11-6 "/var/log/apache2/other_vhosts_access.log" 2016-11-6 "/var/log/cron.log" 2012-9-13
I guess re-configuring ISPconfig services and then creating symbolic links will be the answer , log rotation seems to be fine
Yes, it looks like all of the source logs are up-to-date (dates with Nov 6), so I agree that the next thing to try is re-configuring all ISPConfig services. Let us know what happens.
All up and running , thank you both for your help , services reconfigured and where possible SSL Certs pasted into ispconfig , logs immediately came right after reconfig