Changer de distribution
Cette documentation décrit la façon de changer la distribution sur laquelle fonctionne BlueMind. Elle peut être utilisée pour mettre à jour la distribution (Ubuntu 20.04 vers Ubuntu 22.04 par exemple).
Cette procédure est basée sur l'installation d'un système cible sur lequel les données seront migrées. Ce nouveau système prendra ensuite la place du premier, au niveau réseau.
Pré-requis
Installation et configuration de BlueMind
- Installer sur le système cible un BlueMind en version identique au système d'origine : si le système d'origine utilise BlueMind 5.0.x, le système cible doit avoir un BlueMind 5.0.x
⚠️ Mot de passe de la base de données
Le mot de passe de la base de données est généré automatiquement lors de l'installation de BlueMind et inscrit dans le fichier/etc/bm/bm.ini. Ce fichier sera écrasé par la synchronisation des données ⇒ copier et sauvegarder le mot de passe de la base de données avant de passer aux opérations de migration. - Jouer l'installation wizard (ou le setup wizard) sur le serveur cible.
- Installer sur le serveur cible l'ensemble des plugins utilisés sur le serveur source (import LDAP, signatures d'entreprise...)
- Configurer l'URL externe du serveur cible : si l'URL externe d'origine est
bluemind.domain.tld, le BlueMind du système cible doit être configuré avecbluemind.domain.tld. - Lancer la Mise en œuvre de la souscription, qui doit être valide pour cet OS.
NB : Dans ce cas précis, il est possible de réutiliser la même souscription, le nouveau serveur venant remplacer l'ancien. - L'utilisateur
rootdu serveur cible doit pouvoir s'authentifier en tant querootsur le serveur d'origine, idéalement en authentification par clé. - L'utilitaire
rsyncdoit-être installé sur les 2 systèmes.
Système
- L'utilitaire
rsyncdoit-être installé sur les 2 systèmes. - Arrêtez les services suivants s'il y a lieu :
- firewalld
- PostgreSQL
RedHat
Pour les serveurs Red Hat :
- 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 - Désactiver Getenforce :
sed -i s/=enforcing/=disabled/ /etc/selinux/config
Migration des données
La migration des données se passe en 3 temps afin de minimiser l'indisponibilité du service :
- Synchronisation à chaud des données du serveur source vers le serveur cible - opération longue, mais ne provoquant pas de coupure de service
- Synchronisation à froid - opération rapide, mais provoquant une coupure de service
- Remplacement des serveurs
Synchronisation à chaud
Cette synchronisation permet de faire la copie initiale des données sans coupure du service.
Pour l'effectuer :
- Se connecter en tant que
rootsur le serveur cible :su - - Stopper les services sur celui-ci :
bmctl stop
systemctl stop postfix.service - Synchroniser les données de BlueMind via l'utilitaire rsync :
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/
Ces opérations peuvent-être interrompues et/ou réalisées plusieurs fois.
Fréquence de synchronisation
Pour minimiser le temps de coupure de service lors de la synchronisation à froid, il est recommandé d'effectuer les synchronisations à chaud le plus fréquemment possible. Cela permet de limiter la volumétrie de données à transférer entre les deux machines.
Plus le temps entre la synchronisation à chaud et la synchronisation à froid est court, plus la synchronisation à froid sera rapide.
Synchronisation à froid
- Stopper les services sur les serveurs d'origine et cible :
bmctl stop
systemctl stop postfix.service - Depuis le serveur cible, refaire une synchronisation des données :
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/ - Depuis le serveur cible, réaliser un démarrage de PostgreSQL du serveur d'origine :
ssh root@origsrv.domain.tld "systemctl start postgresql.service" - Depuis le serveur cible, réaliser un dump de la base de données du serveur d'origine :
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 - Depuis le serveur cible, copier les fichiers du serveur d'origine :
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 - Depuis le serveur cible, réaliser un démarrage de PostgreSQL :
systemctl start postgresql.service - Monter à nouveau la base de données sur le serveur cible :
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💡 Mot de passe de la base de données
Dans le cas où le mot de passe de la base de données n'aurait pas été sauvegardé (voir Prérequis), ou pour toute autre raison, il est possible à cette étape de mettre à jour le mot de passe de la base de données du serveur cible pour qu'il soit identique à celui du serveur source :su - postgres
psql -d bj
ALTER ROLE bj WITH PASSWORD '<mot_de_passe>';
\q
exitRedémarrer ensuite BlueMind :
bmctl restart - Lancer la reconfiguration automatique de Keycloak sur le serveur cible :
bm-cli auth reconfigure
Remplacement des serveurs
- Stopper le serveur d'origine
- Reconfigurer le fichier
bm.inidu serveur cible pour lui attribuer l'adresse IP du serveur d'origine (voir Changer l'adresse IP d'un serveur BlueMind) - Redémarrer le serveur cible et le connecter au réseau à la place du serveur d'origine afin qu'il soit joignable à la place du serveur origine
Reconfiguration du système
Manuellement
- Reconfigurer le pare-feu :
sed -i "s/${old_ip}/${new_ip}/g" /etc/init.d/bm-iptables
systemctl restart bm-iptables.service - Reconfigurer 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 - Lancer la reconfiguration de l'outil de supervision bm-tick :
kapacitor list tasks | awk '{print $1}' | grep -v ID | xargs -I {} kapacitor delete tasks {}
bm-cli tick reconfigure
Via l'AdminConsole
Se connecter à la console d'administration de BlueMind en tant qu'utilisateur admin0@global.virt puis :
- Se rendre dans la partie Sécurité > Gestion du pare-feu et cliquer immédiatement sur le bouton "Enregistrer" pour forcer la régénération des règles du pare-feu BlueMind
- Se rendre dans la partie Gestion du Système > Maintenance des mails, cliquer sur le bouton "Exécuter" pour re-générer les tables de routage de mails Postfix
- Se rendre dans la partie Gestion du Système > Configuration Système et remplacer l'ancienne adresse IP du champ "Mes réseaux" par la nouvelle adresse ou plage d'adresse pour laquelle on souhaite être relais ouvert avant de cliquer sur le bouton "Enregistrer"
- Lancer la reconfiguration de l'outil de supervision bm-tick :
kapacitor list tasks | awk '{print $1}' | grep -v ID | xargs -I {} kapacitor delete tasks {}
bm-cli tick reconfigure