Add documentation for Nutanix cluster management, Synology NAS updates, Windows 11 operator setup, decision support system installation, and Totem Manager configuration

- Created guides for adding/removing nodes in Nutanix clusters and installing Nutanix servers.
- Documented the process for updating Nutanix infrastructure and Synology NAS.
- Added instructions for preparing a Windows 11 operator workstation, including Sysprep and network configuration.
- Established steps for setting up the decision support system and configuring Totem Manager.

Docker/Dépannage/Augmenter espace disque.md

@@ -0,0 +1,177 @@
+# Augmenter l'espace disque d'un volume LVM
+
+Cette procédure concerne principalement l'espace utilisé par les données cartographiques. Elle décrit l'extension d'un volume logique (LV) à partir d'espace déjà disponible dans le volume de groupe (VG), l'agrandissement d'un disque existant ou l'ajout d'un nouveau disque.
+
+> **Précaution :** vérifier les sauvegardes et prendre un snapshot de la VM avant toute modification du disque ou des partitions. Confirmer les noms du disque, de la partition PV, du VG et du LV sur la machine. Ne jamais réutiliser aveuglément les valeurs d'exemple.
+
+## 1. Comprendre les éléments LVM
+
+- Un disque physique ou une partition de disque peut servir de volume physique (PV).
+- Un volume de groupe (VG) agrège un ou plusieurs PV.
+- Un volume logique (LV) est créé dans un VG et porte un système de fichiers.
+- Un point de montage donne accès au système de fichiers.
+
+Dans l'exemple de la procédure source, le VG est `gluster-vg`, le LV cartographique est `gis` et son chemin est `/dev/mapper/gluster--vg-gis--lv`.
+
+Pour l'environnement GlusterFS décrit dans la source, `/mnt/gis` et `/mnt/data` sont des points de montage réseau, tandis que `/gluster/gis` et `/gluster/data` correspondent aux systèmes de fichiers locaux adossés aux volumes logiques. Identifier le LV local concerné avant toute extension : ne pas passer un point de montage réseau à une commande LVM.
+
+## 2. Diagnostiquer l'espace disponible
+
+Vérifier le système de fichiers et l'espace utilisé :
+
+```bash
+df -hT
+```
+
+Examiner les disques, partitions et signatures :
+
+```bash
+lsblk -f
+sudo fdisk -l
+```
+
+Afficher les PV, VG et LV :
+
+```bash
+sudo pvs
+sudo vgs
+sudo lvs
+sudo pvdisplay
+sudo vgdisplay
+sudo lvdisplay
+```
+
+Le fichier `/etc/fstab` peut aider à faire correspondre les systèmes de fichiers aux points de montage :
+
+```bash
+cat /etc/fstab
+```
+
+Si `VFree`/l'espace libre du VG est suffisant, passer à la section 3. S'il n'y en a pas assez, choisir entre agrandir un disque existant (section 4) et ajouter un nouveau disque (section 5).
+
+## 3. Étendre un LV avec l'espace libre du VG
+
+Déterminer la taille à ajouter à partir de l'espace libre constaté et des besoins futurs. Ne pas utiliser une taille arbitrairement grande. La valeur `+500000G` présente dans la source est manifestement incorrecte et ne doit pas être utilisée.
+
+Pour ajouter une taille définie, remplacer `TAILLE` par la quantité validée :
+
+```bash
+sudo lvresize --resizefs --size +TAILLE /dev/mapper/gluster--vg-gis--lv
+```
+
+Exemple de la source, ajout de 5 Go au LV cartographique :
+
+```bash
+sudo lvresize --resizefs --size +5G /dev/mapper/gluster--vg-gis--lv
+```
+
+Pour affecter tout l'espace libre du VG au LV, uniquement si cela est prévu et approuvé :
+
+```bash
+sudo lvresize --resizefs -l +100%FREE /dev/mapper/gluster--vg-gis--lv
+```
+
+Cette dernière commande ne laisse aucun espace libre dans le VG pour d'autres LV. Vérifier le chemin du LV et l'espace libre avant de l'exécuter.
+
+## 4. Agrandir un disque existant
+
+Cette méthode s'applique lorsque la capacité du disque virtuel a été augmentée dans l'hyperviseur et que le PV se trouve sur une partition existante.
+
+### 4.1 Agrandir le disque virtuel et relire sa capacité
+
+1. Après avoir pris un snapshot, augmenter la capacité du bon disque dans l'hyperviseur. Dans l'exemple source, l'augmentation est de 50 Go.
+2. Vérifier que Linux voit la nouvelle taille :
+
+```bash
+sudo fdisk -l
+lsblk
+```
+
+Dans l'exemple source, le disque passe de 50 à 100 Go, tandis que la partition reste encore à 50 Go.
+
+### 4.2 Agrandir la partition PV
+
+Identifier précisément le disque et le numéro de partition. Exemple source : partition 1 sur `/dev/sdb`.
+
+```bash
+sudo growpart -v /dev/sdb 1
+```
+
+Vérifier la nouvelle taille de la partition :
+
+```bash
+lsblk
+```
+
+### 4.3 Redimensionner le PV, puis le LV
+
+Après l'agrandissement de la partition, redimensionner le PV pour que le VG détecte la capacité ajoutée. Exemple source :
+
+```bash
+sudo pvresize /dev/sdb1
+sudo vgs
+```
+
+Vérifier que l'espace libre est apparu dans le VG, puis étendre le LV concerné. Exemple d'ajout de 50 Go au LV cartographique :
+
+```bash
+sudo lvresize --resizefs --size +50G /dev/mapper/gluster--vg-gis--lv
+```
+
+Remplacer `/dev/sdb1`, le chemin du LV et la taille par les valeurs réellement confirmées sur la VM.
+
+## 5. Ajouter un nouveau disque au VG
+
+Utiliser cette méthode si le VG ne dispose pas d'assez d'espace et qu'un nouveau disque doit être ajouté à la VM.
+
+1. Ajouter le disque dans l'hyperviseur.
+2. Vérifier son nom et sa capacité :
+
+```bash
+lsblk -f
+sudo fdisk -l
+```
+
+3. Confirmer que le disque choisi est bien le nouveau disque et qu'il ne contient aucune donnée à conserver. La source utilise `/dev/sdc` comme exemple.
+4. Créer le PV :
+
+```bash
+sudo pvcreate /dev/sdc
+```
+
+5. Ajouter le PV au VG concerné. Exemple source :
+
+```bash
+sudo vgextend gluster-vg /dev/sdc
+```
+
+6. Vérifier que le PV appartient au VG et que l'espace libre a augmenté :
+
+```bash
+sudo pvs
+sudo vgdisplay gluster-vg
+```
+
+L'exemple source indique que le VG passe de 5 à 15 Go libres après l'ajout d'un disque de 10 Go. Ces valeurs sont illustratives.
+
+7. Après avoir confirmé l'espace disponible, étendre le LV concerné. Exemple d'ajout de 10 Go :
+
+```bash
+sudo lvresize --resizefs --size +10G /dev/mapper/gluster--vg-gis--lv
+```
+
+## 6. Vérifier l'extension
+
+Contrôler la taille du LV et l'espace du système de fichiers :
+
+```bash
+sudo pvs
+sudo vgs
+sudo lvs
+sudo df -hT
+lsblk
+```
+
+Confirmer que le point de montage local prévu affiche la nouvelle capacité et que les services concernés fonctionnent normalement.
+
+> Si les données font partie d'un volume GlusterFS répliqué ou distribué, cette procédure ne décrit que l'extension locale du stockage. Vérifier la procédure d'exploitation GlusterFS pour déterminer les opérations à effectuer sur les autres nœuds et le volume Gluster.

