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.
This commit is contained in:
Maxime BOURIEAU
@@ -0,0 +1,102 @@
|
||||
# Corriger un espace disque récurrent sur la VM Remote
|
||||
|
||||
Cette procédure décrit l'extension d'un disque virtuel, d'une partition LVM, du volume physique et du volume logique. Les valeurs `almalinux`, `/dev/sda3` et 100 Go sont des exemples issus de la procédure source : confirmer les noms et tailles sur la VM avant toute modification.
|
||||
|
||||
> **Précaution :** toute modification de partition ou de stockage comporte un risque. Vérifier les sauvegardes et prendre un snapshot de la VM avant l'intervention. Ne pas poursuivre si le disque, la partition, le volume logique ou le système de fichiers cible ne sont pas clairement identifiés.
|
||||
|
||||
## 1. Diagnostiquer le volume de groupe
|
||||
|
||||
Vérifier la taille et l'espace libre du volume de groupe :
|
||||
|
||||
```bash
|
||||
sudo vgdisplay
|
||||
```
|
||||
|
||||
Dans l'exemple source, le groupe `almalinux` fait environ 69,57 Go au total et indique `Free PE / Size 0 / 0`. Cela signifie qu'il ne reste pas d'espace libre dans le volume de groupe pour agrandir un volume logique. La capacité totale du VG correspond à l'ensemble de ses volumes physiques.
|
||||
|
||||
## 2. Identifier le disque et le volume physique
|
||||
|
||||
Examiner les disques détectés et les volumes physiques :
|
||||
|
||||
```bash
|
||||
sudo lvmdiskscan
|
||||
sudo pvdisplay
|
||||
```
|
||||
|
||||
Dans l'exemple source, la partition LVM est `/dev/sda3`. Vérifier cette information sur la VM; ne pas supposer que le disque est toujours `/dev/sda` ni que la partition est toujours la troisième.
|
||||
|
||||
## 3. Augmenter le disque virtuel
|
||||
|
||||
1. Dans Nutanix, prendre un snapshot de la VM selon la procédure de l'environnement.
|
||||
2. Augmenter la capacité du disque virtuel. L'exemple source augmente le disque à 100 Go.
|
||||
3. Confirmer dans la configuration de la VM que le bon disque a été agrandi.
|
||||
|
||||
## 4. Faire détecter la nouvelle capacité par le système
|
||||
|
||||
La procédure source mentionne un invité Ubuntu qui peut continuer à afficher l'ancienne capacité, environ 70 Go dans son exemple. Après l'extension dans Nutanix, relancer la détection du disque :
|
||||
|
||||
```bash
|
||||
sudo sh -c 'echo 1 > /sys/class/block/sda/device/rescan'
|
||||
```
|
||||
|
||||
Remplacer `sda` par le nom du disque réellement identifié. Si le disque n'est toujours pas détecté à la nouvelle taille, redémarrer la VM selon le plan d'intervention, puis vérifier de nouveau sa capacité.
|
||||
|
||||
## 5. Étendre la partition du volume physique
|
||||
|
||||
Avant de modifier la table de partitions, confirmer que `/dev/sda3` est bien la partition LVM à étendre et que l'espace ajouté se trouve après cette partition.
|
||||
|
||||
1. Lancer l'outil sur le disque identifié :
|
||||
|
||||
```bash
|
||||
sudo cfdisk /dev/sda
|
||||
```
|
||||
|
||||
2. Sélectionner la partition LVM (par exemple `/dev/sda3`) et choisir **Resize**.
|
||||
3. Accepter la nouvelle taille proposée uniquement après vérification du disque et de la partition sélectionnés.
|
||||
4. Sélectionner **Write** pour enregistrer la table de partitions, puis confirmer.
|
||||
|
||||
Ne pas supprimer ni recréer la partition. Si le partitionnement affiché ne correspond pas à la configuration attendue, arrêter et demander une validation à l'équipe responsable.
|
||||
|
||||
## 6. Redimensionner le volume physique LVM
|
||||
|
||||
Une fois la partition agrandie, informer LVM de sa nouvelle taille. Remplacer `/dev/sda3` par la partition vérifiée :
|
||||
|
||||
```bash
|
||||
sudo pvresize /dev/sda3
|
||||
```
|
||||
|
||||
Contrôler le résultat :
|
||||
|
||||
```bash
|
||||
sudo pvdisplay
|
||||
sudo vgdisplay
|
||||
```
|
||||
|
||||
Le volume de groupe doit maintenant afficher de l'espace libre. L'exemple source indique environ 30 Go disponibles après l'extension; cette valeur dépend de la taille réelle du disque et des autres volumes.
|
||||
|
||||
## 7. Étendre le volume logique et le système de fichiers
|
||||
|
||||
Identifier d'abord le volume logique concerné, son point de montage et le type de système de fichiers. Les captures de la procédure source ne précisent ni le chemin du volume logique, ni la taille à lui attribuer, ni la commande exacte d'extension. Ne pas sélectionner un volume ou consommer tout l'espace libre sans confirmation.
|
||||
|
||||
Après validation du volume logique cible et de la taille à ajouter, effectuer son extension selon la procédure LVM approuvée pour la VM.
|
||||
|
||||
Si le système de fichiers concerné est XFS, l'agrandir après l'extension du volume logique en ciblant son point de montage :
|
||||
|
||||
```bash
|
||||
sudo xfs_growfs <POINT_DE_MONTAGE>
|
||||
```
|
||||
|
||||
Remplacer `<POINT_DE_MONTAGE>` par le point de montage réel. N'utiliser `xfs_growfs` que pour un système de fichiers XFS; si le type de système de fichiers ou la méthode requise n'est pas certain, arrêter et consulter la procédure correspondante.
|
||||
|
||||
## 8. Vérifier le résultat
|
||||
|
||||
Vérifier que le volume logique et le système de fichiers présentent la capacité attendue et que l'espace disque est disponible :
|
||||
|
||||
```bash
|
||||
sudo pvs
|
||||
sudo vgs
|
||||
sudo lvs
|
||||
df -h
|
||||
```
|
||||
|
||||
Confirmer également que les services de la VM Remote fonctionnent normalement après l'intervention.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -0,0 +1,33 @@
|
||||
# Dépanner un service VerneMQ en échec
|
||||
|
||||
## 1. Vérifier l'état du service
|
||||
|
||||
Si le service VerneMQ reste en état `failed`, relever les erreurs et confirmer que la suppression du magasin de messages est bien nécessaire avant d'appliquer la procédure ci-dessous.
|
||||
|
||||
```bash
|
||||
sudo service vernemq status
|
||||
```
|
||||
|
||||
## 2. Purger le magasin de messages si nécessaire
|
||||
|
||||
> **Attention :** la suppression du contenu de `/var/lib/vernemq/msgstore` peut entraîner la perte des messages persistants et des messages en attente. N'effectuer cette opération qu'après validation, selon la procédure de sauvegarde et de rétention applicable à l'environnement.
|
||||
|
||||
Exécuter les commandes séparément et vérifier que le service est arrêté avant la purge :
|
||||
|
||||
```bash
|
||||
sudo service vernemq stop
|
||||
sudo service vernemq status
|
||||
```
|
||||
|
||||
Après confirmation de l'arrêt et des autorisations nécessaires, supprimer le contenu du magasin :
|
||||
|
||||
```bash
|
||||
sudo rm -rf /var/lib/vernemq/msgstore/*
|
||||
```
|
||||
|
||||
Puis redémarrer le service et vérifier son état :
|
||||
|
||||
```bash
|
||||
sudo service vernemq start
|
||||
sudo service vernemq status
|
||||
```
|
||||
@@ -0,0 +1,245 @@
|
||||
# Créer et déployer un certificat wildcard
|
||||
|
||||
Le SDIS 88 et le domaine `sdis88.fr` sont utilisés comme exemples dans cette procédure. Adapter les domaines, noms de fichiers, chemins et adresses à l'environnement concerné.
|
||||
|
||||
> **Sécurité :** un fichier `.pem` généré depuis un PFX peut contenir la clé privée. Le protéger comme un secret, limiter son accès et le transférer uniquement par un canal approuvé. Ne jamais publier la clé privée dans la documentation ni dans un espace partagé non autorisé.
|
||||
|
||||
## 1. Prérequis
|
||||
|
||||
1. Faire commander le nouveau certificat par le client et coordonner la demande avec le référent habituel (contact cité dans la procédure source : Julien Vidal).
|
||||
2. Récupérer auprès du client les fichiers fournis par l'autorité de certification et la passphrase, le cas échéant. Conserver les secrets dans RDM.
|
||||
3. Récupérer le dossier `OpenSSL-Win32` sur le NAS SI-OPS. Le chemin exact reste à confirmer dans l'environnement.
|
||||
4. Installer Keystore Explorer, en version 5.5.2 si possible.
|
||||
5. Déterminer le type de fichiers reçus (PFX complet, PFX incomplet ou autre) et suivre uniquement le parcours correspondant.
|
||||
|
||||
## 2. Vérifier un PFX complet
|
||||
|
||||
Cette procédure s'applique lorsque le client fournit un PFX complet et sa passphrase.
|
||||
|
||||
1. Ouvrir le fichier `.pfx` dans Keystore Explorer et saisir la passphrase fournie par le client.
|
||||
2. Pour faciliter l'identification, renommer l'alias du certificat si nécessaire.
|
||||
3. Ouvrir le certificat wildcard et vérifier son sujet (par exemple `*.sdis88.fr`) ainsi que ses dates de validité. Les dates doivent correspondre à la période attendue.
|
||||
4. Vérifier la chaîne de certification : pour chaque certificat, comparer le CN de l'émetteur avec le CN de l'autorité suivante et vérifier que les certificats de la chaîne sont valides.
|
||||
5. Exporter le PFX si un nouveau mot de passe doit lui être appliqué. Utiliser le mot de passe conservé dans `RDM > Commun > Certificat Wildcard`.
|
||||
6. Enregistrer le PFX exporté dans le répertoire `OpenSSL-Win32` utilisé pour la conversion.
|
||||
|
||||
La procédure source mentionne un « PFX incomplet », mais ne donne pas les étapes permettant de le compléter. Dans ce cas, demander au fournisseur le PFX complet et sa chaîne de certification, ou utiliser une procédure de récupération validée. Ne pas supposer que la chaîne peut être reconstruite à partir du seul fichier incomplet.
|
||||
|
||||
## 3. Convertir le PFX en PEM
|
||||
|
||||
Le PEM est utilisé pour les mises à jour des serveurs et équipements concernés. Dans une invite de commandes Windows, se placer dans le répertoire contenant le PFX et définir la configuration OpenSSL :
|
||||
|
||||
```cmd
|
||||
cd /d C:\OpenSSL-Win32
|
||||
set OPENSSL_CONF=C:\OpenSSL-Win32\openssl.cnf
|
||||
```
|
||||
|
||||
Avec OpenSSL 32 bits :
|
||||
|
||||
```cmd
|
||||
openssl pkcs12 -in sdis88.fr.pfx -out sdis88.pem -nodes
|
||||
```
|
||||
|
||||
Avec OpenSSL 64 bits :
|
||||
|
||||
```cmd
|
||||
"C:\Program Files\OpenSSL-Win64\bin\openssl.exe" pkcs12 -in sdis88.fr.pfx -out sdis88.pem -nodes
|
||||
```
|
||||
|
||||
Remplacer les noms de fichiers par ceux de l'environnement. La commande peut demander la passphrase du PFX.
|
||||
|
||||
> L'option `-nodes` écrit la clé privée sans chiffrement dans le PEM. Protéger immédiatement le fichier, ne pas le laisser dans un répertoire temporaire ou partagé et le supprimer de façon sécurisée lorsque les déploiements et contrôles sont terminés.
|
||||
|
||||
Ne transmettre le PEM au client que si cela est nécessaire et autorisé, par un canal sécurisé; vérifier auparavant si le client a réellement besoin de la clé privée.
|
||||
|
||||
## 4. Vérifier le certificat depuis les réseaux concernés
|
||||
|
||||
Après le déploiement et le redémarrage des services concernés, vérifier le certificat présenté par les services :
|
||||
|
||||
- Depuis le réseau Systel, ouvrir `https://aml.sdisXX.fr` en remplaçant `XX` par le numéro du SDIS. Même si la page est blanche, examiner le certificat présenté.
|
||||
- Depuis un poste TELEMW ou le réseau du SDIS, ouvrir `https://startweb.sdisXX.fr` et examiner le certificat présenté.
|
||||
|
||||
Ces URL servent à vérifier respectivement les accès HA-EXT et HA-INT. Contrôler le domaine, la période de validité et la chaîne de certification; rafraîchir la page après le redémarrage de HAProxy.
|
||||
|
||||
## 5. Mettre à jour HA-INT et HA-EXT
|
||||
|
||||
Appliquer les étapes à chaque paire HA concernée. Sauvegarder les configurations avant modification et procéder sur un serveur à la fois.
|
||||
|
||||
### 5.1 Sauvegarder la configuration HAProxy
|
||||
|
||||
Avec WinSCP :
|
||||
|
||||
1. Se connecter au serveur HA.
|
||||
2. Ouvrir `/etc/haproxy`.
|
||||
3. Dupliquer `haproxy.cfg` et nommer la copie avec la date, l'opération et l'intervenant, par exemple `haproxy.cfg_AAAA_MM_JJ_renouvellement-certificat_initiales`.
|
||||
|
||||
Ou, en SSH, créer une copie de sauvegarde :
|
||||
|
||||
```bash
|
||||
cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg_AAAA_MM_JJ_operation_intervenant
|
||||
```
|
||||
|
||||
Répéter la sauvegarde sur les HA concernés.
|
||||
|
||||
### 5.2 Vérifier les chemins des certificats dans HAProxy
|
||||
|
||||
1. Récupérer une copie de la configuration initiale de HA1 et l'ouvrir dans Notepad++.
|
||||
2. Rechercher toutes les références aux fichiers `.pem`.
|
||||
3. Vérifier que le nom indiqué dans la configuration correspond au nom du nouveau certificat qui sera déposé sur le serveur.
|
||||
4. Préférer un nom générique stable, afin de ne pas modifier la configuration à chaque renouvellement. Si la configuration utilise déjà un nom générique correct, ne pas le modifier.
|
||||
5. Déployer la configuration mise à jour sur le serveur concerné et conserver la sauvegarde initiale.
|
||||
|
||||
### 5.3 Remplacer le certificat et valider la configuration
|
||||
|
||||
Dans l'exemple source, le répertoire du certificat est `/etc/ssl/private/sdis88.fr`. Vérifier le chemin configuré sur le serveur et adapter les noms :
|
||||
|
||||
```bash
|
||||
cd /etc/ssl/private/sdis88.fr
|
||||
mv sdis88.pem sdis88_AAAA.pem
|
||||
cp /home/systel/sdis88.pem ./
|
||||
```
|
||||
|
||||
Exécuter la validation avant de redémarrer HAProxy :
|
||||
|
||||
```bash
|
||||
haproxy -c -f /etc/haproxy/haproxy.cfg
|
||||
```
|
||||
|
||||
Si la validation échoue, vérifier que le nouveau PEM est dans le répertoire attendu et que son nom correspond exactement à celui référencé dans `haproxy.cfg`. Ne pas redémarrer le service avec une configuration invalide.
|
||||
|
||||
Quand la validation réussit, redémarrer HAProxy :
|
||||
|
||||
```bash
|
||||
service haproxy restart
|
||||
```
|
||||
|
||||
La procédure source indique qu'HA1 peut être redémarré en premier car le service redémarre rapidement. Contrôler le service et le certificat après ce premier redémarrage avant de poursuivre sur l'autre serveur HA.
|
||||
|
||||
## 6. Mettre à jour les certificats StartWeb si nécessaire
|
||||
|
||||
Cette étape n'est pas nécessaire si, après la mise à jour des HA-INT, le certificat présenté par `https://startweb.sdisXX.fr` est déjà le nouveau certificat.
|
||||
|
||||
Le PEM contient la clé privée et un ou plusieurs certificats. À partir du PEM, préparer les fichiers `.key` et `.crt` :
|
||||
|
||||
1. Dans un éditeur de texte, copier le bloc de clé privée, de `BEGIN PRIVATE KEY` à `END PRIVATE KEY`, dans un fichier `.key`. Si le PEM utilise un autre type de marqueur de clé, conserver les délimiteurs exacts du bloc correspondant.
|
||||
2. Copier le ou les blocs `BEGIN CERTIFICATE` / `END CERTIFICATE` qui suivent la clé dans un fichier `.crt`, conformément au format attendu par la configuration NGINX.
|
||||
3. Vérifier que les noms de fichiers correspondent aux chemins référencés par NGINX.
|
||||
|
||||
Transférer les fichiers vers `/home/systel` sur chaque StartWeb concerné. Les emplacements indiqués dans la source sont `/etc/nginx/certs` et `/etc/ssl/private/sdisxx`; vérifier le répertoire réellement utilisé avant toute modification.
|
||||
|
||||
Exemple pour `/etc/nginx/certs` :
|
||||
|
||||
```bash
|
||||
mv /etc/nginx/certs/sdis88.fr.crt /etc/nginx/certs/sdis88.fr.crt_AAAA
|
||||
mv /etc/nginx/certs/sdis88.fr.key /etc/nginx/certs/sdis88.fr.key_AAAA
|
||||
cp /home/systel/sdis88.fr.crt /etc/nginx/certs/
|
||||
cp /home/systel/sdis88.fr.key /etc/nginx/certs/
|
||||
service nginx restart
|
||||
```
|
||||
|
||||
Si les certificats sont stockés dans `/etc/ssl/private/sdisxx`, adapter les commandes à ce chemin et vérifier que les noms correspondent exactement à la configuration. Répéter sur les serveurs StartWeb nécessaires et contrôler le certificat après redémarrage.
|
||||
|
||||
## 7. Ajouter les autorités de certification au magasin GlassFish
|
||||
|
||||
Les appareils anciens peuvent ne pas connaître les autorités de certification récentes. Vérifier le magasin de certificats du serveur Web et y ajouter les autorités manquantes si nécessaire.
|
||||
|
||||
1. Se connecter au serveur Web avec WinSCP.
|
||||
2. Sauvegarder le fichier suivant en ajoutant une date et une description au nom de la copie :
|
||||
|
||||
```text
|
||||
/opt/glassfish5/glassfish/domains/domain1/config/cacerts.jks
|
||||
```
|
||||
|
||||
3. Récupérer une copie de `cacerts.jks` sur le poste d'administration et l'ouvrir dans Keystore Explorer.
|
||||
4. Examiner les certificats et vérifier si les autorités de la chaîne wildcard sont déjà présentes.
|
||||
5. Si une autorité manque, utiliser **Importer un certificat de confiance** et l'ajouter. Répéter pour chaque autorité manquante.
|
||||
6. Transférer le magasin mis à jour sur le serveur et redémarrer le service GlassFish selon la procédure d'exploitation de l'environnement.
|
||||
|
||||
## 8. Renouveler le certificat du Bastion
|
||||
|
||||
Le Bastion utilise un certificat au format CRT et une clé au format KEY. Préparer les deux fichiers depuis le PEM selon la section 6, puis :
|
||||
|
||||
1. Vérifier les chemins de certificat configurés dans :
|
||||
|
||||
```text
|
||||
/etc/apache2/sites-available/guacamole.conf
|
||||
```
|
||||
|
||||
2. Se placer dans le répertoire de certificats configuré. La source donne `/etc/ssl/private/SDISXX` comme exemple.
|
||||
3. Renommer les certificats existants pour les sauvegarder, puis déposer les nouveaux fichiers depuis `/home/systel`.
|
||||
|
||||
Exemple :
|
||||
|
||||
```bash
|
||||
cd /etc/ssl/private/SDISXX
|
||||
mv SDISXX-Wildcard.crt SDISXX-Wildcard_AAAA.crt
|
||||
mv SDISXX-Wildcard.key SDISXX-Wildcard_AAAA.key
|
||||
cp /home/systel/SDISXX-Wildcard.crt ./
|
||||
cp /home/systel/SDISXX-Wildcard.key ./
|
||||
```
|
||||
|
||||
Respecter exactement les noms et la casse attendus par `guacamole.conf`; les chemins Linux sont sensibles à la casse. Vérifier la configuration, puis redémarrer Apache :
|
||||
|
||||
```bash
|
||||
sudo service apache2 restart
|
||||
```
|
||||
|
||||
Contrôler l'accès au Bastion et le certificat présenté.
|
||||
|
||||
## 9. Mettre à jour le certificat MyIRIS+
|
||||
|
||||
1. Préparer le fichier `.key` et le fichier `.crt` à partir du PEM selon la section 6.
|
||||
2. Se connecter avec WinSCP à la VM `RPMyIRIS+-TURN` (entrée disponible dans RDM).
|
||||
3. Sauvegarder les certificats présents dans `/home/systel/certs` :
|
||||
|
||||
```bash
|
||||
mv /home/systel/certs/nginx.crt /home/systel/certs/nginx_AAAA.crt
|
||||
mv /home/systel/certs/nginx.key /home/systel/certs/nginx_AAAA.key
|
||||
```
|
||||
|
||||
4. Déposer les nouveaux fichiers `.crt` et `.key` dans `/home/systel/certs`.
|
||||
5. Charger les certificats et redémarrer les conteneurs avec le script :
|
||||
|
||||
```bash
|
||||
utils/load-certs.sh
|
||||
```
|
||||
|
||||
6. Vérifier le certificat et le fonctionnement WebRTC avec l'outil de test [Trickle ICE](https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/). Utiliser le compte, le nom DNS et le mot de passe propres à l'environnement; récupérer les secrets dans RDM.
|
||||
|
||||
## 10. Mettre à jour le WAF pour CSPM
|
||||
|
||||
### 10.1 Prérequis et préparation des fichiers
|
||||
|
||||
Mettre à jour le certificat sur les quatre HAProxy avant le WAF.
|
||||
|
||||
Découper le PEM en trois fichiers, en vérifiant l'ordre et le contenu des blocs :
|
||||
|
||||
- `wildcard_AAAA.key` : bloc de clé privée;
|
||||
- `wildcard_AAAA.crt` : certificat du domaine `*.sapeurs-pompiers.mc` uniquement;
|
||||
- `intermediaire.txt` : certificats intermédiaires restants.
|
||||
|
||||
Protéger le fichier `.key` comme un secret.
|
||||
|
||||
### 10.2 Importer les certificats dans le WAF
|
||||
|
||||
Depuis la VM de télémaintenance, lancer **R&S Web Application** et se connecter à l'hôte `10.255.246.73`, port `3001`. Utiliser le compte `admin`; récupérer le mot de passe dans RDM.
|
||||
|
||||
1. Ouvrir **Setup > SSL > Certificates**.
|
||||
2. Cliquer sur **Add** et charger les trois fichiers dans les champs correspondants.
|
||||
3. Pour chaque application/tunnel concerné, cliquer sur **Modify**, ouvrir l'onglet **SSL**, sélectionner le certificat importé, puis confirmer avec **OK**.
|
||||
4. Appliquer la modification au tunnel.
|
||||
|
||||
Il est possible de traiter les tunnels un par un et de cliquer sur **Apply** après chacun, ou de modifier plusieurs tunnels puis d'appliquer les changements ensemble. Vérifier que chaque tunnel concerné utilise le nouveau certificat.
|
||||
|
||||
### 10.3 Vérifier le résultat
|
||||
|
||||
Depuis un navigateur côté Systel, ouvrir `https://sau.sapeurs-pompiers.mc` et contrôler le certificat présenté, notamment son domaine et ses dates.
|
||||
|
||||
La procédure source indique de ne pas tenir compte d'un message d'erreur et de regarder uniquement la date. Ne pas considérer une alerte de sécurité comme un résultat valide : si le navigateur signale une erreur TLS, vérifier le nom de domaine, la chaîne, la validité et l'application effective du certificat avant de clôturer l'intervention.
|
||||
|
||||
## 11. Contrôles finaux et nettoyage
|
||||
|
||||
- Vérifier chaque URL et chaque service concerné après le redémarrage.
|
||||
- Confirmer les dates, le nom du domaine et la chaîne de certification.
|
||||
- Conserver les copies de sauvegarde des certificats et configurations selon la politique de retour arrière.
|
||||
- Supprimer de façon sécurisée les PEM et fichiers temporaires contenant la clé privée lorsque les contrôles sont terminés et que leur conservation n'est plus nécessaire.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Espace disque toujours plein après la purge des journaux
|
||||
|
||||
## 1. Vérifier l'espace utilisé
|
||||
|
||||
Après la purge des journaux, vérifier de nouveau l'espace du système de fichiers racine :
|
||||
|
||||
```bash
|
||||
df -h /
|
||||
```
|
||||
|
||||
Si `/` est toujours à 100 %, repérer les fichiers volumineux du système de fichiers racine :
|
||||
|
||||
```bash
|
||||
sudo find / -xdev -type f -size +100M -print
|
||||
```
|
||||
|
||||
L'option `-xdev` limite la recherche au système de fichiers contenant `/`. Examiner les chemins et leur usage avant toute suppression; ne pas supprimer un fichier simplement parce qu'il est volumineux.
|
||||
|
||||
## 2. Vérifier l'espace occupé par journald
|
||||
|
||||
Consulter l'espace utilisé par le journal système :
|
||||
|
||||
```bash
|
||||
sudo journalctl --disk-usage
|
||||
```
|
||||
|
||||
Si journald occupe un espace excessif et que la politique de rétention l'autorise, supprimer les journaux archivés antérieurs à quatre semaines :
|
||||
|
||||
```bash
|
||||
sudo journalctl --vacuum-time=4weeks
|
||||
```
|
||||
|
||||
Adapter la durée à la politique de conservation des journaux. Cette opération supprime des journaux anciens qui pourraient être nécessaires à une analyse ultérieure.
|
||||
|
||||
## 3. Contrôler le résultat
|
||||
|
||||
Vérifier de nouveau l'espace disque et la taille des journaux :
|
||||
|
||||
```bash
|
||||
df -h /
|
||||
sudo journalctl --disk-usage
|
||||
```
|
||||
|
||||
Si le système de fichiers reste plein, réexaminer les fichiers volumineux et demander une analyse avant toute autre suppression.
|
||||
@@ -0,0 +1,104 @@
|
||||
# Mettre à jour HYCU
|
||||
|
||||
## 1. Vérifier le chemin de mise à niveau et télécharger le paquet
|
||||
|
||||
HYCU peut nécessiter des mises à niveau intermédiaires. Ne pas sauter de version sans vérifier le chemin pris en charge. Consulter les notes de version dans la documentation HYCU : [support.hycu.com](https://support.hycu.com/hc/en-us).
|
||||
|
||||
1. Se connecter au portail de support HYCU avec le compte dont les informations sont conservées dans RDM.
|
||||
2. Ouvrir la section **HYCU for Private Cloud & Data Centers**.
|
||||
3. Sélectionner les versions intermédiaires nécessaires et télécharger les paquets dans l'ordre indiqué par les notes de version.
|
||||
|
||||
Formats de paquet mentionnés dans la procédure source :
|
||||
|
||||
| Type et version HYCU | Plateforme / méthode | Paquet |
|
||||
| --- | --- | --- |
|
||||
| HYCU LEGACY, avant 5.2.0 | Nutanix | `.qcow2` |
|
||||
| HYCU LEGACY, avant 5.2.0 | VMware | `.vmdk` |
|
||||
| HYCU NEW, indiqué comme supérieur à 5.2.0 dans la source | Mise à jour depuis l'interface HYCU | `.hymig` |
|
||||
|
||||
La procédure indique également que la méthode HYCU NEW s'applique à partir de 5.2.0. Vérifier dans les notes de version le format de paquet et la méthode à utiliser pour la version exacte visée, notamment pour 5.2.0.
|
||||
|
||||
## 2. Prérequis et sauvegarde du contrôleur HYCU
|
||||
|
||||
Avant de commencer, s'assurer que la machine virtuelle du contrôleur HYCU est sauvegardée et qu'aucune alerte bloquante ne subsiste.
|
||||
|
||||
Si HYCU signale une sauvegarde requise :
|
||||
|
||||
1. Ouvrir **Virtual Machines**.
|
||||
2. Sélectionner la VM HYCU et cliquer sur **Backup**.
|
||||
3. Confirmer avec **Yes**.
|
||||
4. Attendre la fin de l'opération. Vérifier que les indicateurs d'état passent au vert et que l'alerte disparaît de la page principale.
|
||||
|
||||
Ne commencer la mise à jour qu'une fois cette sauvegarde terminée.
|
||||
|
||||
## 3. Mettre à jour HYCU LEGACY sur Nutanix
|
||||
|
||||
Répéter cette procédure pour chaque version intermédiaire requise.
|
||||
|
||||
1. Dans Prism Element, ouvrir les paramètres, puis l'onglet **Image Configuration**.
|
||||
2. Cliquer sur **Upload Image**.
|
||||
3. Nommer l'image selon le format `hycu-<Version>-<Revision>`. Exemple : `hycu-5.0.0-1491`.
|
||||
4. Sélectionner le type d'image **DISK** et importer le fichier `.qcow2` téléchargé.
|
||||
5. Dans l'interface HYCU, ouvrir les paramètres, puis **Software Update**.
|
||||
6. Vérifier que l'image chargée apparaît dans la liste des versions disponibles, puis confirmer la mise à jour.
|
||||
|
||||
L'assistant redirige vers la page **Welcome**. La VM HYCU s'arrête; un clone avec le suffixe `New` est créé et l'ancienne VM est renommée avec un suffixe correspondant à l'ancienne version. La nouvelle VM démarre avec l'adresse IP et les paramètres de l'ancienne.
|
||||
|
||||
Après le démarrage :
|
||||
|
||||
1. Attendre que la page d'accueil soit de nouveau disponible, puis se connecter à HYCU.
|
||||
2. Vérifier la version, l'accès à l'interface et le bon fonctionnement des services et des sauvegardes.
|
||||
3. Effectuer une sauvegarde du nouveau contrôleur HYCU.
|
||||
4. Ne supprimer l'ancienne VM qu'après validation complète et selon la procédure de conservation/retour arrière en vigueur.
|
||||
|
||||
## 4. Mettre à jour HYCU LEGACY sur VMware ESXi
|
||||
|
||||
La mise à jour sur VMware se fait en remplaçant le disque système HYCU. Procéder avec soin : conserver le disque retiré tant que la nouvelle version n'a pas été validée.
|
||||
|
||||
### 4.1 Suspendre les tâches et arrêter la VM
|
||||
|
||||
1. Dans HYCU, ouvrir **Settings > Power Options**.
|
||||
2. Sélectionner **Suspend all** pour suspendre les tâches de sauvegarde.
|
||||
3. Attendre la fin de toutes les tâches en cours.
|
||||
4. Dans l'interface VMware, ouvrir **Machines virtuelles > HYCU**, puis arrêter la VM.
|
||||
|
||||
### 4.2 Importer et placer le nouveau disque
|
||||
|
||||
1. Importer le fichier `.vmdk` dans un répertoire temporaire distinct du répertoire de la VM, par exemple `MAJ`.
|
||||
2. Attendre la fin du transfert. Vérifier que la progression atteint 100 % et que l'opération apparaît comme terminée.
|
||||
3. Copier le fichier `.vmdk` importé dans le répertoire de la VM.
|
||||
4. Vérifier que la copie est terminée avant de modifier la configuration matérielle de la VM.
|
||||
|
||||
### 4.3 Remplacer le disque système
|
||||
|
||||
1. Dans VMware, ouvrir **Machines virtuelles > HYCU > Modifier**.
|
||||
2. Retirer **Disque dur 2**, qui contient l'ancienne version du disque système `hycu-x-x-x-xxxx.vmdk`.
|
||||
3. Ne pas supprimer le fichier de l'ancien disque : le conserver pour un éventuel retour arrière.
|
||||
4. Enregistrer la modification.
|
||||
5. Modifier de nouveau la VM, puis sélectionner **Ajouter un disque dur > Disque dur existant**.
|
||||
6. Parcourir le datastore et sélectionner le nouveau fichier `.vmdk` copié dans le répertoire de la VM.
|
||||
7. Vérifier que le disque SCSI ajouté est le disque de démarrage (`0:0`), puis enregistrer.
|
||||
|
||||
La procédure source précise que le disque de 10 Go contient le système HYCU et que l'autre disque de 32 Go contient les paramètres et l'arborescence des sauvegardes. Vérifier les tailles et rôles des disques dans la configuration réelle avant toute modification.
|
||||
|
||||
### 4.4 Redémarrer et contrôler
|
||||
|
||||
1. Démarrer la VM et ouvrir sa console distante.
|
||||
2. Vérifier que HYCU démarre sur la version attendue.
|
||||
3. Se connecter à l'interface Web et contrôler le bon fonctionnement du contrôleur.
|
||||
4. Réactiver les tâches suspendues et vérifier l'état des sauvegardes.
|
||||
5. Après validation et selon la politique de retour arrière, supprimer les fichiers `.vmdk` de l'ancienne version dans le répertoire temporaire `MAJ` et dans le répertoire de la VM.
|
||||
|
||||
## 5. Mettre à jour HYCU NEW avec un paquet `.hymig`
|
||||
|
||||
Pour la méthode HYCU NEW, la procédure source indique qu'il n'est plus nécessaire d'importer une image dans Nutanix.
|
||||
|
||||
1. Depuis l'interface HYCU Controller, ouvrir **Settings > Software Upgrade**.
|
||||
2. Pour **Upgrade From**, sélectionner **Upload File**.
|
||||
3. Sélectionner le fichier `.hymig` correspondant à la version et au chemin de mise à niveau validés.
|
||||
4. Lancer la mise à jour et attendre qu'elle se termine sans interrompre le contrôleur.
|
||||
5. Se reconnecter à HYCU et vérifier la version, l'état des services et le bon fonctionnement des sauvegardes.
|
||||
|
||||
## 6. Vérifications finales
|
||||
|
||||
Pour le parcours utilisé, confirmer que le contrôleur HYCU est accessible, que la version attendue est installée et que les tâches de sauvegarde sont actives et s'exécutent normalement. Conserver les anciennes VM ou les anciens disques jusqu'à la fin de la période de validation prévue pour permettre un retour arrière.
|
||||
+139
@@ -0,0 +1,139 @@
|
||||
# Mettre en place un plan de sauvegarde HYCU
|
||||
|
||||
## 1. Prérequis
|
||||
|
||||
Installer et préparer le NAS Synology en suivant la procédure [Installation serveur NAS Synology](https://tfs2k18.systel-sa.com/tfs/Systel/Etudes/_wiki/wikis/Etudes.wiki/1648/Installation-serveur-NAS-Synology).
|
||||
|
||||
Avant de commencer, confirmer le modèle du ou des NAS et le nombre d'instances HYCU. Les dossiers à créer et les cibles à déclarer dépendent de l'architecture retenue.
|
||||
|
||||
## 2. Préparer le NAS
|
||||
|
||||
### 2.1 Créer l'utilisateur HYCU
|
||||
|
||||
Dans le Panneau de configuration du NAS, ouvrir **Utilisateur et groupe**, puis **Créer un utilisateur**. Créer un compte dédié à HYCU. Générer son mot de passe avec RDM, l'y enregistrer et accorder à ce compte les accès nécessaires aux dossiers de sauvegarde.
|
||||
|
||||
Pour les options de l'assistant qui ne sont pas précisées ici, appliquer la configuration validée pour le NAS concerné.
|
||||
|
||||
### 2.2 Créer les dossiers partagés
|
||||
|
||||
Dans **Panneau de configuration > Dossier partagé > Créer un dossier partagé**, créer les dossiers selon le modèle du NAS et l'architecture :
|
||||
|
||||
| Modèle et rôle | Dossiers partagés |
|
||||
| --- | --- |
|
||||
| RS1619xs+, NAS 1 | `hycu_daily`, `hycu1_archive1mois`, `hycu1_archive3mois`, `hycu1_archive6mois` |
|
||||
| RS1619xs+, NAS 2 | `hycu_daily`, `hycu2_archive1mois`, `hycu2_archive3mois`, `hycu2_archive6mois`* |
|
||||
| RS3621xs+, NAS 1 | `hycu_daily`, `hycu1_archive1mois`, `hycu1_archive6mois`, `hycu1_archive12mois`** |
|
||||
| RS3621xs+, NAS 2 | `hycu_daily`, `hycu2_archive1mois`, `hycu2_archive6mois`, `hycu2_archive12mois`* ** |
|
||||
|
||||
`*` Les dossiers d'archives du NAS 2 sont requis uniquement lorsque deux instances HYCU sont utilisées.
|
||||
|
||||
`**` Pour créer des dossiers immuables sur un NAS RS3621xs+, suivre la procédure [NAS immuable (RPS3621RSxs)](https://tfs2k18.systel-sa.com/tfs/Systel/Etudes/_wiki/wikis/Etudes.wiki/2325/NAS-Immuable-(RPS3621RSxs)).
|
||||
|
||||
Lors de la création des dossiers, activer la somme de contrôle des données et autoriser l'utilisateur HYCU à y accéder. Appliquer les autres options selon la configuration validée du NAS.
|
||||
|
||||
## 3. Déclarer les cibles SMB dans HYCU
|
||||
|
||||
Dans HYCU, ouvrir l'onglet **Target**. Chaque dossier partagé nécessaire doit être déclaré comme cible sur la ou les instances HYCU concernées.
|
||||
|
||||
| Target Name | Dossier NAS indiqué dans la source | Compression | Use for archiving |
|
||||
| --- | --- | --- | --- |
|
||||
| `nas1_daily` | `hycu_daily` | Oui | Non |
|
||||
| `nas1_archive1mois` | `hycu_archive1mois` | Oui | Oui |
|
||||
| `nas1_archive3mois` | `hycu_archive3mois` | Oui | Oui |
|
||||
| `nas1_archive6mois` | `hycu_archive6mois` | Oui | Oui |
|
||||
| `nas2_daily`* | `hycu_daily` sur le NAS 2 | Oui | Non |
|
||||
|
||||
`*` En présence d'un deuxième NAS, ajouter la cible `nas2_daily` hébergée sur le NAS 2. Dans une infrastructure complète à deux instances HYCU, déclarer sur HYCU2 les dossiers partagés du NAS 2 ainsi que la cible Daily du NAS 1.
|
||||
|
||||
**Vérification des noms :** le tableau des cibles ci-dessus utilise `hycu_archive...`, tandis que le tableau de création des dossiers utilise les préfixes `hycu1_` et `hycu2_`. Vérifier le nom réel du dossier partagé sur le NAS et sélectionner ce nom à l'identique dans HYCU. Ne pas créer de dossier supplémentaire uniquement pour résoudre cette différence.
|
||||
|
||||
Pour créer une cible :
|
||||
|
||||
1. Cliquer sur **Add**, puis sélectionner **SMB**.
|
||||
2. Renseigner le nom de la cible et le nombre de sauvegardes simultanées adapté à l'environnement.
|
||||
3. Indiquer l'adresse IP du NAS, le nom du dossier partagé et le compte HYCU. Récupérer son mot de passe dans RDM.
|
||||
4. Activer la compression. Activer **Use for archiving** pour les cibles d'archives, et la désactiver pour les cibles Daily.
|
||||
5. Répéter l'opération pour les autres cibles nécessaires.
|
||||
|
||||
## 4. Créer les politiques d'archivage
|
||||
|
||||
Dans **Policies > Archiving**, créer les politiques ci-dessous. L'heure de début indiquée dans la procédure source est `12 AM`.
|
||||
|
||||
| Nom de la politique | Option | Début | Hebdomadaire | Mensuel |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `Archive_faible` | Weekly | `12 AM` | Friday, récurrence toutes les 4 semaines, rétention 4 semaines, cible `nas1_archive1mois` | Aucun |
|
||||
| `Archive_moyen` | Weekly | `12 AM` | Friday, récurrence toutes les semaines, rétention 4 semaines, cible `nas1_archive1mois` | Aucun |
|
||||
| `Archive_forte` | Weekly, Monthly | `12 AM` | Saturday, récurrence toutes les semaines, rétention 4 semaines, cible `nas1_archive1mois` | First Saturday, rétention 3 mois, cible `nas1_archive3mois` |
|
||||
| `Archive_critique` | Weekly, Monthly | `12 AM` | Sunday, récurrence toutes les semaines, rétention 4 semaines, cible `nas1_archive1mois` | First Sunday, rétention 6 mois, cible `nas1_archive6mois` |
|
||||
|
||||
Créer chaque politique, renseigner ses paramètres conformément au tableau et vérifier que les cibles d'archivage existent dans HYCU.
|
||||
|
||||
## 5. Créer les fenêtres de sauvegarde
|
||||
|
||||
Dans **Policies > Time Window**, cliquer sur **Add**, puis sélectionner **Backup window**. Créer les fenêtres suivantes :
|
||||
|
||||
| Nom | Lun. | Mar. | Mer. | Jeu. | Ven. | Sam. | Dim. |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| `backupwindow_faible` | INCR 00h-08h | INCR 00h-08h | INCR 00h-08h | INCR 00h-08h | FULL 00h-08h | INCR 00h-08h | INCR 00h-08h |
|
||||
| `backupwindow_moyen` | INCR 00h-08h | INCR 00h-08h | INCR 00h-08h | INCR 00h-08h | FULL 00h-08h | INCR 00h-08h | INCR 00h-08h |
|
||||
| `backupwindow_forte` | INCR 00h-08h | INCR 00h-08h | INCR 00h-08h | INCR 00h-08h | INCR 00h-08h | FULL 00h-08h | INCR 00h-08h |
|
||||
| `backupwindow_critique` | INCR 00h-08h | INCR 00h-08h | INCR 00h-08h | INCR 00h-08h | INCR 00h-08h | INCR 00h-08h | FULL 00h-08h |
|
||||
|
||||
Pour une architecture à deux NAS, créer également une fenêtre de copie en sélectionnant **Add > Copy window** :
|
||||
|
||||
| Nom | Lun. | Mar. | Mer. | Jeu. | Ven. | Sam. | Dim. |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| `Copy window` | 19-00h | 19-00h | 19-00h | 19-00h | 19-00h | 19-00h | 19-00h |
|
||||
|
||||
La source indique `19-00h` pour chaque jour. Vérifier le format attendu par la version de HYCU utilisée avant d'enregistrer la fenêtre.
|
||||
|
||||
## 6. Créer les politiques de sauvegarde
|
||||
|
||||
Dans l'onglet **Policies**, sélectionner une politique par défaut (**Bronze**, **Silver** ou **Gold**) et cliquer sur **Edit**. Pour la quatrième politique, cliquer sur **New**.
|
||||
|
||||
| Policy Name | Backup / Recover / Retention | Backup chain | Target | Backup window | Archiving |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| `policy_faible` | 1 day / 1 day / 1 week | 7 days | `nas1_daily` | `backupwindow_faible` | `Archive_faible` |
|
||||
| `policy_moyen` | 1 day / 1 day / 1 week | 7 days | `nas1_daily` | `backupwindow_moyen` | `Archive_moyen` |
|
||||
| `policy_forte` | 1 day / 1 day / 1 week | 7 days | `nas1_daily` | `backupwindow_forte` | `Archive_forte` |
|
||||
| `policy_critique` | 1 day / 1 day / 2 weeks | 7 days | `nas1_daily` | `backupwindow_critique` | `Archive_critique` |
|
||||
|
||||
Renseigner et vérifier les paramètres de chaque politique selon le tableau.
|
||||
|
||||
## 7. Affecter les machines virtuelles
|
||||
|
||||
Dans l'onglet **Virtual Machines**, sélectionner une ou plusieurs VM, cliquer sur **Set policy**, puis attribuer la politique correspondante :
|
||||
|
||||
| Politique | Type de VM | Exemples |
|
||||
| --- | --- | --- |
|
||||
| `policy_faible` | VM de Formation ou de Test | `BDF`, `MultiF`, `MultiT` |
|
||||
| `policy_moyen` | VM secondaire ou annexe | `Multi2`, `Start2`, `RPINT2`, `Prev`, `HYCU`, `centreon-poller`, `Telem`, `Bastion` |
|
||||
| `policy_forte` | VM principale ou unitaire, et `AD2` | `AD1`, `AD2`, `Multi1`, `Start1`, `RPINT1`, `Broker1`, `NFS`, `DWH` |
|
||||
| `policy_critique` | VM de base de données | `BD1`, `BD2` |
|
||||
|
||||
Vérifier les affectations dans HYCU après l'application des politiques.
|
||||
|
||||
## 8. Configuration avec deux NAS
|
||||
|
||||
### 8.1 Copier les sauvegardes courantes
|
||||
|
||||
Créer sur le NAS 2 le dossier partagé `HYCU - Daily`, puis l'ajouter comme cible dans HYCU.
|
||||
|
||||
Dans les paramètres de chaque politique de sauvegarde concernée, activer **Copy**. Ajouter la cible du NAS 2, définir une rétention d'une semaine, activer l'option **Window** et sélectionner la fenêtre **Copy window** créée précédemment.
|
||||
|
||||
### 8.2 Synchroniser les dossiers d'archives avec Rsync
|
||||
|
||||
La procédure source indique que HYCU ne gère pas plusieurs copies d'archives. Utiliser Rsync pour synchroniser les dossiers d'archives entre les deux NAS.
|
||||
|
||||
Prérequis : les deux NAS doivent pouvoir communiquer entre eux sur le port `22` (SSH).
|
||||
|
||||
Sur chaque NAS :
|
||||
|
||||
1. Dans **Panneau de configuration > Services de fichiers > Rsync**, activer le service Rsync.
|
||||
2. Dans l'onglet **Avancé**, ouvrir la liste des tâches et cliquer sur **Créer**.
|
||||
3. Nommer la tâche et sélectionner le dossier d'archives à synchroniser.
|
||||
4. Renseigner les identifiants de l'autre NAS et activer la compression.
|
||||
5. Planifier la copie en dehors des périodes de sauvegarde afin de limiter la charge du NAS.
|
||||
6. Répéter l'opération pour chaque dossier d'archives.
|
||||
|
||||
Lors d'un déploiement complet comportant deux instances HYCU, créer également les règles de synchronisation dans l'autre sens pour les archives de HYCU2.
|
||||
@@ -0,0 +1,51 @@
|
||||
# Exporter une machine virtuelle depuis un hyperviseur ESXi
|
||||
|
||||
Deux méthodes sont décrites ci-dessous : l'export avec le script `export_vm_esxi.sh` ou l'export manuel depuis l'interface Web ESXi.
|
||||
|
||||
## 1. Exporter avec le script CLI
|
||||
|
||||
Le script se trouve dans le dépôt Git `F5CloudNative/tools/esxi/export_vm_esxi.sh`. Le récupérer sur la machine depuis laquelle l'export sera exécuté.
|
||||
|
||||
### 1.1 Paramètres
|
||||
|
||||
| Option | Description | Obligatoire |
|
||||
| --- | --- | --- |
|
||||
| `-r` ou `--remote_esxi` | Adresse IP de l'hyperviseur ESXi source | Oui |
|
||||
| `-u` ou `--user` | Compte autorisé à accéder à ESXi | Oui |
|
||||
| `-p` ou `--password` | Mot de passe du compte ESXi | Oui |
|
||||
| `-v` ou `--version` | Version matérielle de la VM à exporter, par exemple `1-19-3` | Oui |
|
||||
| `-d` ou `--export_dir` | Répertoire local de destination | Oui |
|
||||
| `-sv` ou `--src_vm` | Nom de la VM source sur ESXi | Oui |
|
||||
| `-dv` ou `--dst_vm` | Nom de la VM à donner aux fichiers exportés | Oui |
|
||||
| `-h` ou `--help` | Affiche l'aide | Non |
|
||||
|
||||
Vérifier les noms d'options disponibles avec `--help` si la version du script diffère.
|
||||
|
||||
### 1.2 Lancer l'export
|
||||
|
||||
Exécuter le script en remplaçant les valeurs d'exemple par celles de l'environnement :
|
||||
|
||||
```bash
|
||||
./export_vm_esxi.sh \
|
||||
-r '<IP_ESXI>' \\
|
||||
-u '<UTILISATEUR_ESXI>' \
|
||||
-p '<MOT_DE_PASSE>' \
|
||||
-v '<VERSION_VM>' \\
|
||||
-d '<REPERTOIRE_DESTINATION>' \\
|
||||
-sv '<NOM_VM_SOURCE>' \
|
||||
-dv '<NOM_VM_EXPORT>'
|
||||
```
|
||||
|
||||
Récupérer les identifiants dans RDM. Ne pas inscrire un mot de passe réel dans cette procédure ni dans un historique de commandes partagé. Si le script ou l'environnement propose un mode de saisie sécurisé, le privilégier.
|
||||
|
||||
Le script crée un répertoire de destination à partir du nom de VM choisi et de sa version, puis exporte le paquet OVF. L'opération peut prendre plusieurs minutes selon la taille de la VM et le débit réseau. Attendre la fin du processus.
|
||||
|
||||
L'export est terminé lorsque le script indique une réussite, par exemple `VM successfully export` et `Finish`. Le script source retire également le fichier NVRAM exporté et son entrée dans le fichier OVF.
|
||||
|
||||
## 2. Exporter manuellement depuis l'interface ESXi
|
||||
|
||||
1. Vérifier que la VM à exporter est arrêtée. L'option d'export n'est pas disponible si elle est en fonctionnement.
|
||||
2. Dans l'interface ESXi, faire un clic droit sur la VM et sélectionner **Exporter**.
|
||||
3. Télécharger un par un les fichiers proposés par l'hyperviseur.
|
||||
4. Enregistrer tous les fichiers de la VM dans le même répertoire local et conserver leurs noms afin que le fichier OVF puisse retrouver les disques associés.
|
||||
5. Attendre la fin de chaque téléchargement et vérifier que tous les fichiers proposés ont été récupérés.
|
||||
@@ -0,0 +1,69 @@
|
||||
# Importer une machine virtuelle sur un hyperviseur ESXi
|
||||
|
||||
Deux méthodes sont décrites ci-dessous : importer la VM avec le script `import_vm_esxi.sh` ou utiliser l'assistant de déploiement OVF dans l'interface ESXi.
|
||||
|
||||
## 1. Préparer les fichiers et la destination
|
||||
|
||||
Récupérer le dossier d'export de la VM depuis le partage Cloud indiqué pour l'intervention. Le paquet doit contenir le fichier OVF et les fichiers de disque associés, notamment les VMDK.
|
||||
|
||||
Avant l'import, confirmer :
|
||||
|
||||
- l'hôte ESXi cible et les identifiants d'accès, disponibles dans RDM;
|
||||
- le nom du datastore cible et l'espace disponible;
|
||||
- le nom du réseau/port group ESXi correspondant à l'environnement cible;
|
||||
- le nom à donner à la VM afin d'éviter un conflit avec une VM existante.
|
||||
|
||||
Le dossier source de la procédure mentionne `VM-K8S-READY` à la racine du script comme exemple de paquet à importer. Remplacer cet exemple par les fichiers de la VM concernée.
|
||||
|
||||
## 2. Importer avec le script CLI
|
||||
|
||||
Le script est indiqué dans le dépôt comme `F5_CloudNative/tools/esxi/import_vm_esxi.sh`. Vérifier le chemin du dépôt et les options reconnues par la version utilisée avec `--help`; la procédure d'export cite un dépôt nommé `F5CloudNative` sans soulignement.
|
||||
|
||||
### 2.1 Paramètres
|
||||
|
||||
| Option | Description | Obligatoire |
|
||||
| --- | --- | --- |
|
||||
| `-r` ou `--remote_esxi` | Adresse IP de l'hyperviseur ESXi cible | Oui |
|
||||
| `-u` ou `--user` | Compte autorisé à accéder à ESXi | Oui |
|
||||
| `-p` ou `--password` | Mot de passe du compte ESXi | Oui |
|
||||
| `-v` ou `--version` | Version matérielle de la VM, par exemple `1-19-3` | Oui |
|
||||
| `-f` ou `--file` | Chemin local du fichier ou paquet OVF à importer | Oui |
|
||||
| `-n` ou `--name` | Nom de la VM sur ESXi | Oui |
|
||||
| `-net` ou `--network` | Nom du réseau/port group ESXi | Oui |
|
||||
| `-d` ou `--datastore` | Nom du datastore ESXi | Oui |
|
||||
| `-h` ou `--help` | Affiche l'aide | Non |
|
||||
|
||||
### 2.2 Lancer l'import
|
||||
|
||||
Adapter les valeurs au paquet et à l'infrastructure cible :
|
||||
|
||||
```bash
|
||||
./import_vm_esxi.sh \\
|
||||
-r '<IP_ESXI>' \\
|
||||
-u '<UTILISATEUR_ESXI>' \\
|
||||
-p '<MOT_DE_PASSE>' \\
|
||||
-v '<VERSION_VM>' \\
|
||||
-f '<CHEMIN_DU_FICHIER_OVF>' \\
|
||||
-n '<NOM_VM_CIBLE>' \\
|
||||
-net '<RESEAU_ESXI>' \\
|
||||
-d '<DATASTORE_ESXI>'
|
||||
```
|
||||
|
||||
Un exemple de réseau fourni dans la procédure source est `Systel PREPROD Network`; utiliser le port group réellement prévu pour l'environnement cible.
|
||||
|
||||
La procédure contient deux formes différentes pour l'option `-f` : un exemple donne le répertoire d'export, tandis que la commande détaillée donne le chemin du fichier `.ovf`. Vérifier l'aide du script ou sa documentation et utiliser le format attendu par cette version. L'exemple détaillé ci-dessus indique le fichier OVF.
|
||||
|
||||
Récupérer les identifiants dans RDM. Ne pas inscrire de mot de passe réel dans la procédure ni dans un historique de commandes partagé. Si le script ou l'environnement permet une saisie sécurisée, la privilégier.
|
||||
|
||||
Attendre la fin de l'import, qui peut prendre plusieurs minutes selon la taille de la VM et le débit réseau. L'opération est terminée lorsque le script signale la réussite de l'import.
|
||||
|
||||
## 3. Importer manuellement depuis l'interface ESXi
|
||||
|
||||
1. Dans l'interface ESXi, cliquer sur **Créer/Enregistrer une machine virtuelle**.
|
||||
2. Sélectionner **Déployer une machine virtuelle à partir d'un fichier OVF**.
|
||||
3. Sélectionner le fichier OVF ainsi que tous les fichiers VMDK associés à la VM.
|
||||
4. Sélectionner le stockage/datastore où la VM sera importée et stockée.
|
||||
5. Configurer le mappage réseau, le type de provisionnement du disque et le démarrage automatique de la VM au terme du déploiement.
|
||||
6. Vérifier le récapitulatif des options, puis valider l'importation.
|
||||
|
||||
Après le déploiement, vérifier que la VM apparaît dans l'inventaire, que son réseau est correctement mappé et qu'elle démarre comme prévu avant sa remise en service.
|
||||
@@ -0,0 +1,180 @@
|
||||
# Mettre à jour un serveur VMware ESXi
|
||||
|
||||
## 1. Prérequis et ordre des opérations
|
||||
|
||||
> **Interruption de service :** cette opération nécessite l'arrêt de toutes les machines virtuelles hébergées sur le serveur ESXi.
|
||||
|
||||
> **Ordre requis :** mettre à jour le firmware avant l'hyperviseur. Si un vCenter est présent, le mettre à jour avant ESXi.
|
||||
|
||||
Cette procédure décrit une mise à jour vers VMware ESXi 8.0 Update 3. La source indique que cette mise à jour est possible depuis les versions 6.7 et 7.0. Vérifier la compatibilité matérielle, le chemin de mise à niveau et la version recommandée auprès des experts Infrastructure avant de commencer.
|
||||
|
||||
Les mises à jour firmware et iLO des serveurs HPE sont fournies dans les paquets **SPP (Service Pack for ProLiant)**. Le paquet ESXi est spécifique aux serveurs HPE ProLiant. Demander aux experts Infrastructure les versions et paquets recommandés pour le serveur concerné.
|
||||
|
||||
Les paquets sont disponibles dans les répertoires suivants :
|
||||
|
||||
```text
|
||||
\\cloud\Produits\Produits_tiers\HPE\Service Pack for Proliant
|
||||
\\cloud\Produits\Produits_tiers\VMWare\VMware_ESXi
|
||||
```
|
||||
|
||||
Avant l'intervention, confirmer le plan d'arrêt et de redémarrage des VM avec les équipes responsables. Prévoir un accès à iLO et à l'interface ESXi ou vCenter.
|
||||
|
||||
## 2. Arrêter les machines virtuelles
|
||||
|
||||
L'ordre et les modalités d'arrêt des services applicatifs doivent être confirmés avec leurs responsables.
|
||||
|
||||
### 2.1 SQL Witness
|
||||
|
||||
Consulter les experts SQL avant d'arrêter la VM SQL Witness.
|
||||
|
||||
### 2.2 Nœud SWARM
|
||||
|
||||
Confirmer le nom exact du nœud avant d'exécuter les commandes : le titre de la procédure source mentionne `SWARM-MANAGER-03`, tandis que sa commande utilise `SWARM-MANAGER-LIVE-03`.
|
||||
|
||||
Sur un manager Swarm, drainer le nœud concerné :
|
||||
|
||||
```bash
|
||||
docker node update --availability drain SWARM-MANAGER-LIVE-03
|
||||
docker node ls
|
||||
docker ps
|
||||
```
|
||||
|
||||
Vérifier avec `docker node ls` que le nœud est drainé et qu'aucune activité ne subsiste avant l'arrêt. Si l'arrêt de la machine est confirmé :
|
||||
|
||||
```bash
|
||||
shutdown -h now
|
||||
```
|
||||
|
||||
Après le redémarrage, réactiver le nœud avec son nom exact :
|
||||
|
||||
```bash
|
||||
docker node update --availability active SWARM-MANAGER-LIVE-03
|
||||
```
|
||||
|
||||
En cas de doute, contacter les DevOps dans Teams, canal `COM-SUPPORTS > DDP - DevOps`.
|
||||
|
||||
### 2.3 Contrôleur HYCU
|
||||
|
||||
1. Se connecter à l'interface HYCU et ouvrir **Jobs**.
|
||||
2. Vérifier qu'aucune sauvegarde n'est en cours.
|
||||
3. Dans les paramètres, ouvrir **Power Options** et cliquer sur **Suspend All** pour empêcher le lancement de nouvelles sauvegardes pendant l'arrêt et le redémarrage.
|
||||
4. Arrêter la VM HYCU depuis ESXi ou vCenter.
|
||||
5. Après le redémarrage, retourner dans **Power Options** et retirer la suspension.
|
||||
|
||||
### 2.4 vCenter
|
||||
|
||||
Si un vCenter est présent, appliquer sa mise à jour avant celle de l'hôte ESXi. Suivre la procédure [Mise à jour VMware vCenter 7 vers 8](https://tfs2k18.systel-sa.com/tfs/Systel/Etudes/_wiki/wikis/Etudes.wiki/2635/MAJ-VMWare-vCenter-7-vers-8).
|
||||
|
||||
Pour l'arrêt du vCenter avant la mise à jour de l'hôte :
|
||||
|
||||
1. Éteindre toutes les autres VM hébergées sur l'hôte.
|
||||
2. Se connecter à **vCenter Server Management** sur `https://IP_vCenter:5480` avec le compte `root`.
|
||||
3. Dans **Actions**, sélectionner **Arrêt** et confirmer si une demande apparaît.
|
||||
|
||||
## 3. Mettre l'hôte ESXi en maintenance
|
||||
|
||||
1. Ouvrir l'interface Web de l'hyperviseur ESXi.
|
||||
2. Vérifier que toutes les VM de l'hôte sont arrêtées.
|
||||
3. Dans le menu de l'hôte, sélectionner **Entrer en mode de maintenance**.
|
||||
4. Confirmer si une fenêtre de confirmation apparaît.
|
||||
5. Vérifier sur la page d'accueil de l'ESXi que l'hôte est bien en mode maintenance.
|
||||
|
||||
## 4. Mettre à jour le firmware HPE avec le SPP
|
||||
|
||||
1. Ouvrir l'interface iLO du serveur et lancer la console distante.
|
||||
2. Depuis la console, monter ou importer le fichier ISO SPP, puis confirmer l'opération.
|
||||
3. Redémarrer le serveur.
|
||||
4. Au démarrage, appuyer sur `F11` pour ouvrir le menu **One-Time Boot Menu**.
|
||||
5. Sélectionner l'entrée correspondant au média SPP monté. Vérifier son libellé dans le menu avant de la choisir.
|
||||
6. Sélectionner **Automatic** pour lancer la mise à jour automatisée.
|
||||
|
||||
La procédure source estime la durée de l'opération à une à deux heures. Ne pas interrompre le serveur. La console iLO peut redémarrer pendant l'installation; se reconnecter si nécessaire pour suivre la suite du processus. Si iLO affiche un message pendant l'installation, ne pas intervenir sans confirmation des experts Infrastructure : les redémarrages peuvent faire partie du processus automatisé.
|
||||
|
||||
Si la console iLO ne se reconnecte pas correctement, vider le cache du navigateur puis réessayer.
|
||||
|
||||
## 5. Mettre à jour ESXi
|
||||
|
||||
Après la mise à jour du firmware, vérifier que l'hôte est démarré et toujours en mode maintenance.
|
||||
|
||||
### 5.1 Déposer le paquet sur un datastore
|
||||
|
||||
1. Dans l'interface ESXi, ouvrir **Stockage > Parcourir les banques de données**.
|
||||
2. Ouvrir le répertoire de mise à jour souhaité ou en créer un.
|
||||
3. Utiliser **Télécharger** pour déposer le paquet ESXi `.zip` sur le datastore.
|
||||
|
||||
### 5.2 Activer SSH et relever le profil
|
||||
|
||||
Activer SSH dans **Hôte > Services > Activer Secure Shell (SSH)**, puis se connecter à l'hôte en SSH.
|
||||
|
||||
Vérifier le mode maintenance :
|
||||
|
||||
```bash
|
||||
esxcli system maintenanceMode get
|
||||
```
|
||||
|
||||
Lister les profils disponibles dans le paquet en remplaçant le chemin par celui du fichier `.zip` :
|
||||
|
||||
```bash
|
||||
esxcli software sources profile list -d <chemin-complet-vers-le-fichier.zip>
|
||||
```
|
||||
|
||||
Exemple :
|
||||
|
||||
```bash
|
||||
esxcli software sources profile list -d /vmfs/volumes/datastore/MAJ/Update.zip
|
||||
```
|
||||
|
||||
Noter le nom exact du profil souhaité pour la commande suivante.
|
||||
|
||||
### 5.3 Installer le profil et redémarrer
|
||||
|
||||
Lancer la mise à jour en remplaçant le chemin et le profil par les valeurs relevées :
|
||||
|
||||
```bash
|
||||
esxcli software profile update -d <chemin-complet-vers-le-fichier.zip> -p <nom-du-profil>
|
||||
```
|
||||
|
||||
Exemple fourni dans la procédure source :
|
||||
|
||||
```bash
|
||||
esxcli software profile update -d /vmfs/volumes/datastore/MAJ/Update.zip -p HPE-Custom-AddOn_803.0.0.12.1.0-11
|
||||
```
|
||||
|
||||
Après la fin de la commande, redémarrer l'hôte :
|
||||
|
||||
```bash
|
||||
esxcli system shutdown reboot --reason "maj vers 8.0U3"
|
||||
```
|
||||
|
||||
Après le redémarrage, vérifier la version ESXi et l'état de l'hôte, puis quitter le mode maintenance si les contrôles sont concluants.
|
||||
|
||||
## 6. Vérifier ou appliquer la licence ESXi
|
||||
|
||||
Ouvrir **Hôte > Gérer > Attribution de licence** et vérifier la licence installée.
|
||||
|
||||
Une mise à jour de version majeure, par exemple de 7.0 à 8.0, nécessite une licence compatible avec la version installée. Si une nouvelle licence est nécessaire :
|
||||
|
||||
1. Se connecter à [Broadcom Support](https://support.broadcom.com/) avec le compte de licence dont les informations sont conservées dans `RDM > COMMUN`.
|
||||
2. Ouvrir **Entitlements** et développer les détails jusqu'à la section **License** pour ESXi.
|
||||
3. Relever la clé au format `XXXXX-XXXXX-XXXXX-XXXXX-XXXXX`.
|
||||
4. Dans ESXi, ouvrir **Hôte > Gérer > Attribution de licence**, choisir **Attribuer une licence**, saisir la clé et cliquer sur **Vérifier la licence**.
|
||||
5. Après validation, cliquer sur **Attribuer une licence** et vérifier que l'attribution est effective.
|
||||
|
||||
Ne pas inscrire la clé de licence dans cette procédure.
|
||||
|
||||
## 7. Mettre à jour VMware Tools
|
||||
|
||||
> La mise à jour de VMware Tools peut nécessiter le redémarrage de la VM. Prévoir l'interruption avec les responsables applicatifs.
|
||||
|
||||
Après la mise à jour de l'hôte, vérifier les VM et mettre à jour VMware Tools lorsqu'une version plus récente est disponible :
|
||||
|
||||
1. Sélectionner la VM dans ESXi ou vCenter.
|
||||
2. Ouvrir **Actions > SE invité > Mettre à niveau VMware Tools**.
|
||||
3. Attendre la fin de l'installation et effectuer le redémarrage requis.
|
||||
4. Vérifier dans la description de la VM que VMware Tools est conforme.
|
||||
|
||||
Répéter pour chaque VM concernée.
|
||||
|
||||
## 8. Remise en service
|
||||
|
||||
Vérifier le bon fonctionnement de l'hôte et des VM, puis confirmer que les services applicatifs sont opérationnels. Réactiver les tâches HYCU suspendues et réactiver le nœud Swarm après validation des équipes concernées.
|
||||
@@ -0,0 +1,22 @@
|
||||
# Ajouter ou retirer des nœuds dans un cluster Nutanix
|
||||
|
||||
## 1. Prérequis
|
||||
|
||||
L'ajout et le retrait de nœuds modifient la capacité et la configuration du cluster. Avant toute intervention, confirmer le cluster cible, la compatibilité des nœuds et le plan d'adressage avec les équipes responsables. Vérifier également l'état du cluster et les prérequis de la version de Prism utilisée.
|
||||
|
||||
## 2. Ajouter des nœuds
|
||||
|
||||
Dans Prism Element, ouvrir **Hardware > Expand Cluster**.
|
||||
|
||||
1. Sélectionner les nœuds à ajouter.
|
||||
2. Renseigner les adresses IPv4 prévues pour chaque nœud :
|
||||
- CVM;
|
||||
- hyperviseur (host);
|
||||
- IPMI.
|
||||
3. Définir **Node Type** sur `HCI`.
|
||||
|
||||
**Important :** la procédure source ne décrit pas les écrans suivants ni les validations finales de l'assistant. Avant de lancer l'expansion, suivre la procédure approuvée pour la version de Nutanix/Prism du cluster et vérifier les valeurs saisies. Ne pas confirmer l'opération en se basant uniquement sur les indications de cette page.
|
||||
|
||||
## 3. Retirer des nœuds
|
||||
|
||||
La procédure source ne fournit aucune étape textuelle de retrait. Ne pas lancer le retrait à partir de ce seul document : consulter la procédure Nutanix validée pour la version du cluster et faire confirmer le plan d'intervention par les équipes responsables avant toute action.
|
||||
@@ -0,0 +1,85 @@
|
||||
# Mettre à jour une infrastructure Nutanix
|
||||
|
||||
## 1. Prérequis
|
||||
|
||||
Avant l'intervention :
|
||||
|
||||
- Vérifier que les sauvegardes sont saines dans HYCU ou Veeam.
|
||||
- Vérifier que Prism Central et les clusters peuvent joindre les services Nutanix nécessaires. Se référer à la matrice de flux. Si l'environnement n'a pas d'accès, utiliser la méthode **Dark Site Direct Upload** selon la procédure prévue.
|
||||
- Vérifier les versions source et cible ainsi que la matrice de compatibilité Nutanix avec l'équipe Infrastructure.
|
||||
|
||||
Traiter les erreurs de santé avant de commencer. Si un contrôle signale une sévérité `ERROR`, `FAIL` ou `WARNING`, contacter l'équipe Infrastructure et ne poursuivre qu'après résolution ou validation explicite.
|
||||
|
||||
## 2. Mettre à jour Prism Central
|
||||
|
||||
### 2.1 Vérifier l'état de santé
|
||||
|
||||
Se connecter en SSH à Prism Central et lancer :
|
||||
|
||||
```bash
|
||||
ncc health_checks run_all
|
||||
```
|
||||
|
||||
Examiner le résultat et résoudre les alertes bloquantes avec l'équipe Infrastructure avant la mise à jour.
|
||||
|
||||
### 2.2 Lancer la mise à jour
|
||||
|
||||
1. Se connecter à l'interface Prism Central.
|
||||
2. Ouvrir **Admin Center > LCM** (Life Cycle Manager).
|
||||
3. Dans l'onglet **Inventory**, cliquer sur **Perform Inventory** pour actualiser l'inventaire et les mises à jour disponibles.
|
||||
4. Lancer la mise à jour validée pour Prism Central et suivre son avancement dans LCM.
|
||||
|
||||
Prism Central télécharge le paquet depuis Nutanix, effectue les contrôles préalables, puis exécute la mise à jour. La durée estimée par la procédure source est d'une à deux heures. Prism Central redémarre pendant l'opération; une interruption d'accès de cinq à dix minutes est à prévoir.
|
||||
|
||||
Lorsque l'accès revient, retourner dans **Admin Center > LCM** et vérifier l'état de la mise à jour.
|
||||
|
||||
## 3. Préparer chaque cluster (Prism Element)
|
||||
|
||||
Répéter les vérifications et la mise à jour de cette section pour chaque cluster du client.
|
||||
|
||||
### 3.1 Vérifier l'état de santé
|
||||
|
||||
Se connecter en SSH à une CVM du cluster et lancer :
|
||||
|
||||
```bash
|
||||
ncc health_checks run_all
|
||||
```
|
||||
|
||||
Résoudre les alertes `ERROR`, `FAIL` et `WARNING` avec l'équipe Infrastructure avant de poursuivre.
|
||||
|
||||
### 3.2 Vérifier les VM en mode agent
|
||||
|
||||
Une VM en mode agent est liée à l'hôte sur lequel elle s'exécute. Elle ne migre pas automatiquement si cet hôte redémarre pendant la mise à jour.
|
||||
|
||||
Rechercher les VM en mode agent :
|
||||
|
||||
```bash
|
||||
acli vm.get \* | grep -B10 "agent_vm: True" | egrep "agent|\{"
|
||||
```
|
||||
|
||||
Si la commande ne retourne aucun résultat, aucune VM en mode agent n'a été détectée.
|
||||
|
||||
Si une VM apparaît :
|
||||
|
||||
1. Ouvrir Prism Element à l'adresse IP du cluster.
|
||||
2. Dans le menu principal, ouvrir **VM**, puis l'onglet **Table**.
|
||||
3. Sélectionner la VM concernée et ouvrir **Update** (double-clic ou clic droit).
|
||||
4. Désactiver **Use this VM as an agent VM**.
|
||||
5. Cliquer sur **Save** pour enregistrer la modification.
|
||||
|
||||
## 4. Mettre à jour chaque cluster
|
||||
|
||||
1. Ouvrir Prism Element à l'adresse IP du cluster. L'entrée correspondante est enregistrée dans RDM sous `NTNX-CLUSTERXX`.
|
||||
2. Ouvrir **LCM**.
|
||||
3. Dans l'onglet **Inventory**, cliquer sur **Perform Inventory** afin d'actualiser l'inventaire et les mises à jour disponibles.
|
||||
4. Appliquer les mises à jour dans l'ordre suivant :
|
||||
1. **NCC**. Une fois la mise à jour terminée, relancer le contrôle de santé NCC en CLI et traiter les alertes avant de continuer.
|
||||
2. **Foundation / Foundation Platforms**.
|
||||
3. **AOS**.
|
||||
4. **AHV**.
|
||||
5. **Firmware**.
|
||||
5. Suivre l'état de chaque mise à jour dans LCM et attendre la fin de l'étape en cours avant de lancer la suivante.
|
||||
|
||||
La mise à jour du cluster peut durer plusieurs heures. Nutanix télécharge les paquets, effectue les contrôles préalables, déplace les VM hors du nœud en cours de mise à jour, puis redémarre les composants concernés (serveur, hyperviseur et CVM).
|
||||
|
||||
Si plusieurs clusters sont présents, vérifier que les mêmes versions cibles sont appliquées à chacun d'eux.
|
||||
@@ -0,0 +1,45 @@
|
||||
# Mettre à jour un NAS Synology
|
||||
|
||||
## 1. Préparer la mise à jour
|
||||
|
||||
### 1.1 Relever le modèle et la version de DSM
|
||||
|
||||
1. Ouvrir l'interface Web du NAS à l'adresse `https://IP_NAS:5001`. Récupérer les informations de connexion dans RDM.
|
||||
2. Dans **Panneau de configuration > Centre d'infos > Général**, relever le modèle du NAS et la version actuelle de DSM.
|
||||
|
||||
### 1.2 Télécharger les paquets de mise à jour
|
||||
|
||||
1. Ouvrir le site officiel [Synology Download Center](https://www.synology.com/fr-fr/support/download) et sélectionner le modèle exact du NAS. Le modèle `RS818RP+` était donné comme exemple dans la procédure source.
|
||||
2. Indiquer la version actuelle et la version cible de DSM.
|
||||
3. Suivre les étapes de mise à niveau proposées par le site. Télécharger tous les paquets requis et noter leur ordre d'installation.
|
||||
4. Copier les fichiers `.pat` à proximité du NAS, sur le poste utilisé pour l'opération.
|
||||
|
||||
Ne pas ignorer les étapes intermédiaires indiquées par Synology : installer les paquets dans l'ordre proposé.
|
||||
|
||||
### 1.3 Vérifier l'état du NAS
|
||||
|
||||
1. Depuis le **Menu principal**, vérifier l'état général du NAS.
|
||||
2. Consulter le stockage dans **Panneau de configuration > Centre d'infos > Stockage**.
|
||||
3. Vérifier que tous les voyants d'état sont au vert avant de commencer.
|
||||
|
||||
Si un voyant signale une anomalie, interrompre la préparation, ouvrir un ticket auprès de Sysnet et signaler tout besoin de remplacement de matériel. Ne pas lancer la mise à jour tant que l'état du NAS n'est pas conforme.
|
||||
|
||||
### 1.4 Exporter la configuration
|
||||
|
||||
Dans **Panneau de configuration > Mise à jour et restauration > Sauvegarde de configuration**, utiliser **Exportation manuelle > Exporter**. Vérifier que le fichier de configuration exporté est accessible avant de poursuivre.
|
||||
|
||||
## 2. Installer les mises à jour DSM
|
||||
|
||||
Répéter les étapes ci-dessous pour chaque paquet `.pat`, en respectant l'ordre établi à la section 1.2 :
|
||||
|
||||
1. Ouvrir **Panneau de configuration > Mise à jour et restauration > Mise à jour du DSM**.
|
||||
2. Cliquer sur **Mise à jour manuelle du DSM**.
|
||||
3. Sélectionner le paquet `.pat` correspondant à l'étape en cours, puis cliquer sur **OK**.
|
||||
4. Dans la fenêtre de confirmation, cocher la case demandée et cliquer sur **Mettre à jour**. Si une confirmation supplémentaire apparaît, cliquer sur **OK**.
|
||||
5. Attendre la fin de l'installation et le redémarrage éventuel du NAS avant de lancer l'étape suivante.
|
||||
|
||||
La procédure source estime la durée d'une mise à jour à environ 5 à 10 minutes. La durée réelle peut varier selon le modèle et le paquet installé. Ne pas interrompre le NAS pendant l'opération.
|
||||
|
||||
## 3. Contrôler le résultat
|
||||
|
||||
Après la dernière étape, vérifier que le NAS est de nouveau accessible, que la version de DSM correspond à la version cible et que l'état général ainsi que le stockage ne signalent pas d'anomalie.
|
||||
@@ -0,0 +1,131 @@
|
||||
# Préparer un poste opérateur sous Windows 11
|
||||
|
||||
## 1. Généraliser l'image avec Sysprep
|
||||
|
||||
Après le redémarrage effectué à la suite du déploiement de l'image, se connecter avec le compte `adminlocal`. Récupérer son mot de passe dans RDM.
|
||||
|
||||
1. Ouvrir `C:\Windows\System32\Sysprep`.
|
||||
2. Exécuter `sysprep.exe`.
|
||||
3. Cocher **Généraliser**, puis cliquer sur **OK**.
|
||||
4. Laisser la préparation se terminer et attendre le redémarrage du poste.
|
||||
|
||||
## 2. Installer Windows 11 avec un compte local
|
||||
|
||||
La procédure source prévoit l'installation sans compte Microsoft et indique que le poste ne doit pas être connecté à Internet pendant cette étape.
|
||||
|
||||
1. À l'écran de configuration initiale, appuyer sur `Maj+F10` pour ouvrir l'invite de commandes.
|
||||
2. Exécuter :
|
||||
|
||||
```cmd
|
||||
oobe\bypassnro
|
||||
```
|
||||
|
||||
3. Attendre le redémarrage du poste.
|
||||
4. Choisir la langue, conserver le clavier français et ignorer l'ajout d'une disposition de clavier supplémentaire.
|
||||
5. À l'écran de connexion réseau, sélectionner **Je n'ai pas Internet**, puis **Continuer avec l'installation limitée**.
|
||||
6. Accepter le contrat de licence et créer le compte local `Test`, sans mot de passe, conformément à la procédure source.
|
||||
7. Pour les questions de configuration et de confidentialité qui ne sont pas décrites dans le texte source, appliquer les choix définis par le standard de configuration du poste.
|
||||
|
||||
Après l'ouverture de session `Test`, se déconnecter et ouvrir une session `adminlocal` avec le mot de passe récupéré dans RDM.
|
||||
|
||||
### Supprimer le compte temporaire
|
||||
|
||||
1. Dans les propriétés de **Ce PC**, ouvrir la gestion des **Profils des utilisateurs** et supprimer le profil `Test`.
|
||||
2. Ouvrir **Ce PC > Gérer > Utilisateurs et groupes locaux > Utilisateurs**, puis supprimer le compte `Test`.
|
||||
|
||||
## 3. Configurer le réseau du poste
|
||||
|
||||
### 3.1 Renommer et configurer les cartes réseau
|
||||
|
||||
1. Ouvrir les connexions réseau et renommer les cartes conformément au schéma de nommage du poste. La touche `F2` permet de renommer une carte sélectionnée.
|
||||
2. Dans les propriétés des cartes concernées, désactiver IPv6 et les options de mise en veille indiquées par la configuration locale validée.
|
||||
3. Vérifier les noms et l'ordre des interfaces avant de créer le teaming.
|
||||
|
||||
Les valeurs détaillées de nommage et les options d'interface visibles dans la source n'étant pas transcrites, utiliser le plan réseau approuvé pour ce poste.
|
||||
|
||||
### 3.2 Créer le teaming
|
||||
|
||||
Le fichier de référence est indiqué dans :
|
||||
|
||||
```text
|
||||
D:\Install\System\Drivers\Teaming Win11
|
||||
```
|
||||
|
||||
Ouvrir PowerShell en tant qu'administrateur et exécuter la commande en vérifiant que les deux noms d'interface correspondent bien aux cartes du poste :
|
||||
|
||||
```powershell
|
||||
New-NetSwitchTeam -Name "Teaming" -TeamMembers "VLAN ALERTE CARTE Haute","VLAN ALERTE CARTE Basse"
|
||||
```
|
||||
|
||||
Attendre la fin de la commande, puis vérifier dans les connexions réseau que la carte **Teaming** est apparue. Ouvrir ses propriétés, désactiver IPv6 conformément à la configuration locale et lui attribuer l'adresse IP du poste selon le plan réseau.
|
||||
|
||||
### 3.3 Renommer le poste
|
||||
|
||||
Attribuer au poste le nom prévu par la convention de nommage, puis le redémarrer. Après le redémarrage, se reconnecter avec le compte `adminlocal`.
|
||||
|
||||
## 4. Configurer l'interface utilisateur et Start
|
||||
|
||||
Détacher les raccourcis inutiles de la barre des tâches. Dans le menu **Démarrer**, désépingler les raccourcis préinstallés qui ne sont pas requis pour le poste, conformément au modèle validé.
|
||||
|
||||
Configurer Start pour s'exécuter en tant qu'administrateur :
|
||||
|
||||
1. Ouvrir `D:\Start\Progs` et faire un clic droit sur `Start.exe`, puis choisir **Propriétés**.
|
||||
2. Dans **Compatibilité**, cocher **Exécuter ce programme en tant qu'administrateur** et cliquer sur **Appliquer**.
|
||||
3. Cliquer sur **Modifier les paramètres pour tous les utilisateurs**, cocher également **Exécuter ce programme en tant qu'administrateur**, puis appliquer et valider.
|
||||
|
||||
## 5. Renseigner les numéros CLS et Synoptique
|
||||
|
||||
Dans l'Éditeur du Registre, renseigner les numéros requis en **Décimal** aux emplacements suivants :
|
||||
|
||||
```text
|
||||
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Systel\CLS
|
||||
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Systel\Start\Synoptique
|
||||
```
|
||||
|
||||
Le numéro du synoptique doit également être configuré dans Start : ouvrir **Paramètres > Postes**, sélectionner le nom du poste, cocher **Synoptique** et saisir le même numéro que celui configuré dans le registre.
|
||||
|
||||
Récupérer les numéros correspondant au poste dans la configuration de référence; ne pas les déduire.
|
||||
|
||||
## 6. Configurer les équipements radio
|
||||
|
||||
### 6.1 Installer le pilote TEN
|
||||
|
||||
1. Ouvrir **Ce PC > Gérer > Gestionnaire de périphériques**.
|
||||
2. Faire un clic droit sur **Pilote TEN2006**, puis sélectionner **Mettre à jour le pilote**.
|
||||
3. Choisir **Parcourir mon poste de travail**, puis **Choisir parmi une liste de pilotes disponibles sur mon ordinateur**.
|
||||
4. Afficher tous les périphériques, puis cliquer sur **Suivant** et **Parcourir**.
|
||||
5. Accéder au dossier de pilote prévu pour le poste, ouvrir le dossier `64bits` et sélectionner le fichier `.inf` indiqué par le package du pilote.
|
||||
6. Choisir `TUSB3410Device`, cliquer sur **Suivant**, puis confirmer avec **Oui** si Windows le demande.
|
||||
7. Vérifier que le TEN est installé dans le Gestionnaire de périphériques.
|
||||
8. Dans les propriétés du port COM du TEN, désactiver l'autorisation de mise en veille indiquée par la configuration validée.
|
||||
|
||||
Le chemin du pilote n'étant pas retranscrit dans le texte source, utiliser le package de pilote approuvé pour le poste.
|
||||
|
||||
### 6.2 Configurer Iris Agent
|
||||
|
||||
1. Ouvrir le fichier suivant avec Notepad++ :
|
||||
|
||||
```text
|
||||
C:\Program Files\IrisV2\DriverNode\Config\config.js
|
||||
```
|
||||
|
||||
2. Modifier l'adresse IP pour qu'elle corresponde au poste opérateur.
|
||||
3. Enregistrer le fichier.
|
||||
4. Redémarrer le service `iris-agent-windows` ou, si nécessaire, redémarrer le poste.
|
||||
|
||||
### 6.3 Configurer le bandeau GVR V2
|
||||
|
||||
1. Lancer le bandeau GVR V2 et se connecter avec le compte `adminSystel`, dont les informations sont conservées dans RDM.
|
||||
2. Lors du premier démarrage, autoriser les périphériques nécessaires, notamment le microphone.
|
||||
3. Ouvrir le menu **...**, puis les paramètres audio, et sélectionner le TEN dans les périphériques du GVR.
|
||||
4. Confirmer les paramètres et relancer le bandeau en mode opérateur.
|
||||
5. L'option **Se souvenir de moi** permet d'éviter une nouvelle saisie du mot de passe. Ne l'activer que si cela est conforme aux règles de sécurité du poste et de l'organisation.
|
||||
|
||||
## 7. Joindre le poste au domaine
|
||||
|
||||
1. Ouvrir les propriétés de **Ce PC**, puis modifier les paramètres du nom de l'ordinateur.
|
||||
2. Définir le nom du poste selon la convention en vigueur et redémarrer si Windows le demande.
|
||||
3. Ouvrir **Paramètres avancés du système > Nom de l'ordinateur > Modifier**.
|
||||
4. Dans **Membre d'un**, choisir **Domaine** et saisir le nom du domaine à joindre. Exemple fourni : `cta60.local`.
|
||||
5. Saisir les identifiants d'un administrateur du domaine, récupérés selon la procédure sécurisée en vigueur, puis valider.
|
||||
6. Redémarrer le poste lorsque Windows le demande et vérifier que la session de domaine peut être ouverte.
|
||||
@@ -0,0 +1,147 @@
|
||||
# Mettre en place l'Aide à la décision
|
||||
|
||||
## 1. Installer et initialiser la base StartDB
|
||||
|
||||
Récupérer les scripts d'installation correspondant au SGBD utilisé (SQL Server ou Oracle) dans :
|
||||
|
||||
```text
|
||||
\\cloud\Produits\Produits_systel\Gestion operationnelle\AD\Installation
|
||||
```
|
||||
|
||||
Se connecter à la base StartDB et exécuter les scripts dans cet ordre :
|
||||
|
||||
1. `Alter_suppression_AD.sql`
|
||||
2. `Alter_creation_AD.sql`
|
||||
3. `alter_init_param_AD.sql`
|
||||
4. `init_AD_restreinte.sql`
|
||||
5. `init_droits.sql`
|
||||
6. `init_questionnaire_pgr_win1252.sql`
|
||||
|
||||
Régulariser ensuite les paramètres à l'aide des scripts correspondant au SGBD :
|
||||
|
||||
```text
|
||||
\\cloud\Produits\Produits_systel\Gestion operationnelle\AD\Adaptation_apres_premiere_install\SQL
|
||||
\\cloud\Produits\Produits_systel\Gestion operationnelle\AD\Adaptation_apres_premiere_install\ORACLE
|
||||
```
|
||||
|
||||
## 2. Configurer les serveurs ActiveMQ dans StartDB
|
||||
|
||||
Adapter la commande du paramètre `AD.service.local.commande` à la plateforme. Les adresses ci-dessous sont les exemples fournis dans la procédure source; les remplacer par les adresses validées pour l'environnement.
|
||||
|
||||
Pour une plateforme disposant de deux serveurs ActiveMQ :
|
||||
|
||||
```sql
|
||||
UPDATE PARAMETRES_CTA_COMPLEMENTAIRES
|
||||
SET valeur = 'D:\Start\Progs\SysAD\java\bin\java -jar d:\\start\\progs\\SysAD\\ServAD.jar ACTIVEMQ_PRIMARY=10.108.1.14 ACTIVEMQ_SECONDARY=10.108.1.24 BROAKER_CONNECTOR=ActiveMQ CONTEXT_CLEAN_INTERVAL=15 CONTEXT_TTL=45 LOCAL_COMMUNICATION=false'
|
||||
WHERE CLE = 'AD.service.local.commande';
|
||||
```
|
||||
|
||||
Pour une plateforme avec un seul serveur ActiveMQ (exemple Formation/Test) :
|
||||
|
||||
```sql
|
||||
UPDATE PARAMETRES_CTA_COMPLEMENTAIRES
|
||||
SET valeur = 'D:\Start\Progs\SysAD\java\bin\java -jar d:\\start\\progs\\SysAD\\ServAD.jar ACTIVEMQ_PRIMARY=10.108.7.14 BROAKER_CONNECTOR=ActiveMQ CONTEXT_CLEAN_INTERVAL=15 CONTEXT_TTL=45 LOCAL_COMMUNICATION=false'
|
||||
WHERE CLE = 'AD.service.local.commande';
|
||||
```
|
||||
|
||||
Conserver les noms de paramètres tels qu'attendus par l'application, notamment `BROAKER_CONNECTOR`. Le paramétrage StartDB est terminé une fois les valeurs propres à la plateforme appliquées.
|
||||
|
||||
## 3. Déployer les sources CopyStart
|
||||
|
||||
Récupérer les sources de l'Aide à la Décision correspondant à la version de référence dans :
|
||||
|
||||
```text
|
||||
\\cloud\Qualité\Alerte
|
||||
```
|
||||
|
||||
Exemple pour SGO 11.7 :
|
||||
|
||||
```text
|
||||
\\cloud\Qualité\Alerte\Version de référence SGO_117\Version Start\Progs\SysAD
|
||||
```
|
||||
|
||||
Copier le répertoire récupéré dans les sources Start de l'environnement client. Un CopyStart sur un poste opérateur distribuera ensuite l'application et son paramétrage.
|
||||
|
||||
### 3.1 Configurer `jdbc_config.xml`
|
||||
|
||||
Créer ou modifier `D:\Start\Progs\SysAD\jdbc_config.xml` pour qu'il pointe vers la base StartDB de l'environnement.
|
||||
|
||||
Exemple de structure pour Oracle :
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<systel.ressource.jdbcconfig
|
||||
systel.ressource.jdbcconfig.driver="oracle.jdbc.OracleDriver"
|
||||
systel.ressource.jdbcconfig.password="REMPLACER_PAR_LE_SECRET_RDM"
|
||||
systel.ressource.jdbcconfig.port="1521"
|
||||
systel.ressource.jdbcconfig.prefix="jdbc:oracle:thin"
|
||||
systel.ressource.jdbcconfig.sid="start"
|
||||
systel.ressource.jdbcconfig.url="jdbc:oracle:thin:@(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.164.1.11)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = 10.164.1.21)(PORT = 1521)) (LOAD_BALANCE = yes) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = START_TAF) (FAILOVER_MODE = (TYPE = select) (METHOD = basic) (RETRIES = 180) (DELAY = 5) ) ) )"
|
||||
systel.ressource.jdbcconfig.user="REMPLACER_PAR_LE_COMPTE_BDD"/>
|
||||
```
|
||||
|
||||
Exemple de structure pour SQL Server :
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<systel.ressource.jdbcconfig
|
||||
systel.ressource.jdbcconfig.driver="com.microsoft.sqlserver.jdbc.SQLServerDriver"
|
||||
systel.ressource.jdbcconfig.password="REMPLACER_PAR_LE_SECRET_RDM"
|
||||
systel.ressource.jdbcconfig.url="jdbc:sqlserver://10.108.1.25;databaseName=StartDB"
|
||||
systel.ressource.jdbcconfig.user="REMPLACER_PAR_LE_COMPTE_BDD"/>
|
||||
```
|
||||
|
||||
Les adresses IP, le compte et le mot de passe de ces exemples doivent être adaptés à la base cible. Récupérer les secrets dans RDM et ne pas les enregistrer en clair dans la documentation ou dans les sources partagées.
|
||||
|
||||
## 4. Installer Java sur les postes opérateurs
|
||||
|
||||
Pour éviter les conflits avec la version de Java déjà installée sur un poste, utiliser une copie locale de Java à côté de l'application Aide à la Décision.
|
||||
|
||||
La procédure source indique un JDK 8u141 au minimum, disponible dans :
|
||||
|
||||
```text
|
||||
\\cloud\Produits\Produits_systel\Gestion operationnelle\AD\Java\jdk1.8.0_141
|
||||
```
|
||||
|
||||
Sur chaque poste opérateur concerné, copier le sous-répertoire `java` dans le répertoire local de SysAD. Exemple de destination source :
|
||||
|
||||
```text
|
||||
\\10.108.1.55\d$\Start\Progs\SysAd\java
|
||||
```
|
||||
|
||||
Adapter le serveur et le chemin de destination à l'environnement client. Vérifier que l'exécutable Java attendu se trouve bien sous `java\bin`.
|
||||
|
||||
## 5. Adapter les GPO selon l'environnement
|
||||
|
||||
Adapter les GPO aux environnements opérationnel, Formation ou Test. La procédure source indique de déposer les fichiers `jdbc_config.xml` correspondants dans :
|
||||
|
||||
```text
|
||||
\\CTA08.local\SYSVOL\CTA08.LOCAL\scripts\CopyFiles\jdbc_config
|
||||
```
|
||||
|
||||
Le domaine `CTA08.local` et les noms d'exemples ci-dessous sont propres à l'exemple source; les remplacer par les chemins de l'environnement cible.
|
||||
|
||||
Pour l'exemple SDIS 08, les GPO mentionnées sont :
|
||||
|
||||
- `USER-USERS-SESSION_OPE-SQL` pour l'environnement opérationnel;
|
||||
- `USER-USERS-SESSION_FORMATION-SQL` pour l'environnement Formation.
|
||||
|
||||
Le contenu précis des paramètres GPO n'étant pas transcrit dans la source, reprendre les réglages d'une configuration validée pour l'environnement concerné.
|
||||
|
||||
## 6. Adapter les scripts de copie de base Formation/Test
|
||||
|
||||
Pour les imports de la base opérationnelle vers Formation/Test, ajouter ou adapter le paramètre de commande SysAD dans les scripts de copie de base de données. L'adresse ActiveMQ doit correspondre à l'environnement cible.
|
||||
|
||||
Exemple fourni pour une plateforme Formation/Test avec un seul serveur ActiveMQ :
|
||||
|
||||
```sql
|
||||
UPDATE PARAMETRES_CTA_COMPLEMENTAIRES
|
||||
SET VALEUR = 'D:\Start\Progs\SysAD\java\bin\java -jar d:\\start\\progs\\SysAD\\ServAD.jar ACTIVEMQ_PRIMARY=10.108.7.14 BROAKER_CONNECTOR=ActiveMQ CONTEXT_CLEAN_INTERVAL=15 CONTEXT_TTL=45 LOCAL_COMMUNICATION=false'
|
||||
WHERE CLE = 'AD.service.local.commande';
|
||||
```
|
||||
|
||||
Remplacer l'adresse d'exemple par celle de l'environnement cible et vérifier que la commande copiée correspond à la configuration StartDB de cet environnement.
|
||||
|
||||
## 7. Activer l'Aide à la Décision dans Start
|
||||
|
||||
Dans Start, ouvrir **Paramètres > OCN 2**, puis activer l'OCN d'Aide à la Décision.
|
||||
@@ -0,0 +1,118 @@
|
||||
# Installer et configurer Totem Manager
|
||||
|
||||
## 1. Prérequis
|
||||
|
||||
Avant l'installation, vérifier que le poste dispose :
|
||||
|
||||
- d'une connexion ODBC fonctionnelle vers la base de données, par exemple en lançant Start;
|
||||
- d'une configuration ActiveMQ dans `C:\Windows\SysWOW64\SysComm\SysComConfig.xml`.
|
||||
|
||||
Sans ces prérequis, Totem Manager ne pourra pas s'ouvrir.
|
||||
|
||||
## 2. Installer l'application
|
||||
|
||||
La version indiquée dans la procédure source est `1.85.116.4-3`. Récupérer le dossier correspondant dans :
|
||||
|
||||
```text
|
||||
\\cloud\Produits\Produits_systel\Gestion operationnelle\TotemManager
|
||||
```
|
||||
|
||||
Copier le dossier de l'application dans `D:\Start\Progs` sur le poste concerné, ou l'ajouter aux sources du CopyStart pour le déployer sur les postes concernés.
|
||||
|
||||
Sur le poste :
|
||||
|
||||
1. Ouvrir une session avec le compte prévu.
|
||||
2. Exécuter `TotemManager.exe`.
|
||||
3. Lorsque l'application apparaît dans la barre des tâches, exécuter `RegisterDll.bat` en tant qu'administrateur.
|
||||
4. Si la fenêtre de commande ne progresse pas après environ deux minutes, appuyer une fois sur Entrée ou Espace pour vérifier si le script attend une saisie. Vérifier ensuite qu'il se termine correctement.
|
||||
5. Ajouter `TotemManager.exe` au démarrage de la session. Le dossier de démarrage indiqué est :
|
||||
|
||||
```text
|
||||
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp
|
||||
```
|
||||
|
||||
## 3. Vérifier l'initialisation
|
||||
|
||||
Se connecter avec le compte CTA ou le compte utilisé sur le poste, puis vérifier que Totem Manager se lance automatiquement à l'ouverture de session.
|
||||
|
||||
Si l'icône est présente dans la barre des tâches, l'ouvrir. Le chargement de la page de configuration peut prendre une trentaine de secondes.
|
||||
|
||||
Dans la section **Infos**, vérifier que toutes les initialisations aboutissent, puis ouvrir **Paramètres**.
|
||||
|
||||
## 4. Configurer Totem Manager
|
||||
|
||||
La configuration peut être reprise d'un autre poste ou réalisée manuellement.
|
||||
|
||||
### 4.1 Copier une configuration existante
|
||||
|
||||
- Pour appliquer au poste courant la configuration d'un poste déjà configuré, sélectionner le poste source puis cliquer sur **Copier la configuration vers ce poste**.
|
||||
- Pour envoyer la configuration du poste courant vers un autre poste, sélectionner le poste cible puis cliquer sur **Copier la configuration depuis ce poste**.
|
||||
|
||||
Vérifier attentivement le poste source et le poste cible avant de lancer la copie.
|
||||
|
||||
### 4.2 Ajouter les activités manuellement
|
||||
|
||||
Choisir un **Type d'activité**, un **Type d'affichage** et une couleur, puis cliquer sur **Ajouter**.
|
||||
|
||||
Les types d'activité comprennent les alarmes et activités téléphoniques suivants.
|
||||
|
||||
**Alarmes**
|
||||
|
||||
- Antares
|
||||
- Appel
|
||||
- Centre
|
||||
- Consigne
|
||||
- DOP
|
||||
- Demande de contact
|
||||
- Dispositifs préventifs
|
||||
- Défaut
|
||||
- Hydrant
|
||||
- Inter-SGO
|
||||
- Matériel
|
||||
- Messagerie hors-alerte
|
||||
- Mobilisation
|
||||
- Opérateur
|
||||
- Personnel
|
||||
- Post-it
|
||||
- Prodalis
|
||||
- RCO
|
||||
- Seuil OPM
|
||||
- Surveillance montagne
|
||||
- Surveillance nautique
|
||||
- Surveillance radio
|
||||
|
||||
**Téléphonie**
|
||||
|
||||
- En communication (filtre possible par provenance d'appel)
|
||||
- En retrait
|
||||
- En sonnerie (filtre possible par provenance d'appel)
|
||||
- Libre
|
||||
- SOS
|
||||
- Startphone : Appel entrant
|
||||
|
||||
### 4.3 Choisir le type d'affichage
|
||||
|
||||
Le type d'affichage détermine le comportement de l'indicateur Busylight :
|
||||
|
||||
| Type | Comportement |
|
||||
| --- | --- |
|
||||
| Simple | Allume l'indicateur avec une couleur fixe sélectionnée. |
|
||||
| Alerte | Fait sonner l'indicateur en continu et clignoter avec une couleur sélectionnée; le niveau sonore est réglable. |
|
||||
| Clignotement | Fait clignoter l'indicateur avec une couleur et un cycle paramétrables. |
|
||||
| Flash | Allume l'indicateur avec une couleur et produit périodiquement un flash d'une autre couleur sélectionnée. |
|
||||
| Notification | Émet une sonnerie ponctuelle et fait clignoter l'indicateur; le niveau sonore est réglable. |
|
||||
| Pulse | Allume l'indicateur et fait varier automatiquement l'intensité de façon continue. |
|
||||
|
||||
### 4.4 Définir l'ordre de priorité
|
||||
|
||||
Classer les activités de la plus prioritaire à la moins prioritaire. Si plusieurs activités sont actives en même temps, l'ordre de la liste détermine celle qui est affichée.
|
||||
|
||||
Dans l'exemple de la procédure source, si un appel du 112 et un appel du 17 arrivent simultanément, le Totem utilise la deuxième ligne plutôt que la quatrième. Vérifier que l'ordre choisi correspond aux priorités opérationnelles du site.
|
||||
|
||||
## 5. Tester la configuration
|
||||
|
||||
La procédure source indique qu'il est possible de simuler l'activité sélectionnée et d'arrêter le test depuis les commandes de la page. Les libellés des commandes ne sont pas précisés dans le texte source; utiliser les contrôles de test affichés dans Totem Manager et vérifier le comportement de l'indicateur.
|
||||
|
||||
## 6. Documentation de référence
|
||||
|
||||
[Dispositif lumineux de salle de commandement](https://tfs2k18.systel-sa.com/doc/fr/01_CTA/STARTPHONE/050_FonctionnalitesOptionnelles/DispositiflumineuxSallecCcde.html)
|
||||
Reference in New Issue
Block a user