3.4. How do I move a list to a different server/Mailman installation.
Note: the process of moving lists and archives from one Mailman 2.1.x installation to another same or newer release installation is very straightforward. It has been outlined several times on the mailman-users@python.org list. A couple of recent posts are at http://mail.python.org/pipermail/mailman-users/2007-January/055208.html and http://mail.python.org/pipermail/mailman-users/2007-January/055211.html.
Various docs and experiences talk about ways to move the pipermail archive fot a list from one server to another, but by far the easiest way is to move the archives/private/LISTNAME.mbox/LISTNAME.mbox file, possibly check it with Mailman's bin/cleanarch and then rebuild the pipermail archive on the new server with Mailman's bin/arch. Doing that and also moving the lists/LISTNAME/config.pck file and possibly running Mailman's bin/genaliases or otherwise making the MTA aware of the new list are generally all that's needed.
Also, see 4.70 How do I change the name of (rename) a list? which talks about changing the name of a list on a given server, but the process for moving a list to another server without changing its name is similar.
There is a document at http://www.debian-administration.org/articles/567 which may also be helpful. It is fairly general, not too Debian specific.
Barry Warsaw has described the process he went through to upgrade from 2.0.10 to 2.1b2, which is similar to the process of moving a list from one server to another, at the following link:
http://www.mail-archive.com/mailman-developers@python.org/msg03127.html
Proceed at your own risk, it may or may not be relevant.
The process of removing subscribers from one list and moving them to another is described in the FAQ answer at:
How do I remove subscribers from a list and put them on a different list?
If you can only move part of the list due to not having full read permissions to the old list, you can regenerate the archive from the .mbox of the old archive using the techniques described in this FAQ answer:
How can I remove a post from the list archive or remove an entire archive?
Finally, you also need to update the MTA aliases. Run <mailman>/bin/genaliases to generate the list (or actually update if you've configured Mailman for you MTA).
Kevin Gagel's steps for moving Mailman from different OS and upgrading to a newer version.
Going from Redhat 7.3, Mailman 2.1.4 to SuSE 8.0, Mailman 2.0.4 while upgrading 2.0.4 to 2.1.5. This can be done in three basic steps.
1.)Copy the lists from the old server to the new server.
2.)Upgrade Mailman from 2.0.4 to 2.1.5
3.)Set the permissions and correct the url.
1 To copy the lists, cd into the mailman directory that holds "data", "archives", and "lists". Use tar to compress them into three files like this:
tar -cpvW -f /root/mmdata ./data tar -cpvW -f /root/mmarchives ./archives tar -cpvW -f /root/mmlists ./lists
Then copy these three files to the new server under the mailman directory where the above directories exist. Once you've done that, cd into that directory and begin the expansion with the following:
tar -xvf mmdata tar -xvf mmarchives tar -xvf mmlists
2 Set the permissions from this directory with:
chown -R nobody:mailman . chmod -R a+rx,g+ws .
3 Now your ready to upgrade from 2.0.4 to 2.1.5, follow all instrunctions for your upgrade in the UPGRADE document. You'll find that in the source package you've downloaded. For the configure process I had to use these paramaters:
--prefix=/usr/lib/mailman --with-var-prefix=/var/lib/mailman --with-groupid=nogroup --with-python=/usr/bin/python
I had use these because SuSE splits the package and installed it to different locations. You can go with the default Mailman install if you'd like. Just be sure to locate the three tar files and expand them to the correct mailman directory.
4 Now your ready to fix the installation. By now you should have mailman running and working but your old lists and archives don't yet show up. This step fixes that. Cd into the mailman/bin directory. Run the following command for each list you have transfered:
withlist -l -r fix_url listname
All should be well and working now. One caveat that might occur is you'll start getting notices about a missing stringIO modules. If this occurs to you then delete the following directories from the mailman directory and redo the above steps:
archives data lists locks logs qfiles spam
If your transfering from one OS to another and the locations of files have changed you'll find that you loose access to the archives. The fix for this is to delete the links in the /pathto/mailman/archives/public directory and redo them with the correct link to /pathto/mailman/archives/private/listname and listname.mbox The key to this one is to examine what you currently have and fix it to what it should be.
Converted from the Mailman FAQ Wizard
This is one of many Frequently Asked Questions.
Comments
The previous comment regarding this being a site admin task rather than a list admin task is correct, however I don't agree with the remark "Mailman should provide a way for List Admins to do this, but it doesn't". The implication of that seems to be that anyone who owns any Mailman list could move it to my server without my involvement. Is this what is wanted?
Not at all. I'm not proposing anything that changes how permissions apply. Allow me to explain what I think Mailman needs wrt List Admin functionality.
Mailman is widely deployed in commercial "shared web hosting" environments, under cPanel control. Customers of such services – and this is the single most popular form of recreational and small business web presence -- don't run their own Mailman instances, and don't have any sort of command-line access to the Mailman server, much less root. Where such Mailman access is provided, either cPanel presents the user with the interface to create lists (and handling the business logic of limiting or charging for lists), or customer service creates the list for the customer, manually; the customer is a List Admin, but they are not Site Admins. Their list appears to be at listname@theirdomain.tld and the Mailman interface is available somewhere at http://theirdomain.tld; it is owned by the owner of theirdomain.tld.
Such a customer is the List Admins for any lists they create at their hosting company. As such they might reasonably want to perform any of the following tasks which are presently not things Mailman directly supports:
1) They might want to backup their list's settings, membership rolls, and archives. A customer might reasonably not trust their hosting company to do backups of the listserver right. (And let me here just allude to the time the company that was donating server access to the non-profit that hosted a list I was on suddenly went bankrupt, and for a week while the server was shipped cross-continent by UPS we had no idea what happened to our list, and no way to recover the membership rolls, etc.)
2) They might want to take such a backup, in a machine-readable form, and be able to submit it to the Mailman interface for a list and have its settings, membership, and/or archives restored. Manually entering all the settings for a Mailman list is, yea verily I am the voice of experience, really quite a lot of hassle, and error prone. The membership and archives can't be manually entered. There is no way to upload archives, and while members can be subscribed, resubscription through the mass-subscription tool loses all sorts of information. It loses just who had previously be set to moderation (ask me how I know!) It means all subscribers that set themselves to no-mail and all subscribers who were automatically to no-mail due to bouncing, are now down as set to no-mail by administrators: so after a move, anyone who might previously have set themselves back to getting mail, has to get a list owner or moderator to do it for them, like they didn't have enough to do.
3) They might want to take such a backup and use it to take their list (listname@theirdomain.tld) with them when they move theirdomain.tld from one Mailman-offering host to another. I've now moved certain lists twice in this List Admins role as part of a domain move, and at no point has it been any fun. I am profoundly grateful that I did not get Mailman service from CornerHost, at which I was a customer when this particular fiasco happened: sometimes people have to move off servers when the people with root aren't answering support requests.
I'm not suggesting that anybody have the ability to upload to a server they haven't been granted the authority to. Merely that there should be web interfaces to allow upload and download of data files for things they already have permissions to read/write.
Please consider this suggestion. It affects what I gather are a rather huge number of Mailman List Admins and the way things presently are makes more work for staff at hosting companies and means the many users who are List Admins but not Site Admins are disenfranchised from their data.
I understand your request, and I understand your pain, but I'm not sure that it is up to Mailman to make up for deficiencies in cPanel and various Mailman hosting services. I really think it's up to cPanel to provide ways for hosted users to access the Mailman file system through cPanel. I understand that this raises many other issues in a hosted environment, but I had a conversation with a cPanel developer at the last PyCon, one result of which can be seen at <https://mail.python.org/pipermail/mailman-users/2013-March/074860.html> so there may be some movement in this direction with cPanel.
I also recognize that even if a perfect solution were available through cPanel, that wouldn't help customers of other, non-cPanel Mailman hosts.
In any case, even if we provided within the Mailman list admin GUI a way to download and upload, say a list's config.pck which is the only thing that contains all the list settings and member data (assuming the default MemberAdaptor is used), I envision a user grabbing a cPanel config.pck and uploading it to a non-cPanel Mailman or vice versa and disaster ensuing when all the web UI returns is a "we hit a bug" screen with no way to even restore the prior config.pck even if the user had been careful enough to make one.
Whoa. No, batch subscription is NOT the same thing as moving a list, and it is not an answer to the question, "How do I move a list to a different server?"
What this page describes is in no way a List Administrator task; everything relevent here can only be done at the command-line with system access, and as such is a Site Administrator task. Yes, Mailman should provide a way for List Admins to do this, but it doesn't. One has to be a Site Admin to move lists from one server to another. Thus this whole page belongs under 4 Site administrator tasks, not here under 3 List administrator tasks.
Probably the entirety of this page should be replaced (here) with, "List administrators cannot move lists. Only Site administrators can move lists."