Docker/Dépannage/Downgrade version Docker

@@ -0,0 +1,133 @@
+# Downgrader Docker sur un cluster Swarm
+
+À la date de juin 2026, la procédure source signale des problèmes avec Docker 28 et 29 sous Ubuntu 24.04. L'équipe DevOps recommande alors Docker `27.5.1-0ubuntu3~24.04.2` comme version stable et compatible avec la pile utilisée. Vérifier la recommandation et la matrice de compatibilité en vigueur avant toute intervention.
+
+> **Important :** effectuer l'opération nœud par nœud. L'installation du paquet peut redémarrer le service Docker et interrompre les conteneurs du nœud. Suivre la procédure de maintenance Swarm approuvée et vérifier la santé du cluster avant de passer au nœud suivant.
+
+## 1. Vérifier l'état et la version actuelle
+
+Sur le nœud concerné, relever la version de Docker et le paquet installé :
+
+```bash
+docker --version
+dpkg -l 'docker.io'
+```
+
+Depuis un manager Swarm, vérifier également l'état des nœuds :
+
+```bash
+docker node ls
+```
+
+## 2. Vérifier les règles APT existantes
+
+Examiner le fichier de pinning, s'il existe :
+
+```bash
+cat /etc/apt/preferences.d/docker-buggy-version-pin
+```
+
+Afficher les versions disponibles et leurs priorités :
+
+```bash
+sudo apt update
+apt policy docker.io
+apt list -a docker.io
+```
+
+Dans la sortie `apt policy` :
+
+- `***` identifie la version actuellement installée;
+- une priorité négative, par exemple `-1`, empêche l'installation de cette version;
+- les priorités positives déterminent la sélection du paquet par APT.
+
+La procédure source indique que Docker 28 et 29 sont exclus et que la branche 27 est privilégiée.
+
+## 3. Configurer le pinning APT
+
+Si le fichier de pinning n'est pas déjà configuré selon la politique de l'organisation, créer `/etc/apt/preferences.d/docker-buggy-version-pin` :
+
+```bash
+sudo tee /etc/apt/preferences.d/docker-buggy-version-pin <<'EOF'
+# Docker 28+: risque de problemes reseau Swarm lors de redeploiements frequents
+# https://github.com/moby/moby/issues/50232
+# Docker 29+: problemes de compatibilite connus avec Traefik v2.10
+# et risques reseau/DNS signales dans la procedure source.
+# Privilegier la branche 27.x, sous reserve de compatibilite validee.
+Package: docker.io
+Pin: version 27.*
+Pin-Priority: 1001
+
+# Bloquer les versions signalees comme problematiques
+Package: docker.io
+Pin: version 28.*
+Pin-Priority: -1
+
+Package: docker.io
+Pin: version 29.*
+Pin-Priority: -1
+EOF
+```
+
+Rafraîchir les index et vérifier le résultat :
+
+```bash
+sudo apt update
+apt policy docker.io
+apt list -a docker.io
+```
+
+Ne pas installer si la version candidate n'est pas celle validée pour le système.
+
+## 4. Récupérer et vérifier le paquet cible
+
+Si la version requise n'est pas disponible dans les sources APT configurées, récupérer le paquet depuis le cache APT de la TELEMW ou depuis une source Ubuntu approuvée.
+
+Exemples de téléchargement fournis par la procédure source :
+
+```bash
+IP_TELEM="ADRESSE_IP_TELEMW"
+curl -fL -o /tmp/docker.io_27.5.1-0ubuntu3_amd64.deb "http://${IP_TELEM}:9999/ftp.ubuntu.com/ubuntu/pool/universe/d/docker.io-app/docker.io_27.5.1-0ubuntu3_amd64.deb"
+```
+
+Ou depuis le dépôt Ubuntu indiqué dans la source :
+
+```bash
+curl -fL -o /tmp/docker.io_27.5.1-0ubuntu3_amd64.deb "http://ftp.ubuntu.com/ubuntu/pool/universe/d/docker.io-app/docker.io_27.5.1-0ubuntu3_amd64.deb"
+```
+
+**Vérifier la révision avant installation :** la version recommandée dans la source est `27.5.1-0ubuntu3~24.04.2`, alors que les noms des paquets présents dans les URL d'exemple indiquent `27.5.1-0ubuntu3`. Confirmer la version exacte, l'architecture et la provenance du fichier avant de l'installer :
+
+```bash
+dpkg-deb -f /tmp/docker.io_27.5.1-0ubuntu3_amd64.deb Version Architecture
+```
+
+Si la version ou l'architecture ne correspond pas au paquet approuvé, ne pas poursuivre avec ce fichier. Utiliser une source de confiance et vérifier l'intégrité du paquet selon les règles internes.
+
+## 5. Installer le downgrade sur un nœud
+
+Confirmer que le nœud est prêt pour la maintenance et appliquer, si nécessaire, la procédure Swarm d'évacuation des charges. Réaliser toutes les étapes suivantes sur un seul nœud à la fois.
+
+Installer le paquet validé :
+
+```bash
+sudo apt install /tmp/docker.io_27.5.1-0ubuntu3_amd64.deb
+```
+
+Adapter le chemin au nom réel du paquet vérifié. APT peut demander confirmation ou signaler des dépendances; lire le plan d'installation avant de l'accepter.
+
+Vérifier la version et l'état Docker sur le nœud :
+
+```bash
+docker --version
+dpkg -l 'docker.io'
+```
+
+Depuis un manager Swarm, vérifier que le nœud est de nouveau sain et que les services attendus fonctionnent :
+
+```bash
+docker node ls
+docker service ls
+```
+
+Ne passer au nœud suivant qu'après validation du nœud courant et de l'état du cluster. Répéter la procédure nœud par nœud.

