[Mailman-Users] Public/private archives problem.

[Richard Barrett]

Forgot to copy list on this:

Begin forwarded message:

> From: Richard Barrett <r.barrett at openinfo.co.uk>
> Date: Mon Aug 11, 2003  6:09:10  pm Europe/London
> To: Tony <tony-mm at arielbusiness.com>
> 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 <r.barrett at openinfo.co.uk>:
>>> 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
>