amavis-stats package is completely unusable
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| amavis-stats (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned | ||
Bug Description
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:/
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/
5.) The log file from which amavis-stats should read, as defined in the amavis-stats configuration file, is incorrect (defined as /var/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), rendering 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/
For demonstration purposes, the daemon is started as such (the "start" argument is omitted):
# /usr/sbin/
2.)
Either the configuration file's actual location should be changed, or a symbolic link should be created to that effect:
# ln /etc/amavis-
Thanks to rat-venus for the suggestion ( https:/
3.)
Attempting to stop the daemon fails:
# /usr/sbin/
No PID file /var/lib/
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/
(35) $pid_file = "$MYHOME/
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://
4.)
Upon starting the service, the following errors are logged to /var/log/syslog:
Mar 7 12:45:01 dev Amavis-
Mar 7 12:45:01 dev Amavis-
This makes perfect sense, as amavis-stats, by default, runs as the www-data user, who, of course, lacks access to /var/lib/
By default, the permissions on the application directory deny the required level of access:
# ls -lah /var/lib/
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/
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/
The only way (of which I am aware) to satisfy all of these requirements is to
# chown -R www-data:adm /var/lib/
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/
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/
The file /var/log/amavis.log does not exist on Debian-based systems, as explained here: http://
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-
It bears mention that there is actually a second Apache configuration file installed to /usr/share/
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:/
I document the solution here: https:/
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://
100 /var/lib/
| description: | updated |
| Launchpad Janitor (janitor) wrote | #1 |
| Changed in amavis-stats (Ubuntu): | |
| status: | New → Confirmed |
Status changed to 'Confirmed' because the bug affects multiple users.