FAQ
Hello,

Is it possible to copy list and archives data from a 2.1.9 Mailman installation, to a 2.1.14 installation, and run bin/update to update data from 2.1.9 to 2.1.14? I assume bin/update will make any necessary changes to data structures, from 2.1.9 to 2.1.14?

Here is why I am doing this:

I took a Mailman 2.1.9 installation from Solaris (everything Mailman is under a single prefix directory) and copied it to A Linux system. I ran make install from Mailman 2.1.14 source, which did `make upgrade' as part of the installation. After some testing, I would like to copy current list and archive data to the Mailman 2.1.14 (Linux) system, at which time that system will become production.


Thanks,

Ivan.























.

Search Discussions

  • Mark Sapiro at Feb 3, 2011 at 10:57 pm

    Ivan Fetch wrote:
    Is it possible to copy list and archives data from a 2.1.9 Mailman installation, to a 2.1.14 installation, and run bin/update to update data from 2.1.9 to 2.1.14? I assume bin/update will make any necessary changes to data structures, from 2.1.9 to 2.1.14?

    Yes and no. If you just copy a lists/LISTNAME/config.pck from any 2.1.x
    or even (I think) from 2.0.x to a more recent installation, the first
    time the list is instantiated, mailman will automatically do any
    required updates.

    bin/update is designed for migrating an entire installation, not
    individual lists, and it normally won't do anything if run by hand in
    an existing installation. It does migration tasks other than updating
    the actual list config.

    For the archives, the recommended process is to first check and if
    necessary fix the archives/private/LISTNAME.mbox/LISTNAME.mbox files
    with bin/cleanarch and then move those mbox files only and build
    archives on the new host with bin/arch --wipe.

    It is possible to just move the archives/private/LISTNAME tree rather
    than running bin/arch --wipe as long as permissions are OK or fixed
    after the move, but you still need to move
    archives/private/LISTNAME.mbox/LISTNAME.mbox.

    You don't need to do anything with archives/public/LISTNAME as those
    symlinks will be created for lists with public archives when the list
    is first accessed.

    See the FAQ at <http://wiki.list.org/x/2oA9>.

    Also, if your MTA uses aliases, you may need to run bin/genaliases
    after the move and/or manually update aliases.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Ivan Fetch at Feb 4, 2011 at 1:52 am
    Hello, thanks for your reply,

    On Thu, 3 Feb 2011, Mark Sapiro wrote:

    Ivan Fetch wrote:
    Is it possible to copy list and archives data from a 2.1.9 Mailman installation, to a 2.1.14 installation, and run bin/update to update data from 2.1.9 to 2.1.14? I assume bin/update will make any necessary changes to data structures, from 2.1.9 to 2.1.14?

    Yes and no. If you just copy a lists/LISTNAME/config.pck from any 2.1.x
    or even (I think) from 2.0.x to a more recent installation, the first
    time the list is instantiated, mailman will automatically do any
    required updates.

    bin/update is designed for migrating an entire installation, not
    individual lists, and it normally won't do anything if run by hand in
    an existing installation. It does migration tasks other than updating
    the actual list config.

    For the archives, the recommended process is to first check and if
    necessary fix the archives/private/LISTNAME.mbox/LISTNAME.mbox files
    with bin/cleanarch and then move those mbox files only and build
    archives on the new host with bin/arch --wipe.

    It is possible to just move the archives/private/LISTNAME tree rather
    than running bin/arch --wipe as long as permissions are OK or fixed
    after the move, but you still need to move
    archives/private/LISTNAME.mbox/LISTNAME.mbox.

    You don't need to do anything with archives/public/LISTNAME as those
    symlinks will be created for lists with public archives when the list
    is first accessed.

    See the FAQ at <http://wiki.list.org/x/2oA9>.

    Also, if your MTA uses aliases, you may need to run bin/genaliases
    after the move and/or manually update aliases.
    Thank you - this helps me walk through the process.

    The goal is to move all lists, archives, and data to the new box, and
    then install Mailman 2.1.14 over those directories - I have done this.

    When this box goes production, I want to refresh the lists, archives,
    and data from the current 2.1.9 Mailman. All paths and host names will
    stay the same.

    It sounds like there isn't anything I have to do after syncing the
    lists, data, and archives directories.

    IF a list's pck file is updated when the list is next instantiated -
    what is the simplest thing that will trigger this? Iterating through all
    lists somehow? (I realize this isn't strictly necessary to do because it
    will happen on the fly)

    Thanks,

    Ivan.
  • Mark Sapiro at Feb 4, 2011 at 2:15 am

    Ivan Fetch wrote:
    When this box goes production, I want to refresh the lists, archives,
    and data from the current 2.1.9 Mailman. All paths and host names will
    stay the same.

    It sounds like there isn't anything I have to do after syncing the
    lists, data, and archives directories.

    That is correct, but there may be timing issues. Are you changing DNS
    or physically reassigning the IP address to the new box.

    If you're changing DNS, I'd start now and give all the relevant DNS
    entries a 5 minute or less TTL, so you don't have to worry about old
    DNS for more than 5 minutes.

    If you're not going to sync qfiles, you need to make sure that all
    queues are empty on the old box. Maybe wait for a quiet moment when
    queues are empty and stop the MTA.

    IF a list's pck file is updated when the list is next instantiated -
    what is the simplest thing that will trigger this? Iterating through all
    lists somehow? (I realize this isn't strictly necessary to do because it
    will happen on the fly)

    From the command line, a simple bin/list_lists will do it. From the
    web, simply going to the listinfo or admin overview page for any host
    will do.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Ivan Fetch at Feb 4, 2011 at 3:00 am
    Hello,

    On Thu, 3 Feb 2011, Mark Sapiro wrote:

    That is correct, but there may be timing issues. Are you changing DNS
    or physically reassigning the IP address to the new box.

    If you're changing DNS, I'd start now and give all the relevant DNS
    entries a 5 minute or less TTL, so you don't have to worry about old
    DNS for more than 5 minutes.
    Thanks for thinking about / covering all of these aspects. The IP will
    move to the new box.

    If you're not going to sync qfiles, you need to make sure that all
    queues are empty on the old box. Maybe wait for a quiet moment when
    queues are empty and stop the MTA.
    I was planning to sync qfiles also (now that you mention it). Looking
    at our current qfiles, some of them have files which look like they should
    be deleted:

    Bounces: 260 (all .bak, but one .tmp)
    Shunt: 145 .pck

    Should I kill the files in bounces, and run unshunt on files in shunt
    which are not terribly old?


    Thanks for your time,

    Ivan.
  • Mark Sapiro at Feb 4, 2011 at 3:21 am

    Ivan Fetch wrote:
    I was planning to sync qfiles also (now that you mention it). Looking
    at our current qfiles, some of them have files which look like they should
    be deleted:

    Bounces: 260 (all .bak, but one .tmp)

    There was a bug in 2.1.9 that would leave the .bak file behind when the
    runner encountered an "unparseable message" exception. You can examine
    these files with bin/dumpdb or bin/show_qfiles, but I think they're
    all spam and should be removed.

    Shunt: 145 .pck

    Should I kill the files in bounces, and run unshunt on files in shunt
    which are not terribly old?

    Again, look at the shunt queue entries with bin/dumpdb or
    bin/show_qfiles and delete all but the "good" ones. Also look in
    Mailman's error log for the corresponding time stamped entries to see
    what the underlying issue is. If it isn't fixed, the messages will
    just be shunted again.

    Once you have only "good" entries in the shunt queue, you can run
    unshunt.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedFeb 3, '11 at 8:26p
activeFeb 4, '11 at 3:21a
posts6
users2
websitelist.org

2 users in discussion

Mark Sapiro: 3 posts Ivan Fetch: 3 posts

People

Translate

site design / logo © 2022 Grokbase