Add installation and configuration guides for Nutanix and Synology NAS, along with server preparation instructions for Linux and Windows environments.

2026-10-15 08:58:51 +02:00
parent 968130672a
commit 735c4b2d58
23 changed files with 721 additions and 0 deletions
@@ -0,0 +1,133 @@
 # Configuration d'un serveur MULTI
 ## 1. Prérequis
 - Suivre la procédure **Exporter et importer une VM depuis la plateforme de Production** pour importer la VM `MULTIx` dans l'environnement client.
 - Suivre la procédure **Préparation d'un serveur Windows** pour préparer le serveur.
 - Disposer du DCSR et d'un accès à l'ancien serveur MULTI.
 ## 2. Configurer l'interface INPT
 L'interface INPT des serveurs MULTI nécessite une configuration particulière.
 1. Ouvrir les connexions réseau avec `ncpa.cpl`, puis les propriétés de la carte réseau.
 2. Ne conserver que les composants nécessaires sur l'interface INPT, conformément à la configuration de référence.
 3. Configurer l'adresse IP et le masque d'après le DCSR ou l'ancienne VM.
 ### Recréer les routes IPv4 statiques
 Sur l'ancien serveur MULTI, exécuter `route print` et relever les routes IPv4 ajoutées manuellement.
 Sur le nouveau serveur MULTI, recréer chaque route avec la commande suivante en remplaçant les valeurs par celles relevées :
 ```cmd
 route -p add x.x.x.x MASK x.x.x.x x.x.x.x
 ```
 Exemple du SDIS 27 :
 ```cmd
 route -p add 10.27.37.240 MASK 255.255.255.240 10.27.37.238
 ```
 ## 3. Copier les fichiers INI
 Sur l'ancien serveur MULTI, récupérer dans `C:\Windows` les fichiers suivants s'ils existent :
 - `GeoFlotteSvr.ini`
 - `GeoLOC.ini`
 Les copier dans `C:\Windows` sur le nouveau serveur. Ouvrir les fichiers avec un éditeur de texte et remplacer les anciennes adresses IP par celles du nouvel environnement. N'utiliser des noms DNS qu'après avoir vérifié qu'ils sont pris en charge par les applications.
 ## 4. Copier les scripts @CIS
 Si le répertoire `C:\@CIS` existe sur l'ancien serveur MULTI, le copier au même emplacement sur le nouveau serveur.
 ## 5. Migrer la configuration du registre
 1. Sur l'ancien serveur MULTI, ouvrir l'éditeur de registre avec `regedit`.
 2. Exporter la clé Systel :
 ```text
 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Systel
 ```
 3. Copier le fichier `.reg` généré sur le nouveau serveur MULTI et l'importer par double clic.
 4. Sur le nouveau serveur, vérifier les clés et valeurs importées.
 5. Remplacer les anciennes adresses IP par celles de la nouvelle infrastructure. Les noms DNS ne doivent être utilisés qu'après validation de leur prise en charge.
 ## 6. Migrer et nettoyer les applications Systel
 Sur l'ancien serveur MULTI, récupérer le répertoire `D:\Start\Progs`, puis le copier au même emplacement sur le nouveau serveur.
 Nettoyer les journaux, fichiers `.old`, répertoires vides et scripts inutilisés. Examiner notamment les répertoires suivants s'ils existent :
 - `Start\Progs\DlgGVR\logs`
 - `Start\Progs\DlgIntrac`
 - `Start\Progs\DlgTE\log`
 - `Start\Progs\GeoParser`
 - `Start\Progs\GestionRC`
 - `Start\Progs\Intrex`
 - `Start\Progs\ServeurPOCSAG`
 Mettre à jour les adresses IP et noms DNS dans les fichiers de configuration concernés, en s'appuyant sur le DCSR et la configuration de l'ancien serveur. Les fichiers journaux sont généralement identifiables par leur date, leur heure et leur contenu.
 Lancer `KeySTARTDB.exe`, saisir le nom du connecteur ODBC et récupérer le mot de passe associé dans RDM.
 ## 7. Configurer ActiveMQ
 Exécuter le script PowerShell `4-Conf_MULTI.ps1` situé dans `D:\Install\Scripts` :
 ```powershell
 D:\Install\Scripts\4-Conf_MULTI.ps1
 ```
 Indiquer le serveur MULTI sur lequel l'action est exécutée. Le script met à jour la configuration ActiveMQ et redémarre le service.
 ## 8. Configurer le compte de service et le démarrage automatique
 Pour chaque serveur MULTI :
 1. Sur Active Directory, vérifier le compte `MULTIx` correspondant et récupérer son mot de passe dans RDM.
 2. Ajouter ce compte au groupe local **Administrateurs** du serveur concerné.
 3. Ouvrir une session sur le serveur avec ce compte.
 4. Ajouter au Bureau public les raccourcis des applications Systel présentes dans `D:\Start\Progs` :
 ```text
 C:\Users\Public\Desktop
 ```
 5. Exécuter en tant qu'administrateur :
 ```text
 D:\Install\System\sources\Autologon.exe
 ```
 6. Accepter le contrat de licence et saisir les identifiants de la session `MULTIx`. Les identifiants doivent être stockés dans RDM.
 7. Ouvrir le dossier de démarrage de la session et y copier les raccourcis vers `DlgIntrac` et `Intrex` :
 ```text
 C:\Users\MULTI1\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
 ```
 Adapter `MULTI1` au nom de la session concernée. Le dossier peut être épinglé à l'accès rapide pour faciliter les interventions ultérieures.
 Ces réglages permettent le démarrage automatique de la session Windows et des applications Systel au démarrage de la VM.
 ## 9. Recréer les partages et tâches planifiées
 Sur l'ancien serveur MULTI, relever les partages SMB et les tâches planifiées. Recréer sur la nouvelle infrastructure ceux qui sont nécessaires, sur le serveur cible approprié, qui n'est pas nécessairement `MULTIx`.
 Exemple pour le SDIS 27 : placer le partage **Systel Start** sur le DFSR des contrôleurs de domaine et le partage **GestionRC** sur les serveurs MULTI. Vérifier les emplacements et besoins dans la configuration de la plateforme.
 Vérifier également les tâches planifiées existantes; la procédure source indique qu'il n'y en avait pas sur l'ancien serveur.
 ## 10. Configurer les vecteurs RTC et le convertisseur Moxa
 > **Attention :** lors du renouvellement d'une infrastructure avec un MULTI virtuel et un convertisseur Moxa, les noms des ports COM peuvent changer dans la configuration du registre d'Intrac.
 Après avoir suivi la procédure **Installation-Convertisseur-MOXA**, relever les liaisons entrantes et sortantes dans le schéma technique du Moxa et dans la configuration du registre d'Intrex.
 Sur la nouvelle VM, organiser les liaisons de façon cohérente : sorties puis entrées, avec `VecteurRCT01 = COM1`, `VecteurRCT02 = COM2`, etc. Pour les liaisons non fonctionnelles encore déclarées dans la configuration, indiquer un port inexistant.
 Vérifier que la configuration du port est identique dans Intrex et dans le Moxa. L'exemple de la procédure source indique un débit de `1200 Baud` pour le Moxa lorsqu'il ne correspond pas à la configuration d'Intrex.
