New AWStats ebuild notes

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 +ExecCGI

Yes, that’s it.

One thought on “New AWStats ebuild notes

  1. I wonder, does anyone reading this blog use awstats in a mass virtualhosting environment? How do you deal with logging – using a common logfile or keep hundreds/thousands of logfiles open, each for one domain/subdomain? is there i.e. some wrapperscript to split the logs, get the domains, loop through them while supplying awstats with a proper conf file? thanks!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s