[Mailman-Users] Public/private archives problem.

Rob Brandt bronto at csd-bes.net
Mon Aug 11 14:43:17 CEST 2003 

The problem is resolved, with great help from Richard.  For the sake of
posterity, let the mailing list archives show:

* Be sure you have proper virtual host mapping (add_virtualhost()) in mm_cfg.py;
* Be sure that the list setting for "Host name this list prefers for email" is
in fact your mail exchange address, not a base URL for browsing (which was my
problem);
* Run fix_url.py

Thanks

Rob



Quoting Rob Brandt <bronto at csd-bes.net>:

> 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
> >
>
>
>
> ------------------------------------------------------
> 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