@@ -0,0 +1,163 @@
 # Configuration des serveurs RPINT et RPEXT
 ## 1. Prérequis
 - Suivre la procédure **Exporter et importer une VM depuis la plateforme de Production** pour importer la VM `RPINTx` ou `RPEXTx` dans l'environnement client.
 - Suivre la procédure **Préparation d'un serveur Linux**.
 - Disposer du DCSR et de l'accès à l'ancien serveur de production pour comparer les configurations.
 ## 2. Vérifier les flux réseau
 Sur le pare-feu, vérifier les flux suivants et demander leur ouverture au service réseau s'ils sont absents :
 | Source | Destination | Protocole | Ports |
 | --- | --- | --- | --- |
 | `RPINTx/RPEXTx` | `AD1/AD2` | TCP et UDP | `53` / `123` |
 | `RPINTx/RPEXTx` | `SNMP` | UDP | `161` / `162` |
 | `TELEMW1/2` | `RPINTx/RPEXTx` | TCP | `22` / `9000` |
 Ouvrir également les flux requis par les backends et les accès HAProxy, conformément au DCSR.
 ## 3. Configurer Keepalived
 ### Rôle
 Keepalived gère l'adresse IP virtuelle utilisée pour assurer la redondance des services HAProxy.
 ### Configuration
 1. Se connecter en SSH au serveur avec le compte `systel`, puis passer en `root`.
 2. Identifier l'interface réseau :
 ```bash
 ip a
 ```
 3. Ouvrir le fichier de configuration :
 ```bash
 nano /etc/keepalived/keepalived.conf
 ```
 4. Mettre à jour le nom de l'interface et l'adresse IP virtuelle conformément au DCSR. Configurer `virtual_router_id` et `priority` selon le tableau :
 | Serveur | `virtual_router_id` | `priority` |
 | --- | ---: | ---: |
 | `RPINT1` | `101` | `101` |
 | `RPINT2` | `101` | `100` |
 | `RPEXT1` | `102` | `101` |
 | `RPEXT2` | `102` | `100` |
 5. Enregistrer le fichier, puis redémarrer Keepalived :
 ```bash
 service keepalived restart
 ```
 6. Vérifier avec `ip a` que l'adresse IP virtuelle apparaît sur le serveur maître.
 ## 4. Installer le certificat wildcard
 HAProxy utilise un certificat wildcard pour les connexions sécurisées (HTTPS, MQTT over WebSocket, etc.).
 1. Depuis l'infrastructure de production actuelle, récupérer le fichier `.pem` par SFTP. Il se trouve dans :
 ```text
 /etc/ssl/private/sdisXX.fr/
 ```
 2. Transférer le fichier dans `/tmp` sur la nouvelle VM.
 3. Déplacer le fichier vers le répertoire prévu :
 ```bash
 mv /tmp/sdisXX.pem /etc/ssl/private/sdisXX.fr/sdisXX.pem
 ```
 4. La procédure source indique la commande suivante pour modifier les permissions :
 ```bash
 chmod 755 /etc/ssl/private/sdisXX.fr/sdisXX.pem
 ```
 > **Sécurité :** un fichier PEM peut contenir une clé privée. Vérifier la permission requise par la politique locale et limiter sa lecture aux comptes et services nécessaires avant d'appliquer `chmod 755`.
 ## 5. Configurer HAProxy
 ### 5.1 Préparer le fichier de configuration
 Le modèle contient deux fichiers dans `/etc/haproxy/` :
 - `haproxy_EXT.cfg` pour RPEXT;
 - `haproxy_INT.cfg` pour RPINT.
 Selon le rôle de la VM, renommer le fichier correspondant en `haproxy.cfg`. L'autre fichier peut être supprimé avec la commande suivante en adaptant le nom :
 ```bash
 rm /etc/haproxy/haproxy_XXX.cfg
 ```
 Modifier le fichier avec `nano` ou le transférer par SFTP pour l'éditer avec Notepad++.
 ### 5.2 Adapter la configuration au client
 Dans `haproxy.cfg` :
 1. Remplacer `sdisXX` par le numéro de département du client.
 2. Remplacer `.xx.` par le deuxième octet IP du client. Vérifier la valeur dans le DCSR.
 3. Comparer la configuration à celle de l'ancien serveur et reporter les paramètres propres au client nécessaires.
 4. Ajouter les résolutions DNS non génériques si elles sont utilisées. Vérifier qu'elles sont également déclarées sur le serveur DNS.
 5. Ajouter les ACL et backends spécifiques au client si nécessaire.
 6. Commenter les backends inutilisés d'après le DCSR (par exemple, ceux associés à GeoServer lorsque le client n'en dispose pas).
 7. Remplacer les identifiants par défaut de l'interface Web HAProxy par un mot de passe aléatoire de 20 caractères. Enregistrer le secret dans RDM; ne pas conserver `systel:systel`.
 ## 6. Vérifier le fonctionnement de HAProxy
 ### 6.1 Valider le fichier de configuration
 Avant de redémarrer le service, vérifier la configuration :
 ```bash
 haproxy -c -f /etc/haproxy/haproxy.cfg
 ```
 Si le contrôle est valide, ou ne signale que des avertissements sans impact, redémarrer HAProxy pour appliquer la configuration :
 ```bash
 service haproxy restart
 ```
 ### 6.2 Consulter l'interface de supervision
 Dans un navigateur, ouvrir :
 ```text
 http://IP_SERVEUR_RP:9000/
 ```
 Utiliser le compte `systel` et récupérer le mot de passe dans RDM.
 Un backend affiché en rouge signale une anomalie. Selon le statut :
 - **L4OUT** : vérifier les règles de pare-feu, l'état du service cible et l'adresse IP/le port de destination.
 - **L7OUT** : vérifier le fonctionnement de l'application cible.
 ## 7. Répliquer la configuration
 Depuis un serveur HAProxy secondaire, exécuter la commande suivante pour récupérer le certificat et la configuration du serveur principal :
 ```bash
 haproxyupdate RPXXX1
 ```
 Remplacer `RPXXX1` par le nom du serveur principal concerné.
 ## 8. Sécuriser les comptes système
 Modifier les mots de passe des comptes `systel` et `root` :
 ```bash
 passwd systel
 passwd root
 ```
 Générer des mots de passe de 20 caractères comprenant des minuscules, des majuscules et des chiffres, puis les enregistrer dans RDM.
