Mailman - The GNU Mailing List Management System Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA 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 UPGRADING FROM 2.0.1 to 2.0.2 Nothing much more than running "make install" (after upgrading) should be necessary. UPGRADING FROM 2.0 to 2.0.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 cron/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 it's 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. [NOTE HOWEVER THAT MAILMAN 2.0 ADDS THIS FILE BACK IN Mailman/pythonlib]. - 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: