Rather perplexing set of problems with a new 2.1.14 vhost install on a DirectAdmin box -- and I'm new to Mailman
![](https://secure.gravatar.com/avatar/ba2ca43ed0d8fe55db1ebf01ab8dfa50.jpg?s=120&d=mm&r=g)
Hi all,
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; I followed the instructions on http://projects.ict4schools.nl/public/wiki/linux-alg/Installing_Mailman_on_D irectAdmin and initial install seemed to finish OK.
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.
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 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'
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.
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'
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.
Any help *greatly* appreciated -- happy to let people examine the system if they so desire, I understand it's difficult chasing bugs without being able to examine specific settings impromptu.
Regards Chris
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Christopher Woods \(CustomMade\) wrote:
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 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.
check_perms shouldn't break permissions on $prefix/cgi-bin/ unless you had to change them for DirectAdmin.
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.
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.
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.
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]
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
![](https://secure.gravatar.com/avatar/ba2ca43ed0d8fe55db1ebf01ab8dfa50.jpg?s=120&d=mm&r=g)
Crikey Mark, thanks for your great response especially given my inaugural post only made the list a couple of hours ago. Have to cop to it - part of the reason I went with that specific install guide was because I'm working in a DA environment (a little nonstandard to begin with). I was also, as you say, angling towards a setup where I could reuse list names -- or rather, not have to worry about clashes (long run, they'll be used for various promo and mailout lists to industry contacts which may well be the same). This VPS is a shared hosting environment too so I didn't think I could justify potentially denying another user a list name if it was common. However, if things just aren't working I see no reason in swimming through treacle until I have a slightly better understanding of Mailman's innards :-)
Wondering if part of the problems are due to the OS (CentOS)... This VPS came specced with it, and I went along with the choice. Little was I aware of the development approach with regards to new and shiny... (this is your cue to all have a chuckle at my expense ;-) My installed Python is 2.4; python-devel was installed new today - but, of course, is still old. Installing the vhosts branch (via bazaar) did initially abort, prompt me to include the toolkit (available in the -devel branch) which I installed fresh before running make install for a second time. Trying yum update python just now, of course, it didn't offer me anything above what I already had -- because this is an old issue which I had no idea about (still on the uphill climb on the learning curve). Discussed here: http://stackoverflow.com/questions/1465036/install-python-2-6-in-centos. Essentially for those unaware (probably just me), CentOS doesn't really like officially supporting latest versions of established software, opting instead for stability over new features (and backporting security fixes). Wreaks havoc if you want to use Python 2.6 because many parts of the OS depend on older versions of packages, including Python 2.4.
I'm on the road all day tomorrow but I'll have a play, get 2.6 installed and then see what happens when I prod the current install. Failing that, I'll ditch it (thanking myself I backed up things like exim confs ;-) and try Mailman's standard flavour.
Thanks so far, feel like I'm slowly making progress. (and I'll be glad to bid adieu to Majordomo) Chris
-- Epilogue
My reading for tomorrow evening so far is as follows:
- http://chrislea.com/2009/09/09/easy-python-2-6-django-on-centos-5/
- http://www.geekymedia.com/tech-articles/rhel5-centos5-rpms-for-python-2-5-an d-2-6/
- http://fedoraproject.org/wiki/EPEL
If you have any more I should check out / bear in mind prior to additional fiddling I'll appreciate any gentle shepherding in the right direction.
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Christopher Woods \(CustomMade\) writes:
Crikey Mark, thanks for your great response
Yeah, +1 to that!
"DA" == "disability assistance"?<wink>
That sounds like a reasonable reason for using the vhost in the first place. I don't think you need to apologize, although you may have misunderstood precisely what the restrictions in vanilla Mailman 2 are (ML names must be unique per Mailman installation, so if you have a private Mailman installation you only have to worry about clashes with lists administered by you at the site level, and of course by domain -- which is an MTA restriction, you can't get around that by having multiple Mailmans serving the same domain).
Wondering if part of the problems are due to the OS (CentOS)...
Yes, in the sense you describe. However, other stable distros (Debian stable, RHEL) have similar restrictions (I don't know if they're as old as 2.4, but if recent Centos is on 2.4, RHEL probably is too). Ubuntu is a bit more recent, but given my friends' experience, I don't know if I'd conside even Ubuntu LTS "stable".
Wreaks havoc if you want to use Python 2.6 because many parts of the OS depend on older versions of packages, including Python 2.4.
You should look into Python virtual environments. In at least one of the distros I use this is called "virtualenv" in the Python category. In a nutshell, it provides a semi-open sandbox ("semi" because Python is sandboxed to a specific version, but you use other system resources as usual, nothing so severe as a chroot or virtual machine).
Yes, it will work, but the virtualenv may be a good way to get the configuration right. (You'll have to install Python 2.6 from source or a separate package anyway; virtualenv will only help with the configuration of the sandbox that you'll need to create.)
![](https://secure.gravatar.com/avatar/f10bf4ea18a58c83f99e6d5a4b12e322.jpg?s=120&d=mm&r=g)
Christopher Woods (CustomMade) wrote:
The EPEL repository for RHEL/CentOS has a python26 package which might be of use to you. You'd need to tell your mailman build to use /usr/bin/python26 for that, but I think it should be workable.
-- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
Does it follow that I reject all authority? Perish the thought. In the
matter of boots, I defer to the authority of the boot-maker.
-- Mikhail Bakunin
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Christopher Woods (CustomMade) wrote:
As Stephen said, this is a perfectly good reason for wanting to use the vhosts branch.
I have just updated it by merging the head of the 2.1 branch. This will remove the Python 2.5 dependency. I also rewrote a section of the bin/newlist help which I hope will make its use more clear.
The create CGI as it exists will only create old style, non-virtual host lists. If you want to pursue this, I can fix it or I may just go ahead if it's not complex.
Wondering if part of the problems are due to the OS (CentOS)...
I run a bleeding edge Mailman in production on a Centos 5 server. It's fairly straightforward. I have installed Python 2.6.5 from source along side the Centos Python 2.4.3 package. You have to leave the Centos package Python as the default or several things, most notably yum, break badly, but you can configure Mailman to use the Python 2.6 installation and it all works fine.
But, as I said, the latest vhost branch should work with Python 2.4.
[...]
Yes, Mailman should work fine with 2.6 coexisting with 2.4, and yes, the yum dependency is the deal breaker for just going to Python 2.6 for everything.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Mark Sapiro wrote:
As I indicated in a prior post, I've tried to clarify the help in bin/newlist.
I've now fixed the create CGI so it should properly create vhost lists and non-vhost lists based on comparing the host portion of the invoking URL with DEFAULT_URL_HOST. If unequal, the list will be created as a vhost list using the web host from the URL and the corresponding email host from add_virtualhost.
I don't understand why the domain in the "no such list" message was "domain1.tld" and not "lists.domain1.tld" unless you had
add_virtualhost('lists.domain1.tld')
rather than
add_virtualhost('lists.domain1.tld', 'lists.domain1.tld')
The former syntax strips the first piece from the web host to get the email host and thus is equivalent to
add_virtualhost('lists.domain1.tld', 'domain1.tld')
But, there may be other reasons I'm not aware of.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Christopher Woods \(CustomMade\) wrote:
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 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.
check_perms shouldn't break permissions on $prefix/cgi-bin/ unless you had to change them for DirectAdmin.
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.
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.
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.
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]
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
![](https://secure.gravatar.com/avatar/ba2ca43ed0d8fe55db1ebf01ab8dfa50.jpg?s=120&d=mm&r=g)
Crikey Mark, thanks for your great response especially given my inaugural post only made the list a couple of hours ago. Have to cop to it - part of the reason I went with that specific install guide was because I'm working in a DA environment (a little nonstandard to begin with). I was also, as you say, angling towards a setup where I could reuse list names -- or rather, not have to worry about clashes (long run, they'll be used for various promo and mailout lists to industry contacts which may well be the same). This VPS is a shared hosting environment too so I didn't think I could justify potentially denying another user a list name if it was common. However, if things just aren't working I see no reason in swimming through treacle until I have a slightly better understanding of Mailman's innards :-)
Wondering if part of the problems are due to the OS (CentOS)... This VPS came specced with it, and I went along with the choice. Little was I aware of the development approach with regards to new and shiny... (this is your cue to all have a chuckle at my expense ;-) My installed Python is 2.4; python-devel was installed new today - but, of course, is still old. Installing the vhosts branch (via bazaar) did initially abort, prompt me to include the toolkit (available in the -devel branch) which I installed fresh before running make install for a second time. Trying yum update python just now, of course, it didn't offer me anything above what I already had -- because this is an old issue which I had no idea about (still on the uphill climb on the learning curve). Discussed here: http://stackoverflow.com/questions/1465036/install-python-2-6-in-centos. Essentially for those unaware (probably just me), CentOS doesn't really like officially supporting latest versions of established software, opting instead for stability over new features (and backporting security fixes). Wreaks havoc if you want to use Python 2.6 because many parts of the OS depend on older versions of packages, including Python 2.4.
I'm on the road all day tomorrow but I'll have a play, get 2.6 installed and then see what happens when I prod the current install. Failing that, I'll ditch it (thanking myself I backed up things like exim confs ;-) and try Mailman's standard flavour.
Thanks so far, feel like I'm slowly making progress. (and I'll be glad to bid adieu to Majordomo) Chris
-- Epilogue
My reading for tomorrow evening so far is as follows:
- http://chrislea.com/2009/09/09/easy-python-2-6-django-on-centos-5/
- http://www.geekymedia.com/tech-articles/rhel5-centos5-rpms-for-python-2-5-an d-2-6/
- http://fedoraproject.org/wiki/EPEL
If you have any more I should check out / bear in mind prior to additional fiddling I'll appreciate any gentle shepherding in the right direction.
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Christopher Woods \(CustomMade\) writes:
Crikey Mark, thanks for your great response
Yeah, +1 to that!
"DA" == "disability assistance"?<wink>
That sounds like a reasonable reason for using the vhost in the first place. I don't think you need to apologize, although you may have misunderstood precisely what the restrictions in vanilla Mailman 2 are (ML names must be unique per Mailman installation, so if you have a private Mailman installation you only have to worry about clashes with lists administered by you at the site level, and of course by domain -- which is an MTA restriction, you can't get around that by having multiple Mailmans serving the same domain).
Wondering if part of the problems are due to the OS (CentOS)...
Yes, in the sense you describe. However, other stable distros (Debian stable, RHEL) have similar restrictions (I don't know if they're as old as 2.4, but if recent Centos is on 2.4, RHEL probably is too). Ubuntu is a bit more recent, but given my friends' experience, I don't know if I'd conside even Ubuntu LTS "stable".
Wreaks havoc if you want to use Python 2.6 because many parts of the OS depend on older versions of packages, including Python 2.4.
You should look into Python virtual environments. In at least one of the distros I use this is called "virtualenv" in the Python category. In a nutshell, it provides a semi-open sandbox ("semi" because Python is sandboxed to a specific version, but you use other system resources as usual, nothing so severe as a chroot or virtual machine).
Yes, it will work, but the virtualenv may be a good way to get the configuration right. (You'll have to install Python 2.6 from source or a separate package anyway; virtualenv will only help with the configuration of the sandbox that you'll need to create.)
![](https://secure.gravatar.com/avatar/f10bf4ea18a58c83f99e6d5a4b12e322.jpg?s=120&d=mm&r=g)
Christopher Woods (CustomMade) wrote:
The EPEL repository for RHEL/CentOS has a python26 package which might be of use to you. You'd need to tell your mailman build to use /usr/bin/python26 for that, but I think it should be workable.
-- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
Does it follow that I reject all authority? Perish the thought. In the
matter of boots, I defer to the authority of the boot-maker.
-- Mikhail Bakunin
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Christopher Woods (CustomMade) wrote:
As Stephen said, this is a perfectly good reason for wanting to use the vhosts branch.
I have just updated it by merging the head of the 2.1 branch. This will remove the Python 2.5 dependency. I also rewrote a section of the bin/newlist help which I hope will make its use more clear.
The create CGI as it exists will only create old style, non-virtual host lists. If you want to pursue this, I can fix it or I may just go ahead if it's not complex.
Wondering if part of the problems are due to the OS (CentOS)...
I run a bleeding edge Mailman in production on a Centos 5 server. It's fairly straightforward. I have installed Python 2.6.5 from source along side the Centos Python 2.4.3 package. You have to leave the Centos package Python as the default or several things, most notably yum, break badly, but you can configure Mailman to use the Python 2.6 installation and it all works fine.
But, as I said, the latest vhost branch should work with Python 2.4.
[...]
Yes, Mailman should work fine with 2.6 coexisting with 2.4, and yes, the yum dependency is the deal breaker for just going to Python 2.6 for everything.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Mark Sapiro wrote:
As I indicated in a prior post, I've tried to clarify the help in bin/newlist.
I've now fixed the create CGI so it should properly create vhost lists and non-vhost lists based on comparing the host portion of the invoking URL with DEFAULT_URL_HOST. If unequal, the list will be created as a vhost list using the web host from the URL and the corresponding email host from add_virtualhost.
I don't understand why the domain in the "no such list" message was "domain1.tld" and not "lists.domain1.tld" unless you had
add_virtualhost('lists.domain1.tld')
rather than
add_virtualhost('lists.domain1.tld', 'lists.domain1.tld')
The former syntax strips the first piece from the web host to get the email host and thus is equivalent to
add_virtualhost('lists.domain1.tld', 'domain1.tld')
But, there may be other reasons I'm not aware of.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (4)
-
Christopher Woods (CustomMade)
-
Mark Sapiro
-
Stephen J. Turnbull
-
Todd Zullinger