Monthly Archives: May 2013

Debian Squeeze->Wheezy dist-upgrade and VMware tools

If you run Debian 6 (Squeeze) under an VMware Hypervisor (ESXi 5.0+) with VMware Tools installed and you want to upgrade to Debian 7 (Wheezy) make sure you uninstall VMware tools in advance.

Several machines did not boot up after the upgrade with the 3.2.x kernel and hanged forever just after “Switching to guest configuration”. I always create snapshots in advance of major upgrades. So there was no data loss, however, the whole upgrade process had to be restarted…

Hint: Starting with Debian 7 open-vm-tools are included in the official Debian repository: This package is an open source replacement for VMware tools and fits perfectly into the Debian system (e.g. post kernel update triggers). IIRC the open-vm-tools package is also included in the official Ubuntu repository (12.04 LTS has a recent version) – there is also an old version in 10.04 LTS included, however, I never tested that. VMware hypervisor detects it as a “third party”/”manually maintained” VMware tools package and provides the usual options.

Update 2013-09-25: I’m using open-vm-tools since May and had no problems so far.

Apache httpd: Use php-cgi without mod_php

The PHP site describes how to use PHP as a Apache httpd module, however that’s not always the desired option (e.g. if you want to use different PHP versions at the same time).

In order to enable PHP in CGI mode we use the action module of Apache httpd. On Debian-based systems you have to enable it using a2enmod actions.

One can enable php-cgi for the whole installation via the global httpd.conf, for vhosts or for specific files/folders using .htaccess-files. The configuration looks as follows:
# CUSTOM: Add PHP parsing (via CGI) handler and action for .php files
ScriptAlias /local-bin/php-cgi /usr/bin/php-cgi
AddHandler application/x-httpd-php .php
Action application/x-httpd-php /local-bin/php-cgi

Maybe you also need to allow access to /usr/bin by adding:

<Directory "/usr/bin">
Order allow,deny
Allow from all
</Directory>

Some other howtos suggest to use a directory as ScriptAlias (e.g. ScriptAlias /local-bin /usr/bin) which might be a security problem, since all tools in /usr/bin can be executed via the web (e.g. http://example.com/local-bin/whoami). Directly using php-cgi prevents this – also php-cgi contains a security check so that I cannot be executed directly.

Update 2013-05-20: Debian 7 has support for this by default (a2enmod php5_cgi, you might need to install php5-cgi).

AWStats on Debian: Incomplete statistics caused by logrotate

AWStats on Debian might generate incomplete statistics. The script update.sh is executed regularly (once every 10 minutes via cron /etc/cron.d/awstats; you should really consider changing this to a bigger interval) in order to update/calculate the statistics (stored in /var/lib/awstats).

I changed the cron-file so that this script is executed once a day. However, the default installation of AWStats only considers /var/log/apache2/access.log (or some other log file) and does not cope with logrotate. So, if logrotate runs /var/log/apache2/access.log is rotated to /var/log/apache2/access.log.1(.gz) and on the next run AWStats only considers the content of the new rotated file. This issue becomes bigger when you increate the update.sh interval – in the default setup you can only loose up 10 minutes.

I reported this to Debian (Debian bug #706491) and proposed a possible solution: Do not use the logfile e.g. /var/log/apache2/access.log in the AWStats config files (e.g. /etc/awstats/awstats.conf: LogFile entry) directly, but use a wrapper script.

My script getlogs.pl can be used as follows: Do not use LogFile=”/var/log/apache2/access.log” in awstats.conf, but LogFile=”getlogs.pl /var/log/apache2/access.log”. If called with exactly one parameter (the logfile) it uses both access.log.1(.gz) (if exists) and access.log. My script can also be executed with “all” as the second parameter, then all existing rotated access.log*-files are used (in the right order and unpacked automatically). This might be useful if you want to build all statistics from scratch or you have bigger update.sh intervals than logrotate intervals. If the second parameter is missing, you can also use the USELOGFILES environent variable. This might be handy if you want to change it’s value more easily w/o editing all awstats.*.conf-files.

Alternative way: Run AWStats as a post-rotate script in logrotate.

AWStats on Debian: Incomplete statistics on new month

When you install AWStats on Debian, buildstatic.sh is executed regularly (once every day via cron /etc/cron.d/awstats) in order to build static statistics pages for the current month (in /var/cache/awstats). However, (on my system) this script is executed every day @3:10am. So in each new month the statistics of the last day of the last month are incomplete. I reported this to Debian with a patch included (Debian bug #706487).