A while ago I setup a fully-fledged groupware server with a combination of iRedMail and SOGo. Last week I have migrated this setup to a new server which was incredibly painless (Actually easier than I expected). Although being a personal setup I didn’t have to worry about downtimes or anything.

Here’s what I did…

Note: At this stage, this is more of a brain dump than anything else.

I tackled the migration in two separate parts – Migrating the iRedMail setup and data, then migrating the SOGo installation.

Part 1: Migrating iRedMail

Download and install iRedMail as usual (Obviously choosing the same backend, moving backends is a completely different problem).

Migrate mail accounts from LDAP:

This is the juicy part, migrating all the data (Mail accounts, aliases, all that jazz) from the old server to the new. It actually turned out to be rather simple, all I did was dump the data out of LDAP on the old server, clear out the LDAP database from the new server and import the dump.

Run backup_openldap.sh - This is located in /var/vmail/backup/backup_openldap.sh or in the tools directory of the iRedMail folder. This will dump a backup of the LDAP data and schema to /var/vmail/backup/ldap/../../*.ldif.bz2

Transfer that bz2 file the new server
Stop LDAP on the new server:

#>service slapd stop
 
 Stopping slapd:  [  OK  ]

Locate the file you copied from the old server and extract the bz2 archive. In my case I extracted it to /util/2013.06.14.10.35.16.ldif

Use slapadd to import the data into LDAP:

#>slapadd -f /etc/openldap/slapd.conf -l /util/2013.06.14.10.35.16.ldif

Start LDAP:

#>service slapd start

You may see some warnings such as:

 /var/lib/ldap/tribalchicken.net/mailForwardingAddress.bdb i[WARNING]ed by “ldap”  
  /var/lib/ldap/tribalchicken.net/shadowLastChange.bdb is not[WARNING] “ldap”  
  Starting slapd:                                            [  OK  ]

In this case, ensure you change the ownership of the slapd bdb files to your slapd user (ldap:ldap):

> chown -R ldap:ldap /var/lib/ldap/tribalchicken.net/*.bdb
> 
> Restart slapd and all should be fine.

At this stage you should be able to log into iRedAdmin with your previous admin user and see that all the data is correct.

Depending on your setup, and how much you have customised it, you may also need to copy some configuration files, such as postfix, amavisd, etc. I copied my postfix main.cf and my amavisd.conf as I had made some changes to the default.

The other thing you need to be aware of is during installation iRedMail generates a random password for the vmail and vmailadmin LDAP accounts, so things won’t quite work properly until this is fixed. To rectify this, I found the easiest way was to copy the password out of the config files and set them in LDAP.

You can find the vmail account password in /etc/dovecot/dovecot-ldap.conf and the *vmailadmin password in /var/www/iRedAdmin-/settings.ini

Migrate mailboxes

You will also want to migrate the actual mailboxes (Stored in /var/vmail) – Simply copy this directory to the same location on the new server (I bzip’d and tar’ed it first, SCP seems to work better with a single file).

Up to you if you want to copy policyd database. To do so, export the policyd database from MySQL and then import into your new server/database. I chose not to do this as my database didn’t have much (anything) in it.

I also had to copy over my certificates and private keys as I was not using self-signed certs. If you do this make sure the correct certificates are listed in the Dovecot and Apache config files.

That concludes migration of iredmail.

Part 2: Migrating SOGo

Migrating the installation of SOGo is even easier than iRedMail.

Install SOGo as usual 

Configure database as usual
Export database from old server, import on new server. For me, this was seriously just a *mysqldump *and import into the new MySQL DB:

OLD#>mysqldump -p -u root sogo > /util/migrate/sogo.sql

scp across to new server

NEW#>mysql -u root -p sogo < /util/migrate/sogo.sql

Copy across your SOGo configuration file – Depending on your version, this may be in ~sogo/GNUstep/Defaults/.GNUstepDefaults or /etc/sogo/sogo.conf. In my case it was still using the GNUstepDefaults file (Which is fine, both will work). I believe there is an easy way to migrate to the new sogo.conf but I haven’t yet looked into it.

I had customised the login image so I had to move that as well.

That’s it! Migration of SOGo is completed. After these steps I found that everything worked as expected and the same as the old server.