I have the task of setting up a replacement for an existing Mailman/Postfix server. I am new to Mailman and I am looking for some guidance in this transition. Mailman is currently being used solely as a diffusion of information. That is, it does not accept contributions from list members (read-only).
Firstly, should I attempt to migrate data/files over to the new system or should I start fresh?
The new system will be running OpenBSD 4.0.
Other comments welcome.
Peter
I have the task of setting up a replacement for an existing Mailman/Postfix server. I am new to Mailman and I am looking for some guidance in this transition. Mailman is currently being used solely as a diffusion of information. That is, it does not accept contributions from list members (read-only).
Firstly, should I attempt to migrate data/files over to the new system or should I start fresh?
The new system will be running OpenBSD 4.0.
I have just moved a 9-year-old list from another installation to mine, and have a draft how-to faq on how I did it that isn't quite ready for prime time. Since I know there isn't any clear information on this in the current mailman FAQ tree, I'll give the salient points fairly briefly. I'm sure that the Mailman developers will want to comment, so I'll let them do the talking after posting this.
It's fairly easy to do a seamless migration of an old Mailman list's personality and history into a new Mailman install. Based on a migration from Mailman 2.1.4 to 2.1.9, what you need from the old installation are:
(base directory is the old mailman tree, typically /usr/local/mailman)
- All of the files under the ./lists/<listname> directory.
- All of the files under the ./archives/private/<listname> directory.
- ./Mailman/mm_cfg.py
- Any other files in the ./archives directory with <listname> in
their names.
A tar of those directory trees plus the mm_cfg.py file gives you the old list's configuration, personality, membership data base, and archives.
On your new system, do a new installation of Mailman at the revision level that the old list was running on. I was moving from a 2.1.4 installation, and building from source, so had to get the Mailman 2.1.4 sources. Follow the instructions in the build and installation guide on the Mailman web site exactly (don't plan on just running configure and doing a make---there is a lot more you need to do).
On the fresh installation, create a new list with the same name as the one you are moving. For example, if you're moving from "waffles@wafflehaus.org," create a new "waffles" list. Use that newly-created list to check out your installation. You can add a few local list member names to convenient mail addresses on your site, and use this to check out the integration with your mailer and web server. Use the old list's mm_cfg.py as a guide in chosing what to put in your installation's mm_cfg.py.
Once you have your installation running, take a look in the ./list/<listname directory>. You'll find config.pck. Check its owner/group and permissions. Copy the old list's config.pck file into the new installation's directory and set its owner/group and permissions to match. Run the fix_url script as needed to get the correct URL for your new installation installed. If there are html files in the old list's list/<listname> directory (template file overlays), copy them over as well.
You should now be able to go to the listinfo page for the list, go into the mailman administrator options page, and review such things as the administrator/moderator addresses and settings, list mailto address, etc. Double check that the link-across URL's between pages are correct for your installation.
Populate the archives directories. I still haven't worked out the best way for doing this, but you'll need the pipermail archives directories and files, and control files that the old Mailman created. The ./bin/check_perms script will help you getting all the owner/group and permissions set properly (Mailman is quite fussy about these).
You should now have your old list completely installed on your new site. From there, you can build the current versions of Python (2.5), Mailman (2.1.9) and do an upgrade installation.
Hank
Hank van Cleef wrote:
I have just moved a 9-year-old list from another installation to mine, and have a draft how-to faq on how I did it that isn't quite ready for prime time. Since I know there isn't any clear information on this in the current mailman FAQ tree, I'll give the salient points fairly briefly. I'm sure that the Mailman developers will want to comment, so I'll let them do the talking after posting this.
I have a few initial remarks interspersed below.
It's fairly easy to do a seamless migration of an old Mailman list's personality and history into a new Mailman install. Based on a migration from Mailman 2.1.4 to 2.1.9, what you need from the old installation are:
(base directory is the old mailman tree, typically /usr/local/mailman)
- All of the files under the ./lists/<listname> directory.
- All of the files under the ./archives/private/<listname> directory.
- ./Mailman/mm_cfg.py
- Any other files in the ./archives directory with <listname> in
their names.
Depending on how you do archives, you *may* not need 2. You may just need the ./archives/private/<listname>.mbox/<listname>.mbox files.
A tar of those directory trees plus the mm_cfg.py file gives you the old list's configuration, personality, membership data base, and archives.
On your new system, do a new installation of Mailman at the revision level that the old list was running on. I was moving from a 2.1.4 installation, and building from source, so had to get the Mailman 2.1.4 sources. Follow the instructions in the build and installation guide on the Mailman web site exactly (don't plan on just running configure and doing a make---there is a lot more you need to do).
It should not be necessary to install the "same" version and then upgrade. In this example, it should be OK to just install Mailman 2.1.9 directly on the new system.
Mailman is aware enough to update a newly encountered, older version config.pck (or even config.db from 2.0.x) to the current format. A lot of what bin/update does when you update to a new release is stuff that Mailman will do on the fly when you drop an 'old' list into a working Mailman, or it is generic stuff having to do with file locations, queue entry formats and other things not directly relevant to a list.
Thus, it is normally just fine to drop a 2.1.4 config.pck into a working 2.1.9 installation.
On the fresh installation, create a new list with the same name as the one you are moving. For example, if you're moving from "waffles@wafflehaus.org," create a new "waffles" list. Use that newly-created list to check out your installation. You can add a few local list member names to convenient mail addresses on your site, and use this to check out the integration with your mailer and web server. Use the old list's mm_cfg.py as a guide in chosing what to put in your installation's mm_cfg.py.
Once you have your installation running, take a look in the ./list/<listname directory>. You'll find config.pck. Check its owner/group and permissions. Copy the old list's config.pck file into the new installation's directory and set its owner/group and permissions to match. Run the fix_url script as needed to get the correct URL for your new installation installed. If there are html files in the old list's list/<listname> directory (template file overlays), copy them over as well.
You should now be able to go to the listinfo page for the list, go into the mailman administrator options page, and review such things as the administrator/moderator addresses and settings, list mailto address, etc. Double check that the link-across URL's between pages are correct for your installation.
Populate the archives directories. I still haven't worked out the best way for doing this, but you'll need the pipermail archives directories and files, and control files that the old Mailman created. The ./bin/check_perms script will help you getting all the owner/group and permissions set properly (Mailman is quite fussy about these).
Assuming you have a complete archives/private/<listname>.mbox/<listname>.mbox from the old installation, you can completely build the pipermail archive on the new installation by the following process.
- Migrate the list and run fix_url if needed.
- Copy the archives/private/<listname>.mbox/<listname>.mbox to the new
installation. 2) Run bin/cleanarch -n < archives/private/<listname>.mbox/<listname>.mbox to help find any unescaped 'From ' lines in the .mbox file. If that finds any problems, run bin/cleanarch < archives/private/<listname>.mbox/<listname>.mbox > tmp cp tmp archives/private/<listname>.mbox/<listname>.mbox 3) Run bin/arch --wipe <listname> to build the new archive. If the .mbox is large, this may choke in which case, run for example: bin/arch --wipe --end=1000 <listname> followed by bin/arch --start=1001 --end=2000 <listname> etc.
Note --wipe on first bin/arch only. Do not try to run the above in parallel - locks will prevent it anyway.
You should now have your old list completely installed on your new site. From there, you can build the current versions of Python (2.5), Mailman (2.1.9) and do an upgrade installation.
As I indicate above, it is OK to start with an up-to-date installation and avoid the upgrade step.
On Mon, 29 Jan 2007 12:37:24 -0800 Mark Sapiro msapiro@value.net wrote:
- All of the files under the ./lists/<listname> directory.
- All of the files under the ./archives/private/<listname>
directory. 3. ./Mailman/mm_cfg.py 4. Any other files in the ./archives directory with <listname> in their names.
When doing this, does a person also tar and move the "mailman" list?
Raquel wrote:
- All of the files under the ./lists/<listname> directory.
- All of the files under the ./archives/private/<listname>
directory. 3. ./Mailman/mm_cfg.py 4. Any other files in the ./archives directory with <listname> in their names.
When doing this, does a person also tar and move the "mailman" list?
It depends. If you are moving lists to an already existing Mailman installation, that installation will already have a 'mailman' list, so it isn't necessary to move it.
If you are moving to a brand new, from source installation that has no lists yet, then move the 'mailman' list too.
In between is moving to a brand new, from a package installation. The package likely has already installed a 'mailman' list, but you might prefer the configuration of the one you already have. If so, move the old one.
On Tue, 18 Sep 2007 10:59:38 -0700 Mark Sapiro msapiro@value.net wrote:
Raquel wrote:
- All of the files under the ./lists/<listname> directory.
- All of the files under the ./archives/private/<listname>
directory. 3. ./Mailman/mm_cfg.py 4. Any other files in the ./archives directory with <listname>
in > >their names.
When doing this, does a person also tar and move the "mailman" list?
It depends. If you are moving lists to an already existing Mailman installation, that installation will already have a 'mailman' list, so it isn't necessary to move it.
If you are moving to a brand new, from source installation that has no lists yet, then move the 'mailman' list too.
In between is moving to a brand new, from a package installation. The package likely has already installed a 'mailman' list, but you might prefer the configuration of the one you already have. If so, move the old one.
-- Mark Sapiro
Thank you, Mark. You told me exactly what I needed.
On Mon, 29 Jan 2007 12:37:24 -0800 Mark Sapiro msapiro@value.net wrote:
Hank van Cleef wrote:
I have just moved a 9-year-old list from another installation to mine, and have a draft how-to faq on how I did it that isn't quite ready for prime time. Since I know there isn't any clear information on this in the current mailman FAQ tree, I'll give the salient points fairly briefly. I'm sure that the Mailman developers will want to comment, so I'll let them do the talking after posting this.
I have a few initial remarks interspersed below.
It's fairly easy to do a seamless migration of an old Mailman list's personality and history into a new Mailman install. Based on a migration from Mailman 2.1.4 to 2.1.9, what you need from the old installation are:
(base directory is the old mailman tree, typically /usr/local/mailman)
- All of the files under the ./lists/<listname> directory.
- All of the files under the ./archives/private/<listname>
directory. 3. ./Mailman/mm_cfg.py 4. Any other files in the ./archives directory with <listname> in their names.
Depending on how you do archives, you *may* not need 2. You may just need the ./archives/private/<listname>.mbox/<listname>.mbox files.
A tar of those directory trees plus the mm_cfg.py file gives you the old list's configuration, personality, membership data base, and archives.
On your new system, do a new installation of Mailman at the revision level that the old list was running on. I was moving from a 2.1.4 installation, and building from source, so had to get the Mailman 2.1.4 sources. Follow the instructions in the build and installation guide on the Mailman web site exactly (don't plan on just running configure and doing a make---there is a lot more you need to do).
It should not be necessary to install the "same" version and then upgrade. In this example, it should be OK to just install Mailman 2.1.9 directly on the new system.
Mailman is aware enough to update a newly encountered, older version config.pck (or even config.db from 2.0.x) to the current format. A lot of what bin/update does when you update to a new release is stuff that Mailman will do on the fly when you drop an 'old' list into a working Mailman, or it is generic stuff having to do with file locations, queue entry formats and other things not directly relevant to a list.
Thus, it is normally just fine to drop a 2.1.4 config.pck into a working 2.1.9 installation.
On the fresh installation, create a new list with the same name as the one you are moving. For example, if you're moving from "waffles@wafflehaus.org," create a new "waffles" list. Use that newly-created list to check out your installation. You can add a few local list member names to convenient mail addresses on your site, and use this to check out the integration with your mailer and web server. Use the old list's mm_cfg.py as a guide in chosing what to put in your installation's mm_cfg.py.
Once you have your installation running, take a look in the ./list/<listname directory>. You'll find config.pck. Check its owner/group and permissions. Copy the old list's config.pck file into the new installation's directory and set its owner/group and permissions to match. Run the fix_url script as needed to get the correct URL for your new installation installed. If there are html files in the old list's list/<listname> directory (template file overlays), copy them over as well.
You should now be able to go to the listinfo page for the list, go into the mailman administrator options page, and review such things as the administrator/moderator addresses and settings, list mailto address, etc. Double check that the link-across URL's between pages are correct for your installation.
Populate the archives directories. I still haven't worked out the best way for doing this, but you'll need the pipermail archives directories and files, and control files that the old Mailman created. The ./bin/check_perms script will help you getting all the owner/group and permissions set properly (Mailman is quite fussy about these).
Assuming you have a complete archives/private/<listname>.mbox/<listname>.mbox from the old installation, you can completely build the pipermail archive on the new installation by the following process.
- Migrate the list and run fix_url if needed.
- Copy the archives/private/<listname>.mbox/<listname>.mbox to
the new installation. 2) Run bin/cleanarch -n < archives/private/<listname>.mbox/<listname>.mbox to help find any unescaped 'From ' lines in the .mbox file. If that finds any problems, run bin/cleanarch < archives/private/<listname>.mbox/<listname>.mbox tmp cp tmp archives/private/<listname>.mbox/<listname>.mbox 3) Run bin/arch --wipe <listname> to build the new archive. If the .mbox is large, this may choke in which case, run for example: bin/arch --wipe --end=1000 <listname> followed by bin/arch --start=1001 --end=2000 <listname> etc.
Note --wipe on first bin/arch only. Do not try to run the above in parallel - locks will prevent it anyway.
You should now have your old list completely installed on your new site. From there, you can build the current versions of Python (2.5), Mailman (2.1.9) and do an upgrade installation.
As I indicate above, it is OK to start with an up-to-date installation and avoid the upgrade step.
-- Mark Sapiro
Just to let everyone know ... I moved some lists from an old server to a new server using the above. It worked very well, except for a few things I had to clean up under sendmail. Thank you for the good map to follow!
participants (4)
-
Mark Sapiro -
Peter Matulis -
Raquel -
vancleef＠lostwells.net