@@ -0,0 +1,52 @@
 # Configurer un serveur SYSLOG
 ## 1. Prérequis
 1. Suivre la procédure **Exporter et importer une VM depuis la plateforme de Production** pour transférer la VM `SYSLOG` vers l'environnement client.
 2. Suivre la procédure **Préparation d'un serveur Linux**.
 La VM comprend normalement les applications Syslog, Loki, Promtail et Grafana, préinstallées et configurées pour l'usage prévu.
 ## 2. Sécuriser les comptes système
 Se connecter en SSH au serveur `SYSLOG` avec le compte `root`, puis modifier les mots de passe des comptes `systel` et `root` :
 ```bash
 passwd systel
 passwd root
 ```
 Générer de nouveaux mots de passe conformes à la politique locale et les enregistrer dans RDM. Ne pas inscrire les secrets dans cette procédure.
 ## 3. Accéder à Grafana
 Dans un navigateur, ouvrir l'adresse suivante en remplaçant `SYSLOG` par l'adresse IP du serveur :
 ```text
 http://SYSLOG:3000/login
 ```
 Si la page ne s'affiche pas correctement, mettre à jour le navigateur ou utiliser une version portable à jour.
 Le compte initial indiqué par la procédure est `admin` avec le mot de passe `admin`. Le remplacer immédiatement par un mot de passe sécurisé et enregistrer ce dernier dans RDM.
 ## 4. Vérifier la source Loki et les journaux
 Dans Grafana :
 1. Ouvrir **Configuration**, puis **Data Sources**.
 2. Sélectionner `loki`, puis cliquer sur **Save & Test** en bas de la page.
 3. Vérifier que les notifications de réussite apparaissent.
 4. Ouvrir **Dashboards** et contrôler que les journaux attendus sont consultables.
 ## 5. Configurer le DNS
 Sur un serveur Active Directory, ouvrir le gestionnaire DNS et créer un enregistrement de type Hôte (A) :
 | Nom | Adresse IP |
 | --- | --- |
 | `SYSLOG` | Adresse IP du serveur SYSLOG |
 ## 6. Activer l'envoi des journaux
 Pour que les journaux soient reçus et affichés, activer leur envoi sur les équipements compatibles et vérifier que ces équipements ciblent le serveur SYSLOG conformément à leur configuration.