Docker/Dépannage/Espace VAR LIB Docker full.md

@@ -0,0 +1,94 @@
+# Espace disque plein dans `/var/lib/docker`
+
+## 1. Vérifier l'espace disque
+
+Confirmer que la partition contenant `/var/lib/docker` est pleine :
+
+```bash
+df -h /var/lib/docker
+```
+
+Vérifier que la tâche cron de purge est configurée pour l'utilisateur `SYSTEL` :
+
+```bash
+crontab -l
+```
+
+La ligne attendue, précédée de son commentaire, est :
+
+```cron
+# Purge docker unused data every sunday at 14
+0 14 * * 7 docker system prune -f
+```
+
+Cette tâche exécute une purge chaque dimanche à 14 h. Si elle est absente, l'ajouter avec `crontab -e` sous le compte `SYSTEL`.
+
+Vérifier dans les journaux système si la commande apparaît :
+
+```bash
+grep 'docker system prune -f' /var/log/syslog
+```
+
+## 2. Identifier les ressources Docker volumineuses
+
+Afficher l'espace consommé par les composants Docker :
+
+```bash
+docker system df
+```
+
+Lister les sous-répertoires les plus volumineux d'`overlay2` :
+
+```bash
+sudo du -h /var/lib/docker/overlay2 | sort -h | tail
+```
+
+Afficher la taille des conteneurs :
+
+```bash
+docker ps -a --format "table {{.ID}}\t{{.Image}}\t{{.Status}}\t{{.Size}}"
+```
+
+La colonne `SIZE` contient deux valeurs, par exemple `40.2kB (virtual 958MB)` :
+
+- `40.2kB` correspond à la taille de la couche inscriptible du conteneur;
+- `virtual 958MB` comprend la couche du conteneur et l'image utilisée.
+
+Lister ensuite les images présentes :
+
+```bash
+docker image ls
+```
+
+> **Important :** ne jamais supprimer manuellement les répertoires sous `/var/lib/docker/overlay2`. Cela peut endommager l'état de Docker et les conteneurs. Utiliser les commandes Docker prévues pour le nettoyage.
+
+## 3. Nettoyer les ressources inutilisées
+
+`docker system prune -a` supprime les conteneurs arrêtés, les réseaux inutilisés, les images qui ne sont utilisées par aucun conteneur et le cache de build. Il ne supprime pas les volumes sans l'option `--volumes`.
+
+Pour examiner la demande de confirmation avant la purge, exécuter :
+
+```bash
+docker system prune -a
+```
+
+Après avoir vérifié le périmètre annoncé, confirmer uniquement si ces ressources peuvent être supprimées et si les images nécessaires pourront être récupérées ou reconstruites.
+
+La commande non interactive indiquée dans la procédure source est :
+
+```bash
+docker system prune -af
+```
+
+L'option `-f` contourne la confirmation. Ne l'utiliser qu'après vérification et autorisation de la purge. Ne pas ajouter `--volumes` sans validation spécifique : cela pourrait supprimer des données persistantes.
+
+## 4. Vérifier le résultat
+
+Après le nettoyage, contrôler de nouveau l'espace disque et l'utilisation Docker :
+
+```bash
+df -h /var/lib/docker
+docker system df
+```
+
+Si l'espace reste insuffisant, identifier les images ou conteneurs concernés avec les commandes de diagnostic ci-dessus et suivre la procédure de maintenance de l'application. Ne pas supprimer les fichiers Docker manuellement.

