This used to work on my machine, but it presumably broke after some change to Mailman. If I try to create a new list via the web interface, I get:
Error: Unknown virtual host: secure.antsclimbtree.com
This is incorrect, secure.antsclimbtree.com most certainly is a known vitual host, both to apache and to exim. Obviously whatever method Mailman is using to check virtual host validity is consulting something other than apache or exim.
The relevant lines from the create.py source codes are:
# Make sure the web hostname matches one of our virtual domains
hostname = Utils.get_domain()
if mm_cfg.VIRTUAL_HOST_OVERVIEW and \
not mm_cfg.VIRTUAL_HOSTS.has_key(hostname):
safehostname = Utils.websafe(hostname)
request_creation(doc, cgidata,
_('Unknown virtual host: %(safehostname)s'))
return
emailhost = mm_cfg.VIRTUAL_HOSTS.get(hostname, mm_cfg.DEFAULT_EMAIL_HOST)
As I don't know python whatsoever, I can't figure out what test is being used here. What I do know is that I can access pages on my server at secure.antsclimbtree.com, and I can send email to secure.antsclimbtree.com as well, so whatever check is being used doesn't seem relevant in my case.
Can someone help me sort this out? Thanks.
-- Mark Edwards
On Sunday, Feb 1, 2004, at 15:58 US/Eastern, Mark Edwards wrote:
This is incorrect, secure.antsclimbtree.com most certainly is a known vitual host, both to apache and to exim. Obviously whatever method Mailman is using to check virtual host validity is consulting something other than apache or exim.
Right, mailman has to consult its own list of virtual hosts in order to be sure it uses the correct, canonical mapping of webserver hosts to mail domains for thru-the-web list creation. See bug #835870, fixed in 2.1.4 -- just because your 'create' CGI is reachable at some URL doesn't necessarily mean you want people to be able to create lists that refer to that hostname, especially for email. In your mm_cfg.py, I believe you'd need to add this:
add_virtualhost('secure.antsclimbtree.com', 'secure.antsclimbtree.com')
since you apparently intend both URLs and email addresses to contain the full hostname. If you omit the second argument, mailman assumes the corresponding emailhost is the same as the webserver minus the first domain component, i.e. 'antsclimbtree.com'.
Or, you could set VIRTUAL_HOST_OVERVIEW = Off if you don't want to be bothered with as many distinctions between virtual hosts. This sounds useful if what you're really doing is running lists under some primary domain with other possible domains acting like aliases for the primary.
As I don't know python whatsoever, I can't figure out what test is being used here.
References to mm_cfg should be a big clue. Typically each python file is a module with its own namespace, so mm_cfg.FOO is the FOO variable set in (or imported by) mm_cfg.py. It's worthwhile when you're upgrading Mailman to take a careful look at NEWS and Defaults.py to check for new settings that you'll need to customize, things in your mm_cfg.py that may have been changed or deprecated, etc. The virtual host settings have been there for several releases.
That said, it might have been possible to resolve bug #835870 without getting in your way, I just have no idea how. I would think list creation would be ok if the domain were defined in mm_cfg.py, _or_ used in any existing list, but that is probably too annoying to implement and still confusing if you add a virtual host later. Certainly consulting the apache or exim config is out of the question.
--RobbyOn Feb 2, 2004, at 7:14 AM, Robby Griffin wrote:
That said, it might have been possible to resolve bug #835870 without getting in your way, I just have no idea how. I would think list creation would be ok if the domain were defined in mm_cfg.py, _or_ used in any existing list, but that is probably too annoying to implement and still confusing if you add a virtual host later. Certainly consulting the apache or exim config is out of the question.
Thanks for the explanation. I understand wanting to limit access to the create cgi, but isn't that the responsibility of how the admin designs the Apache implementation? If I don't want a particular domain to allow access to the cgi's, I don't alias them from that virtual domain. I'm not sure what's gained by adding a check to the cgi.
In any case, now that I know what's up its no big deal. I would
suggest that the error message could be something more descriptive,
like "Error: secure.antsclimbtree.com not valid in mm_cfg.py".
"Unknown virtual host" is pretty vague. If I had seen an error with
mm_cfg.py in it, I would have figured this out in 2 minutes.
Thanks for the help!
-- Mark Edwards
participants (2)
-
Mark Edwards -
Robby Griffin