On Jul 24, 2007, at 10:46 PM, Mark Sapiro wrote:
Chris Waltham wrote:
I have been tasked with moving a Mailman 2.0.12 installation from a Solaris (SPARC) server to a Linux (x86) server. The Linux server will be receiving a copy of Mailman 2.1.9, so obviously I am making the 2.0.x -> 2.1.x jump in there. Also, on Solaris, Mailman lives in / home/mailman but on Linux I will be putting it in /blender/mailman (and thus using move_list to update archives, fix_url, etc.)
What makes this migration slightly tricky is that the server hosts around 840 lists. Therefore, going through each list pre- and post- migration by hand would be a little time-consuming for me, so I want to avoid that where possible :-)I noticed that, when doing a "make update" when installing 2.1.9, a couple of lists from 2.0.12 failed the update process and I had to Control-C them for the process to continue. I'm not sure what the exact problem was, hence I'm wondering if there is any kind of check that I can run in a FOR loop to verify a list's integrity. And, yes, I've run check_db and check_perms and neither report problems, this just seems to be a handful of lists out of the 800-odd that seem a little flaky.
There is little you can do to verify the integrity of a list other
than trying to instantiate it which will also update it if necessary (and possible). check_perms only checks permissions (and it has a bug regarding archives/private). check_db only checks that list data can be loaded from lists/<listname>/config.* files. It doesn't sanity check the result.Do you know which lists failed in bin/update (run by make update)? If so do these lists have lists/<listname>/config.pck files which are converted from the config.db files and indicate the conversion of the list data was probably successful. In any case, are there any lists that don't have lists/<listname>/config.pck files? These would be the problem lists.
One list that failed both "make update" and the below-mentioned
"config_list" is named "bowsun". Here is a copy of its contents:
drwxrwsr-x 2 mailman mailman 4096 Jul 24 11:03 ./
drwxrwsr-x 844 mailman mailman 65536 Jul 24 11:01 ../
-rwxr-xr-- 1 mailman mailman 1692 Jul 30 2003
admindbpreamble.html*
-rwxr-xr-- 1 mailman mailman 357 Jan 19 2001 archives.html*
-rw-rw---- 1 root mailman 15076 Jul 23 15:37 config.db
-rw-rw---- 1 mailman mailman 15075 Jun 29 07:03 config.db.last
-rw-rw---- 1 root mailman 12578 Jul 24 11:03 config.pck
-rw-rw---- 1 root mailman 12578 Jul 24 10:51 config.pck.last
-rwxr-xr-- 1 mailman mailman 189 Jan 19 2001 handle_opts.html*
-rwxr-xr-- 1 mailman mailman 1026 Jan 19 2001 headfoot.html*
-rwxr-xr-- 1 mailman mailman 3136 Jan 19 2001 listinfo.html*
-rwxr-xr-- 1 mailman mailman 4106 Jan 19 2001 options.html*
-rw-rw-r-- 1 root mailman 443875 Jul 24 08:41 request.pck
-rwxr-xr-- 1 mailman mailman 1169 Jan 19 2001 roster.html*
-rwxr-xr-- 1 mailman mailman 198 Jan 19 2001 subscribe.html*
I'm not sure how to start troubleshooting that one..?
One way to do a better sanity check or problem detection on these (or even on all) lists is
bin/config_list -i /dev/null listname
This will attempt to instantiate the list and if it's a 2.0.12 list convert the data in config.db and save as config.pck.
Okay great, I'm giving that a try now in the background.
One bit of advice. Once the lists are all converted, remove the config.db and config.db.last files from the lists/<listname>/ directories. If you don't do this, it is possible that at some future time, the config.pck and config.pck.last files could become corrupt and cause Mailman to fall back to the then ancient config.db.
Good tip, I'll be sure to use it! One thing I've noticed is a problem
with genaliases. Going off this URL: http://acd.ucar.edu/~fredrick/
linux/mailman/upgrading.html it suggests running "genaliases", saving
the output to a text file, and merging that with my current /etc/
aliases. However, when I run genaliases, it returns no output and no
errors. Is there a place I should start troubleshooting that from?
Thanks!
Chris