Changing Distribution

This article describes how to change the distribution BlueMind works on. It can be used to update the distribution (Ubuntu 16.04 to Ubuntu 18.04 for instance).

This procedure is based on installing a target system to which the data is migrated. This new system will then replace the original one at the network level.

Installation prerequisites

Installing and configuring BlueMind

• Install a version of BlueMind on the target system that is identical to the one on the source system; for example, if the source system is running BlueMind 4.8.23, the target system must also be running BlueMind 4.8.23
• Save the database password: The database password is automatically generated during BlueMind installation and stored in the /etc/bm/bm.ini file; however, this file will be overwritten during data synchronization, so it is important to copy and save the target server’s database password before proceeding with the migration.
• Play the installation wizard (or setup wizard) on the target server.
• Install on the target server all plugins used on the source server (LDAP import, company signatures...)
• Configure the target server's external URL: if the original external URL is bluemind.domain.tld, the target system's BlueMind must be configured with bluemind.domain.tld.
• Install a subscription valid for this OS.
  *Note: In this case, it is possible to reuse the same subscription, with the new server replacing the old one.
• The root user on the target server must be able to authenticate as root on the origin server, ideally using key authentication.

System

• The rsync utility must be installed on both systems.
• Stop the following services if necessary:
  • firewalld
  • PostgreSQL

RedHat

For RedHat servers :

• ajouter les rpms adaptés à la version
  Exemple pour la version 8 :

  dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
  dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm

• Disable Getenforce:

  sed -i s/=enforcing/=disabled/ /etc/selinux/config

Migration

Data migration is done in three steps to minimize service downtime:

1. hot synchronization of server data to the target server - this is a time-consuming operation but does not cause service interruption
2. cold synchronization - quick operation but causes service interruption
3. switching servers

Hot synchronization

Allows you to make an initial copy of data without interrupting the service:

1. Connect as root on the target server: su -
2. Stop services on it:

bmctl stop
systemctl stop postfix.service

3. Synchronize BlueMind data using the rsync utility:

rsync -avH --delete root@origsrv.domain.tld:/var/spool/cyrus/ /var/spool/cyrus/
rsync -avH --delete root@origsrv.domain.tld:/var/lib/cyrus/ /var/lib/cyrus/
rsync -avH --delete root@origsrv.domain.tld:/var/spool/bm-hsm/ /var/spool/bm-hsm/
rsync -avH --delete root@origsrv.domain.tld:/var/spool/sieve/ /var/spool/sieve/
rsync -avH --delete root@origsrv.domain.tld:/var/spool/bm-elasticsearch/ /var/spool/bm-elasticsearch/
rsync -avH --delete root@origsrv.domain.tld:/var/spool/bm-docs/ /var/spool/bm-docs/
rsync -avH --delete root@origsrv.domain.tld:/var/spool/bm-filehosting/ /var/spool/bm-filehosting/

These operations can be interrupted and/or performed several times.

:::info Synchronization frequency

To minimize downtime during synchronization, It is recommended to perform hot synchronization as often as possible. This allows to limit the volume of data to be transmitted between the two machines.

The shorter the time between hot synchronization and cold synchronization, the faster cold synchronization will be.

:::

Cold synchronization

1. Stop services on origin and target servers:

bmctl stop
systemctl stop postfix.service

2. From the target server, perform a new data synchronization:

rsync -avH --delete root@origsrv.domain.tld:/var/spool/cyrus/ /var/spool/cyrus/
rsync -avH --delete root@origsrv.domain.tld:/var/lib/cyrus/ /var/lib/cyrus/
rsync -avH --delete root@origsrv.domain.tld:/var/spool/bm-hsm/ /var/spool/bm-hsm/
rsync -avH --delete root@origsrv.domain.tld:/var/spool/sieve/ /var/spool/sieve/
rsync -avH --delete root@origsrv.domain.tld:/var/spool/bm-elasticsearch/ /var/spool/bm-elasticsearch/
rsync -avH --delete root@origsrv.domain.tld:/var/spool/bm-docs/ /var/spool/bm-docs/
rsync -avH --delete root@origsrv.domain.tld:/var/spool/bm-filehosting/ /var/spool/bm-filehosting/

3. From the target server, restart the PostgreSQL of the original server:

ssh root@origsrv.domain.tld "systemctl start postgresql.service"

4. From the target server, perform a database dump of the original server:

ssh root@origsrv.domain.tld "PGPASSWORD=bj pg_dump --format=c --username=bj --host localhost bj" > /tmp/dump-bj.sql
ssh root@origsrv.domain.tld "PGPASSWORD=bj pg_dump --format=c --username=bj --host localhost bj-data" > /tmp/dump-bj-data.sql

5. From the target server, copy the files from the original server:

rsync -av -r root@origsrv.domain.tld:/etc/bm/ /etc/bm
rsync -av -r root@origsrv.domain.tld:/etc/nginx/sw.htpasswd /etc/nginx/sw.htpasswd
rsync -av -r root@origsrv.domain.tld:/etc/bm-hps/ /etc/bm-hps
rsync -av -r root@origsrv.domain.tld:/etc/ssl/certs/bm_cert*.pem /etc/ssl/certs
rsync -av -r root@origsrv.domain.tld:/var/lib/bm-ca/ /var/lib/bm-ca
rsync -av -r root@origsrv.domain.tld:/usr/share/bm-elasticsearch/config/elasticsearch.yml /usr/share/bm-elasticsearch/config/elasticsearch.yml
rsync -av -r root@origsrv.domain.tld:/etc/imapd* /etc/
rsync -av -r root@origsrv.domain.tld:/etc/cyrus* /etc/
rsync -av -r root@origsrv.domain.tld:/etc/bm-webmail/ /etc/bm-webmail/
rsync -av -r root@origsrv.domain.tld:/etc/postfix/main.cf /etc/postfix/main.cf
rsync -av -r root@origsrv.domain.tld:/etc/postfix/master.cf /etc/postfix/master.cf
rsync -av -r root@origsrv.domain.tld:/etc/postfix/master_relay_transport-flat /etc/postfix/master_relay_transport-flat
rsync -av -r root@origsrv.domain.tld:/etc/postfix/master_relay_transport.db /etc/postfix/master_relay_transport.db
rsync -av -r root@origsrv.domain.tld:/etc/postfix/transport-flat /etc/postfix/transport-flat
rsync -av -r root@origsrv.domain.tld:/etc/postfix/transport.db /etc/postfix/transport.db
rsync -av -r root@origsrv.domain.tld:/etc/postfix/virtual_alias-flat /etc/postfix/virtual_alias-flat
rsync -av -r root@origsrv.domain.tld:/etc/postfix/virtual_alias.db /etc/postfix/virtual_alias.db
rsync -av -r root@origsrv.domain.tld:/etc/postfix/virtual_domains-flat /etc/postfix/virtual_domains-flat
rsync -av -r root@origsrv.domain.tld:/etc/postfix/virtual_domains.db /etc/postfix/virtual_domains.db
rsync -av -r root@origsrv.domain.tld:/etc/postfix/virtual_mailbox-flat /etc/postfix/virtual_mailbox-flat
rsync -av -r root@origsrv.domain.tld:/etc/postfix/virtual_mailbox.db /etc/postfix/virtual_mailbox.db

6. From the target server, restart PostgreSQL:

systemctl start postgresql.service

7. Re-mount the database on the target server:

chown postgres:postgres /tmp/dump*
su - postgres
  dropdb bj
  dropdb bj-data
  createdb bj
  createdb bj-data
  pg_restore -C -d bj /tmp/dump-bj.sql
  pg_restore -C -d bj-data /tmp/dump-bj-data.sql

Switching servers

1. Stop the original server
2. Reconfigure the target server's bm.ini file to assign it the IP address of the original server (see Changing a BlueMind Server's IP Address)
3. Restart the target server and connect to the network instead of the original server so that it can be reached instead of the original server

Post-migration

Log into the BlueMind Administration console as admin0@global.virt and:

1. Go to the section Security > Firewall and immediately click "Save" to force the BlueMind firewall's rules regeneration
2. Go to System Management > Manage messaging system, click "Run" to regenerate the mail postfix routing tables
3. Go to System Management > System Configuration and replace the old IP address in the "My Networks" field by the new address or the address range for which you want the relay open and click "Save"