Begin forwarded message:
From: Richard Barrett <[EMAIL PROTECTED]> Date: Mon Aug 11, 2003 6:09:10 pm Europe/London To: Tony <[EMAIL PROTECTED]> Subject: Re: [Mailman-Users] Public/private archives problem.
Tony
On Monday, August 11, 2003, at 04:50 pm, Tony wrote:
Hi Richard,
Quoting Richard Barrett <[EMAIL PROTECTED]>:I must have been having a stupid day as I was not entirely clear from either the referenced bug report or your initial post about which of these interpretations I should adopt.
Nah, I'm sure it's down to the way I wrote it :/ We all have off days.....
Example: I have a list called "test" on clientdomain1.
The path to the list and all the admin pages etc is http://clientdomain1/mailman/<whatever>/test_clientdomain1/
This list could also be accessed by another virtual domain on the same
server
as:
http://clientdomain2/mailman/<whatever>/test_clientdomain1/
When the archives are set to public, the archive address is: http://clientdomain1/mailman/private/test_clientdomain1/
Did you mean the statement immediately above or are you just reflecting
on the fact that a public list is still available through its private
list URL?
No, I was being stupid. The above statement should have read: When the archives are set to public, the archive address is: http://hostingproviderservername/pipermail/test_clientdomain1/
This appears the same on both the main page for the list and in the admin interface.
Just to confirm; do you mean the web pages returned by the URLs http://clientdomain1/mailman/listinfo/test_clientdomain1 and http://clientdomain1/mailman/admin/test_clientdomain1?
Yes, these are the pages that report the archive location to br the hostingproviderservername address.
I am now talking about plain vanilla, unmodified, MM 2.1.2 code. The[....]
GetBaseArchiveURL() function used to generate the links to both public
and private list archives. Its operation is subtly different in two
cases although both depend upon the values in the VIRTUAL_HOSTS
dictionary which is conventionally constructed by calls to the
add_virtualhosts() function in the MM configuration file mm_cfg.py.
What is happening in the case of a private archive that the 'correct' host name
is being returned?
When generating a reference to a private archive the GetBaseArchiveURL() function uses a different list attribute called web_page_url. The standard MM 2.1.2 web creation scripts, both web and command line, set web_page_url and host_name in a compatible way. So too does the the fix_url script referred to by earlier posts on this subject.
Is there a reason the two are different?
If I am honest, it is not immediately obvious to me why the difference in computing the hostname used in private and public archive URLs. But with a properly configured vanilla Mailman installation, the results should be same in either case.
What would happen if they were both the same?
Unfortunately, I am not in a position to check out what is being done on the
server, since I am merely a client and have bugger all access to the server :(
But you could check the 'Host name this list prefers for email' option on the General Options page of one of your problem lists (3rd from last option with MM 2.1.2). Does this look to be correct? I would expect it to.
As you say, it could be how CPanel have integrated mm, or it could be a
configuration issue with how they set it up.
There is fresh news. There is good news and there is bad news.
The good news is that you are not alone. I have just fooled around with a demo CPanel facility of a web hosting supplier. Lo and behold the the links to the list archives - the /pipermail URLs - switch from the virtual host name to the base server host name; see:
http://free-try-before-buy.com/mailman/listinfo/delist_free-try- before-buy.com
and follow the list archive link. Lo and behold you get to:
http://server.6np.net/pipermail/delist_free-try-before-buy.com/
although the 'desired' URL works OK:
http://free-try-before-buy.com/pipermail/delist_free-try-before- buy.com/
The bad news is that this looks like a built in 'feature' of the current CPanel implementation.
My guess is that the CPanel's own scripts are used by CPanel in place of the standard Mailman scripts to create new lists and that these scripts set the list web_page_url and host_name attributes directly but without adding any matching add_virtualhost() calls to mm_cfg.py to expand the VIRTUAL_HOSTS dictionary.
This would not be a major surprise as the VIRTUAL_HOSTS dictionary stuff now in Mailman is a MM 2.1.x introduction and CPanel basic implementation predates it with MM 2.0.x.
If I can find time I will look at the issue a bit harder but right now I cannot see any easy solution for you. Basically it looks to me like a rough edge on the CPanel implementation rather than a bug in > Mailman.
Can you suggest anywhere I can look (or point the hosting provider at) that
discusses the configuration in detail so we can try to establish where the
problem lies?
You could try posting a query to one of support forums on www.cpanel.com to see if one of their support people can confirm/deny my hypothesis and hopefully offer a solution.
Let me know how you get on.
thanks,
Tony
----------------------------------------------------------------------- Richard Barrett http://www.openinfo.co.uk
------------------------------------------------------ Mailman-Users mailing list [EMAIL PROTECTED] 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/
This message was sent to: [EMAIL PROTECTED] Unsubscribe or change your options at http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
