[Mailman-Users] Upgrading to 2.1 - a couple of Qs

[Richard Barrett]

At 09:16 21/02/2003, david.gordon wrote:
>I want to go from 2.0.13 to 2.1.1. I (think I) understand I need to
>install 2.1 then move my current list archives etc over to the new
>directory. Its all in the documents!

First, you can go directly from 2.0.13 to 2.1.1. There is no need to do the 
upgrade in two hops.

Second, you do not need to update lists one at a time. This is just a 
precautionary approach.

You can in fact upgrade a 2.0.13 installation to 2.1.1 by just installing 
2.1.1 over the 2.0.13 installation.

If you have a production server with a bunch of critical lists and you 
cannot take risks with your list service then you could try the 
precautionary approach.

I faced the problem of having a large number of lists, some of which 
function as primary channels of communication between customers and 
company, where problems with list service are simply unacceptable to 
management. See the following archived e-mail for how I approached the 
problem, and it wasn't doing the lists one at a time:

http://mail.python.org/pipermail/mailman-users/2003-February/026611.html

>I don't understand this, what is the concept here? Don't I just rename
>the new MM21 directory to the 'old' name and everything would work.
>Perhaps I am missing some basic *nix theory?!

The precautionary upgrade approach discussed in the MM $build/INSTALL file 
is just a suggestion. It just outlines a way of having two different 
version of MM installed and coexistng on a server, with some lists being 
serviced by one version and others being serviced by the other version.

> >RewriteRule ^/mailman/(.*)/(foo-list.*) \
> >$MM21/cgi-bin/$1/$2 \
> >[T=application/x-httpd-cgi]
>
>and
>
> >RewriteRule ^/pipermail/(foo-list.*) $MM21/archives/public/$1
>
>Given my (test) lists are called "test" and "testtwo", can someone help
>me fill in the gaps. Should I add two lines to my VirtualHost for
>mydomain.tld thus...
>
>         RewriteRule ^/mailman/(.*)/(test.*) \
>                       mailman/cgi-bin/$1/$2 \
>                   [T=application/x-httpd-cgi]

No need as the single rule will match any list whose name begins with the 4 
characters 'test'.

>But I don't know what these variables refer to " mailman/cgi-bin/$1/$2 \"

RewriteRules are based on regular expressions, which are used for pattern 
matching:

1. The first part of the rule - '^/mailman/(.*)/(test.*)' - specifies a 
pattern to match against. The brackets '(' and ')' are used to capture 
substrings during pattern matching.

2. If the match succeeds the second part of the rule - 
'mailman/cgi-bin/$1/$2' - says what the revised URL is to be. The $1 and $2 
refer to substrings of the pattern, matched by the first part of the rule.

3. The third part - '[T=application/x-httpd-cgi]' - tells Apache the 
MIME  type of the rewritten URL. In this case it lets the RewriteRule 
function as a ScriptAlias directive.

So for the rule above:

4. if, for example, the requested URL is: /mailman/admin/test-list1/general

5. then the match succeeds and:

     $1 = 'admin'

     $2 = 'test-list1/general'

6. the URL is written as: mailman/cgi-bin/admin/test-list1/general



>One rewrite for each list?
>
>Maybe some one could translate what the rewrite is doing. And explain
>what "sharing the same URL-space" means.

"sharing the same URL-space" means that URLs providing web access to lists 
look the same regardless of which version of MM is servicing the list., The 
URLs are distinguished only by the listname in the URL. But depending on 
which list is being addressed, and hence which version of MM is handling 
the list, the appropriate version of the MM CGI script concerned has to be 
run. The purpose of the RewriteRules is to match against listnames and if 
the match succeeds, change the requested URI into one which calls the 
alternate CGI scripts of the alternate MM installation.

This means that, from a web browser user's standpoint, the web GUI to the 
lists is an homogenous URL space. The server RewriteRules sort out the problem.


>Thank you.
>
>--
>david.gordon