I'm running the master/master on Centos7.5 and seem to be having issues with the awstats generation. I had it working for one site for 6 months but that has stopped and tried to start for another site but it is not generating at all. I'm not sure if it stopped on a prior ispconfig upgrade or when going from CentOS 7.3 to 7.5. So far I have found that the script path /usr/lib/cgi-bin/awstats.pl for ISPConfig -> Server Config does not exist. I tried to change it to /usr/share/awstats/wwwroot/cgi-bin/ location but ISPConfig would not accept that saying invalid path. So I just add ln -sf /usr/share/awstats/wwwroot/cgi-bin/ /usr/lib/cgi-bin but no updated stats overnight. On reading another post I read the /etc/awstats/awstats.conf file should be defined which I don't have, I'm not sure if specific Includes are required for that but it could be an old post. I have setup ln -sf /etc/awstats/awstats.model.conf /etc/awstats/awstats.conf to test. I can't see any errors in the ispconfig logs or when running debug but I'm not sure how to run awstats specifically ? Just as a guess I tried /usr/share/awstats/tools/awstats_updateall.pl now -awstatsprog=/usr/lib/cgi-bin/awstats.pl That ran through the /etc/awstats confs it seems and I noticed for some sites yesterday-access.log was not valid yesterday-access.log -> /var/www/clients/client3/web13/log/20180608-access.log So the 20180608-access.log does not exist it seems. I see an access.log that has content since the day the stats stopped it seems, also zero size error.log and one error.log.1.gz file. So from that I take it some logrotate value has changed in the upgrade maybe, is there a specific setting to get daily rotations without numbers that ISPConfig etc are expecting ?
I can see the /var/log/ispconfig/httpd/domain.ltd/access.log exists but again its content is from Jun 9th until now. The fstab entry for the site is correct. Maybe this relates to a file permission issue I had with unison......I need to change the /var/www/client/client<no>/web<no> back. Its currently root:root at that level but I think its meant to be web<no>client<no> ?
This might be an issue with the server replication. The log files are in /var/log/ispconfig/httpd/.... and then the bind mounts are mounting the web log folders of the domains into the log folders of the sites. Did you check if it's the exact same situation on both nodes?
Only just looking at the stats issue again, they are still not generating and access.log is the same on both servers. The access.log files do not seem to be getting rotated each day and contains data from back in July. I have just turned off weekly backups to see if that is causing the issue as I see in the /var/log/ispconfig/cron.log file some errrors. ``` Sun Aug 12 00:02:08 NZST 2018 PHP Warning: chown(): Operation not permitted in /usr/local/ispconfig/server/lib/classes/cron.d/500-backup.inc.php on line 109 Sun Aug 12 00:02:08 NZST 2018 PHP Warning: chgrp(): Operation not permitted in /usr/local/ispconfig/server/lib/classes/cron.d/500-backup.inc.php on line 110 Sun Aug 12 00:03:01 NZST 2018 Sun Aug 12 00:03:01 NZST 2018 Sun Aug 12 00:03:02 NZST 2018 finished. Sun Aug 12 00:04:02 NZST 2018 Sun Aug 12 00:04:02 NZST 2018 Sun Aug 12 00:04:02 NZST 2018 finished. Sun Aug 12 00:04:36 NZST 2018 PHP Warning: chown(): Operation not permitted in /usr/local/ispconfig/server/lib/classes/cron.d/500-backup.inc.php on line 145 Sun Aug 12 00:04:36 NZST 2018 PHP Warning: chgrp(): Operation not permitted in /usr/local/ispconfig/server/lib/classes/cron.d/500-backup.inc.php on line 146 Sun Aug 12 00:04:37 NZST 2018 PHP Warning: chown(): Operation not permitted in /usr/local/ispconfig/server/lib/classes/cron.d/500-backup.inc.php on line 109 Sun Aug 12 00:04:37 NZST 2018 PHP Warning: chgrp(): Operation not permitted in /usr/local/ispconfig/server/lib/classes/cron.d/500-backup.inc.php on line 110 ``` The directory getting backed up into is /var/backup which is an nfs share on another VM.
When saying the access.log is not getting rotated each day I'm assuming that its meant to get rotated and that is used by awstats.
Also can you say if the /var/www/clients/client[value]/web[value] permissions owner and group should be set to ? I seem to have a bit of a mix with some root:root and others set to web[value]:client[value]. permissions are drwxr-xr-x
Is this an apache or nginx web server? Here are the permissions: Code: drwxr-xr-x 10 root root 4096 Jun 6 22:35 . drwxr-xr-x 4 root root 4096 Jul 11 18:09 .. drwxr-xr-x 2 web1 client0 4096 Jun 6 22:35 cgi-bin drwxr-xr-x 2 root root 4096 Aug 13 11:34 log drwx--x--- 2 web1 client0 4096 Jun 6 22:35 private drwx------ 2 web1 client0 4096 Jun 6 22:35 .ssh drwxr-xr-x 2 root root 4096 Jun 6 22:35 ssl drwxrwx--- 2 web1 client0 4096 Jun 6 22:35 tmp drwx--x--x 6 web1 client0 4096 Jul 4 14:02 web drwx--x--- 2 web1 client0 4096 Jun 6 22:35 webdav There can be additional directories when the site has a jail for ssh users or cronjobs.
Till, its an nginx server. Can you indicate what the permissions should be above that directory e.g. at /var/www/clients/client[value]/ level ? I can see there is data in the respective /var/log/ispconfig/httpd/<domain> folders but it doesnt appear to be getting rotated from the July date. Is there a way to test the rotation etc is working ?
Do you see the exact same logs (and the exact same content in the latest log file) in /var/log/ispconfig/httpd/<domain>/ and /var/www/<domain>/log/ ? My guess is that the bind mount for the log folder is missing so that /var/www/<domain>/log/ does not show the log files from /var/log/ispconfig/httpd/<domain>/ which results in failed log rotation and in non working stats.
I just did a cksum of the two paths and the results is same for access.log cksum /var/log/ispconfig/httpd/<domain>/access.log cksum /var/www/<domain>/log/access.log I checked two of the domains and both are the same sizes
cronatab -l gives :- * * * * * /usr/local/ispconfig/server/server.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done * * * * * /usr/local/ispconfig/server/cron.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
I went into the /etc/awstats directory and ran :- /usr/share/awstats/tools/awstats_buildstaticpages.pl -config=<domain> -update -awstatsprog=/usr/lib/cgi-bin/awstats.pl -dir=/var/www/clients/client3/web13/web/stats Which ran or updates that stats for that domain, well I think it has.....just going to try one that isn't running at all yet
till, I noticed that one of the new domains does not have a awsindex.html and started reading this https://git.ispconfig.org/ispconfig/ispconfig3/issues/4818 Which talks about having awstats system wide cron jobs, just wondering if that could be the problem ? I can see under /etc/cron.hourly there is a awstats file, could that be a problem ?
Have tried that overnight and no luck. Still just getting bigger and bigger access.log files with no rotation and also no stats generated. Is there a manual way to run the cron.sh with full debug ?
You can run the awstats cron plugin with: cd /usr/local/ispconfig/server/ cron_debug.php --cronjob=150-awstats.inc.php and the logfile plugin with: cd /usr/local/ispconfig/server/ cron_debug.php --cronjob=200-logfiles.inc.php You are using apache as web server, right? Or is this a ngiinx system?
I just ran php cron_debug.php --cronjob=200-logfiles.inc.php and php cron_debug.php --cronjob=150-awstats.inc.php and both just output finished ?
Yes, there is no more debug code inside. It's ok as long as they did not spit out any errors. Then you miss a line in the root crontab which exists on Nginx systems only: Code: 0 0 * * * /usr/local/ispconfig/server/scripts/create_daily_nginx_access_logs.sh &> /dev/null
