If you didn't used the logfile functionality yet, you have to configure it.
First put in localconf.php or use the Install-Tool:
$TYPO3_CONF_VARS["FE"]["logfile_dir"] = my_logfile_dir/
This is the path where Typo3 should write webserver-style logfiles to.
This path must be write-enabled for the webserver!
Now enable logfile writing in your template with TypoScript:
config.stat = 1
config.stat_apache = 1
config.stat_apache_logfile =mydomain.log
// you can use this if you want database logging also but it's not needed
config.stat_mysql = 1
Important: you have to create the (empty) logfile by your own. Typo3 won't do it.
Remember to make it writable for the webserver.
Have a look if the awstats.pl script is executable (e.g. chmod 0755) for the webserver.
Just call the module from the backend. I hope everything else is self explanatory.
Inside of the module you will be asked to configure your logfiles. Follow the instructions.
If you want to update the AWStats script to a newer version replace the files in the awstats/ folder of the extension. files/folders:
Insert after the first line (#!...) of the awstats.pl script three lines that it looks like that:
#!/usr/bin/perl
if (!$ENV{'TYPO3_MAGIC'}) {
return;
}
Do not overwrite awstats.conf. If an update of this file is needed then have a look at the options I changed. Especially search for things like __AWS_DIR__. There's no need to set up the conf file for a particular domain!
Apart from many satisfied users of the AWStats module there are some people with problems to get it run. Because the module is a wrapper for a perl script (AWStats itself) it's a bit hairy to make the module work in some environments or detect if it won't work.
For those people who have problems there's a new debug mode in the module. If the AWStats script fails for some reason the debug output will be shown automatically. But you can force the module to show debug output if it's needed:
Open the logfile link in a new window (with shift-click, or a right click option). You see the url in your new browser window. Something like that:
...index.php?config=typo3lab.colorcube.de&logfile=typo3lab.log&domains=typo3lab.colorcube.de
add '&dbg=1' to the url:
.....&domains=typo3lab.colorcube.de&dbg=1
That should bring some debug output. Maybe that helps you. Otherwise save the page and send it to me with a description if you maybe have a special server or a special setup.
A security hole was recently found in AWStats versions from 5.0 to 6.4 when AWStats is used as a CGI: A remote user can execute arbitrary commands on your server using permissions of your web server user (in most cases user "nobody").
As you see security holes were found in older versions of AWStats. This is related to parameters that can be passed to the awstats.pl script which is in general a normal thing. But one could used that feature to force an unwanted behavior of the script.
How is the situation with this extension?
The current version of AWStats which is used by this extension is not known to have a security hole.
If your webserver was not configured to run CGI script inside your whole webspace (which is very uncommon), but only in a cgi-bin directory for example, the found security hole had no effect on this extension.
The extension is designed to call the awstat.pl Perl script directly and not as a CGI script. This means the included AWStats script can't be called from the outside with a browser.