Submitted by signet on Mon, 07/29/2013 - 03:39 Pro Licensee
When creating a new Virtual Server under Debian 7 (Wheezy), g+w permissions are missing on awstats directories. Therefore, Debian's awstats cron job is unable to run and dies. When running chmod g+w awstats all works as expected.
Status:
Closed (fixed)
Comments
Submitted by andreychek on Mon, 07/29/2013 - 07:47 Comment #1
Howdy -- thanks for all your bug reports!
Just to clarify this particular one -- is the directory you have to adjust "/home/USERNAME/awstats"?
Submitted by signet on Mon, 07/29/2013 - 10:16 Pro Licensee Comment #2
Yes, exactly. Sorry I wasn't clear on that.
Submitted by JamieCameron on Mon, 07/29/2013 - 19:58 Comment #3
VIrtualmin sets up its own awstats cron jobs that run as the domain user, which shouldn't have this problem.
In fact, I think we disable the Debian-provided global awstats cron job at installation time.
Submitted by signet on Tue, 07/30/2013 - 01:38 Pro Licensee Comment #4
If you're thinking of disabling Debian's native cronjob for awstats it might make sense to introduce e.g. /etc/awstats/virtualmin/${DOM}.conf and leave the original cronjob alone. This way, it'll never clash with regular package updates from Debian. Or, just add write permissions for the group as I initially mentioned.
Submitted by JamieCameron on Tue, 07/30/2013 - 02:53 Comment #5
I think the real bug here is that we aren't disabling the Debian AWstats cron job at Virtualmin install time.
What is the exact command that this cron job runs on your system?
Submitted by signet on Mon, 08/05/2013 - 02:06 Pro Licensee Comment #6
Good morning,
This is the job:
kees@srv01:~$ cat /etc/cron.d/awstats MAILTO=root
*/10 * * * * www-data [ -x /usr/share/awstats/tools/update.sh ] && /usr/share/awstats/tools/update.sh
Generate static reports:10 03 * * * www-data [ -x /usr/share/awstats/tools/buildstatic.sh ] && /usr/share/awstats/tools/buildstatic.sh
As mentioned before, I feel just disabling the job isn't the way to go; it'll interfere with Awstats configuration not generated or maintained by Virtualmin.
I think the following of two approaches suit the job:
1) Fixing the permissions on /home/foobar/awstats with g+w, or 2) Introducing e.g. /etc/awstats/virtualmin/.conf with separate config for Virtualmin keeping all Debian stuff intact.
Regards, Kees
Submitted by JamieCameron on Mon, 08/05/2013 - 15:38 Comment #7
The Virtualmin installer is supposed to disable those cron jobs - did you install initially using our install.sh script?
Creating the configs in a sub-directory might work, but then again it may prevent awstats from finding the config file for a domain. I would instead recommend against trying to mix Virtualmin and manually created AWstats configs on the same machine. Instead, just import any other websites/domains into Virtualmin.
Submitted by signet on Wed, 08/07/2013 - 03:18 Pro Licensee Comment #8
Yes, I've used install.sh on a cleanly installed Debian Wheezy and I didn't intervent or "repair" the job.
Submitted by signet on Wed, 08/07/2013 - 03:26 Pro Licensee Comment #9
By the way, I'm now hosting a bunch of domains, just chmod g+w'ed all the awstats directories under /home//awstats and everything works like a charm. The awstats cronjob is now able to run nicely using the www-data user, as it's supposed to do.
Submitted by signet on Wed, 08/07/2013 - 04:01 Pro Licensee Comment #10
I now see all jobs scheduled under cron as the root user; didn't see them before. Although I feel such tasks should run as a regular user, I now understand your point of view on the clashing issue with the default Debian configuration.
Just removed Debian's cron job and "restored" the permissions.
Submitted by signet on Wed, 08/07/2013 - 04:05 Pro Licensee Comment #11
On CentOS 5 and 6 there's a job alike Debian's:
[root@somebox ~]# ls -lh /etc/cron.hourly total 4.0K -rwxr-xr-x 1 root root 188 Oct 9 2011 awstats
The job runs as root so it doesn't complain about permissions en al. If you'd like to disable the Awstats jobs in a future Virtualmin release, it might make sense to do this for RHEL deratives as well.
Submitted by JamieCameron on Wed, 08/07/2013 - 18:08 Comment #12
One problem with changing the group ownership is that those directories will no longer count towards the domain's quota.
Submitted by signet on Fri, 08/30/2013 - 02:21 Pro Licensee Comment #13
That's completely true Jamie. But as I said, if you'd disable the cron job on Debian, it makes sense to do this on RHEL derivates as well. Thanks.