@@ -0,0 +1,125 @@
 # Configurer un serveur Start / StartMob
 ## 1. Prérequis
 1. Suivre la procédure **Exporter et importer une VM depuis la plateforme de Production** pour transférer la VM `STARTx` vers l'environnement client.
 2. Suivre la procédure **Préparation d'un serveur Linux**.
 3. Disposer du DCSR et, en cas de renouvellement d'infrastructure, de l'accès à l'ancien serveur en production afin de reprendre ses options et paramètres.
 ## 2. Vérifier la configuration DNS
 Sur un serveur Active Directory de la plateforme cible, vérifier la présence des entrées suivantes et les créer si nécessaire :
 | Nom | Type et cible | Usage |
 | --- | --- | --- |
 | `AD1` | Alias ou hôte vers `AD1` | DNS et NTP |
 | `AD2` | Alias ou hôte vers `AD2` | DNS et NTP |
 | `ServeurActiveMQ1` | Alias vers `MULTI1` | Connexion ActiveMQ |
 | `ServeurActiveMQ2` | Alias vers `MULTI2` | Connexion ActiveMQ |
 | `SNMP` | Alias ou hôte vers `SNMP` | Supervision SNMP |
 | `[SQL] ServeurBD` | Alias vers `BDSQLVIP` | Connexion à la base SQL |
 | `[Oracle] BD1` | Alias ou hôte vers `BD1` | Connexion à la base Oracle |
 | `[Oracle] BD2` | Alias ou hôte vers `BD2` | Connexion à la base Oracle |
 | `mobilite.sdisXX.fr` | Alias vers `RPINTVIP` | Connexion au broker VerneMQ |
 Adapter les enregistrements au type de plateforme (Production, Formation ou Test) selon le DCSR et la configuration validée de l'environnement.
 ## 3. Vérifier les flux réseau
 Sur le pare-feu, vérifier les flux suivants et demander leur ouverture au service réseau s'ils sont absents :
 | Source | Destination | Protocole | Port(s) |
 | --- | --- | --- | --- |
 | `STARTx` | `AD1/AD2` | TCP et UDP | `53` / `123` |
 | `STARTx` | `MULTI1/MULTI2` | TCP | `61616` |
 | `STARTx` | `SNMP` | UDP | `161` / `162` |
 | `STARTx` | `BDVIP` (SQL) | TCP | `1433` |
 | `STARTx` | `BD1/BD2` (Oracle) | TCP | `1521` |
 | `STARTx` | `NF399` | TCP | `18080` |
 | `RPINT1/RPINT2/RPINTVIP` | `STARTx` | TCP | `18989` |
 | `STARTx` | `RPINT1/RPINT2/RPINTVIP` | TCP | `1883` |
 | `TELEMW1/TELEMW2` | `STARTx` | TCP | `22` / `8989` |
 ## 4. Récupérer les fichiers StartServer
 Récupérer sur le Cloud Systel l'application StartServer/Polux et les fichiers de configuration correspondant à la version de Start utilisée. Le chemin de référence est :
 ```text
 \\cloud\Qualité\Alerte\Version de référence SGO_11x\Version Start\Progs\Polux
 ```
 Pour un renouvellement d'infrastructure, récupérer les fichiers sur le serveur actuellement en production afin de préserver les options et les paramètres propres au client. Vérifier la version applicable avant le transfert.
 1. Se connecter au nouveau serveur Start en SFTP.
 2. Ouvrir le répertoire `/opt/startserver`.
 3. Supprimer les fichiers et répertoires devenus inutiles ou incompatibles avec la version à installer. En cas de renouvellement, vérifier leur contenu avant suppression.
 4. Déposer les nouveaux fichiers `startserver` et `conf` dans `/opt/startserver`, en remplaçant les fichiers existants lorsque cela est nécessaire.
 ## 5. Configurer StartServer
 Se connecter en SSH au serveur `STARTx`.
 ### 5.1 Créer le lien symbolique Polux
 Dans `/opt/startserver`, créer ou remplacer le lien `Polux.jar` pour qu'il pointe vers le fichier JAR de la version transférée :
 ```bash
 cd /opt/startserver
 ln -s -f Polux-xxx.xxx.xxxx-x.jar Polux.jar
 ```
 Remplacer `Polux-xxx.xxx.xxxx-x.jar` par le nom exact du fichier installé.
 ### 5.2 Régler la mémoire maximale
 Éditer le fichier de service :
 ```bash
 nano /opt/startserver/conf/startserver.service.conf
 ```
 Modifier `STARTSERVER_MAX_MEM` pour réserver 3 Go de RAM au système. Par exemple, pour un serveur disposant de 30 Go de RAM, définir la valeur à 27 Go. Vérifier la syntaxe et l'unité attendues par le fichier existant.
 ### 5.3 Adapter les fichiers de configuration
 Éditer `config.properties` :
 ```bash
 nano /opt/startserver/conf/config.properties
 ```
 Mettre à jour le rôle du serveur ainsi que les adresses IP et noms DNS des serveurs associés, conformément au DCSR et à la configuration de l'ancien serveur.
 Dans la section C (MQTT), définir l'identifiant de connexion au broker MQTT avec le nom du rôle du serveur. Utiliser le rôle approprié pour le serveur StartServer principal ou secondaire afin d'identifier clairement chaque connexion au broker.
 Parcourir également l'ensemble de `config.properties`, puis vérifier et adapter, selon le besoin, les fichiers `plugins.properties` et `units.properties` présents dans le même répertoire `conf`. Reprendre les paramètres spécifiques à l'environnement depuis le DCSR ou l'ancien serveur; ne pas déduire de valeurs absentes de cette procédure.
 ## 6. Démarrer et vérifier le service
 En SSH, démarrer le service puis vérifier son état :
 ```bash
 service startserver start
 service startserver status
 ```
 Vérifier que le processus est indiqué comme étant `running`.
 Dans un navigateur, ouvrir l'adresse suivante en remplaçant `STARTx` par le nom ou l'adresse du serveur :
 ```text
 http://STARTx:8989/systel-rest/poluxeye/#/home
 ```
 Vérifier que l'application se charge complètement.
 ## 7. Sécuriser les comptes système
 Modifier les mots de passe des comptes `systel` et `root` :
 ```bash
 passwd systel
 passwd root
 ```
 Générer des mots de passe conformes à la politique locale et les enregistrer dans RDM. Ne pas inscrire les secrets dans cette procédure.
