Domain problem in post action on admindb forms for multi-domain mailman
I'm running Mailman 2.1.13 from the Debian Squeeze repositories (on Debian Squeeze) to provide mailing lists across several domains. The domains that are not the primary mailing list domain have 301 redirects of URLs such as .../listinfo/xxxx or .../admin/xxxx to the primary domain.
In most cases this works, because the action in the form is relative, and the page is showing on the primary domain on account of the redirects. When the form is submitted, the request therefore goes to the primary mailman domain. (Other domains are typically on different servers from Mailman, and do not have Mailman installed at all).
However, the .../admindb/xxxx pages seem to have a specific domain in the action attribute of the form, and it is the actual domain of the mailing list, not the primary domain. Although the redirect sends the post to the mailman server, redirecting a post request loses all the data, so nothing happens.
Is there something wrong with my setup? Is there a way to resolve this problem?
On Mon, Sep 05, 2011 at 04:41:18PM +0100, Martin Brampton wrote:
Why not just ServerAlias them?
Is there something wrong with my setup? Is there a way to resolve this
problem?
Or (Reverse)ProxyPass them -- both assuming you're using Apache as your httpd.
If that's undesirable, VIRTUAL_HOST_OVERVIEW may be useful.
-- Politicians are like diapers. They should be changed often, and for the same reason.
Martin Brampton wrote:
I'm running Mailman 2.1.13 from the Debian Squeeze repositories (on Debian Squeeze) to provide mailing lists across several domains. The >domains that are not the primary mailing list domain have 301 redirects of URLs such as .../listinfo/xxxx or .../admin/xxxx to the primary >domain.
In most cases this works, because the action in the form is relative, and the page is showing on the primary domain on account of the redirects. >When the form is submitted, the request therefore goes to the primary mailman domain. (Other domains are typically on different servers >from Mailman, and do not have Mailman installed at all).
So from what you are saying, you are running Mailman in several domains, at the root of the domain (for example, listname@example.com instead of listname@lists.example.com), and example.com is typically hosted off a separate web server?
Instead of using redirects, have you looked at using Mod_Proxy to do the redirection at the backend on the web server hosting domain.com?
Thanks. Andrew.
Martin Brampton wrote:
This is the root of your problem. The domains which are not primary should be defined in the web server as virtual hosts in your web server.
Oh. So the other domain's A record points to a different box and it's that box that redirects it to the Mailman box. Mailman is not designed to work in that way.
I suggest the following. Using say www.example.com as a domain hosted on a foreign box, establish a new domain, say list.example.com with an A record pointing to the Mailman box, and make list.example.com a virtual host in the web server on the Mailman box.
If this won't work for some reason, or if you prefer, you could look at Mailman/Cgi/admindb.py on the Mailman host. Find the line
admindburl = mlist.GetScriptURL('admindb', absolute=1)in the definition of the main() function. If you change that to
admindburl = mlist.GetScriptURL('admindb')it should make the action URL in the forms relative. There are other occurrences of mlist.GetScriptURL('admin', absolute=1) in the module, but they are for non-POST links.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks very much for the various suggestions. Sorry I evidently didn't make it immediately clear that the servers are not all on the same IP address. Use of reverse proxy should work, although I'd prefer to avoid loading mod_proxy if possible, to avoid having to think about ensuring it is secure.
There is no specific naming scheme in operation in my setup, except that the mailman web server is called lists.example.org. The other domains that have mailing lists could have any name, unrelated to the mailman domain, and could be at several possible IP addresses. Mailing lists have email addresses that are simply listname@domain.tld or similar.
It doesn't seem too unreasonable to ask for mailman to work in this environment, and it very nearly does :) It doesn't seem too outrageous to run all mail services on a single server, and to run several web servers, none of which runs mail services at all. Web servers definitely run better without mail, and a single mail server can handle a lot of mail.
The simplest and immediately effective (I've done it!) solution is the hack to admindb.py.
I also like the subdomain scheme (to avoid hacking mailman), except I don't know how to implement it in mailman. Would the "lists" be added to the basic domain name by:
DEFAULT_URL_PATTERN = 'http://lists.%s/'
and would that work across all the uses of URLs? Would it be necessary to knock off the "lists" in the primary domain of lists.example.com by:
DEFAULT_URL_HOST = 'example.com'
so as to counteract the "lists" being added by DEFAULT_URL_PATTERN? Or would that have other ramifications?
But I fear a problem then arises at my mailman server, because there is a further redirect to the SSL version of the site (because I don't like passwords being sent as plain text for anything that matters), and there are liable to be problems with the SSL certificate if a variety of domains are pointed into an SSL site.
So maybe I should reconsider reverse proxying!
On 05/09/2011 18:22, Mark Sapiro wrote:
Martin N Brampton wrote:
The simplest and immediately effective (I've done it!) solution is the hack to admindb.py.
I'm glad that's working for you. I'm not sure why this is an absolute URL in the Mailman base. There are many things in Mailman that have "always been that way", and since I don't know all the history, I don't always know if they are just anachronisms or if their purpose is still relevant.
No. What you need to do is make sure there is an entry like
addvirtualhost('lists.domain.tld', 'domain.tld')
for each domain.tld. There should already be one perhaps like
addvirtualhost('domain.tld', 'domain.tld') anyway. If there is, just add 'lists.' to the first argument. If there isn't one, there should have been so add it now.
Then you need to run
bin/withlist -l -r fix_url LISTNAME -u lists.domain.tld
where domain.tld is the domain of the list. You could create a simple shell script to do this for all lists.
No. If you add the 'lists.' to the hostnames in add_virtualhost, you don't have to worry about the lists in the Mailman server's domain. Presumably they are already accounted for with the existing DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST and add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST) and wouldn't change.
Well part of this is handled by setting the scheme in DEFAULT_URL_PATTERN to https, but the certificate issue is probably going to be a deal breaker.
So maybe I should reconsider reverse proxying!
Quite possibly so. That's beyond my area of expertise so others will have to advise on that.
See the FAQs at <http://wiki.list.org/x/mIA9>, <http://wiki.list.org/x/lYA9> and perhaps others for more detail on add_virtualhost and fix_url.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Mon, Sep 05, 2011 at 04:41:18PM +0100, Martin Brampton wrote:
Why not just ServerAlias them?
Is there something wrong with my setup? Is there a way to resolve this
problem?
Or (Reverse)ProxyPass them -- both assuming you're using Apache as your httpd.
If that's undesirable, VIRTUAL_HOST_OVERVIEW may be useful.
-- Politicians are like diapers. They should be changed often, and for the same reason.
Martin Brampton wrote:
I'm running Mailman 2.1.13 from the Debian Squeeze repositories (on Debian Squeeze) to provide mailing lists across several domains. The >domains that are not the primary mailing list domain have 301 redirects of URLs such as .../listinfo/xxxx or .../admin/xxxx to the primary >domain.
In most cases this works, because the action in the form is relative, and the page is showing on the primary domain on account of the redirects. >When the form is submitted, the request therefore goes to the primary mailman domain. (Other domains are typically on different servers >from Mailman, and do not have Mailman installed at all).
So from what you are saying, you are running Mailman in several domains, at the root of the domain (for example, listname@example.com instead of listname@lists.example.com), and example.com is typically hosted off a separate web server?
Instead of using redirects, have you looked at using Mod_Proxy to do the redirection at the backend on the web server hosting domain.com?
Thanks. Andrew.
Martin Brampton wrote:
This is the root of your problem. The domains which are not primary should be defined in the web server as virtual hosts in your web server.
Oh. So the other domain's A record points to a different box and it's that box that redirects it to the Mailman box. Mailman is not designed to work in that way.
I suggest the following. Using say www.example.com as a domain hosted on a foreign box, establish a new domain, say list.example.com with an A record pointing to the Mailman box, and make list.example.com a virtual host in the web server on the Mailman box.
If this won't work for some reason, or if you prefer, you could look at Mailman/Cgi/admindb.py on the Mailman host. Find the line
admindburl = mlist.GetScriptURL('admindb', absolute=1)in the definition of the main() function. If you change that to
admindburl = mlist.GetScriptURL('admindb')it should make the action URL in the forms relative. There are other occurrences of mlist.GetScriptURL('admin', absolute=1) in the module, but they are for non-POST links.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks very much for the various suggestions. Sorry I evidently didn't make it immediately clear that the servers are not all on the same IP address. Use of reverse proxy should work, although I'd prefer to avoid loading mod_proxy if possible, to avoid having to think about ensuring it is secure.
There is no specific naming scheme in operation in my setup, except that the mailman web server is called lists.example.org. The other domains that have mailing lists could have any name, unrelated to the mailman domain, and could be at several possible IP addresses. Mailing lists have email addresses that are simply listname@domain.tld or similar.
It doesn't seem too unreasonable to ask for mailman to work in this environment, and it very nearly does :) It doesn't seem too outrageous to run all mail services on a single server, and to run several web servers, none of which runs mail services at all. Web servers definitely run better without mail, and a single mail server can handle a lot of mail.
The simplest and immediately effective (I've done it!) solution is the hack to admindb.py.
I also like the subdomain scheme (to avoid hacking mailman), except I don't know how to implement it in mailman. Would the "lists" be added to the basic domain name by:
DEFAULT_URL_PATTERN = 'http://lists.%s/'
and would that work across all the uses of URLs? Would it be necessary to knock off the "lists" in the primary domain of lists.example.com by:
DEFAULT_URL_HOST = 'example.com'
so as to counteract the "lists" being added by DEFAULT_URL_PATTERN? Or would that have other ramifications?
But I fear a problem then arises at my mailman server, because there is a further redirect to the SSL version of the site (because I don't like passwords being sent as plain text for anything that matters), and there are liable to be problems with the SSL certificate if a variety of domains are pointed into an SSL site.
So maybe I should reconsider reverse proxying!
On 05/09/2011 18:22, Mark Sapiro wrote:
Martin N Brampton wrote:
The simplest and immediately effective (I've done it!) solution is the hack to admindb.py.
I'm glad that's working for you. I'm not sure why this is an absolute URL in the Mailman base. There are many things in Mailman that have "always been that way", and since I don't know all the history, I don't always know if they are just anachronisms or if their purpose is still relevant.
No. What you need to do is make sure there is an entry like
addvirtualhost('lists.domain.tld', 'domain.tld')
for each domain.tld. There should already be one perhaps like
addvirtualhost('domain.tld', 'domain.tld') anyway. If there is, just add 'lists.' to the first argument. If there isn't one, there should have been so add it now.
Then you need to run
bin/withlist -l -r fix_url LISTNAME -u lists.domain.tld
where domain.tld is the domain of the list. You could create a simple shell script to do this for all lists.
No. If you add the 'lists.' to the hostnames in add_virtualhost, you don't have to worry about the lists in the Mailman server's domain. Presumably they are already accounted for with the existing DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST and add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST) and wouldn't change.
Well part of this is handled by setting the scheme in DEFAULT_URL_PATTERN to https, but the certificate issue is probably going to be a deal breaker.
So maybe I should reconsider reverse proxying!
Quite possibly so. That's beyond my area of expertise so others will have to advise on that.
See the FAQs at <http://wiki.list.org/x/mIA9>, <http://wiki.list.org/x/lYA9> and perhaps others for more detail on add_virtualhost and fix_url.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (5)
-
Adam McGreggor -
Andrew Hodgson -
Mark Sapiro -
Martin Brampton -
Martin N Brampton