Aller au contenu

Montée de version à chaud du Mediation Controller

Important

La documentation de montée de version à chaud du Mediation Controller est prévue pour tout Mediation Controller fonctionnant avec Debian 11. Le contrôle de la version de Debian peut se faire avec la commande suivante (à exécuter en SSH ou en accès console) :

1
cat /etc/debian_version

Information

Pour rappel, le passage en tant que root sur les machines Debian doit s'effectuer avec la commande suivante :

1
su -

Préparation

Ouverture des flux

Lors de la montée de version du produit, de nombreux paquets doivent être téléchargés auprès des dépôts Debian du fait du passage de la version 11 à 12 de Debian. L'accès TCP 80 doit être ouvert vers security.debian.org et ftp.fr.debian.org.

Pour tester l'ouverture des flux sur la machine, une synchronisation des dépôts Debian peut être lancée, si des messages d'erreur d'accès aux dépôts Debian sont affichées alors le flux réseau n'est pas ouvert, probablement bloqué par le pare-feu d'entreprise. La synchronisation des dépôts est initiable avec la commande suivante :

1
apt update

Téléchargement du miroir et outils nécessaires

Le miroir cyberelements Cleanroom 4.6 est téléchargeable depuis ce lien (nécessite la création d'un compte client) : Systancia Marketplace

En plus du miroir des outils tiers seront nécessaires pour le processus de montée de version :

  • Un client SSH (sur Windows l'outil PuTTY peut être utilisé)
  • Un client SCP (sur Windows les outils WinSCP ou FileZilla peuvent être utilisés)

Installation et utilisation de l'outil screen

L’outil screen permet d’ouvrir plusieurs terminaux shell dans une même console. Il est impératif d’exploiter cet outil pour réaliser la montée de version cyberelements Cleanroom, afin de lever la dépendance vis-à-vis de la stabilité de la connectivité réseau. En effet, sans exploitation de l’outil screen, l’installation serait stoppée en cas de rupture de la connectivité SSH avec les serveurs Systancia Cleanroom.

En exploitant l’outil screen, à la reconnexion sur la console shell de l’équipement cyberelements Cleanroom, le terminal dans lequel le processus de mise à jour a été exécuté pourra être récupéré.

L’installation du paquet screen est à réaliser avec la ligne de commande suivante :

1
apt install --no-install-recommends screen

Pour ouvrir un nouveau terminal screen, la commande suivante doit être exécutée :

1
screen -S <ID>

Remplacer <ID> par un nom permettant d'identifier la session.

Exemple

Pour la montée de version de cyberelements l'identifiant cye-upgrade est facilement identifiable. La commande serait donc la suivante :

1
screen -S cye-upgrade

Pour récupérer un terminal ouvert par screen il suffit d'exécuter la commande suivante :

1
screen -r <ID>

Remplacer <ID> par le nom défini à l'ouverture de la session.

Exemple

Le terminal précédement ouvert avec l'identifiant cye-upgrade est récupérable avec la commande suivante :

1
screen -r cye-upgrade

Afin de fermer le terminal une fois l’intervention de montée de version terminée, la commande exit ou le raccourcis clavier Ctrl+D est à saisir dans le terminal.

Un retour à la console est alors opéré. Le message « screen is terminating » confirme la fermeture du terminal.

Extension d'espace disque pour les appliances virtuelles

Les appliances virtuelles Systancia Cleanroom 4.4 ou 4.5 ont besoin d'avoir une extension de leur disque de 2 Go qui seront ajoutés à la partition /usr. Cette opération est nécessaire afin d'avoir suffisamment d'espace disque pour la montée de version et de ne pas se retrouver bloqué pendant l'opération.

Lors de la connexion au Mediation Controller, que ce soit en SSH ou en mode console, un message d'accueil vous prévient d'être connecté à une machine Systancia. Une ligne supplémentaire indique la version de l'appliance.

Exemple

Une appliance virtuelle Mediation Controller en version 4.5 donnera le résultat suivant :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
         ____            _                   _
        / ___| _   _ ___| |_ __ _ _ __   ___(_) __ _
        \___ \| | | / __| __/ _  | '_ \ / __| |/ _  |
         ___) | |_| \__ \ || (_| | | | | (__| | (_| |
        |____/ \__, |___/\__\__,_|_| |_|\___|_|\__,_|
               |___/
#################################################################
# WARNING:                                                      #
# You must have specific authorization to access this machine.  #
# Unauthorized access to this machine is prohibited and will be #
# considered as intrusion.                                      #
# Unauthorized users will be logged, monitored, and could be    #
# prosecuted.                                                   #
#################################################################
Systancia Cleanroom 4.5.0 B77

Dans le cas où la machine n'est pas une appliance virtuelle fournie avec la version 4.4 ou 4.5, ce chapitre peut être ignoré pour passer à la montée de version.

Sauvegarde vivement recommandée

Les étapes qui vont suivre vont réaliser des modifications sur le partitionnement disque du Mediation Controller. Si des modifications manuelles avaient été réalisées il est possible que les indications suivantes ne soient pas adaptées entrainant un blocage de la machine.

Avant d'aller plus loin, veuillez réaliser une sauvegarde de la machine ou le cas échéant duppliquer la machine virtuelle. Les snapshots ne pourront pas être utilisés car, notamment avec VMware, ils bloquent la possibilité d'étendre un disque.

Au niveau de l'hyperviseur étendre l'espace disque de la machine virtuelle de 2 Go supplémentaires. En cas de non possibilité d'étendre le disque, vérifier qu'aucun snapshots n'est présent, et sinon, éteindre la machine virtuelle si l'extension à chaud n'est pas supportée.

Une fois l'espace disque étendu au niveau de la machine virtuelle, les commandes suivantes, à exécuter en tant que root, sont nécessaires afin d'étendre la partition /usr :

1
2
3
4
5
6
echo 1 > /sys/class/block/sda/device/rescan
start_lvm_partition=`fdisk -l /dev/sda | grep LVM | awk '{print $2}'`
echo -e "d\n2\nn\ne\n2\n\n\nn\n$start_lvm_partition\n\nt\n5\n8E\nw" | fdisk /dev/sda
pvresize /dev/sda5
lvresize -l +100%FREE /dev/mapper/SystanciaLVMGroup-usr
resize2fs /dev/mapper/SystanciaLVMGroup-usr

Montée de version

Mise à jour des paquets Debian

La montée de version de cyberelements Cleanroom nécessitant la montée de version de Debian, il est recommandé de correctement mettre à jour les paquets Debian 11 avant la bascule vers Debian 12. Pour ceci exécuter les commandes suivantes en tant que root (mise à jour système puis suppression des paquets inutiles) :

1
2
3
apt update
apt upgrade -y
apt autoremove -y

Des messages demandant de modifier la configuration de plusieurs fichiers de configuration pourront apparaître, dans ces cas sélectionner le choix pour conserver la configuration actuelle.

Préparation des pilotes Microsoft SQL Server

Des actions complémentaires sont nécessaires si les pilotes Microsoft SQL Server sont installés (c'est le cas sur les appliances virtuelles founies par Systancia).
Pour contrôler leurs présences sur le serveur, la commande suivante peut-être exécutée en tant que root :

1
apt list --installed ms*

Si aucun retour n'apparaît, alors les pilotes ne sont pas installés et vous pouvez passer à l'étape de préparation du miroir.
Sinon, si les pilotes sont installés, deux paquets devraient être listés : msodbcsql17 et mssql-tools. Poursuivez les indications de cette section.

Exemples

Un serveur sur lequel les pilotes ne sont pas installés aurait le résultat de la commande précédente comme ceci : 

1
Listing... Done

Tandis qu'un serveur sur lequel les pilotes sont installés aura un résultat équivalent à ceci (la version des paquets pouvant être différente) :

1
2
3
Listing... Done
msodbcsql17/bullseye,now 17.10.6.1-1 amd64 [installed]
mssql-tools/bullseye,now 17.10.1.1-1 amd64 [installed]

Les commandes suivantes sont nécessaires afin d'installer une version spécifique des paquets pour garantir le succès de la montée de version :

1
env ACCEPT_EULA=Y apt install -y --allow-downgrades odbcinst=2.3.6-0.1+b1 odbcinst1debian2=2.3.6-0.1+b1 libodbc1=2.3.6-0.1+b1 unixodbc=2.3.6-0.1+b1 mssql-tools=17.9.1.1-1 msodbcsql17=17.9.1.1-1

Configurer le dépôt Microsoft adapté à Debian 12 pour préparer la montée de version :

1
echo "deb [arch=amd64] https://packages.microsoft.com/debian/12/prod bookworm main" > /etc/apt/sources.list.d/mssql-release.list

Préparation du miroir cyberelements Cleanroom 4.6

Le miroir récupéré lors de la phase de préparation (fichier avec l'extension tgz) doit être envoyé sur le serveur via SCP. Il est à déposer dans le répertoire /tmp/.

Puis vient ensuite la préparation du miroir en exécutant les commandes suivantes en tant que root (une suppression de fichiers résiduels d'une ancienne montée de version est prévue) :

1
2
3
mkdir -p /opt/systancia/repository
rm -rf /opt/systancia/repository/*
tar xvzf /tmp/*.tgz -C /opt/systancia/repository/

Configuration d'APT

Le gestionnaire de paquet APT est paramétré pour récupérer les paquets Debian 11, il est nécessaire de le reconfigurer pour récupérer les paquets Debian 12. Il est aussi nécessaire de mettre à jour la référence du miroir local de cyberelements Cleanroom. Pour se faire exécuter les commandes suivantes en tant que root :

1
2
echo -e 'deb http://security.debian.org/debian-security/ bookworm-security main contrib non-free non-free-firmware\ndeb http://ftp.fr.debian.org/debian bookworm main contrib non-free non-free-firmware\ndeb http://ftp.fr.debian.org/debian bookworm-updates main contrib non-free non-free-firmware' > /etc/apt/sources.list
echo "deb file:///opt/systancia/repository/ bookworm ipdiva" > /etc/apt/sources.list.d/systancia.list

En plus de paramétrer les nouveaux dépôts, nous recommandons vivement l'application du paramétrage suivant permettant d'indiquer à APT de ne pas installer les dépendances recommandées qui ne sont pas obligatoirement nécessaire, dans un but de réduction des composants installés. La commande suivante permet d'appliquer ce paramétrage en tant que root :

1
echo -e 'APT::Install-Recommends false;\nAPT::Install-Suggests false;' > /etc/apt/apt.conf.d/99norecommends

Pour finir il est nécessaire de remettre à jour la liste des paquets des dépôts avec la commande suivante :

1
apt update

Déclenchement de la montée de version

Accéder en SSH au serveur Mediation Controller et passer root, puis ouvrir un screen tel qu'indiqué plus haut.

Débuter par mettre à jour certains paquets spécifiques afin que la montée de version puisse se réaliser. Un message d'erreur à l'exécution de la première commande est attendu, mais l'erreur sera corrigée avec la seconde commande :

1
2
apt install -y python3-cleanroom-django-mssql python3-ipdiva-ua-parser python3-ipdiva-user-agents python3-ipdiva-django2
apt install -y --fix-broken

Lorsqu'on monte de version un Mediation Controller Debian 11 vers Debian 12, le paquet collectd est mis à jour et devient incompatible avec le fichier de configuration généré par cyberelements Cleanroom (/etc/collectd/collectd.conf). Cela peut générer une erreur lors de la mise à jour.

Pour l'éviter, on désactive collectd :

1
2
systemctl stop collectd 
systemctl disable collectd

Suite à cela, la montée de version peut être initiée avec la commande suivante :

1
apt dist-upgrade -y

Lors de la montée de version plusieurs questions seront demandées à propos de la conservation de fichiers de configurations pour les mettre à jour d’après la configuration standard Debian 12 ou de conserver la configuration particulière en place. Voici nos recommandations pour la plupart des fichiers pouvant être rencontrés :

Fichier de configuration Action recommandée
/etc/issue A conserver, répondre N
/etc/issue.net A conserver, répondre N
/etc/security/limits.conf A conserver, répondre N
/etc/login.defs A conserver, répondre N
/etc/shibboleth/shibboleth2.xml A conserver, répondre N
/etc/shibboleth/shibd.logger Appliquer les modifications, répondre Y
/etc/default/ntpsec Appliquer les modifications, répondre Y
/etc/snmp/snmpd.conf Appliquer les modifications, répondre Y
/etc/logrotate.d/IPdivaServer Appliquer les modifications, répondre Y
/etc/ssh/sshd_config A conserver, répondre Garder la version actuellement installée
/etc/ssh/ssh_config Appliquer les modifications, répondre Y
/etc/apache2/ports.conf A conserver, répondre N
/etc/init.d/apache2 A conserver, répondre N
/etc/modsecurity/modsecurity.conf-recommended Appliquer les modifications, répondre Y
/etc/ipdiva/httpd/commonParameters.conf Appliquer les modifications, répondre Y
/etc/ipdiva/care/djangosettings.ini Appliquer les modifications, répondre Y
/etc/crontab Appliquer les modifications, répondre Y
/etc/openssl.cnf Appliquer les modifications, répondre Y
/etc/audit/rules.d/audit.rules A conserver, répondre N
/etc/pam.d/su A conserver, répondre N
/etc/sysctl.conf A conserver, répondre N

Accepter le message de configuration du paquet glibc :

Accepter le redémarrage automatique des services :

Une fois la montée de version terminée, exécuter les commandes suivantes réactiver collectd, supprimer les paquets inutiles et redémarrer la machine :

1
2
3
4
systemctl start collectd
systemctl enable collectd
apt autoremove -y
reboot

Actions spécifiques aux Mediations Controllers Cluster

Sur le serveur Mediation Controller SLAVE, exécutez les commandes suivantes pour resynchroniser le secret partagé entre le Mediation Controller MASTER et le SLAVE :

1
2
hostManagerCtl masterSynchro /etc/ipdiva/secure/secret /etc/ipdiva/secure/secret
systemctl restart apache2

Montée de version de l'instance de BDD PostgreSQL

Sur le serveur Mediation Controller, la mise à jour de l’instance de BDD PostgreSQL 13 vers la version 15 est à réaliser. Pour cela exécuter les prochaines indications avec les droits root.

Vérifier l’état des instances Postgresql avant migration :

1
pg_lsclusters

Exécuter les commandes suivantes afin de mettre à jour l'instance de base de données vers la version 15 de PostgreSQL :

1
2
3
4
pg_dropcluster --stop 15 main
systemctl stop postgresql
pg_upgradecluster 13 main
systemctl start postgresql

Contrôler la bonne montée de version de l'instance de base de données, deux instances doivent apparaître, l'une en version 13 et l'autre en version 15 qui est la seule active. Le contrôle s'effectue avec la commande suivante :

1
pg_lsclusters

Si la montée de version s'est correctement réalisée, alors l'instance de base de données en version 13 peut être supprimée :

1
pg_dropcluster 13 main

La suppression des paquets PostgreSQL en version 13 peut être initiée :

1
apt -y --purge autoremove postgresql-client-13 postgresql-13

Migration de la BDD cyberelements Cleanroom

La configuration du produit est enregistrée en base de données, celle-ci nécessite une migration pour lui permettre de contenir les configurations des évolutions apportées par la nouvelle version. L'opération s'effectue sur le Mediation Controller en tant que root.

Architecture cluster

Pour une architecture cluster il est nécessaire d'effectuer l'opération uniquement depuis un seul Mediation Controller, peut importe lequel.

Il est en plus nécessaire d'exécuter la commande suivante :

1
python3 /var/lib/ipdiva/care/manage.py migrate

La migration des données est déclenchée avec une commande équivalente à celle-ci :

1
python3 /var/lib/ipdiva/care/manage.py migrate --database=<org_clr>

Où <org_clr> doit être remplacé par le nom d'organisation à migrer. Noter bien que si le Mediation Controller possède plusieurs organisations (multi-tenants), alors il faudra exécuter autant de fois qu'il y a d'organisations à migrer.

Exemple

Pour une plateforme cyberelements Cleanroom qui possède les organisations systancia et systancia-test, il sera nécessaire d'exécuter les commandes suivantes :

1
2
python3 /var/lib/ipdiva/care/manage.py migrate --database=systancia
python3 /var/lib/ipdiva/care/manage.py migrate --database=systancia-test

Suite à la migration des base de données, un redémarrage du service Apache2 est nécessaire :

1
systemctl restart apache2

Restauration de configurations

Certaines configurations ont été écrasées lors du processus de montée de version qui ont besoin d'être rétablies.

Fichier commonParameters.conf :

Reporter les balises <Location> relatives aux passerelles HTML5 généralement situées en fin de fichier depuis le fichier /etc/ipdiva/httpd/commonParameters.conf.dpkg-old vers /etc/ipdiva/httpd/commonParameters.extra.conf (créer le fichier s'il n'existe pas). Si aucune balise <Location> n’est présente alors les exemples suivants pourront être recopiés.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
<Location /HTML5/>
    Order allow,deny
    Allow from all
    ProxyPass http://127.0.0.1:1234/systanciaHTML5-6.0/ flushpackets=on
    ProxyPassReverse http://127.0.0.1:1234
</Location>

<Location /HTML5/websocket-tunnel>
    Order allow,deny
    Allow from all
    ProxyPass ws://127.0.0.1:1234/systanciaHTML5-6.0/websocket-tunnel
    ProxyPassReverse ws://127.0.0.1:1234/systanciaHTML5-6.0/websocket-tunnel
</Location>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<Location /HTML5-1/>
    Order allow,deny
    Allow from all
    ProxyPass http://127.0.0.1:1234/systanciaHTML5-6.0/ flushpackets=on
    ProxyPassReverse http://127.0.0.1:1234
</Location>

<Location /HTML5-1/websocket-tunnel>
    Order allow,deny
    Allow from all
    ProxyPass ws://127.0.0.1:1234/systanciaHTML5-6.0/websocket-tunnel
    ProxyPassReverse ws://127.0.0.1:1234/systanciaHTML5-6.0/websocket-tunnel
</Location>

<Location /HTML5-2/>
    Order allow,deny
    Allow from all
    ProxyPass http://127.0.0.1:1235/systanciaHTML5-6.0/ flushpackets=on
    ProxyPassReverse http://127.0.0.1:1235
</Location>

<Location /HTML5-2/websocket-tunnel>
    Order allow,deny
    Allow from all
    ProxyPass ws://127.0.0.1:1235/systanciaHTML5-6.0/websocket-tunnel
    ProxyPassReverse ws://127.0.0.1:1235/systanciaHTML5-6.0/websocket-tunnel
</Location>

Fichier djangosettings.ini :

Reporter à l’identique les informations de la ligne 2 « allowed_hosts » du fichier /etc/ipdiva/care/djangosettings.ini.dpkg-old vers le fichier /etc/ipdiva/care/djangosettings.ini. Ceci peut être automatisé avec la commande suivante en tant que root :

1
sed -i "2c\\`sed -n '2p' /etc/ipdiva/care/djangosettings.ini.dpkg-old`" /etc/ipdiva/care/djangosettings.ini

Application des restaurations :

Afin d'appliquer les restaurations, un redémarrage du service Apache2 est nécessaire en tant que root :

1
systemctl restart apache2

Validation

Une fois l’opération de montée de version réalisée, une phase de validation du bon fonctionnement de l’infrastructure cyberelements Cleanroom est requise avant remise en production. En cas d’échec de validation, un retour arrière via la restauration des sauvegardes serveurs cyberelements Cleanroom est à envisager.

Accéder à l’interface administrateur d’une organisation, puis accéder au menu « A propos » dans la barre de contrôle pour contrôler que la version du Mediation Controller soit bien passée en 4.6.

De premiers tests de fonctionnement de la plateforme peuvent être initiés, toutefois nous recommandons d'utiliser une version 4.6 des Edge Gateway pour garantir un fonctionnement optimal des applications cyberelements Cleanroom.