I tried installing AWStats a couple months ago on my server, got frustrated after an hour or two of reading the documentation and trying to figure out permissions problems, gave up and then tried again about two weeks ago, this time with more patience. Maybe after reading my notes (on RedHat Linux) someone else won’t have to exercise as much patience.
First step: download AWStats, unzip (I unpacked to /usr/local/awstats/) and then execute the following script to start the setup process:
perl awstats_configure.pl
After you complete that step, you’ll have a couple AWStats directives in your Apache configuration. Since some of the sites I’ve written use servlet filters to do URL rewriting and because I wanted to minimize the number of AWStats entry points (AWStats was recently hacked), I setup a virtual host in Apache as a reporting domain. I then moved the AWStats directives inside this reporting virtual domain.
Next, using the sample awstats.mysite.com.conf, you’ll need to create the a domain configuration file for every site that you want to report on and place each one in /etc/awstats/ (read more about the domain configuration files here, scroll down to step #4 and #5). So I ended up with something like:
# ls /etc/awstats
awstats.cephas.net.conf
awstats.blackberryblog.com.conf
...
After you’ve got all your configuration files setup, you’ll want to run awstats against all your old log files (assuming that you’ve got old log files that you want to process). There’s no easy way of getting all your old log files processed, I had to modify the configuration file to point to the zipped up log file:
LogFile="gzip -d </usr/hosts/yoursite.com/logs/200205.zip | "
run awstats:
perl awstats.pl -config=yoursite.com -update
and then modify the configuration file to point to the next month. If I was better at shell scripting I’m sure I could have worked out some way of automating this, but I didn’t have that many log files laying around so it wasn’t a big deal. After you’ve processed all your old log files, you’ll want to point AWStats to look at your current log files. I configured my machine so that it always processes the log file based on yesterday’s date, so my configuration looked like this:
LogFile="/usr/hosts/yoursite.com/logs/%YYYY-24%MM-24.log"
and then I setup a cron job to execute AWStats every night by saving this snippet of code as a script and placing it in your /etc/cron.daily/ folder (cron.daily runs based on the settings in /etc/crontab)
#!/bin/bash
cd /usr/local/awstats/tools
perl awstats_updateall.pl now
So now you’ve got your configuration files, you’ve got a script that processes your logs automatically every night and you want to view the reports from a web browser. So you point your web browser to:
http://reporting.yoursite.com/awstats/awstats.pl?config=yoursite.com
and if you’re like me at this point you’ll run into an error message that makes no sense at all:
[Fri Jun 03 15:52:42 2005] [crit] [client xxx.xxx.xxx.xxx] (13)Permission denied: /usr/local/awstats/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable
The funny thing was that I didn’t have an htaccess file anywhere near the awstats configuration, this error message drove me batty. After googling for an exceptionally long period of time, I updated both /var/lib/awstats/
and /usr/local/awstats/
so that the Apache user owned them.
chown apache.apache /var/lib/awstats
chown apache.apache /usr/local/awstats
Finally, unless you want everyone to see your stats (and allow anyone to access the AWStats.pl script), you’ll want to lock down the cgi-bin directory so that only valid users can access your system. Create a .htaccess and a .htpasswd file in your /usr/local/awstats/wwwroot/cgi-bin/ directory (making to sure to set AllowOverride All in your directive inside the VirtualHost in apache). Configure your .htaccess to only allow access to valid-user:
AuthName "reporting"
AuthType Basic
AuthUserFile /usr/local/awstats/wwwroot/cgi-bin/.htpasswd
Require valid-user
You can create the .htpasswd file by running this command:
htpasswd -c $filename $username
and then add users:
htpasswd $filename $username
and make sure to modify your AWStats configuration file to allow access to __REMOTE_USER__ or the specific user that you want to grant access to that file.
You should now have a working, secure and fully automated AWStats reporting system! Congratulations!
Be careful with the AWStats CGI configuration (disable it if at all possible, and certainly restrict access to it via htpasswd!) There was a recent remotely exploitable security bug that opened up a shell on any awstats systems. The patch was not well publicized, either. Where there’s one bug, there are often more…
I had the same problem with awstats setup and your post helped me figure it out! The problem is permssions; it seems that awstats ships by default as chmod 700 and thus isn’t readable by apache.
apache should have a better error message though. The problem isn’t that .htaccess isn’t readable, it’s that the parent dir isn’t readable, and thus apache cannot CHECK for the existence of the .htaccess file.
I filed an apache bug to update their error message.
Thanks and enjoy!
Alan
Thx for your hint with the CHOWN.command 😉
Rob
Thanks for the chown-hint! Saved my version from being uninstalled… 😉
Thank you, Aaron, your explanation was very helpful. God bless you!
To recover old logs on one go try something like…
LogFile=”for i in `seq 2 8`; do gzip -d < /var/log/apache2/admonsters.com-access.log.$i.gz; done | “