From b132a73f15e432eaf43310fce9196ca0c0651465 Mon Sep 17 00:00:00 2001 From: <> Date: Thu, 2 Jan 2003 05:25:50 +0000 Subject: This commit was manufactured by cvs2svn to create branch 'Release_2_1-maint'. --- UPGRADING | 373 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 373 insertions(+) create mode 100644 UPGRADING (limited to 'UPGRADING') diff --git a/UPGRADING b/UPGRADING new file mode 100644 index 00000000..5214a85c --- /dev/null +++ b/UPGRADING @@ -0,0 +1,373 @@ +Mailman - The GNU Mailing List Management System +Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc. +59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + + +A NOTE ABOUT MODERATION + + When you upgrade from Mailman 2.0.x to Mailman 2.1, you should + double check that your moderation and privacy options are still + set the way you want them. The Mailman options dealing with + moderation and privacy have changed significantly, to make them + easier to understand and control. Ever effort was taken to + translate the old configuration variables to the new configuration + variables, but because the old semantics were so complex, it is + possible your settings may not have been correctly translated. + + Check especially the values for (in Privacy -> Sender Filters) + default_member_moderation, generic_nonmember_action, and + accept_these_nonmembers. Check also the moderation flag on member + accounts in the Membership Management screen. + + +UPGRADING FROM PREVIOUS VERSIONS + + For the most part, upgrading Mailman is as easy as just installing + the latest version over the existing version. However, there are + some changes that need to be taken care of manually. + + What you need to do depends on the version you are using and the + version you are upgrading to. In all cases, you should first turn + off your mail and web access to your Mailman installation. You're + essentially upgrading a database, and it's usually a good idea to + make sure the database cannot be modified in the middle of the + upgrade. + + My recommendations are + + - Turn off your incoming mail daemon. Most remote smtp servers + will simply queue up messages destined for your domain if port + 25 is shut off. + + - Temporarily disable web access to Mailman. You can do this by + either turning off your web server temporarily, or by setting up + a temporary redirect to a "service unavailable" page for the + Mailman URLs. Refer to your web server documentation for + details. + + Mailman will NOT upgrade the template files for existing lists. + Chuq Von Rospach gives some useful advice in this message to the + users mailing list: + + http://mail.python.org/pipermail/mailman-users/2000-September/006826.html + + [Actually, the upgrade to MM2.1a2 /will/ shuffle template files, + deleting any that it detects are unchanged from the original + defaults (calculated via md5 checksums).] + + +UPGRADING FROM 2.0.x to 2.1 + + In Mailman 2.1, the qrunner subsystem has been completely + rewritten. You no longer start qrunner from cron! Instead, there + is a bin/mailmanctl script which is used to start, stop, and + restart mail delivery. This script is appropriate to use as a + Unix init script. Be sure to update your crontab with the new + cron/crontab.in file. + + NOTE: It is very important that if you are upgrading from a + pre-MM2.1alpha2 system to a post-MM2.1alpha2 system that you let + the old qrunner process clear any and all messages sitting in the + qfiles/ directory *BEFORE* you upgrade. Otherwise after the + upgrade, those messages will not get delivered, and I'm not + exactly sure yet how to upgrade those pending messages. + + NOTE: When upgrading to Mailman 2.1beta1, you will need to + regenerate your aliases files. There have been many changes to + the alias names, the programs they map to, and the name of the + wrapper script. See README. for details of making + Mailman work with your mail server. + + To regenerate your aliases, use the bin/genaliases script. + + Mailman 2.1 introduces multilingual (a.k.a. internationalization + or i18n) support. Previously only one language per list was + supported, and it was assumed that this language would be English. + The upgrade script for Mailman 2.1 creates a subdirectory `en' + inside each lists/ directory. It then copies all the + .txt and .html files from lists/ into + lists//en. + + If you have modified those templates to contain non-English text, + you will have to manually rename the en subdirectories to the + language code for the language of your templates. Mailman's + upgrade script should handle cleaning up any templates which are + duplicates of the defaults, but you'll want to double check this + manually. + + If you are running a MM2.0.x system with non-standard patches + applied, you might have some other problems with your upgrade. + Here are some instances we know about: + + - If you've applied patch #413752 (coerce to plaintext), then your + upgraded will not go smoothly. Take a look at patch #651406 for + an unofficial solution. + + http://sf.net/tracker/?group_id=103&atid=300103&func=detail&aid=413752 + http://sf.net/tracker/?group_id=103&atid=300103&func=detail&aid=651406 + + +UPGRADING INDIVIDUAL LISTS + + If you're nervous about upgrading all of your lists to 2.1 in one + go, you can move them and upgrade them one at a time. Start by + doing a clean Mailman 2.1 installation in an empty directory -- + call it $MM21. (I'll assume your Mailman 2.0 installation is in + $MM20.) + + Doing this means you'll have co-habiting Mailman 2.0 and 2.1 + installations for a while, until you have moved all of your lists + to Mailman 2.1. Depending on your MTA and web server, this could + be transparent and painless, or it could be an ongoing headache. + + If you use Apache with mod_rewrite, then it's fairly + straightforward to set things up so that both Mailman 2.0 and 2.1 + inhabit the /mailman and /pipermail URL-space of your server; this + makes the transition almost transparent to list admins and + subscribers. See below for details. + + Now, for each list that you want to move, you'll have to + + * Shut down your MTA. + + If you have a lot of outgoing list traffic, you might need to + leave your MTA up but only let it accept connections from + 127.0.0.1 (localhost), so Mailman 2.0 can flush its queue. + How to do this is MTA-dependent; for Exim, you can set + "local_interfaces = 127.0.0.1" and "kill -HUP" the Exim + daemon. + + * Shut down your web server. For a more professional look, or + if you want to allow people to keep accessing the rest of your + web site, you could make your web server respond to all + /mailman/ URLs with a "temporarily unavailable" message. + + How to do this is web server-dependent; with Apache and + mod_rewrite, this does the trick: + + RewriteRule ^/mailman/.* /var/www/unavailable.html [L] + + (Of course, you'll have to supply your own + /var/www/unavailable.html.) + + * Force Mailman 2.0 to process its queue: + + python -S $MM20/cron/qrunner + + (This is only necessary if there are any files in $MM20/qfiles; + if you need to do this, make sure you left your MTA listening to + 127.0.0.1.) + + * Move the list: + + cd $MM20 + mv -i lists/foo-list $MM21/lists + mv -i archives/private/foo-list $MM21/archives/private + mv -i archives/private/foo-list.mbox $MM21/archives/private + rm archives/public/foo-list + rm archives/public/foo-list.mbox + cd $MM21 + bin/withlist -l -r fix_url mylist + + (The fix_url step will not be necessary if your Mailman 2.0 + and 2.1 installations will be sharing the same URL-space.) + + * Edit your web server config so the list's URLs continue to + work. There are two possible approaches here; the simpler way + is to setup a new slice of URL-space that will be used by your + Mailman 2.1 installation, eg. /mailman-21: + With Apache and mod_rewrite: + + RewriteRule /mailman/(.*)/(foo-list.*) /mailman-21/$1/$2 [R=temp] + + (The [R=temp] assumes that "/mailman-21/" is a temporary URL, + and you'll move all your lists to "/mailman/" when the + transition to Mailman 2.1 is complete.) + + If you don't want to expose ugly temporary URLs like + "/mailman-21" to the world, it's only slightly more work to make + Mailman 2.0 and 2.1 share the same slices of URL-space. Here's + how to do it with Apache and mod_rewrite: + + RewriteRule ^/mailman/(.*)/(foo-list.*) \ + $MM21/cgi-bin/$1/$2 \ + [T=application/x-httpd-cgi] + + Not only is this more aesthetically pleasing, it's faster -- no + redirects. + + In either case, you'll want to rewrite the list's archive URLs + to Mailman 2.1's archive: + + RewriteRule ^/pipermail/(foo-list.*) $MM21/archives/public/$1 + + * Restart your web server (or disable the "temporarily + unavailable" stuff). + + * Restart your MTA (or make it listen to more than just + 127.0.0.1). + + +UPGRADING FROM 2.0 to 2.0.x (where x >= 1) + + Nothing much more than running "make install" (after upgrading) + should be necessary. + + +UPGRADING FROM 2.0 beta to 2.0 final + + You MUST re-run configure; running config.status is not sufficient + due to some recent changes in the autoconf scripts. You can do a + head of config.status if you don't remember the options you + originally ran configure with. + + The cron jobs for Mailman 2.0 final have changed considerably, + including the frequency with which they run. You should reload + misc/crontab.in for the `mailman' user to get the right settings. + See the INSTALL file for details. + + FAILURE TO DO THIS WILL RESULT IN A LESS THAN OPTIMALLY FUNCTIONAL + MAILMAN INSTALLATION. + + +UPGRADING FROM 1.x to 2.x + + In addition to the instructions above, I highly recommend that you + make sure your Mailman queue is cleared /before/ upgrading. + + Mailman version 1.x had a cron script called run_queue which was + part of its bulk mailer. With Mailman 2.x there is no default + bulk mailer (it lets the MTA handle this), and it is currently + unknown what the effects of upgrading are on the run_queue script, + but I'll bet it's not good. :) + + The way to make sure that your Mailman queue is empty is to look + in your $prefix/data directory. If you see any files that start + with "mm_q." you've still got messages waiting on the queue. You + can run $prefix/cron/run_queue by hand until the queue is cleared. + Multiple invocations of this script won't help though; they lock + each other out. Also, be warned that clearing the queue can take + a while and may cause a large load on your system (two reasons why + all this stuff has been redesigned in 2.x :). + + You do not need to run "make update" if you are upgrading from + version 1.0 or 1.1 to version 2.0, since this is now run + automatically when you do a "make install". However you should + modify your crontab entries to execute cron/qrunner instead of + cron/run_queue. You can also safely remove the file + $prefix/cron/run_queue. + + If you are upgrading from a pre-1.0 beta, you need to follow the + instructions below. + + +UPGRADING FROM PRE-1.0 to 2.x + + You need to do a few extra things to make sure that the file + system layout for the early 1.0 betas is upgraded to the 1.x + configuration. There are two ways to do this. + + First, from the source directory, after you've done a "make + install" you can run "make update". "make update" creates a file + named "update.log" in the top level of the source distribution. + If the script that updates the Mailman filesystem encounters + something that is not resolvable, it will log info about this to + "update.log". This is worth checking after the upgrade completes. + + You can also just change to the installation directory (i.e. $prefix) + and run bin/update. This is the same as above except that the + update.log file is not generated. + + Check your crontab entry. Remove any runs of obsolete scripts, in + particular cron/upvolumes_yearly, cron/upvolumes_monthly, or + cron/archive. + + +WHAT "MAKE UPDATE" DOES + + Below is an annotated listing of the things that "make update" + does. Hopefully, this will help resolve any problems you are + having. + + Note that it can't hurt to run "make update" each time you + upgrade, but if you're running version 1.0 or newer, it won't help + much either! + + - To upgrade to 1.0b10, you will need to copy + templates/options.html to lists//options.html for each + mailing list you have. However, if you have edited the + options.html file, say from the Web interface, you will have to + merge these changes in manually. + + - The upgrade to 1.0b7 included the removal of + Mailman/smtplib.py{,c} since Mailman now uses the default Python + 1.5.2 version of smtplib. + + - Archiving files are moved around as part of integrating + Pipermail into Mailman, as of 1.0b6. In particular, + + 1) if a list has only a private mbox archive + $prefix/archives/private/ is moved to + $prefix/archives/private/.mbox/ + + 2) if a list has only a public mbox archive + $prefix/archives/public/ is moved to + $prefix/archives/private/.mbox/ + + and a symlink is made that points + $prefix/archives/public/.mbox to + $prefix/archives/private/.mbox/ + + 3) if a list has both private and public mbox archives, + make update picks one of the above 2 configurations based on + whether or not the list currently is archived publicly. It then + renames the other mbox to mbox.preb6. + + 4) if a list used recent CVS sources, where archives were placed in + $prefix/public_html/archives, then these are moved to + $prefix/archives/private/ and a symlink is made from + $prefix/archives/public/ to that spot if the list's + archives are public. Also, a permissions-related security + problem is removed. + + To integrate mbox archives of old lists, log in as user `mailman' + and run $prefix/bin/arch . + + Also, by default, beta6 does both mbox and html based archiving, + but you can configure Mailman to do one, both, or neither. + Please see $prefix/Mailman/Defaults.py for details. + + There was a short period of time when the CVS sources archiving + code was not organized into its own package. The pickled + articles in the archives that were placed into archives during + this period stored the path to the module HyperArch, but that + module has moved. You can quick fix this by running + + ln -s $prefix/Mailman/Archiver/HyperArch.py \ + $prefix/Mailman/HyperArch.py + + - If upgrading from version 1.0b4 or earlier, "make update" moves + list-specific templates. For each list, + $prefix/templates//* is moved to $prefix/lists/. + Please reference the generic templates in $prefix/templates to see + if any variables have changed (There shouldn't be many, only + options.html was updated from b5 to b6). + + For really old versions of Mailman, you may not even have + subdirectories in $prefix/templates! In this case + you will need to manually copy some files into your new list + directories. Here's an example shell command that will do the + trick: + + cp templates/{archives,handle_opts,listinfo,roster,subscribe}.html lists/ + + - Some modules that existed in previous versions, but that have + been replaced with newer (differently named) modules, are + removed. + + + +Local Variables: +mode: indented-text +indent-tabs-mode: nil +End: -- cgit v1.2.3