Docker/Mise a jour Docker.md

@@ -0,0 +1,64 @@
+# Mise à jour des nœuds Docker Swarm
+
+## Vérifier la disponibilité des nœuds
+
+Sur le nœud manager, vérifier que chaque nœud concerné affiche **Ready** dans la colonne `STATUS` et **Active** dans la colonne `AVAILABILITY`. Corriger tout problème avant de poursuivre.
+
+```bash
+docker node ls
+```
+
+**Attention :** appliquer cette procédure à un seul nœud worker à la fois.
+
+## Placer un nœud worker en maintenance
+
+Sur le nœud manager, exécuter la commande suivante en remplaçant `<nom_du_noeud>` par le nom du worker concerné :
+
+```bash
+docker node update --availability drain <nom_du_noeud>
+```
+
+## Vérifier la disponibilité du nœud
+
+Sur le nœud manager, vérifier dans `docker node ls` que la colonne `AVAILABILITY` affiche **Drain** pour le nœud sélectionné. Son état dans la colonne `STATUS` doit rester **Ready**.
+
+```bash
+docker node ls
+```
+
+## Vérifier le déplacement des tâches Swarm
+
+Sur le nœud en mode **Drain**, vérifier que les tâches des services Swarm ont été déplacées. Les conteneurs qui ne sont pas gérés par Swarm ne sont pas déplacés automatiquement.
+
+```bash
+docker ps
+```
+
+## Mettre à jour les paquets du système
+
+```bash
+apt update
+apt upgrade
+```
+
+`apt update` actualise la liste des paquets disponibles ; `apt upgrade` installe les mises à jour proposées. Examiner les changements avant de confirmer.
+
+## Rétablir la disponibilité du nœud
+
+Sur le nœud manager, exécuter la commande suivante en remplaçant `<nom_du_noeud>` par le nom du worker mis à jour :
+
+```bash
+docker node update --availability active <nom_du_noeud>
+```
+
+## Vérifier l'état du nœud et des services
+
+Sur le nœud mis à jour, vérifier les conteneurs avec `docker ps`. Leur présence dépend du placement des tâches Swarm ; confirmer également que les services sont à l'état attendu.
+
+```bash
+docker ps
+```
+
+## Répéter l'opération sur chaque nœud worker
+
+Procéder **un nœud à la fois** et attendre la fin de sa mise à jour avant de passer au suivant.