[Mailman-Users] Public/private archives problem.

Rob Brandt bronto at csd-bes.net
Mon Aug 11 10:58:56 CEST 2003


Richard;

Thanks for your help in this.  I am going to email you a link to my "testlist",
which you can log into as an administrator and see for yourself what the
problem is.  My server does not run CPanel, so I don't think that's an issue
here.  My server is sitting here next to my desk, so I have full control if you
need any information.

Best Regards

Rob


Quoting Richard Barrett <r.barrett at openinfo.co.uk>:

> 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
>
>
> ------------------------------------------------------
> Mailman-Users mailing list
> Mailman-Users at 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/
>
> This message was sent to: bronto at csd-bes.net
> Unsubscribe or change your options at
> http://mail.python.org/mailman/options/mailman-users/bronto%40csd-bes.net
>






More information about the Mailman-Users mailing list