@@ -0,0 +1,128 @@
 # Configurer un serveur StartWeb
 ## 1. Prérequis
 1. Suivre la procédure **Exporter et importer une VM depuis la plateforme de Production** pour transférer la VM `STARTWEBx` vers l'environnement client.
 2. Suivre la procédure **Préparation d'un serveur Linux**.
 3. Disposer du DCSR et, en cas de renouvellement, de l'accès à l'ancien serveur afin de reprendre les paramètres propres à l'environnement.
 ## 2. Vérifier le DNS
 Sur un serveur Active Directory de la plateforme cible, vérifier les entrées suivantes et les créer si nécessaire :
 | Nom | Type et cible | Usage |
 | --- | --- | --- |
 | `AD1` | Alias ou hôte vers `AD1` | DNS et NTP |
 | `AD2` | Alias ou hôte vers `AD2` | DNS et NTP |
 | `SNMP` | Alias ou hôte vers `SNMP` | Supervision SNMP |
 Vérifier les autres noms DNS requis pour l'environnement dans le DCSR et dans la configuration de la plateforme.
 ## 3. Vérifier les flux réseau
 Sur le pare-feu, vérifier les flux suivants et demander leur ouverture au service réseau s'ils sont absents :
 | Source | Destination | Protocole | Port(s) |
 | --- | --- | --- | --- |
 | `STARTWEBx` | `AD1/AD2` | TCP et UDP | `53` / `123` |
 | `STARTWEBx` | `SNMP` | UDP | `161` / `162` |
 | `RPINT1/RPINT2/RPINTVIP` | `STARTWEBx` | TCP | `443` |
 | `TELEMW1/TELEMW2` | `STARTWEBx` | TCP | `22` / `443` |
 ## 4. Vérifier NGINX
 Une fois les prérequis réseau vérifiés, se connecter au serveur en SSH avec le compte `root`.
 Le portail StartWeb utilise NGINX, préconfiguré pour écouter sur le port `443`. Le certificat autosigné se trouve dans :
 ```text
 /etc/ssl/private/nginx/
 ```
 La procédure source indique une longue durée de validité du certificat. Vérifier sa validité conformément aux exigences de l'environnement.
 ## 5. Installer StartWeb
 ### 5.1 Récupérer et transférer l'archive
 Récupérer sur le Cloud Systel l'application portail correspondant à la version de Start utilisée :
 ```text
 \\cloud\Qualité\Alerte\Version de référence SGO_11x\Version StartWeb\startweb-xxx.xxx.zip
 ```
 Transférer l'archive par SFTP vers `/tmp` ou `/home/systel` sur la VM StartWeb. En cas de renouvellement, sauvegarder au préalable les fichiers de configuration existants qui doivent être conservés.
 Déplacer l'archive sélectionnée dans `/var/www/html`. Adapter le chemin source et le nom de fichier à l'emplacement et à la version réellement transférés. Exemple de nom fourni dans la procédure source : `startweb-485.117.2503-3(54195).zip`.
 ### 5.2 Nettoyer et déployer les fichiers
 Dans `/var/www/html`, identifier les archives présentes et confirmer le nom exact de l'archive à installer. Supprimer uniquement les anciennes archives de template, sans supprimer l'archive sélectionnée. Ne pas utiliser `rm /var/www/html/startweb-4*` après avoir déplacé l'archive : ce motif correspond également à l'archive StartWeb choisie.
 Avant de supprimer le répertoire `StartWeb` existant, vérifier son contenu et sauvegarder les fichiers à conserver. Supprimer ou déplacer l'ancien répertoire uniquement lorsque son remplacement est confirmé.
 Se placer dans le répertoire Web, puis extraire l'archive sélectionnée en indiquant son nom exact :
 ```bash
 cd /var/www/html
 unzip startweb-xxx.xxx.zip
 ```
 Remplacer `startweb-xxx.xxx.zip` par le nom réel de l'archive. Renommer ensuite `release` en `StartWeb` en respectant les majuscules :
 ```bash
 mv release/ StartWeb/
 ```
 ## 6. Configurer StartWeb
 Se placer dans le répertoire de configuration :
 ```bash
 cd /var/www/html/StartWeb/conf/
 ```
 Créer les fichiers de configuration actifs à partir des modèles `.example` :
 ```bash
 cp parametrageService.js.example parametrageService.js && cp routesBlackList.json.example routesBlackList.json
 ```
 Éditer `parametrageService.js` pour l'adapter à l'infrastructure et aux serveurs disponibles :
 ```bash
 nano parametrageService.js
 ```
 Les valeurs propres au client sont à reprendre du DCSR, de l'ancien serveur ou d'une configuration validée. Une copie du fichier de référence peut également être disponible dans `/var/www/` sur la VM Template. Dans ce cas, la copier puis l'adapter avant utilisation :
 ```bash
 cp /var/www/parametrageService.js /var/www/html/StartWeb/conf/
 ```
 Après modification, aucun redémarrage de NGINX n'est requis selon la procédure source : les changements sont pris en compte directement.
 ## 7. Déployer StartMob
 La configuration de StartWeb et StartWebMob est désormais identique. Depuis `/var/www/html`, copier le répertoire `StartWeb` vers `StartWebMob`, en respectant les majuscules :
 ```bash
 cp -r /var/www/html/StartWeb/ /var/www/html/StartWebMob/
 ```
 Si `StartWebMob` existe déjà, vérifier son contenu et le sauvegarder ou le remplacer avant la copie, afin d'éviter de créer un répertoire imbriqué.
 ## 8. Vérifier le fonctionnement
 Sur la page de supervision du `RPINTVIP`, vérifier que la ligne correspondant au serveur `STARTWEBx` est verte.
 ## 9. Sécuriser les comptes système
 Modifier les mots de passe des comptes `systel` et `root` :
 ```bash
 passwd systel
 passwd root
 ```
 Générer les mots de passe conformément à la politique locale et les enregistrer dans RDM. Ne pas inscrire les secrets dans cette procédure.
