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 http://projects.ict4schools.nl/public/wiki/linux-alg/Installing_Mailman_on_D... 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@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: '/home/mailman/locks/gate_news.lock.node1.customhost.org.uk.12404.0'
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@lists.primarydomain.tld From: root@sub.primarydomain.tld [note -- node1.primarydomain.tld was the Xen subdomain assigned to the CentOS VPS when it was first configured] Subject: Cron <mailman@node1> /usr/bin/python -S /home/mailman/cron/gate_news 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@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 main 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@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 <https://code.launchpad.net/~mailman-coders/mailman/2.1>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan