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_DirectAdmin > >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-t...@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: mail...@lists.primarydomain.tld > From: r...@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=some...@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-t...@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 <m...@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org