Skip to main content

Changing Distribution

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

This procedure is based on installing a target system to which the data is migrated. This new system will then take the place of the first, at network level.

Prerequisites​

Installing and configuring BlueMind​

  • Install a BlueMind version identical to the original system on the target system: if the original system uses BlueMind 5.0.x, the target system must have BlueMind 5.0.x.

    ⚠️ Database password
    The database password is automatically generated when BlueMind is installed and written to the /etc/bm/bm.ini file. This file will be overwritten by data synchronization ⇒ copy and save database password before proceeding with migration operations.

  • Play the installation wizard (or the 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. For further information see the page Configuring external URLs and autodiscover.
  • Run Setting up the subscription, which must be 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.
  • The rsync utility must be installed on both systems.

System​

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

RedHat​

For RedHat servers :

  • add rpms adapted to the version
    Example for 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

Data Migration​

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

  1. Hot synchronization of data from the source server to the target server - time-consuming operation, but does not cause downtime
  2. Cold synchronization - fast operation, but causes a service interruption
  3. Replacing Servers

Hot synchronization​

This synchronization allows you to make the initial copy of data without interruption of the service.

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.

Procedure:

  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/bm-hsm/ /var/spool/bm-hsm/
    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/
    rsync -avH --delete root@origsrv.domain.tld:/var/spool/cyrus/ /var/spool/cyrus/

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

Cold synchronization​

Service cutout

Caution: these operations momentarily cut off access to BlueMind and may disconnect users, who may then lose their work in progress. They must therefore be carried out at a time when there is no risk of impacting users.

Procedure:

  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/spool/bm-hsm/ /var/spool/bm-hsm/
    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
    ssh root@origsrv.domain.tld "PGPASSWORD=bj pg_dump --format=c --username=bj --host localhost keycloak" > /tmp/dump-keycloak.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 root@origsrv.domain.tld:/etc/nginx/sw.htpasswd /etc/nginx/sw.htpasswd
    rsync -av 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 root@origsrv.domain.tld:/usr/share/bm-elasticsearch/config/elasticsearch.yml /usr/share/bm-elasticsearch/config/elasticsearch.yml
    rsync -av root@origsrv.domain.tld:/etc/postfix/main.cf /etc/postfix/main.cf
    rsync -av root@origsrv.domain.tld:/etc/postfix/master.cf /etc/postfix/master.cf
    rsync -av root@origsrv.domain.tld:/etc/postfix/master_relay_transport-flat /etc/postfix/master_relay_transport-flat
    rsync -av root@origsrv.domain.tld:/etc/postfix/master_relay_transport.db /etc/postfix/master_relay_transport.db
    rsync -av root@origsrv.domain.tld:/etc/postfix/transport-flat /etc/postfix/transport-flat
    rsync -av root@origsrv.domain.tld:/etc/postfix/transport.db /etc/postfix/transport.db
    rsync -av root@origsrv.domain.tld:/etc/postfix/virtual_alias-flat /etc/postfix/virtual_alias-flat
    rsync -av root@origsrv.domain.tld:/etc/postfix/virtual_alias.db /etc/postfix/virtual_alias.db
    rsync -av root@origsrv.domain.tld:/etc/postfix/virtual_domains-flat /etc/postfix/virtual_domains-flat
    rsync -av root@origsrv.domain.tld:/etc/postfix/virtual_domains.db /etc/postfix/virtual_domains.db
    rsync -av root@origsrv.domain.tld:/etc/postfix/virtual_mailbox-flat /etc/postfix/virtual_mailbox-flat
    rsync -av 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
    dropdb keycloak
    createdb bj
    createdb bj-data
    createdb keycloak
    pg_restore -d bj /tmp/dump-bj.sql
    pg_restore -d bj-data /tmp/dump-bj-data.sql
    pg_restore -d keycloak /tmp/dump-keycloak.sql
    exit

    💡 Database password
    In the event that the database password has not been saved (see Prerequisites, or for any other reason, it is possible at this stage to update the database password on the target server so that it is identical to that on the source server:

    su - postgres
    psql -d bj
    ALTER ROLE bj WITH PASSWORD '<mot_de_passe>';
    \q
    exit

    Then restart BlueMind:

    bmctl restart
  8. Start the automatic reconfiguration of Keycloak on the target server: 
    bm-cli auth reconfigure

Switching servers​

Procedure:

  1. Stop the original server
  2. Reconfigure the target server's bm.ini file to assign the origin server's IP address (see Changing BlueMind server 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

System reconfiguration​

Manually​

  1. Reconfiguring the firewall: 
    sed -i "s/${old_ip}/${new_ip}/g" /etc/init.d/bm-iptables
    systemctl restart bm-iptables.service
  2. Reconfiguring postfix: 
    sed -i "s/${old_ip}/${new_ip}/g" /etc/postfix/main.cf /etc/postfix/transport-flat
    postmap /etc/postfix/transport-flat
    mv /etc/postfix/transport-flat.db /etc/postfix/transport.db
  3. Reconfigure the bm-tick supervision tool: 
    kapacitor list tasks | awk '{print $1}' | grep -v ID | xargs -I {} kapacitor delete tasks {}
    bm-cli tick reconfigure

Via AdminConsole​

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

  1. Go to Security > Manage Firewall and immediately click on the "Save" button to force the regeneration of BlueMind firewall rules
  2. Go to System management > Manage messaging system, click on the "Run" button to re-generate the Postfix mail 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"
  4. Reconfigure the bm-tick supervision tool: 
    kapacitor list tasks | awk '{print $1}' | grep -v ID | xargs -I {} kapacitor delete tasks {}
    bm-cli tick reconfigure

Find out more​

Related BlueMind documentation pages

Last updated on