Mark Sapiro wrote: > Frank Griffin wrote: >> According to the UPGRADE document, file formats have changed as have >> actual files (some new, some gone). What triggers the 2.1 version to do >> the necessary conversions ? Is it just finding files of the old version >> and recognizing them as such ? > > > Yes, as far as the old config.db to new config.pck conversion is > concerned. > > As far as other files such as the pending database and qfiles are > concerned, these will be converted by bin/update if you are upgrading > an installation, but if you are simply moving lists from an old to a > new installation, it is best to deal with pending requests and queued > messages on the old system and blow off anything that is left. There > is no automated way of converting these in the new installation. > > >> Does the last_mailman_version in the >> data directory trigger this ? > > > No. last_mailman_version tells bin/update whether it needs to do > anything. This comes into play when installing an upgrade, but when > moving an old list's config.(db|pck) into an existing installation, it > is the DATA_FILE_VERSION in the config file itself that triggers the > update. > > >> There are various minor concerns, such as file permissions, aliases, >> redoing public archive symlinks, and so forth. This made me wonder if >> it would be easier/possible to run bin/newlist for each existing 2.0 >> list in the 2.1.9 system, and *then* bring over the data, lists, and >> archives/private directories. Advisable ? > > > No. This is absolutely wrong. If you create the list on the new system > first, Mailman will always see that list's config.pck and will never > look at the config.db that you move over. > > My advice is: > > Do not create the lists on the new host. > > Do not move anything from the data/ directory. > > Move only the config.db from the lists/<listname>/ directories. > > Move the archives/private/ tree. > > Run bin/list_lists which will instantiate every list and convert every > old config.db to a new config.pck. > > Run bin/genaliases to create/update aliases. > > After conversion, remove the config.db files as if you don't, a > possible future problem in reading the config.pck and config.pck.last > files could cause Mailman to fall back to the then outdated config.db. > > Public archive symlinks will be created automatically the first time a > list's configuration is saved. The bin/list_lists accessing and > converting of the config.db files won't do this, but a list post or > accessing the admin web interface for a list will. >
Mark, Thanks for the reply. I've recently gotten back to this and wanted to post my results. In addition to the steps you posted, I needed to run "withlist -a -l -r fix_url". However, I have one anomaly that still needs resolution: All of the lists I moved had the option set to reply to the list (yes, I know), and they show up this way when I display them in the admin UI. However, when I post to them, the post mails arrive with a reply-to of the poster and the list description linked to an email address of the list owner, e.g. List-Id: WebData Project Discussion <webdata.ftgme2.griffin.selectbs.com> List-Unsubscribe: <http://ftgme2.griffin.selectbs.com/mailman/listinfo/webdata>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://ftgme2.griffin.selectbs.com/pipermail/webdata> List-Post: <mailto:[EMAIL PROTECTED]> List-Help: <mailto:[EMAIL PROTECTED]> List-Subscribe: <http://ftgme2.griffin.selectbs.com/mailman/listinfo/webdata>, <mailto:[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED], WebData Project Discussion <[EMAIL PROTECTED]> In this case, the list owner is [EMAIL PROTECTED] and the poster is [EMAIL PROTECTED] . It seems to me that this ought to be WebData Project Discussion <[EMAIL PROTECTED]> . Did I miss a step ? What can I do to correct this ? ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp