Since there has been quite a bit of noise on the stable request bug for the newest AWStats version, and I’ve actually wanted to write this down before it went stable, but the security issues there forced my hand a little bit.
It is obvious when you look at the installed layout of the new awstats that this version installs quite differently from the previous one; for once it doesn’t use webapp-config any longer, but it also changes the paths used to install the tools and other scripts. There are a few reasons for this so let me revisit them a bit.
The webapp-config system was designed to help managing web application deployment in Gentoo by allowing install of multiple version on different vhosts. This was a generally good approach for software designed around the concepts of old-style web applications, written in Perl/CGI or PHP, which are self-contained in a single installation directory, but it fails badly when you deal with modern application designs such as Rails, TurboGears, and so on. For this reason you can see that it starts to “wither” as the modern applications are just not usable with such a system.
In the case of AWStats, while it is a web application written in Perl/CGI, it is far from being a self-contained one: it provides a number of system tools that are used system-level, and has a system-wide configuration file system in /etc/awstats. Also, it strictly doesn’t need to be used as a CGI, as you can easily produce daily and then provide static web pages for those. With all these restrictions, the requirement to use webapp-config is pretty much pointless; as an added bonus, none of the AWStats ebuilds ever allowed slotted, side-by-side installation of multiple version, which is the primary use of webapp-config.
Since you lose the previously-installed version when upgrading, webapp-config becomes now a burden, rather than an ease in management. I have been running it without using that system for quite a long while, but upgrades were still bothering me as the path to the CGI scripts changed version by version, as they are tied to the ebuild’s version and revision. Thus, the new system.
First of all, the tools are now installed in the path so you don’t need to use full path to them. Then the whole application is installed onto a single path: /usr/share/awstats/wwwroot (the path is in line with the upstream documentation); you can then use your webserver configuration to either alias those paths to the exposed one, or simply symlink them around in your webserver’s document root. As a reference, this is the kind of configurations I use on my statistics vhost (which is, as I have written before, secured and password-protected to avoid giving pagerank to spammers):
Allow from all
SetHandler cgi-script
Options +ExecCGICode language: JavaScript (javascript)Yes, that’s it.