I had to migrate a sympa installation from one domain to another. The sympa manual is certainly not of a much help. After a bit of trial and error this is my recipe.

A small warning: keep your backup available at all times. This procedure works with grep, sed and friends and it is not certainly fool proof.

• Switch off your MTA and sympa daemon. From this moment on, you will have about 12h to finish your migration. After this time, you might start to loose incoming emails.

• Dump the sql database. With mysql you can use mysqldump to obtain a copy of you db. Since the sympa daemon if off, it should be safe to perform a hot dump.

olddomain# mysqldump sympa > sympa.sql

• Make a backup of your archives. On debian everything you need should be in /var/lib/sympa. Moreover you should remember to make a backup copy of /etc/sympa.

olddomain# tar zcvf sympa.tgz /var/lib/sympa

• If you are migrating sympa to a different machine, this is a good time to copy everything there, configure the MTA to accept messages for the new domain. Since nobody knows about this new domain yet (you should give yourself a bit of time to test it !), you can switch on the MTA and sympa.

• Now it’s time to recreate the sympa db. But before that, you need to do a bit of sed magic in the db dump file. The problem here is that the domain of all your mailing lists is in the database. If you are using a domain for your lists, then it should be easy.

newdomain# cat dump | sed -i 's/sympa.olddomain.org/sympa.newdomain.org/g' > dump.new

• Ok then. We are ready to load the new dump in the db and start the sql server. Remeber also to change the domain in the configuration files in the /etc/sympa directory. If everything goes according to plans, you should be able to see the list of all you mailing lists.

newdomain# mysql sympa < dump.new

• Almost done. We need to fix the config files for each list. This should do :

for i in `find -name config` ; do cp $i /var/lib/sympa/expl/sympa.newdomain.org/$i.sed ; done

for i in `find -name config` ; do sed 's/sympa\.olddomain\.org/sympa\.newdomain\.org/' < $i.sed > $i ; done

• What is left to do it to recreate the archives. Sympa can recreate the entire web archives from the mailing lists row mboxes. To make this work, you need to change the name of all directories in /var/lib/wwsarchive. What I’ve done is something like:

newdomain# cd /var/lib/wwsarchive
newdomain# for i in `ls` ; do mv $i ${i/@sympa.olddomain.org/@sympa.newdomain.org} ; done

• Now go to the admin interface of sympa and ask for a complete rebuild of the web archives. This should schedule the rebuild. You can check the sympa logs to make sure the procedure worked. In a few minutes, depending on the size of you archives, you should be able to access your web archives.

• Now it’s time to add a rewrite or redirect in you old MTA to send all emails for you old domain, to the new domain. Then you should restart the old MTA, and see all the email flowing to the new sympa daemon. In order to completely remove the old domain, you should add a permanent error sometimes in the future.

NOTA (molto) BENE

I still think that sympa is a bloated and badly written piece of software. It is developed and sponsored by a consortium of French universities. If you want an efficient and manageable mailing list manager you should look somewhere else.

Update

Just for comparison… today I migrated a mailman installation to a new server. Well, the gist is (more or less) tar zcvf mailman.tgz /var/lib/mailman && scp mailman.tgz newhost: && cd /var/lib && tar zxvf mailman.tgz . Configure/Start mailman. The rest is history.

Ahhh if you change domain, there is a nice script called fix_url in the mailman directory. To easy to beat a dead horse, isn’t ?

Last week I took over the task of migrating sympa from a vserver machine to a xen vm. In the process I upgraded the sympa version and changed the MTA, from sendmail (ahhhhhhhhhh) to postfix. In my opinion sympa is designed to do far too many things just to be a mailing list manager. In particular, it has its own mail spool, it organizes mail delivering (via the MTA) and bounces.

Because of this design, the easiest way to configure it to work with postfix is to use it as a transport and let it do whatever … The problem with this configuration is that postfix doesn’t have any mean to know, for a give domain, which user (mailing list) is legal and which one is not. To get around this problem, one solution is to remove the local recipient check setting local_recipient_maps to empty. However this way, postfix will accept all emails, and subsequently generate a bounce if the local user doesn’t really exists. This can be used my spammers and it’s a very bad idea. The postfix manual explains this very well is bold.

To get around this problem, my simple solution then is to generate a postfix map to give back to postifx a bit more of control over this business.

Now, my local_recipient_maps looks like:

local_recipient_maps = $alias_maps, hash:/etc/postfix/sympa-recipients

and this is a small script I run every now and then to re-generate the hash table.

#!/bin/sh

for i in `ls /var/lib/sympa/expl/sympa.pps.jussieu.fr`; do 
    echo "$i unsed"; 
done > /etc/postfix/sympa-recipients
postmap /etc/postfix/sympa-recipients

/etc/init.d/postfix reload

for reference, this is the error you would get without local_recipient_maps.

sympa postfix / smtpd [12345]: NOQUEUE: reject: RCPT from xxxxxxxxxxx[xxx.xxx.xxx.xxx]: 550 5.1.1 test123@sympa.xxxx.org: Recipi ent address rejected: User unknown in local recipient table; from=me@ ex.org to=test123@sympa.xxxx.org proto=ESMTP helo=

Today I wrote a small script to allow mrbs [1] to authenticate with the sympa[2] database. mrbs has a nice feature to use an external command to do authentication. This is a simple script that query the sympa db.

#! /usr/bin/perl
use lib '/usr/lib/sympa/bin';
use wwslib;

unless (require Crypt::CipherSaber) {
    die "Crypt::CipherSaber not installed ; cannot crypt passwords";
}

require 'tools.pl';

use List;

## Load sympa config
&Conf::load('/etc/sympa/sympa.conf') || die 'config_error';
chdir $Conf::Conf{'home'};

($email,$password) = ($ARGV[0],$ARGV[1]);

&List::db_connect() || die "Can't connect to database";
my $dbh = &List::db_get_handler();
my $sql = "SELECT password_user FROM user_table WHERE email_user = '$email'";
my $sth =  $dbh->prepare($sql) || die "Can't prepare SQL statement";
$sth->execute || die "Unable to execute SQL statement";

my $user = $sth->fetchrow_hashref;

$sth->finish();
&List::db_disconnect();

my $dbpass = &tools::decrypt_password($user->{'password_user'});

if ($dbpass eq $password) {
        print "auth succeeded\n";
        exit;
} else {
        print "auth failed\n";
        exit(1);
}

and this is the snippet to add in the mrbs config file. Of course is necessary to configure sudo.

# 'auth_ext' configuration settings
$auth["prog"]   = "sudo -u sympa /usr/local/bin/sympa_pass.pl";
$auth["params"] = "#USERNAME# #PASSWORD#";

Working on this small script I discovered that sympa doesn’t really encrypt passwords, but use this ciphersaber perl library to do a strange base64 encoding of the password. For me this is particularly brain-dead as it add nothing to security and make the tool less interoperable.

If you want to decrypt all sympa password in db db, you just need to use the function below:

&tools::decrypt_password($user->{'password_user'});

[1] http://mrbs.sourceforge.net/ [2] http://www.sympa.org/