[Mailman-Users] Rather perplexing set of problems with a new 2.1.14vhost install on a DirectAdmin box -- and I'm new to Mailman

Mark Sapiro mark at msapiro.net
Thu Nov 24 03:28:08 CET 2011

Christopher Woods \(CustomMade\) wrote:
>After becoming frustrated with Majordomo I decided to install Mailman on a
>DirectAdmin box I fell into managing. After some research I found Mark
>Sapiro's 2.1.14 vhost port
>(https://code.launchpad.net/~msapiro/mailman/vhost) which includes some
>fixes and merges of virtual hosting patches to the 2.1.13 base;

Why are you using the vhosts branch? Do you need to support separate
lists that have the same name but different domains? If not, don't use
the vhosts branch.

> I followed
>the instructions on
>and initial install seemed to finish OK.

I see these imply you need the vhosts branch if you have multiple
virtual hosts. This is not true in general and is only true if you
need list names which aren't globally unique.

>I configured it with the default_email_host of lists.primarydomain.tld and
>default_url_host of lists.primarydomain.tld (I'm obfuscating all URLs) in
>mm_cfg.py; I also set up three additional virtualhosts in mm_cfg.py with the
>add_virtualhost() command, let's call those lists.domain[2-4].tld.
>I could load the mailman listinfo page -- and after a couple of small fixes
>to Apache aliases, including realising that running "check_perms -f" on an
>already-functional installation resets the permissions on "/cgi-bin/" and
>breaks the install, I thought I was up and running.

check_perms shouldn't break permissions on $prefix/cgi-bin/ unless you
had to change them for DirectAdmin.

>After checking DNS had refreshed, I could bring up the mailman/listinfo
>welcome page for all of the domains configured. Having created the mailman
>list as part of the installation at the command prompt without issue, and
>received the email as expected, I went straight to the
>http://lists.domain1.tld virtualhost and set up a new list named
>'announce-test' via "http://lists.domain1.tld/mailman/create". This seemed
>to work ok and threw no errors; however when clicking on the list from the
>success page, I just got "No such list announce-test at domain1.tld". NB that
>this error message also shows "domain1.tld" and not "lists.domain1.tld" as
>expected, so it looks like it's ignored the subdomain -- why, I do not know.

I don't offhand know either, but I think that the create CGI may not
work in this branch. It may be that you have to create all lists with
bin/newlist, and it too is unintuitive in that you need to both
specify the listname as a fully qualified posting address and specify
the --urlhost= option.

>I then went back to my email and noticed that mailman had sent me an
>approval email with two attachments: the original "confirm" email and a
>"gate_news" email, containing the following:
>Traceback (most recent call last):
>  File "/home/mailman/cron/gate_news", line 293, in ?
>    main()
>  File "/home/mailman/cron/gate_news", line 268, in main
>    lock.lock(timeout=0.5)
>  File "/home/mailman/Mailman/LockFile.py", line 243, in lock
>    self.__write()
>  File "/home/mailman/Mailman/LockFile.py", line 422, in __write
>    fp = open(self.__tmpfname, 'w')
>IOError: [Errno 13] Permission denied:

There is a permissions problem with gate_news which is run every 5
minutes by cron. gate_news is trying to create a lock and doesn't have
permission. The next issue is Mailman's cron jobs are running as user
'mailman' so the above error report from the cron job is mailed by
crond to 'mailman' which is a post to the 'mailman' list.

>The body of the main message reads:
>As list administrator, your authorization is requested for the following
>mailing list posting:
>    List:    mailman at lists.primarydomain.tld
>    From:    root at sub.primarydomain.tld  [note -- node1.primarydomain.tld
>was the Xen subdomain assigned to the CentOS VPS when it was first
>    Subject: Cron <mailman at node1> /usr/bin/python -S
>    Reason:  Post by non-member to a members-only list
>At your convenience, visit:
>    http://lists.primarydomain.tld/mailman/admindb/mailman
>to approve or deny the request.

So errors from cron are being sent to the 'mailman' list. You can
configure this list to accept non-member posts or you can put

MAILTO=someone at example.com

at the beginning of Mailman's crontab to avoid this issue.

>If I then visit http://lists.primarydomain.tld/mailman/admindb/mailman
>But attempting to log in with any password just shows "Bug in Mailman
>version 2.1.14 We're sorry, we hit a bug!" and an indication to check
>tracebacks and the Mailman error logs (which I have done, and can see
>nothing untoward except this:
>admin(17706): Traceback (most recent call last):
>admin(17706):   File "/home/mailman/scripts/driver", line 112, in run_main
>admin(17706):     main()
>admin(17706):   File "/home/mailman/Mailman/Cgi/admindb.py", line 106, in
>admin(17706):     cgidata.getvalue('adminpw', '')):
>admin(17706):   File "/home/mailman/Mailman/SecurityManager.py", line 244,
>in WebAuthenticate
>admin(17706):     print self.MakeCookie(ac, user)
>admin(17706):   File "/home/mailman/Mailman/SecurityManager.py", line 262,
>in MakeCookie
>admin(17706):     path = parsed.path
>admin(17706): AttributeError: 'tuple' object has no attribute 'path'

This require Python 2.5 at a minimum. For earlier Python versions you
could change line 262 of /home/mailman/Mailman/SecurityManager.py to

        path = parsed[2]

>Calling 'list_lists' from the commandline shows 'announce-test' and
>'mailman', as expected. The only thing I haven't done is added the list's
>aliases yet to the 'aliases' file -- I'm guessing they need to go into
>/etc/aliases rather than in a DirectAdmin /etc/virtual/<domain> aliases file
>(which don't currently exist anyway, as the subdomains are only set up as A
>records in DA's DNS management panel).
>Finally, tailing /home/mailman/logs/error shows the following when I try to
>load the announce-test listinfo page:
>No such list "announce-test at domain1.tld":
>I'm at my wit's end; I feel like I'm so close but I'm still building up my
>Linux experience and this has gone beyond the scope of my current knowledge.
>I really don't want to have to revert to Majordomo but I don't honestly know
>what to look at yet to try and fix these misconfigurations.

If you really need the vhosts branch, I'll work with you on the
problems, but if you can live with globally unique list names, I
suggest you update your Python to 2.6.x and install either the
2.1.14-1 tarball from <https://launchpad.net/mailman/+download> or the
head of the branch at

Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

More information about the Mailman-Users mailing list