I have a bunch of lists that resides on an old 2.1.2 installation.. I want to move these to a newer machine with Mailman v2.1.7. I'd like to move both lists and archives.
On the mailman web site, a script called "move_list" is mentioned, but that script doesn't exist on any of my systems...
Tips and hints are welcome!
Anders Norrbring Norrbring Consulting
Anders Norrbring wrote:
I have a bunch of lists that resides on an old 2.1.2 installation.. I want to move these to a newer machine with Mailman v2.1.7. I'd like to move both lists and archives.
On the mailman web site, a script called "move_list" is mentioned, but that script doesn't exist on any of my systems...
The move_list script was for Mailman 2.0.x. It is not in Mailman 2.1.x.
The process is fairly straightforward, but it is complicated a bit if the domain names for web access and/or email are different on the new machine. There are many discussions of this in the archives of this list and there is a FAQ at <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.004.htp> but it too is out of date.
The basic procedure assuming domain names change is the following:
- move the lists/listname/ directory and contents for each list.
- move the archives/private/listname.mbox/ directory and archives/private/listname.mbox/listname.mbox file for each list.
- run fix_url on each list to update its host_name and hidden web_page_url attributes. fix_url runs under bin/withlist. Run bin/fix_url.py for instructions.
- run bin/arch on each list to build the archives with correct links to the listinfo page.
If domain names don't change, you can skip steps 3 and 4 and add to step 2 - move the archives/private/listname directory and it's contents for each list. You don't need to move the archives/public stuff as it is checked and created/deleted as necessary each time the list is accessed.
Mailman will automatically update the list data as needed from 2.1.2 to 2.1.7 when the list is accessed.
The above assumes there aren't held messages. If there are, they should be dealt with on the old machine before the move. Also, if there is the possibility of incoming posts during the move, it is a good idea to stop the MTAs to keep things from hitting Mailman during the move.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks Mark, A very easy to go by description! I was thinking in these lines, but wanted to check first.
Again, thanks. Anders.
Mark Sapiro skrev:
Anders Norrbring wrote:
I have a bunch of lists that resides on an old 2.1.2 installation.. I want to move these to a newer machine with Mailman v2.1.7. I'd like to move both lists and archives.
On the mailman web site, a script called "move_list" is mentioned, but that script doesn't exist on any of my systems...
The move_list script was for Mailman 2.0.x. It is not in Mailman 2.1.x.
The process is fairly straightforward, but it is complicated a bit if the domain names for web access and/or email are different on the new machine. There are many discussions of this in the archives of this list and there is a FAQ at <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.004.htp> but it too is out of date.
The basic procedure assuming domain names change is the following:
- move the lists/listname/ directory and contents for each list.
- move the archives/private/listname.mbox/ directory and archives/private/listname.mbox/listname.mbox file for each list.
- run fix_url on each list to update its host_name and hidden web_page_url attributes. fix_url runs under bin/withlist. Run bin/fix_url.py for instructions.
- run bin/arch on each list to build the archives with correct links to the listinfo page.
If domain names don't change, you can skip steps 3 and 4 and add to step 2 - move the archives/private/listname directory and it's contents for each list. You don't need to move the archives/public stuff as it is checked and created/deleted as necessary each time the list is accessed.
Mailman will automatically update the list data as needed from 2.1.2 to 2.1.7 when the list is accessed.
The above assumes there aren't held messages. If there are, they should be dealt with on the old machine before the move. Also, if there is the possibility of incoming posts during the move, it is a good idea to stop the MTAs to keep things from hitting Mailman during the move.
At 4:05 PM +0100 10/29/06, Anders Norrbring wrote:
I have a bunch of lists that resides on an old 2.1.2 installation. I want to move these to a newer machine with Mailman v2.1.7.
Keep in mind that 2.1.7 has been superceded by 2.1.8 and now 2.1.9. I believe that there may be some serious security issues with the older code, and would recommend that you upgrade to the current version as opposed to 2.1.7.
The upgrade steps should be the same, the only thing that will differ is the version of Mailman.
-- Brad Knowles, <brad@shub-internet.org>
Trend Micro has announced that they will cancel the stop.mail-abuse.org mail forwarding service as of 15 November 2006. If you have an old e-mail account for me at this domain, please make sure you correct that with the current address.
Brad Knowles skrev:
At 4:05 PM +0100 10/29/06, Anders Norrbring wrote:
I have a bunch of lists that resides on an old 2.1.2 installation. I want to move these to a newer machine with Mailman v2.1.7.
Keep in mind that 2.1.7 has been superceded by 2.1.8 and now 2.1.9. I believe that there may be some serious security issues with the older code, and would recommend that you upgrade to the current version as opposed to 2.1.7.
The upgrade steps should be the same, the only thing that will differ is the version of Mailman.
Yeah.. I'll do a RPM build for SUSE on the latest version as soon as I can find the time. The thing I was a bit concerned about was the move from one machine to the other. Seemed to work fine though..
Except that the e-mail footers still shows the old web page link.. I haven't been digging into it yet though.
--
Anders Norrbring Norrbring Consulting
Anders Norrbring wrote:
Yeah.. I'll do a RPM build for SUSE on the latest version as soon as I can find the time. The thing I was a bit concerned about was the move from one machine to the other. Seemed to work fine though..
Maybe I'm old fashioned, but building from source can sometimes be a good way to go here. It's not very hard, and you learn more about the package you're building. This can help a lot of something goes wrong because then you don't see the program as a closed box. Plus, with complicated programs, when you build them yourself, you know exactly what options you use, which you can then document for your group. Once you've done this, then it makes moving to other machines, and maybe other distributions, easier.
I know this isn't the way some people like to operate, and I often debate this with people I work with, but this approach has worked well for me, including my recent installation of Mailman.
Cordially,
Jon Forrest forrest@ce.berkeley.edu Computer Resources Manager Civil and Environmental Engineering Dept. 305 Davis Hall Univ. of Calif., Berkeley Berkeley, CA 94720-1710 510-642-0904
In a flurry of recycled electrons, Jon Forrest wrote:
Maybe I'm old fashioned, but building from source can sometimes be a good way to go here. It's not very hard, and you learn more about the package you're building. This can help a lot of something goes wrong because then you don't see the program as a closed box.
I suppose that I'm also rather 'old-fashioned" in that my preferred installation is from source, followed by using bsd ports. I've always found that using RPMs annoyed me. Either I have to go back and add missing dependancies, I don't know where things are installed, or the build options are wrong. (Even on linux, I try to use original sources, not SRPMs.)
And as Jon said, you can learn quite a bit about what you're installing just by installing it. I mean, how many people that install from RPMs even know that there might be a README file to read, let along to and find it?
You could try installing freebsd instead of linux. Once the base OS is installed, doing postfix (or exim) and mailman is quite easy.
z!
At 8:56 AM -0800 10/30/06, Carl Zwanzig wrote:
I suppose that I'm also rather 'old-fashioned" in that my preferred installation is from source, followed by using bsd ports.
Of course, I prefer installing from source, too. Especially when it comes to things like Mailman. The irony here is that for the NTP Public Services project, when I initially installed Mailman so that I could switch over from Majordomo (like, four or five years ago), I used the BSD port system. So, when it came time to do the upgrade to 2.1.9, I ended up using the BSD port system once again.
You could try installing freebsd instead of linux. Once the base OS is installed, doing postfix (or exim) and mailman is quite easy.
I've gotten to the point where I no longer talk to people about switching OSes. I may talk about the superiority of using BSD filesystems with Soft Updates for mail-related applications, and if people are curious then I'll be able to talk about that in more depth.
But otherwise I've gotten to the point where I figure that most people aren't going to switch OSes just because I suggest it, and that my doing so just annoys them and doesn't have any positive impact.
-- Brad Knowles, <brad@shub-internet.org>
Trend Micro has announced that they will cancel the stop.mail-abuse.org mail forwarding service as of 15 November 2006. If you have an old e-mail account for me at this domain, please make sure you correct that with the current address.
Carl Zwanzig writes:
I suppose that I'm also rather 'old-fashioned" in that my preferred installation is from source,
When was the last time you installed a BIOS from source?<wink> At some level everybody has to trust their system from that level on down, until it proves itself buggy. I don't think choice of that level is a matter of fashion; pros will be sharpening their own tools, hobbyists go to Sears and buy them off the shelf.
And as Jon said, you can learn quite a bit about what you're installing just by installing it.
Sure. I can't blame people who don't though. As a general principle, it's all too often the case that all you gain is a knowledge of pain. I wouldn't impose installing most GNOME apps from source on my worst enemy.
In the case of Mailman, the defaults *don't* suck and the batteries *are* included, it's definitely worth the small amount of extra time spent.
I mean, how many people that install from RPMs even know that there might be a README file to read, let along to and find it?
This is something that has peeved me for a decade. Installers for commercial software usually offer you the README after installation. Why don't pkgsrc and dpkg and rpm and portage and MacPorts do that?
(Yes, I suggested that to the dselect maintainer, way back when. I guess I should do it again, now that debconf actually works---it should be possible to adapt similar techniques.)
stephen@xemacs.org wrote:
Carl Zwanzig writes:
I mean, how many people that install from RPMs even know that there might be a README file to read, let along to and find it?
This is something that has peeved me for a decade. Installers for commercial software usually offer you the README after installation. Why don't pkgsrc and dpkg and rpm and portage and MacPorts do that?
If rpm asked me if I wanted to read the README every time I installed a package, I'd claw my eyes out. rpm has always worked in a fully automated fashion, i.e. no prompting for EULAs, etc.
"rpm -qld mailman" tells me where all the docs are, thankyouverymuch. ;-)
-- Dan Young <dyoung@mesd.k12.or.us> Multnomah ESD - Technology Services 503-257-1562
Jon Forrest skrev:
Anders Norrbring wrote:
Yeah.. I'll do a RPM build for SUSE on the latest version as soon as I can find the time. The thing I was a bit concerned about was the move from one machine to the other. Seemed to work fine though..
Maybe I'm old fashioned, but building from source can sometimes be a good way to go here. It's not very hard, and you learn more about the package you're building. This can help a lot of something goes wrong because then you don't see the program as a closed box. Plus, with complicated programs, when you build them yourself, you know exactly what options you use, which you can then document for your group. Once you've done this, then it makes moving to other machines, and maybe other distributions, easier.
I know this isn't the way some people like to operate, and I often debate this with people I work with, but this approach has worked well for me, including my recent installation of Mailman.
Cordially,
Well Jon, I do the builds, then I install them.. :) SUSE doesn't provide latest-version packages, therefore I create them myself, and put them online for others to use if they want.
--
Anders Norrbring Norrbring Consulting
participants (7)
-
Anders Norrbring -
Brad Knowles -
cpz＠tuunq.com -
Dan Young -
Jon Forrest -
Mark Sapiro -
stephen＠xemacs.org