[Mailman-Users] Public/private archives problem.

[Richard Barrett]

Tony

The questions I am asking are to elicit information that will 
distinguish between and identify whether there is a problem with (a) 
Mailman or (b) misconfiguration of Mailman or (c) third party 
modifications made to Mailman or (d) other aspects of the host system 
configuration such as the Apache server.

You are complaining about links but I can interpret that in several 
ways:

1. whether the URL of concern is accepted and served by the Apache 
server when you think/prefer it should or should not be.

2. whether the URL of concern is found embedded in the HTML text of a 
web page generated by Mailman as either a static page or by a Mailman 
CGI script.

3. whether the URL of concern is found embedded in the HTML text of a 
web page generated by something other than Mailman as either a static 
page or as one delivered by a CGI script.

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.

Now see further comments below.

Richard

On Monday, August 11, 2003, at 01:14  pm, Tony wrote:

> Hi Richard,
>
> Quoting Richard Barrett <r.barrett at ftel.co.uk>:
>> Rob's bug report, as with yours, lack precision in specifying exactly
>> which Mailman generated pages have links on them which contain (in the
>> HTML text), absolute URLs referring to the wrong hostname. See my
>> comments below on the broadfer questions that need to be answered in
>> order to attack the perceived problem.
>
> Sorry, I thought it was clear enough.  I will elaborate.
>
>> I do not work with it myself, but I believe that the CPanel virtual
>> hosting support software, which your hosting provider may be using,
>> does perform some trickery to help avoid conflicts between list names
>> on different virtual hosts. If your hosting provider is using that and
>> something related to it is misconfigured then this may be contributing
>> to the problem.
>
> Correct.  The list directory gets names <listname>_<domain> to avoid 
> conflicts
> with any other similarly named lists.  CPanel is what is being used in 
> this
> case.
>
> This means that any other virtual host on the server can access the 
> mail
> archives by providing the correct path name to the list.
>
>> When you say "if the archive is public, then the address is
>> http://myhostingprovidersservername.com/pipermail/listname" what
>> precisely do you mean?
>
> What I mean is that the link to the archives, and only this link, from 
> what I
> can see, shows the hosting provider's server name and not the virtual 
> domain
> for the client.
>
> 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?

>
> When the list archives are set to public, then the archive address is:
> http://hostingproviderservername/pipermail/test_clientdomain1/
>
> I would expect this to read:
> http://clientdomain1/pipermail/test_clientdomain1/
> or similar.
>
> 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?

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.

In the case of a public archive, the function does a lookup for the 
list's host_name attribute (visible/editable on the General Options 
page of the list) in an inversion of the VIRTUAL_HOSTS dictionary. The 
actual statement that forms the URL is:

   url = mm_cfg.PUBLIC_ARCHIVE_URL % {
           'listname': self.internal_name(),
           'hostname': inv.get(self.host_name, mm_cfg.DEFAULT_URL_HOST),
         }

This works reliably on  vanilla MM installation with a correctly set up 
VIRTUAL_HOSTS dictionary, so long as each URL_FQDN key in the 
dictionary is associated with a unique EMAIL_FQDN value.

If the list's host_name is not found then the DEFAULT_URL_HOST value, 
which is likely to be that of your myhostingprovidersservername.com, 
will be used.

I have no idea as to how CPanel integrates with Mailman or how the 
mm_cfg.py Mailman configuration file is maintained as new domains are 
hosted by a server on the system you are depending on.

My best guess is that something that should be done is not being done 
and you are getting the DEFAULT_URL_HOST in your public archive URL. I 
do not think you are seeing a bug in Mailman per se.

>
>> Or are there links on other pages on the server that have the
>> 'defective' domain in their URLs?
>
> No.
>
>> To get much further with diagnosing the problem will need a bit more
>> input from you.
>
> I hope I have provided enough info for you - if not, please tell me 
> what else
> you need to know.
>
> many thanks,
>
> Tony
>
-----------------------------------------------------------------------
Richard Barrett                               http://www.openinfo.co.uk