Problem with archive URL
My mailman is configured to have as its default_email_host
alliance.brown.edu, but the default_url_host to be
list.alliance.brown.edu. However, our list information pages list the
archive link as alliance.brown.edu instead of the proper list.a.b.e
link as it should be.
We host other virtual hosts at this site, all of them using list.name
and they have no problem with the archive, it's just this one domain.
How can we ensure the info pages go to the right URL without manually
editing each list HTML page, but also ensure no changes to the other
virtual hosts?
Julia Frizzell Systems Administrator/Help Desk Manager The Education Alliance 222 Richmond Street, Suite 300 Providence, Rhode Island 02903-4226 julia_frizzell@brown.edu 401.274.9548 x311 or 800.521.9550 x311 401.421.7650 (fax) http://www.alliance.brown.edu
Julia Frizzell wrote:
My mailman is configured to have as its default_email_host
alliance.brown.edu, but the default_url_host to be
list.alliance.brown.edu. However, our list information pages list the
archive link as alliance.brown.edu instead of the proper list.a.b.e
link as it should be.
This is one of two problems. If these are private archives, you probably need to run fix_url on the lists. See <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.069.htp>.
If these are public archives, you may have hard coded a host name in PUBLIC_ARCHIVE_URL in mm_cfg.py.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Feb 16, 2007, at 3:42 PM, Mark Sapiro wrote:
Julia Frizzell wrote:
My mailman is configured to have as its default_email_host alliance.brown.edu, but the default_url_host to be list.alliance.brown.edu. However, our list information pages list the archive link as alliance.brown.edu instead of the proper list.a.b.e link as it should be.
This is one of two problems. If these are private archives, you probably need to run fix_url on the lists. See <http://www.python.org/cgi-bin/faqw-mm.py? req=show&file=faq04.069.htp>.
If these are public archives, you may have hard coded a host name in PUBLIC_ARCHIVE_URL in mm_cfg.py.
They're public archives, and I do not have a hard coded host name in
my mm_cfg.py.
Interestingly enough, ALL of the other links work perfectly. It is
ONLY the list for the archives that has a problem. Should I worry
about running the fix_url.py and having it create problems for the
currently working links and potentially messing up the other virtual
hosts, or should I just relax and let it do its thing?
BTW, this change will not be done on a Friday at 4:00, so I'm looking
for a Monday morning solution. :)
Julia Frizzell Systems Administrator/Help Desk Manager The Education Alliance 222 Richmond Street, Suite 300 Providence, Rhode Island 02903-4226 julia_frizzell@brown.edu 401.274.9548 x311 or 800.521.9550 x311 401.421.7650 (fax) http://www.alliance.brown.edu
Julia Frizzell wrote:
On Feb 16, 2007, at 3:42 PM, Mark Sapiro wrote:
Julia Frizzell wrote:
My mailman is configured to have as its default_email_host alliance.brown.edu, but the default_url_host to be list.alliance.brown.edu. However, our list information pages list the archive link as alliance.brown.edu instead of the proper list.a.b.e link as it should be.
This is one of two problems. If these are private archives, you probably need to run fix_url on the lists. See <http://www.python.org/cgi-bin/faqw-mm.py? req=show&file=faq04.069.htp>.
If these are public archives, you may have hard coded a host name in PUBLIC_ARCHIVE_URL in mm_cfg.py.
They're public archives, and I do not have a hard coded host name in
my mm_cfg.py.Interestingly enough, ALL of the other links work perfectly. It is
ONLY the list for the archives that has a problem. Should I worry
about running the fix_url.py and having it create problems for the
currently working links and potentially messing up the other virtual
hosts, or should I just relax and let it do its thing?BTW, this change will not be done on a Friday at 4:00, so I'm looking
for a Monday morning solution. :)
I hate to interject here, but wouldn't you rather test during off-peak hours, instead of the heat of Monday morning where a mistake might cost a lot more? That being said, you can apply changes to a single list, and not all lists in an installation. Citing the output from bin/withlist:
--all / -a
This option only works with the -r option. Use this if you want to
execute the script on all mailing lists. When you use -a you should
not include a listname argument on the command line. The variable `r' will be a list of all the results.
Best, Ryan
--
Ryan Steele
Systems Administrator steele@agora-net.com
AgoraNet, Inc. (302) 224-2475
314 E. Main Street, Suite 1 (302) 224-2552 (fax)
Newark, DE 19711 http://www.agora-net.com
Julia Frizzell Systems Administrator/Help Desk Manager The Education Alliance 222 Richmond Street, Suite 300 Providence, Rhode Island 02903-4226 julia_frizzell@brown.edu 401.274.9548 x311 or 800.521.9550 x311 401.421.7650 (fax) http://www.alliance.brown.edu
Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/steele%40agora-net.com
Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
Julia Frizzell wrote:
They're public archives, and I do not have a hard coded host name in
my mm_cfg.py.Interestingly enough, ALL of the other links work perfectly. It is
ONLY the list for the archives that has a problem. Should I worry
about running the fix_url.py and having it create problems for the
currently working links and potentially messing up the other virtual
hosts, or should I just relax and let it do its thing?
I went to your listinfo overview page to see what Mailman version you are using, and I see it is 2.1.5.
2.1.5 inverts the VIRTUAL_HOSTS dictionary, and looks up the lists host_name attribute (email host) in the inverted dictionary to get the corresponding web host. This is not done in current Mailman and is subject to error if the VIRTUAL_HOSTS dictionary has duplicate values.
I suggest the problem is as follows:
Mailman was configured such that the Defaults.py settings for DEFAULT_URL_HOST and DEFAULT_EMAIL_HOST are both 'alliance.brown.edu', and this entry is put in VIRTUAL_HOSTS by the add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST) in Defaults.py
mm_cfg.py contains
DEFAULT_URL_HOST = 'lists.alliance.brown.edu' DEFAULT_EMAIL_HOST = 'alliance.brown.edu' add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
This results in a VIRTUAL_HOSTS dictionary =
{'lists.alliance.brown.edu': 'alliance.brown.edu', 'alliance.brown.edu': 'alliance.brown.edu'}
which, since dictionaries can't have duplicate keys, gets inverted to
{'alliance.brown.edu': 'alliance.brown.edu'}
If I am correct, the solution to this problem is to add
VIRTUAL_HOSTS.clear()
to mm_cfg.py preceeding the add_virtualhost() as
DEFAULT_URL_HOST = 'lists.alliance.brown.edu' DEFAULT_EMAIL_HOST = 'alliance.brown.edu' VIRTUAL_HOSTS.clear() add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
2.1.5 inverts the VIRTUAL_HOSTS dictionary, and looks up the lists host_name attribute (email host) in the inverted dictionary to get the corresponding web host. This is not done in current Mailman and is subject to error if the VIRTUAL_HOSTS dictionary has duplicate values.
I neglected to say that this trick is only done for public archive URLs, which is why everything else works.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Julia Frizzell -
Mark Sapiro -
Ryan Steele