@@ -0,0 +1,120 @@
 # Configurer un serveur WEB
 ## 1. Prérequis
 1. Suivre la procédure **Exporter et importer une VM depuis la plateforme de Production** pour transférer la VM `WEBx` vers l'environnement client.
 2. Suivre la procédure **Préparation d'un serveur Linux**.
 3. Disposer du DCSR et, en cas de renouvellement, de l'accès à l'ancien serveur afin de reprendre les paramètres propres au client.
 ## 2. Vérifier le DNS
 Sur un serveur Active Directory de la plateforme cible, vérifier les entrées suivantes et les créer si nécessaire :
 | Nom | Type et cible | Usage |
 | --- | --- | --- |
 | `AD1` | Alias ou hôte vers `AD1` | DNS et NTP |
 | `AD2` | Alias ou hôte vers `AD2` | DNS et NTP |
 | `ServeurActiveMQ1` | Alias vers `MULTI1` | Connexion ActiveMQ |
 | `ServeurActiveMQ2` | Alias vers `MULTI2` | Connexion ActiveMQ |
 | `SNMP` | Alias ou hôte vers `SNMP` | Supervision SNMP |
 | `[SQL] ServeurBD` | Alias vers `BDSQLVIP` | Connexion à la base SQL |
 | `[Oracle] BD1` | Alias ou hôte vers `BD1` | Connexion à la base Oracle |
 | `[Oracle] BD2` | Alias ou hôte vers `BD2` | Connexion à la base Oracle |
 Adapter les enregistrements aux plateformes de Production, de Formation ou de Test selon le DCSR et la configuration validée de l'environnement.
 ## 3. Vérifier les flux réseau
 Sur le pare-feu, vérifier les flux suivants et demander leur ouverture au service réseau s'ils sont absents :
 | Source | Destination | Protocole | Port(s) |
 | --- | --- | --- | --- |
 | `WEBx` | `AD1/AD2` | TCP et UDP | `53` / `123` |
 | `WEBx` | `MULTI1/MULTI2` | TCP | `61616` |
 | `WEBx` | `SNMP` | UDP | `161` / `162` |
 | `WEBx` | `BDVIP` (SQL) | TCP | `1433` |
 | `WEBx` | `BD1/BD2` (Oracle) | TCP | `1521` |
 | `RPINT1/RPINT2/RPINTVIP` | `WEBx` | TCP | `443` (et `18080` pour l'ancien HTTP, si utilisé) |
 | `TELEMW1/TELEMW2` | `WEBx` | TCP | `22` / `443` / `4848` |
 ## 4. Accéder à l'administration du portail
 Depuis un serveur Windows TELEMW, ouvrir l'interface d'administration :
 ```text
 https://WEBx:4848/
 ```
 Utiliser le compte d'administration et récupérer son mot de passe dans RDM. Si le mot de passe initial est encore en vigueur, le remplacer immédiatement par un secret robuste et mettre à jour RDM. Ne pas conserver de mot de passe en clair dans cette procédure.
 ## 5. Configurer les paramètres Java
 Dans l'interface GlassFish, ouvrir les paramètres Java de l'instance concernée. Pour un renouvellement, comparer les réglages de l'ancien serveur et les reporter lorsqu'ils sont applicables.
 - `-Xmx5120m` définit la mémoire maximale de GlassFish. Régler cette valeur à la mémoire totale de la VM moins 1 Go. L'exemple fourni pour une VM de 6 Go est `5120m`.
 - `-Xms1024m` définit la mémoire minimale (1 Go). Ne pas modifier ce paramètre selon la procédure source.
 - `-DACTIVEMQ_IP=ServeurActiveMQ1;ServeurActiveMQ2` désigne les serveurs ActiveMQ. Modifier ce paramètre uniquement pour les plateformes de Test et de Formation, selon leur configuration.
 - `-DENV_NAME=WEBx` doit correspondre au rôle de la VM : `WEB1`, `WEB2`, `WEBF` ou `WEBT`.
 - `-DNOM_CARTE_GCIS=sdisXX.gcm` : remplacer `XX` par le numéro du département.
 Si l'envoi de courriels par le portail est utilisé, configurer les paramètres SMTP suivants avec les valeurs du client :
 ```text
 -Dmail.smtp.host=1.2.3.4
 -Dmail.smtp.user=USER
 -Dmail.smtp.password=<mot de passe SMTP depuis RDM>
 -Dmail.smtp.from=user@sdisxx.fr
 -Dmail.smtp.auth=true
 -Dmail.smtp.port=25
 ```
 Remplacer les valeurs d'exemple par celles fournies par le client. Stocker le mot de passe SMTP dans RDM, pas dans cette procédure.
 ## 6. Configurer la base de données
 Dans les paramètres BDD, ouvrir `jdbc/start` et choisir dans **Pool Name** le type de base présent sur l'infrastructure cible : `SQL` ou `Oracle`.
 Ouvrir ensuite la ressource correspondante : `Start_SQL` ou `Start_ORA`. Vérifier et adapter, selon le DCSR ou la configuration validée, l'utilisateur, le mot de passe, le nom de VM et la chaîne de connexion. Récupérer les mots de passe dans RDM.
 Pour tester la connexion, ouvrir l'onglet **General**, puis cliquer sur **Ping**. Confirmer que le test réussit.
 ## 7. Vérifier les paramètres serveur et redirections
 Contrôler les paramètres du serveur GlassFish. En cas de renouvellement de VM, comparer avec l'ancien serveur et reporter les paramètres nécessaires.
 Dans `server-config / Virtual Servers / server`, vérifier et reporter, s'ils existent, les paramètres de redirection, notamment ceux utilisés pour la géolocalisation mobile.
 ## 8. Déployer l'application Web
 Récupérer sur le Cloud Systel le fichier EAR correspondant à la version de Start utilisée. Les emplacements de référence indiqués sont :
 ```text
 \\cloud\Qualité\Alerte\Version de référence SGO_11x\Version WebCIS\systel-alerte-v485.11x.xxxx-x-xxxxxx_iCome_SGO_11x.xxxx-RC.ear
 \\cloud\Qualité\Production_Version\Publiée\SGO_4.85.117\Archives
 ```
 Dans l'interface d'administration, ouvrir **Applications**, puis cliquer sur **Deploy**. Charger le fichier `.ear`, sélectionner `server`, décocher **Implicit CDI**, puis cliquer sur **OK** pour lancer le déploiement.
 Vérifier que l'application apparaît dans la liste, puis tester son fonctionnement à l'une des adresses suivantes :
 ```text
 https://WEBx/systel-alerte-web/Console.jsp
 https://portail.sdisxx.fr/
 ```
 ## 9. Sécuriser les comptes système
 Modifier les mots de passe des comptes `systel` et `root` :
 ```bash
 passwd systel
 passwd root
 ```
 Générer des mots de passe conformes à la politique locale et les enregistrer dans RDM. Ne pas inscrire les secrets dans cette procédure.
 ## 10. Dépanner une erreur SSL de HAProxy
 En cas d'erreur de couche 6 dans HAProxy (`SSL handshake failure`), vérifier les paramètres SSL du port `443` dans l'interface GlassFish. Les valeurs exactes doivent être reprises de la configuration validée de l'ancien serveur ou de la documentation de l'environnement; elles ne figurent pas dans le texte source disponible.
 Selon la procédure source, la modification de ces paramètres ne nécessite pas de redémarrage pour être prise en compte.