[ mailman-Feature Requests-1533331 ] support moving lists to another mailman instance

[SourceForge.net]

Feature Requests item #1533331, was opened at 2006-08-02 13:27
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1533331&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric S. Raymond (esr)
Assigned to: Nobody/Anonymous (nobody)
Summary: support moving lists to another mailman instance

Initial Comment:
I'm having to move a project off a hosting site that
uses Mailman, and have discovered to my shock that
there is no easy way to capture a snapshot of the list
state and re-instantiate it on another Mailman instance.  

While this remains the case, Mailman is a prison for my
data.  The only way I could get even the subscriber
list was by tedious screen-scraping of the membership
management CGI, made more tedious because the interface
only wants to show me the subscriber list in small
chunks.  

Breaking up the list archives by month is all very well
but I want to be able to get all of the traffic -- and
I want to be able to upload it into another Mailman
instance.

I gave up on metadata such as hide and digest bits
entirely; there's no equivalent of mass subscribe that
would let me set those, I'd have to patch them in by
hand per each subscriber address in the new list
instance.  

The *correct* design would be to allow me to download
one file that's an XML document containing subscriber
list, metadata such as digest and hide bits, and the
traffic.  That blob should be uploadable to another
Mailman instance in a way that simply re-instantiates
the list.


----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-08-06 20:02

Message:
Logged In: YES 
user_id=12800

Here's the procedure for moving a list with shell access:

http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.004.htp

As for security, should the XML output include user
passwords?   If you're exporting via the web, probably not.
 If you're exporting via the shell, probably so.  Also, not
every installation will want to allow list owners to move
their lists (e.g. python.org probably wouldn't).  If I had
to guess I'd say that if list owners can delete their lists,
they can probably move them.  See what I mean about there
being issues?

It's a good idea though so I've added it as a possible item
for MM2.2:

http://wiki.list.org/x/IQ

It probably needs more discussion on mailman-developers though.

----------------------------------------------------------------------

Comment By: Eric S. Raymond (esr)
Date: 2006-08-02 13:58

Message:
Logged In: YES 
user_id=3060

First, that "if you have shell access" is a big if.  I do
not in fact have shell access to the list server, and it's a
bad thing if the Mailman design assumes I do.

Second, AFAIK the "easy" procedure is not documented.

Third, I don't see any (additional) security implications. 
All the pieces of state are already available through the
administration interface, they're just a royal pain in the
ass to extract by hand.

Finally, you should support moveable list snapshots because
it gives Mailman users the guarantee that they can have
*all* their data back in a transparent form whenever they
need it.


----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-08-02 13:39

Message:
Logged In: YES 
user_id=12800

FWIW, It's very easy to move a list if you have shell access
to the server Mailman is running on.  There are many
security implications to allowing access to all that data
via the web.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1533331&group_id=103