Comment 0 for bug 962589

Revision history for this message
Ben Johnson (a03-6eo-chg) wrote :

This package could not possibly have been tested before inclusion in Ubuntu; nearly every aspect of the package is incorrect.

Summary of issues:

1.) amavis-stats is started with a Cron job, which, as described at https://bugs.launchpad.net/ubuntu/+source/amavis-stats/+bug/477510 , is incorrect; amavis-stats should be started as a daemon.

2.) The amavis-stats daemon does not start because its configuration file does not exist at the expected location.

3.) The amavis-stats daemon cannot be stopped because its process ID (PID) file does not exist at the expected location.

4.) When the daemon is started, it is unable to write to the required directory, /var/lib/amavis-stats, because the permissions on this directory are incorrect.

5.) The log file from which amavis-stats should read, as defined in the amavis-stats configuration file, is incorrect (defined as /var/log/amavis.log, but should be /var/log/mail.log).

6.) The user:group under which the amavis-stats daemon runs lacks read access to required log file, /var/log/mail.log.

7.) Apache configuration file is not copied into place, so location alias /amavis-stats is not accessible via HTTP(S), rending the amavis-stats interface unreachable.

8.) The PHP script, index.php, is riddled with problems, some of which prevent even basic operation (fatal errors occur) with PHP >= 5.3.

Issue details:

1.)

The Cron job should be removed and an up-start script to start the daemon (/usr/sbin/amavis-stats) should be added instead. The fact that amavis-stats should be started as a daemon is evident from Ubuntu's own manpage for this package: http://manpages.ubuntu.com/manpages/lucid/man1/amavis-stats.1.html

For demonstration purposes, the daemon is started as such (the "start" argument is omitted):

# /usr/sbin/amavis-stats

2.)

Either the configuration file's actual location should be changed, or a symbolic link should be created to that effect:

# ln /etc/amavis-stats/amavis-stats.conf /etc/ -s

Thanks to rat-venus for the suggestion ( https://bugs.launchpad.net/ubuntu/+source/amavis-stats/+bug/477510/comments/3 ).

3.)

Attempting to stop the daemon fails:

# /usr/sbin/amavis-stats stop
No PID file /var/lib/amavis-stats/amavis-stats.pid, can't stop the process

The same type of error occurs with the "reload" argument.

As such, it is necessary to kill the process directly, e.g., with SIGTERM -- less than ideal.

The relevant lines in amavis-stats.conf seem to be accurate, so the precise nature of the issue is not immediately clear:

(20) # $MYHOME = '/var/lib/amavis-stats'; # (default is '/var/lib/amavis-stats')
(35) $pid_file = "$MYHOME/amavis-stats.pid"; # (default is "$MYHOME/amavis-stats.pid")

This bug was added to the Debian tracker on 2009.05.13, but was expunged during automated maintenance before a solution was found. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528589#17 .

4.)

Upon starting the service, the following errors are logged to /var/log/syslog:

Mar 7 12:45:01 dev Amavis-Stats[20295]: Starting -> localhost
Mar 7 12:45:01 dev Amavis-Stats[20295]: ERROR : /var/lib/amavis-stats does not exist or cannot be written to.

This makes perfect sense, as amavis-stats, by default, runs as the www-data user, who, of course, lacks access to /var/lib/amavis-stats (as amavis-stats:adm are the user:group on the directory).

By default, the permissions on the application directory deny the required level of access:

# ls -lah /var/lib/amavis-stats
total 8.0K
drwxr-xr-x 2 amavis-stats adm 4.0K May 14 2009 .
drwxr-xr-x 49 root root 4.0K Mar 22 13:32 ..

The user:group combination under which the amavis-stats service is run must:

a.) Have read/write access to /var/lib/amavis-stats (whose ownership is amavis-stats:adm, by default)
b.) Have read access to /var/log/mail.log (whose ownership is syslog:adm, by default)

And the Apache user (www-data, by default) must:

a.) Have write access to /var/lib/amavis-stats

The only way (of which I am aware) to satisfy all of these requirements is to

# chown -R www-data:adm /var/lib/amavis-stats

and change the user:group under which the amavis-stats daemon is started to www-data:adm ~ line 25 of amavis-stats.conf:

# Set the user and group to which the daemon will change if started as root
# (otherwise just keeps the UID unchanged, and these settings have no effect):
$daemon_user = 'www-data'; # (no default; customary: www-data)
$daemon_group = 'adm'; # (no default; customary: www-data)

Perhaps there is a better solution that makes use of the amavis-stats group that is created upon installation, the process of which, by the way, throws the following warning:

Setting up amavis-stats (0.1.22-1) ...
adduser: Warning: The home directory `/var/lib/amavis-stats' does not belong to the user you are currently creating.

5.)

Around line 38 of amavis-stats.conf, the $scan_logfile value must be changed to the following:

# What log file to scan for amavisd-new data:
$scan_logfile = "/var/log/mail.log"; # (default is "/var/log/amavis.log")

The file /var/log/amavis.log does not exist on Debian-based systems, as explained here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289892 . Rather, amavis-new logs all activity to /var/log/mail.log.

It is worth noting also that the Cron job that is included in the package (see point 1, above) references /var/log/mail.info instead of /var/log/mail.log, so perhaps the former should be used throughout.

6.)

One solution to this problem is described in point 4, above. On Ubuntu systems, the user:group for /var/log/mail.log is syslog:adm. As such, the only solution seems to be to start the amavis-stats daemon with adm group permissions.

7.)

As with point 2, above, either the Apache configuration file's actual location should be changed, or a symbolic link should be created to that effect:

ln -s /etc/amavis-stats/apache.conf /etc/apache2/conf.d/amavis-stats.conf

It bears mention that there is actually a second Apache configuration file installed to /usr/share/amavis-stats/amavis-stats.alias.conf, that appears to be a bit more robust. Should it be used instead?

8.)

Only critical errors (those that prevent even the most basic operation) are addressed herein. There are dozens of other changes that should be made, however, and I will file a separate bug report for those.

a.) Obsoleted function usage causes fatal errors. This problem is described here: https://bugs.launchpad.net/ubuntu/+source/amavis-stats/+bug/677820

I document the solution here: https://bugs.launchpad.net/ubuntu/+source/amavis-stats/+bug/677820/comments/1 .

b.) Lack of open_basedir white-listing in PHP configuration prevents the script from functioning properly. I intend to file a separate bug report for these issues and will update this report with references when I do so.

------------------ SYSTEM INFORMATION ------------------

# lsb_release -rd
Description: Ubuntu 10.04.4 LTS
Release: 10.04

# apt-cache policy amavis-stats
amavis-stats:
  Installed: 0.1.22-1
  Candidate: 0.1.22-1
  Version table:
 *** 0.1.22-1 0
        500 http://us.archive.ubuntu.com/ubuntu/ lucid/universe Packages
        100 /var/lib/dpkg/status