1
by
This commit was manufactured by cvs2svn to create branch |
1 |
Mailman - The GNU Mailing List Management System |
417
by bwarsaw
Notes on upgrading from 2.1.4 to 2.1.5. |
2 |
Copyright (C) 1998-2004 by the Free Software Foundation, Inc. |
749
by tkikuchi
FSF office has moved to 51 Franklin Street. |
3 |
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA |
1
by
This commit was manufactured by cvs2svn to create branch |
4 |
|
5 |
||
6 |
UPGRADING FROM PREVIOUS VERSIONS |
|
7 |
||
426
by bwarsaw
Clarify some upgrading issues. |
8 |
For the most part, upgrading Mailman entails installing the latest version |
9 |
over the existing version. Usually, you can unpack the new release, run |
|
10 |
'configure' with the same options you used in your previous install, and |
|
11 |
then do a 'make install'. However, there are some changes that may need |
|
12 |
to be taken care of manually. |
|
1
by
This commit was manufactured by cvs2svn to create branch |
13 |
|
417
by bwarsaw
Notes on upgrading from 2.1.4 to 2.1.5. |
14 |
What you need to do depends on the version you are using and the version |
15 |
you are upgrading to. In all cases, you should first turn off your mail |
|
16 |
and web access to your Mailman installation. You're essentially upgrading |
|
17 |
a database, and it's usually a good idea to make sure the database cannot |
|
18 |
be modified in the middle of the upgrade. |
|
1
by
This commit was manufactured by cvs2svn to create branch |
19 |
|
426
by bwarsaw
Clarify some upgrading issues. |
20 |
My recommendations are: |
1
by
This commit was manufactured by cvs2svn to create branch |
21 |
|
417
by bwarsaw
Notes on upgrading from 2.1.4 to 2.1.5. |
22 |
- Turn off your incoming mail daemon. Most remote smtp servers will |
23 |
simply queue up messages destined for your domain if port 25 is shut |
|
24 |
off. |
|
25 |
||
26 |
- Temporarily disable web access to Mailman. You can do this by either |
|
27 |
turning off your web server temporarily, or by setting up a temporary |
|
28 |
redirect to a "service unavailable" page for the Mailman URLs. Refer to |
|
29 |
your web server documentation for details. |
|
30 |
||
31 |
||
32 |
UPGRADING FROM 2.1.4 to 2.1.5 |
|
33 |
||
34 |
In Mailman 2.1.5, some significant changes have been made to the file |
|
35 |
formats for qfiles and the pendings database. All care has been taken to |
|
36 |
make sure the upgrades happen automatically and smoothly, but you should |
|
37 |
double check and, for the ultra-paranoid, make backups of your Mailman |
|
38 |
site before you upgrade. BE SURE TO TURN OFF MAILMAN AS DESCRIBED ABOVE |
|
39 |
BEFORE YOU UPGRADE. |
|
40 |
||
984.6.3
by A.M. Kuchling
Small grammar fixes; update reference to README.<mta> files |
41 |
Specifically, in MM2.1.4 every message in the queues was represented by |
417
by bwarsaw
Notes on upgrading from 2.1.4 to 2.1.5. |
42 |
two files, a .msg or .pck file containing the email message, and a .db |
43 |
file containing metadata about the message. In MM2.1.5 this has been made |
|
44 |
more efficient by using only one file (with a .pck extension) for both the |
|
45 |
message and metadata. This should make MM2.1.5 half as hostile to the |
|
46 |
file system. |
|
47 |
||
48 |
The bin/upgrade script, which is run automatically when you upgrade, |
|
49 |
should convert all the old style qfiles to the new style qfiles. Note |
|
50 |
that this could take a long time if you have a lot of files in your qfiles |
|
51 |
subdirectories. Pay particular attention to files you might have in |
|
52 |
qfiles/shunt; these will get upgraded too, although files in qfiles/bad |
|
53 |
will not. |
|
54 |
||
55 |
In MM2.1.4, the database file containing pending actions (i.e |
|
56 |
subscriptions, unsubscriptions, message holds, etc.) was shared globally |
|
57 |
among all mailing lists. In MM2.1.5, each list now has its own pending |
|
58 |
database file. All care has been taken to properly split pending actions |
|
59 |
from the global to the list-specific files, but it's possible there are |
|
60 |
bugs here. Best practice is to clear all pending actions before you
|
|
61 |
upgrade, although this is not always possible.
|
|
1
by
This commit was manufactured by cvs2svn to create branch |
62 |
|
63 |
||
64 |
UPGRADING FROM 2.0.x to 2.1
|
|
65 |
||
417
by bwarsaw
Notes on upgrading from 2.1.4 to 2.1.5. |
66 |
When you upgrade from Mailman 2.0.x to Mailman 2.1, you should double
|
67 |
check that your moderation and privacy options are still set the way you
|
|
68 |
want them. The Mailman options dealing with moderation and privacy have
|
|
69 |
changed significantly, to make them easier to understand and control.
|
|
70 |
Ever effort was taken to translate the old configuration variables to the
|
|
71 |
new configuration variables, but because the old semantics were so
|
|
72 |
complex, it is possible your settings may not have been correctly
|
|
73 |
translated.
|
|
74 |
||
75 |
Check especially the values for (in Privacy -> Sender Filters)
|
|
76 |
default_member_moderation, generic_nonmember_action, and
|
|
984.6.3
by A.M. Kuchling
Small grammar fixes; update reference to README.<mta> files |
77 |
accept_these_nonmembers. Also check the moderation flag on member
|
417
by bwarsaw
Notes on upgrading from 2.1.4 to 2.1.5. |
78 |
accounts in the Membership Management screen.
|
79 |
||
1
by
This commit was manufactured by cvs2svn to create branch |
80 |
In Mailman 2.1, the qrunner subsystem has been completely
|
81 |
rewritten. You no longer start qrunner from cron! Instead, there
|
|
82 |
is a bin/mailmanctl script which is used to start, stop, and
|
|
83 |
restart mail delivery. This script is appropriate to use as a
|
|
84 |
Unix init script. Be sure to update your crontab with the new
|
|
85 |
cron/crontab.in file.
|
|
86 |
||
87 |
NOTE: It is very important that if you are upgrading from a
|
|
88 |
pre-MM2.1alpha2 system to a post-MM2.1alpha2 system that you let
|
|
89 |
the old qrunner process clear any and all messages sitting in the
|
|
90 |
qfiles/ directory *BEFORE* you upgrade. Otherwise after the
|
|
984.6.3
by A.M. Kuchling
Small grammar fixes; update reference to README.<mta> files |
91 |
upgrade, those messages will not get delivered, and there is no
|
92 |
easy way to upgrade those pending messages.
|
|
1
by
This commit was manufactured by cvs2svn to create branch |
93 |
|
89
by bwarsaw
Backporting from the HEAD -- top level files |
94 |
NOTE: When upgrading to Mailman 2.1, you will need to regenerate
|
95 |
your aliases files. There have been many changes to the alias
|
|
96 |
names, the programs they map to, and the name of the wrapper
|
|
984.6.3
by A.M. Kuchling
Small grammar fixes; update reference to README.<mta> files |
97 |
script. See the Mailman Installation Manual for details of making
|
98 |
Mailman work with your mail server.
|
|
1
by
This commit was manufactured by cvs2svn to create branch |
99 |
|
100 |
To regenerate your aliases, use the bin/genaliases script.
|
|
101 |
||
984.1.75
by Mark Sapiro
Updated Version.py for 2.1.10b4. |
102 |
IMPORTANT: The encryption algorithm for list admin passwords has
|
103 |
changed which means that after upgrading from 2.0.x to 2.1.x, list
|
|
104 |
passwords will have to be reset. There is a new bin/change_pw tool
|
|
105 |
to help with this.
|
|
106 |
||
1
by
This commit was manufactured by cvs2svn to create branch |
107 |
Mailman 2.1 introduces multilingual (a.k.a. internationalization
|
108 |
or i18n) support. Previously only one language per list was
|
|
109 |
supported, and it was assumed that this language would be English.
|
|
110 |
The upgrade script for Mailman 2.1 creates a subdirectory `en'
|
|
111 |
inside each lists/<listname> directory. It then copies all the |
|
112 |
.txt and .html files from lists/<listname> into |
|
113 |
lists/<listname>/en. |
|
114 |
||
115 |
If you have modified those templates to contain non-English text, |
|
116 |
you will have to manually rename the en subdirectories to the |
|
117 |
language code for the language of your templates. Mailman's |
|
118 |
upgrade script should handle cleaning up any templates which are
|
|
119 |
duplicates of the defaults, but you'll want to double check this |
|
120 |
manually. |
|
121 |
||
122 |
If you are running a MM2.0.x system with non-standard patches |
|
123 |
applied, you might have some other problems with your upgrade. |
|
124 |
Here are some instances we know about: |
|
125 |
||
126 |
- If you've applied patch #413752 (coerce to plaintext), then your |
|
984.6.3
by A.M. Kuchling
Small grammar fixes; update reference to README.<mta> files |
127 |
upgrade will not go smoothly. Take a look at patch #651406 for
|
1
by
This commit was manufactured by cvs2svn to create branch |
128 |
an unofficial solution.
|
129 |
||
130 |
http://sf.net/tracker/?group_id=103&atid=300103&func=detail&aid=413752
|
|
131 |
http://sf.net/tracker/?group_id=103&atid=300103&func=detail&aid=651406
|
|
132 |
||
133 |
||
134 |
UPGRADING INDIVIDUAL LISTS
|
|
135 |
||
136 |
If you're nervous about upgrading all of your lists to 2.1 in one |
|
137 |
go, you can move them and upgrade them one at a time. Start by |
|
138 |
doing a clean Mailman 2.1 installation in an empty directory -- |
|
139 |
call it $MM21. (I'll assume your Mailman 2.0 installation is in |
|
140 |
$MM20.)
|
|
141 |
||
142 |
Doing this means you'll have co-habiting Mailman 2.0 and 2.1 |
|
143 |
installations for a while, until you have moved all of your lists |
|
144 |
to Mailman 2.1. Depending on your MTA and web server, this could |
|
145 |
be transparent and painless, or it could be an ongoing headache. |
|
146 |
||
147 |
If you use Apache with mod_rewrite, then it's fairly |
|
148 |
straightforward to set things up so that both Mailman 2.0 and 2.1
|
|
149 |
inhabit the /mailman and /pipermail URL-space of your server; this
|
|
150 |
makes the transition almost transparent to list admins and
|
|
151 |
subscribers. See below for details.
|
|
152 |
||
153 |
Now, for each list that you want to move, you'll have to |
|
154 |
||
155 |
* Shut down your MTA. |
|
156 |
||
157 |
If you have a lot of outgoing list traffic, you might need to |
|
158 |
leave your MTA up but only let it accept connections from |
|
159 |
127.0.0.1 (localhost), so Mailman 2.0 can flush its queue. |
|
160 |
How to do this is MTA-dependent; for Exim, you can set |
|
161 |
"local_interfaces = 127.0.0.1" and "kill -HUP" the Exim |
|
162 |
daemon. |
|
163 |
||
164 |
* Shut down your web server. For a more professional look, or |
|
165 |
if you want to allow people to keep accessing the rest of your |
|
166 |
web site, you could make your web server respond to all |
|
167 |
/mailman/ URLs with a "temporarily unavailable" message. |
|
168 |
||
169 |
How to do this is web server-dependent; with Apache and |
|
170 |
mod_rewrite, this does the trick: |
|
171 |
||
172 |
RewriteRule ^/mailman/.* /var/www/unavailable.html [L] |
|
173 |
||
174 |
(Of course, you'll have to supply your own |
|
175 |
/var/www/unavailable.html.)
|
|
176 |
||
177 |
* Force Mailman 2.0 to process its queue:
|
|
178 |
||
179 |
python -S $MM20/cron/qrunner
|
|
180 |
||
181 |
(This is only necessary if there are any files in $MM20/qfiles;
|
|
182 |
if you need to do this, make sure you left your MTA listening to
|
|
183 |
127.0.0.1.)
|
|
184 |
||
185 |
* Move the list:
|
|
186 |
||
187 |
cd $MM20
|
|
188 |
mv -i lists/foo-list $MM21/lists
|
|
189 |
mv -i archives/private/foo-list $MM21/archives/private
|
|
190 |
mv -i archives/private/foo-list.mbox $MM21/archives/private
|
|
191 |
rm archives/public/foo-list
|
|
192 |
rm archives/public/foo-list.mbox
|
|
193 |
cd $MM21
|
|
194 |
bin/withlist -l -r fix_url mylist
|
|
195 |
||
196 |
(The fix_url step will not be necessary if your Mailman 2.0
|
|
197 |
and 2.1 installations will be sharing the same URL-space.)
|
|
198 |
||
199 |
* Edit your web server config so the list's URLs continue to |
|
200 |
work. There are two possible approaches here; the simpler way |
|
201 |
is to setup a new slice of URL-space that will be used by your |
|
202 |
Mailman 2.1 installation, eg. /mailman-21: |
|
203 |
With Apache and mod_rewrite: |
|
204 |
||
205 |
RewriteRule /mailman/(.*)/(foo-list.*) /mailman-21/$1/$2 [R=temp] |
|
206 |
||
207 |
(The [R=temp] assumes that "/mailman-21/" is a temporary URL, |
|
208 |
and you'll move all your lists to "/mailman/" when the |
|
209 |
transition to Mailman 2.1 is complete.)
|
|
210 |
||
211 |
If you don't want to expose ugly temporary URLs like |
|
212 |
"/mailman-21" to the world, it's only slightly more work to make |
|
213 |
Mailman 2.0 and 2.1 share the same slices of URL-space. Here's |
|
214 |
how to do it with Apache and mod_rewrite: |
|
215 |
||
216 |
RewriteRule ^/mailman/(.*)/(foo-list.*) \ |
|
217 |
$MM21/cgi-bin/$1/$2 \ |
|
218 |
[T=application/x-httpd-cgi] |
|
219 |
||
220 |
Not only is this more aesthetically pleasing, it's faster -- no |
|
221 |
redirects.
|
|
222 |
||
223 |
In either case, you'll want to rewrite the list's archive URLs |
|
224 |
to Mailman 2.1's archive: |
|
225 |
||
226 |
RewriteRule ^/pipermail/(foo-list.*) $MM21/archives/public/$1 |
|
227 |
||
228 |
* Restart your web server (or disable the "temporarily |
|
229 |
unavailable" stuff). |
|
230 |
||
231 |
* Restart your MTA (or make it listen to more than just |
|
232 |
127.0.0.1). |
|
233 |
||
234 |
||
235 |
UPGRADING FROM 2.0 to 2.0.x (where x >= 1) |
|
236 |
||
237 |
Nothing much more than running "make install" (after upgrading) |
|
238 |
should be necessary. |
|
239 |
||
240 |
||
241 |
UPGRADING FROM 2.0 beta to 2.0 final |
|
242 |
||
243 |
You MUST re-run configure; running config.status is not sufficient |
|
244 |
due to some recent changes in the autoconf scripts. You can do a |
|
245 |
head of config.status if you don't remember the options you |
|
246 |
originally ran configure with.
|
|
247 |
||
248 |
The cron jobs for Mailman 2.0 final have changed considerably,
|
|
249 |
including the frequency with which they run. You should reload
|
|
250 |
misc/crontab.in for the `mailman' user to get the right settings. |
|
251 |
See the INSTALL file for details. |
|
252 |
||
253 |
FAILURE TO DO THIS WILL RESULT IN A LESS THAN OPTIMALLY FUNCTIONAL |
|
254 |
MAILMAN INSTALLATION. |
|
255 |
||
256 |
||
257 |
UPGRADING FROM 1.x to 2.x |
|
258 |
||
259 |
In addition to the instructions above, I highly recommend that you |
|
260 |
make sure your Mailman queue is cleared /before/ upgrading. |
|
261 |
||
262 |
Mailman version 1.x had a cron script called run_queue which was |
|
263 |
part of its bulk mailer. With Mailman 2.x there is no default |
|
264 |
bulk mailer (it lets the MTA handle this), and it is currently |
|
265 |
unknown what the effects of upgrading are on the run_queue script, |
|
266 |
but I'll bet it's not good. :) |
|
267 |
||
268 |
The way to make sure that your Mailman queue is empty is to look |
|
269 |
in your $prefix/data directory. If you see any files that start |
|
270 |
with "mm_q." you've still got messages waiting on the queue. You |
|
271 |
can run $prefix/cron/run_queue by hand until the queue is cleared.
|
|
272 |
Multiple invocations of this script won't help though; they lock |
|
273 |
each other out. Also, be warned that clearing the queue can take |
|
274 |
a while and may cause a large load on your system (two reasons why |
|
275 |
all this stuff has been redesigned in 2.x :). |
|
276 |
||
277 |
You do not need to run "make update" if you are upgrading from |
|
278 |
version 1.0 or 1.1 to version 2.0, since this is now run |
|
279 |
automatically when you do a "make install". However you should |
|
280 |
modify your crontab entries to execute cron/qrunner instead of |
|
281 |
cron/run_queue. You can also safely remove the file |
|
282 |
$prefix/cron/run_queue. |
|
283 |
||
284 |
If you are upgrading from a pre-1.0 beta, you need to follow the |
|
285 |
instructions below. |
|
286 |
||
287 |
||
288 |
UPGRADING FROM PRE-1.0 to 2.x |
|
289 |
||
290 |
You need to do a few extra things to make sure that the file |
|
291 |
system layout for the early 1.0 betas is upgraded to the 1.x |
|
292 |
configuration. There are two ways to do this. |
|
293 |
||
294 |
First, from the source directory, after you've done a "make |
|
295 |
install" you can run "make update". "make update" creates a file
|
|
296 |
named "update.log" in the top level of the source distribution.
|
|
297 |
If the script that updates the Mailman filesystem encounters
|
|
298 |
something that is not resolvable, it will log info about this to
|
|
299 |
"update.log". This is worth checking after the upgrade completes.
|
|
300 |
||
301 |
You can also just change to the installation directory (i.e. $prefix)
|
|
302 |
and run bin/update. This is the same as above except that the
|
|
303 |
update.log file is not generated.
|
|
304 |
||
305 |
Check your crontab entry. Remove any runs of obsolete scripts, in
|
|
306 |
particular cron/upvolumes_yearly, cron/upvolumes_monthly, or
|
|
307 |
cron/archive.
|
|
308 |
||
309 |
||
310 |
WHAT "MAKE UPDATE" DOES
|
|
311 |
||
312 |
Below is an annotated listing of the things that "make update"
|
|
313 |
does. Hopefully, this will help resolve any problems you are
|
|
314 |
having.
|
|
315 |
||
316 |
Note that it can't hurt to run "make update" each time you |
|
317 |
upgrade, but if you're running version 1.0 or newer, it won't help |
|
318 |
much either! |
|
319 |
||
320 |
- To upgrade to 1.0b10, you will need to copy |
|
321 |
templates/options.html to lists/<listname>/options.html for each |
|
322 |
mailing list you have. However, if you have edited the |
|
323 |
options.html file, say from the Web interface, you will have to |
|
324 |
merge these changes in manually. |
|
325 |
||
326 |
- The upgrade to 1.0b7 included the removal of |
|
327 |
Mailman/smtplib.py{,c} since Mailman now uses the default Python |
|
328 |
1.5.2 version of smtplib. |
|
329 |
||
330 |
- Archiving files are moved around as part of integrating |
|
331 |
Pipermail into Mailman, as of 1.0b6. In particular, |
|
332 |
||
333 |
1) if a list has only a private mbox archive |
|
334 |
$prefix/archives/private/<listname> is moved to |
|
335 |
$prefix/archives/private/<listname>.mbox/<listname> |
|
336 |
||
337 |
2) if a list has only a public mbox archive |
|
338 |
$prefix/archives/public/<listname> is moved to |
|
339 |
$prefix/archives/private/<listname>.mbox/<listname> |
|
340 |
||
341 |
and a symlink is made that points |
|
342 |
$prefix/archives/public/<listname>.mbox to |
|
343 |
$prefix/archives/private/<listname>.mbox/<listname> |
|
344 |
||
345 |
3) if a list has both private and public mbox archives, |
|
346 |
make update picks one of the above 2 configurations based on |
|
347 |
whether or not the list currently is archived publicly. It then |
|
348 |
renames the other mbox to mbox.preb6. |
|
349 |
||
350 |
4) if a list used recent CVS sources, where archives were placed in |
|
351 |
$prefix/public_html/archives, then these are moved to |
|
352 |
$prefix/archives/private/<listname> and a symlink is made from |
|
353 |
$prefix/archives/public/<listname> to that spot if the list's |
|
354 |
archives are public. Also, a permissions-related security
|
|
355 |
problem is removed.
|
|
356 |
||
357 |
To integrate mbox archives of old lists, log in as user `mailman'
|
|
358 |
and run $prefix/bin/arch <listname> <path-to-mbox-archive>. |
|
359 |
||
360 |
Also, by default, beta6 does both mbox and html based archiving, |
|
361 |
but you can configure Mailman to do one, both, or neither. |
|
362 |
Please see $prefix/Mailman/Defaults.py for details. |
|
363 |
||
364 |
There was a short period of time when the CVS sources archiving |
|
365 |
code was not organized into its own package. The pickled |
|
366 |
articles in the archives that were placed into archives during |
|
367 |
this period stored the path to the module HyperArch, but that |
|
368 |
module has moved. You can quick fix this by running |
|
369 |
||
370 |
ln -s $prefix/Mailman/Archiver/HyperArch.py \ |
|
371 |
$prefix/Mailman/HyperArch.py |
|
372 |
||
373 |
- If upgrading from version 1.0b4 or earlier, "make update" moves |
|
374 |
list-specific templates. For each list, |
|
375 |
$prefix/templates/<listname>/* is moved to $prefix/lists/<listname>. |
|
376 |
Please reference the generic templates in $prefix/templates to see
|
|
377 |
if any variables have changed (There shouldn't be many, only
|
|
378 |
options.html was updated from b5 to b6).
|
|
379 |
||
380 |
For really old versions of Mailman, you may not even have
|
|
381 |
<listname> subdirectories in $prefix/templates! In this case
|
|
382 |
you will need to manually copy some files into your new list
|
|
383 |
directories. Here's an example shell command that will do the
|
|
384 |
trick:
|
|
385 |
||
386 |
cp templates/{archives,handle_opts,listinfo,roster,subscribe}.html lists/<listname>
|
|
387 |
||
388 |
- Some modules that existed in previous versions, but that have
|
|
389 |
been replaced with newer (differently named) modules, are
|
|
390 |
removed.
|
|
391 |
||
392 |
||
393 |
||
394 |
Local Variables:
|
|
395 |
mode: indented-text
|
|
396 |
indent-tabs-mode: nil
|
|
397 |
End:
|