Angatar/mailman2

Admin interface crashed without prior config

abitrolly opened this issue · 5 comments

I can't get to the admin interface to configure lists. The image is run with podman, but docker will likely get the same results.

$ podman run -d --name mailman2 -p 127.0.0.1:8080:80 -e URL_ROOT= docker.io/d3fk/mailman2
b0fff7047eea84e8ecabee861568cabdcc055ad341c46892669bb388322cb3ea
$ curl 127.0.0.1:8080
<html><h2>Welcome to lists.example.com</h2></html>
$ curl 127.0.0.1:8080/admin
<head><title>Bug in Mailman version 2.1.29</title></head>
<body bgcolor=#ffffff><h2>Bug in Mailman version 2.1.29</h2>
<p><h3>We're sorry, we hit a bug!</h3>

<p>Please inform the webmaster for this site of this
problem.  Printing of traceback and other system information has been
explicitly inhibited, but the webmaster can find this information in the
Mailman error logs or the web server logs.

Hi,
I've just tested the docker equivalent command and it is well working... a few differences with yours : the ip is not required with the -p option (it is just optional), and I would mention "" as value of the URL_ROOT env just to be sure it is well set with an empty string.
So according with the fact that the following docker command gives a working admin page at localhost:8080/admin

 docker run -d --name mailman2 -p 8080:80 -e URL_ROOT="" d3fk/mailman2

the following podman command should give you as well a working admin page at localhost:8080/admin

 podman run -d --name mailman2 -p 8080:80 -e URL_ROOT="" docker.io/d3fk/mailman2

my local docker version is: 20.10.14

EDITED: Pasted previous logs from wrong terminal.

Last command for podman still doesn't work for me. In /var/log/apache2/error.log I see this.

# cat /var/log/apache2/error.log 
[Thu May 05 18:27:06.880359 2022] [mpm_event:notice] [pid 2685:tid 139880527926400] AH00489: Apache/2.4.38 (Debian) configured -- resuming normal operations
[Thu May 05 18:27:06.880744 2022] [core:notice] [pid 2685:tid 139880527926400] AH00094: Command line: '/usr/sbin/apache2 -D FOREGROUND'
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[----- Mailman Version: 2.1.29 -----]
[----- Traceback ------]
Traceback (most recent call last):
  File "/var/lib/mailman/scripts/driver", line 85, in run_main
    immediate=1)
  File "/var/lib/mailman/Mailman/Logging/StampedLogger.py", line 52, in __init__
    Logger.__init__(self, category, nofail, immediate)
  File "/var/lib/mailman/Mailman/Logging/Logger.py", line 50, in __init__
    self.__get_f()
  File "/var/lib/mailman/Mailman/Logging/Logger.py", line 68, in __get_f
    1)
  File "/usr/lib/python2.7/codecs.py", line 898, in open
    file = __builtin__.open(filename, mode, buffering)
IOError: [Errno 13] Permission denied: '/var/lib/mailman/logs/error'
[----- Python Information -----]
sys.version     = 2.7.16 (default, Oct 10 2019, 22:02:15) 
[GCC 8.3.0]
sys.executable  = /usr/bin/python
sys.prefix      = /usr
sys.exec_prefix = /usr
sys.path        = ['/var/lib/mailman/pythonlib', '/var/lib/mailman', '/usr/lib/mailman/scripts', '/var/lib/mailman', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/lib/python2.7/site-packages', '/usr/lib/python2.7/dist-packages']
sys.platform    = linux2
[----- Environment Variables -----]
	SERVER_NAME: 127.0.0.1
	REMOTE_ADDR: 10.0.2.100
	PYTHONPATH: /var/lib/mailman
	REMOTE_PORT: 50806
	REQUEST_SCHEME: http
	SCRIPT_NAME: /admin
	REQUEST_METHOD: GET
	HTTP_HOST: 127.0.0.1:8080
	SERVER_PORT: 8080
	SERVER_PROTOCOL: HTTP/1.1
	QUERY_STRING: 
	REQUEST_URI: /admin
	DOCUMENT_ROOT: /var/www/lists

Looks like /var/log/mailman is owned by root, and list user can not write to it.

root@e0939a3684f0:/# ls -la /var/lib/mailman/logs
lrwxrwxrwx 1 list list 16 May  5 18:27 /var/lib/mailman/logs -> /var/log/mailman
root@e0939a3684f0:/# ls -la /var/log/mailman     
total 8
drwxrwsr-x 2 root root 4096 May  5 18:27 .
drwxr-xr-x 6 root root 4096 Apr 25 23:03 ..
-rw-rw---- 1 root root    0 May  5 18:27 error

Might be a bug with podman 3.0.1 on Debian 11, because there is no such error with podman 3.4.4 on Fedora 35. On Fedora 35 the ownership of /var/log/mailman is different.

root@89a0a1645bf4:/# ls -la /var/log/mailman
total 12
drwxrwsr-x. 2 root list 4096 May  5 18:25 .
drwxr-xr-x. 6 root root 4096 Apr 27 13:00 ..
-rw-rw----. 1 root list    0 May  5 18:25 error
-rw-rw----. 1 list list  464 May  5 18:25 qrunner

So I am going to redirect this bug to podman maintainers.

It is quite unlikely that the podman version impacts on how are set the directories permissions in the container.
The most probable scenario is that you had an initial incomplete deployment of the d3fk/mailman2 container that didn't set the permissions of this directory correctly (the container is only operational when the health-check says it is healthy: the run.sh script has to be completed); Therefore as the directory /var/log/mailman is declared as a volume to keep track of logs over multiple deployments, an anonymous volume is created on your first deployment.... that might have kept the incorrect permissions previously set.
So, I suggest you to stop and remove your mailman2 container, clear the unused volumes with a podman volume prune, pull a fresh d3fk/mailman2 image and try to redeploy on your Debian 11 with podman 3.0.1.
Keep me posted.

Didn't help.

Cleaned up all containers, images, pruned volumes.

podman rm -a
podman rmi -a
podman volume prune

Executed.

$ podman run -d --name mailman2 -p 8080:80 -e URL_ROOT="" docker.io/d3fk/mailman2
Trying to pull docker.io/d3fk/mailman2:latest...
Getting image source signatures
Copying blob 4be315f6562f done  
Copying blob 0161847e98bb done  
Copying blob 0114d2f80a7e done  
Copying blob 267c5c56422b done  
Copying blob 1c1169c80944 done  
Copying blob 5f8c46fbb95b done  
Copying blob 4d2b090d4b37 done  
Copying blob 897402335f0d done  
Copying blob d9fe4801b31e done  
Copying blob caeea80f17a5 done  
Copying blob dc9aa09054cb done  
Copying config 4b9a0817e6 done  
Writing manifest to image destination
Storing signatures
f061e7feea321a4838e6528913771209d2dea98fdff70d2382f4884c53b28ca3

The same error.

$ curl 127.0.0.1:8080/admin
<head><title>Bug in Mailman version 2.1.29</title></head>
<body bgcolor=#ffffff><h2>Bug in Mailman version 2.1.29</h2>
<p><h3>We're sorry, we hit a bug!</h3>

<p>Please inform the webmaster for this site of this
problem.  Printing of traceback and other system information has been
explicitly inhibited, but the webmaster can find this information in the
Mailman error logs or the web server logs.

And the mailman logs dir is owned by root.

$ podman exec mailman2 ls -la /var/log/mailman
total 8
drwxrwsr-x 2 root root 4096 May 11 15:51 .
drwxr-xr-x 6 root root 4096 Apr 27 13:00 ..
-rw-rw---- 1 root root    0 May 11 15:51 error

Hum... that's strange, indeed! I assume you well checked that there was no volume remaining after the commands (if the volume of interest was considered in use by podman it would not have been cleaned by the prune command).

In that case I'm curious to know what would be the result of the following command on your running mailman2 container

podman exec mailman2 /usr/lib/mailman/bin/check_perms -f

If "No problems found" is well reported as the result, it is that the mailman check_perms script does not check /var/log/mailman for the right permissions.

BTW, the following command should then simply fix your deployment:

podman exec mailman2 chgrp list /var/log/mailman

Is that working or do you encounter other errors?