Add installation and configuration guides for Nutanix and Synology NAS, along with server preparation instructions for Linux and Windows environments.
This commit is contained in:
Maxime BOURIEAU
@@ -0,0 +1,176 @@
|
||||
# Configurer un serveur Active Directory
|
||||
|
||||
## 1. Prérequis
|
||||
|
||||
- Suivre la procédure **Exporter et importer une VM depuis la plateforme de Production** pour importer la VM AD dans l'environnement client.
|
||||
- Disposer de notions de base sur Active Directory et les stratégies de groupe (GPO).
|
||||
- Suivre la procédure **Préparation d'un serveur Windows** pour préparer le serveur.
|
||||
- Récupérer le mot de passe initial dans le coffre-fort sécurisé prévu à cet effet; ne pas stocker de mot de passe en clair dans cette procédure.
|
||||
|
||||
## 2. Installer les rôles et créer le domaine
|
||||
|
||||
Effectuer ces étapes d'abord sur AD1, puis sur AD2.
|
||||
|
||||
1. Ouvrir `D:\Install\Scripts`.
|
||||
2. Exécuter `4-Creation_Domaine_AD.ps1` avec les droits requis.
|
||||
3. Si le script demande de ne plus afficher un message, saisir `T`.
|
||||
4. Saisir le nom complet du domaine Active Directory conformément au DCSR.
|
||||
5. Indiquer le serveur en cours de configuration : `AD1` ou `AD2`.
|
||||
|
||||
### 2.1 Configurer AD1
|
||||
|
||||
Lorsque le script le demande, saisir le mot de passe de restauration des services d'annuaire (DSRM). Générer un mot de passe robuste de 20 caractères comprenant des majuscules, des minuscules et des chiffres, puis l'enregistrer dans RDM.
|
||||
|
||||
Laisser l'installation des rôles et du domaine se terminer. Appuyer sur **Entrée** pour terminer et redémarrer le serveur.
|
||||
|
||||
Après le redémarrage, vérifier les paramètres DNS de l'interface réseau : l'adresse du DNS secondaire peut avoir été réinitialisée. Se reporter à la procédure **Préparation d'un serveur Windows**.
|
||||
|
||||
### 2.2 Configurer AD2
|
||||
|
||||
Exécuter également `4-Creation_Domaine_AD.ps1` sur AD2 et choisir `AD2`.
|
||||
|
||||
Lorsque le script le demande :
|
||||
|
||||
1. Saisir les identifiants d'un administrateur du domaine, en précisant le nom NetBIOS ou le nom complet du domaine.
|
||||
2. Saisir le mot de passe de restauration DSRM configuré pour le domaine.
|
||||
3. Attendre la fin de l'installation, puis appuyer sur **Entrée** pour terminer et redémarrer.
|
||||
|
||||
## 3. Configurer le domaine Active Directory
|
||||
|
||||
Avant de poursuivre, terminer les opérations précédentes sur AD1 et AD2 et vérifier que les deux contrôleurs de domaine sont configurés et synchronisés. Les étapes suivantes ne sont à effectuer que sur un seul contrôleur de domaine; l'exemple utilise AD1. Les changements sont répliqués vers AD2.
|
||||
|
||||
1. Sur le contrôleur choisi, ouvrir `D:\Install\Scripts` et exécuter `5-Configuration_Domaine_AD.ps1` avec les droits requis.
|
||||
2. Si le script demande de ne plus afficher un message, saisir `T`.
|
||||
3. Saisir le numéro de département sur deux ou trois caractères.
|
||||
4. Indiquer le moteur de base de données utilisé par l'infrastructure en saisissant `ORA` ou `SQL` en majuscules.
|
||||
5. Indiquer si l'infrastructure comporte des plateformes de formation et de test en saisissant `OUI` ou `NON` en majuscules.
|
||||
|
||||
Le script installe le magasin central de modèles ADMX, crée les unités d'organisation, les comptes utilisateurs, les groupes et les GPO.
|
||||
|
||||
Des ajustements manuels restent nécessaires.
|
||||
|
||||
## 4. Mettre à jour les GPO
|
||||
|
||||
Les captures de la procédure d'origine contenaient certains paramètres et valeurs qui ne sont pas retranscrits ici. Pour ces paramètres, se référer au DCSR, aux GPO de référence ou à l'équipe responsable avant toute modification.
|
||||
|
||||
### 4.1 GPO `WORKSTATIONS-CONFIGURATION`
|
||||
|
||||
- Corriger les paramètres propres au client en remplaçant `xx` par le numéro de département, selon le DCSR et la configuration de référence.
|
||||
- Pour le paramètre de groupe en erreur, supprimer l'entrée incorrecte et recréer le groupe attendu d'après la configuration de référence.
|
||||
|
||||
### 4.2 GPO `WORKSTATIONS-SUP-VEILLE`
|
||||
|
||||
Ajouter au filtrage de sécurité le ou les postes **Mur d'Image**, s'ils existent.
|
||||
|
||||
### 4.3 GPO `SERVERS-SERVICES-SPOOLER`
|
||||
|
||||
Cette GPO doit s'appliquer à tous les serveurs, sauf aux serveurs **MULTI** et **SPOOLER**. La procédure indique que la GPO n'est normalement pas liée à l'OU `T1-INFRA-SERVERS` de ces serveurs. Créer un filtre WMI pour exclure les machines dont le nom contient `SPOOLER` ou `MULTI` :
|
||||
|
||||
- **Nom** : `Exclure SPOOLER et MULTI`
|
||||
- **Espace de noms** : `root\CIMv2`
|
||||
- **Requête** :
|
||||
|
||||
```sql
|
||||
SELECT * FROM Win32_ComputerSystem WHERE NOT (Name LIKE "%SPOOLER%" OR Name LIKE "%MULTI%")
|
||||
```
|
||||
|
||||
Associer ensuite ce filtre WMI à la GPO `SERVERS-SERVICES-SPOOLER`.
|
||||
|
||||
### 4.4 GPO `USERS-ENV-CONF`
|
||||
|
||||
- Corriger les paramètres propres au client en remplaçant `xx` par le numéro de département, selon la configuration de référence.
|
||||
- Mettre à jour les chemins des redirections des dossiers **Images** et **Téléchargement**.
|
||||
- Adapter le chemin selon que la plateforme utilise un NAS ou non :
|
||||
|
||||
```text
|
||||
\\ctaXX.local\SYSTEL\PartageOP
|
||||
\\NAS-X\PartageOP
|
||||
```
|
||||
|
||||
### 4.5 GPO `USERS-PRINTERS_ADD_ALL`
|
||||
|
||||
Remplacer les imprimantes par celles du client. Les imprimantes doivent d'abord être installées sur le serveur d'impression SPOOLER.
|
||||
|
||||
### 4.6 GPO `USERS-ENV-RESTRICTION`
|
||||
|
||||
Corriger le paramètre propre au client en remplaçant `xx` par le numéro de département, selon la configuration de référence.
|
||||
|
||||
### 4.7 GPO `SERVERS-WORKSTATION-DENY-ADMIN*`
|
||||
|
||||
Mettre à jour les comptes des stratégies de groupe concernées. Une fois ces stratégies appliquées, l'ouverture de session RDP avec un compte Administrateur du domaine peut être interdite. Utiliser alors `AdminLocal` ou le compte dédié au serveur, à condition qu'il appartienne au groupe local **Administrateurs** (par exemple sur `MULTI1`, `MULTI2` ou `DWH`).
|
||||
|
||||
Pour chacune des stratégies listées ci-dessous, vérifier les droits pour les trois paramètres suivants :
|
||||
|
||||
- **Interdire l'ouverture d'une session locale**
|
||||
- **Interdire l'ouverture de session en tant que service**
|
||||
- **Interdire l'ouverture de session par les services Terminal Server**
|
||||
|
||||
Supprimer les comptes inconnus et ajouter les comptes du domaine concernés. Adapter `CTAxx` au nom de domaine de la plateforme. Les listes sont séparées par des points-virgules :
|
||||
|
||||
```text
|
||||
SERVERS-WORKSTATION-DENY-ADMIN
|
||||
CTAxx\DnsAdmins; CTAxx\Admins du domaine; CTAxx\Administrateurs du schéma; CTAxx\Administrateurs de l’entreprise
|
||||
|
||||
SERVERS-WORKSTATION-DENY-ADMIN+BD1+BD2
|
||||
CTAxx\DnsAdmins; CTAxx\BD2; CTAxx\BD1; CTAxx\Admins du domaine; CTAxx\Administrateurs du schéma; CTAxx\Administrateurs de l’entreprise
|
||||
|
||||
SERVERS-WORKSTATION-DENY-ADMIN+BDF
|
||||
CTAxx\DnsAdmins; CTAxx\BDF; CTAxx\Admins du domaine; CTAxx\Administrateurs du schéma; CTAxx\Administrateurs de l’entreprise
|
||||
|
||||
SERVERS-WORKSTATION-DENY-ADMIN+BDF+BD1
|
||||
CTAxx\DnsAdmins; CTAxx\BDF; CTAxx\BD1; CTAxx\Admins du domaine; CTAxx\Administrateurs du schéma; CTAxx\Administrateurs de l’entreprise
|
||||
|
||||
SERVERS-WORKSTATION-DENY-ADMIN+BDF+BD2
|
||||
CTAxx\DnsAdmins; CTAxx\BDF; CTAxx\BD2; CTAxx\Admins du domaine; CTAxx\Administrateurs du schéma; CTAxx\Administrateurs de l’entreprise
|
||||
|
||||
SERVERS-WORKSTATION-DENY-ADMIN+MULTI1
|
||||
CTAxx\MULTI1; CTAxx\DnsAdmins; CTAxx\Admins du domaine; CTAxx\Administrateurs du schéma; CTAxx\Administrateurs de l’entreprise
|
||||
|
||||
SERVERS-WORKSTATION-DENY-ADMIN+MULTI2
|
||||
CTAxx\MULTI2; CTAxx\DnsAdmins; CTAxx\Admins du domaine; CTAxx\Administrateurs du schéma; CTAxx\Administrateurs de l’entreprise
|
||||
|
||||
SERVERS-WORKSTATION-DENY-ADMIN-T0
|
||||
CTAxx\DnsAdmins; CTAxx\Admins du domaine; CTAxx\Administrateurs du schéma
|
||||
```
|
||||
|
||||
Répéter la liste des utilisateurs dans chacune des trois stratégies correspondantes, conformément à la configuration de référence. Vérifier les comptes et les droits avant de lier ou d'appliquer les GPO.
|
||||
|
||||
## 5. Mettre à jour les comptes de service
|
||||
|
||||
Dans Active Directory, ouvrir l'OU `T1-ZONE > T1-INFRA > T1-INFRA-USERS`.
|
||||
|
||||
Activer les comptes utilisés pour administrer l'infrastructure (commutateurs, pare-feu, Nutanix, TELEML et bastion), selon les besoins de la plateforme. Pour chaque compte activé, générer un mot de passe robuste de 20 caractères avec caractères spéciaux et l'enregistrer dans RDM.
|
||||
|
||||
## 6. Placer les postes et serveurs dans leurs OU
|
||||
|
||||
Après leur jonction au domaine, déplacer les objets ordinateurs depuis l'OU `Computers` vers l'OU appropriée :
|
||||
|
||||
- Postes opérateurs : `T2-WORKSTATIONS`.
|
||||
- Serveurs : `T1-SERVERS`.
|
||||
- Serveurs TELEML et SPOOLER : `T1-INFRA-SERVERS`.
|
||||
- Serveurs `TELEM_T0` : `T0-SERVERS`.
|
||||
|
||||
## 7. Configurer DFSR (partage de fichiers)
|
||||
|
||||
> **Prérequis :** les deux serveurs AD doivent être créés et répliqués avant de commencer.
|
||||
|
||||
### 7.1 Créer l'espace de noms
|
||||
|
||||
1. Ouvrir **Gestion du système de fichiers distribués DFS** et lancer l'assistant **Nouvel espace de noms**.
|
||||
2. Ajouter AD1 comme serveur d'espace de noms.
|
||||
3. Saisir `SYSTEL` comme nom de l'espace de noms et ouvrir **Modifier les paramètres**.
|
||||
4. Configurer les paramètres conformément à la configuration de référence et valider.
|
||||
5. Conserver les paramètres par défaut pour les écrans suivants, puis cliquer sur **Créer** et **Fermer**.
|
||||
6. Sélectionner l'espace de noms créé, puis choisir **Ajouter un serveur d'espace de noms**.
|
||||
7. Ajouter AD2, configurer les paramètres conformément à la référence, puis valider les éventuels avertissements après vérification.
|
||||
|
||||
### 7.2 Configurer les droits NTFS sur AD1
|
||||
|
||||
AD1 sert de serveur de référence. Configurer les droits suivants :
|
||||
|
||||
- `D:\SYSTEL\Profils` : lecture et exécution pour `GRP_USERS_T2`.
|
||||
- `D:\SYSTEL\Partages` : lecture et modification pour `GRP_USERS_T1` et `GRP_USERS_T2`.
|
||||
|
||||
### 7.3 Configurer la réplication DFSR
|
||||
|
||||
La procédure source s'arrête pendant la configuration de la réplication. Compléter cette section à partir de la configuration de référence avant d'exploiter le partage : création du groupe de réplication, ajout d'AD1 et AD2, sélection du membre principal, définition des chemins locaux et planification de la réplication. Les paramètres détaillés n'étant pas présents dans le texte source, ne pas les deviner.
|
||||
@@ -0,0 +1,138 @@
|
||||
# Configuration d'un serveur AVL/MDG
|
||||
|
||||
## 1. Prérequis
|
||||
|
||||
- Suivre la procédure **Exporter et importer une VM depuis la plateforme de Production** pour importer la VM AVL dans l'environnement client.
|
||||
- Suivre la procédure **Préparation d'un serveur Windows** pour préparer le serveur.
|
||||
- Avoir accès à l'ancien serveur AVL, au nouveau serveur, au DCSR, à SQL Server Management Studio et à RDM.
|
||||
|
||||
## 2. Configurer l'interface INPT
|
||||
|
||||
L'interface INPT du serveur AVL nécessite une configuration particulière.
|
||||
|
||||
1. Ouvrir les connexions réseau avec la commande `ncpa.cpl`.
|
||||
2. Ouvrir les propriétés de la carte réseau concernée.
|
||||
3. Ne conserver que les composants requis pour l'interface INPT, conformément à la configuration de référence.
|
||||
4. Configurer l'adresse IP et le masque selon le DCSR ou la configuration de l'ancienne VM. L'exemple d'origine concerne le SDIS 27.
|
||||
|
||||
### 2.1 Recréer les routes IPv4 statiques
|
||||
|
||||
Sur l'ancien serveur AVL, afficher la table de routage :
|
||||
|
||||
```cmd
|
||||
route print
|
||||
```
|
||||
|
||||
Repérer les routes IPv4 ajoutées manuellement. Sur le nouveau serveur, recréer chaque route 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 donné pour le SDIS 27 :
|
||||
|
||||
```cmd
|
||||
route -p add 10.27.37.240 MASK 255.255.255.240 10.27.37.238
|
||||
```
|
||||
|
||||
## 3. Migrer la configuration du registre
|
||||
|
||||
1. Sur l'ancien serveur AVL, lancer l'éditeur de registre avec `regedit`.
|
||||
2. Exporter la clé Systel suivante :
|
||||
|
||||
```text
|
||||
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Systel
|
||||
```
|
||||
|
||||
3. Copier le fichier `.reg` généré sur le nouveau serveur et l'importer par double clic.
|
||||
4. Sur le nouveau serveur, ouvrir `regedit` et vérifier les clés et valeurs de `HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Systel`.
|
||||
5. Remplacer les anciennes adresses IP par celles du nouvel environnement. Les noms DNS peuvent être utilisés seulement après validation de leur prise en charge par les applications concernées.
|
||||
|
||||
## 4. Migrer la base SQL LOC
|
||||
|
||||
### 4.1 Sauvegarder la base sur l'ancien serveur
|
||||
|
||||
Avec SQL Server Management Studio, effectuer une sauvegarde de la base `LOC`.
|
||||
|
||||
### 4.2 Copier et restaurer la sauvegarde
|
||||
|
||||
1. Copier le fichier `LOC.bak` sur le nouveau serveur AVL, dans `D:\SQL_Backup`.
|
||||
2. Avec SQL Server Management Studio, restaurer la base `LOC` à partir de cette sauvegarde.
|
||||
3. Vérifier et configurer les options de restauration avant de valider.
|
||||
|
||||
Les options exactes étaient indiquées dans les captures de la procédure d'origine; les confirmer selon l'état de la base et les pratiques SQL du client avant de lancer la restauration.
|
||||
|
||||
### 4.3 Vérifier les utilisateurs SQL
|
||||
|
||||
Les comptes `sa` et `eadstel` sont mentionnés comme déjà créés. Ne pas modifier leurs mots de passe sans validation : certaines applications installées sur le serveur AVL peuvent les utiliser directement. Consulter RDM pour les identifiants autorisés; ne pas inscrire leurs mots de passe dans cette procédure.
|
||||
|
||||
## 5. Vérifier le connecteur ODBC
|
||||
|
||||
Vérifier que le connecteur ODBC `LOCATIONS` fonctionne.
|
||||
|
||||
Si sa configuration doit être restaurée, exécuter le fichier suivant :
|
||||
|
||||
```text
|
||||
D:\Install\Scripts\4-ODBC_LOC.reg
|
||||
```
|
||||
|
||||
Après import, contrôler à nouveau la configuration et le fonctionnement du connecteur.
|
||||
|
||||
## 6. Configurer les applications Systel
|
||||
|
||||
### 6.1 AVL Software
|
||||
|
||||
Depuis l'ancien serveur AVL, copier les fichiers suivants vers les mêmes emplacements sur le nouveau serveur :
|
||||
|
||||
```text
|
||||
C:\Program Files (x86)\AVL Software\Admin\Admin.ini
|
||||
C:\Program Files (x86)\AVL Software\SLoc\srvloc.ini
|
||||
```
|
||||
|
||||
Mettre à jour dans ces fichiers les adresses IP qui doivent pointer vers le nouvel environnement.
|
||||
|
||||
### 6.2 GeoLocAntares
|
||||
|
||||
1. Copier le répertoire suivant depuis l'ancien serveur AVL vers le même emplacement sur le nouveau serveur :
|
||||
|
||||
```text
|
||||
D:\Start\Progs\GeoLocAntares
|
||||
```
|
||||
|
||||
2. Nettoyer le répertoire en supprimant les journaux et les fichiers anciens ou de sauvegarde (`.old`, `.bak`, etc.).
|
||||
3. Modifier `CONFIG_GEOLOCANTARES.xml`.
|
||||
4. Mettre à jour l'adresse IP du serveur AVL.
|
||||
5. Vérifier la cohérence du numéro de SDIS.
|
||||
6. Mettre à jour l'adresse IP de `RPINTVIP` pour les champs `ADRESSE_IP_PINC` et `SEC`.
|
||||
|
||||
Les valeurs exactes doivent correspondre au DCSR et à la configuration réseau du client.
|
||||
|
||||
## 7. Configurer le compte de service et le démarrage automatique
|
||||
|
||||
1. Sur le serveur Active Directory, créer le compte de service AVL et enregistrer son mot de passe dans RDM.
|
||||
2. Ajouter ce compte au groupe local **Administrateurs** du serveur AVL concerné.
|
||||
3. Ouvrir une session sur le serveur AVL avec le compte de service.
|
||||
4. Exécuter en tant qu'administrateur :
|
||||
|
||||
```text
|
||||
D:\Install\System\sources\Autologon.exe
|
||||
```
|
||||
|
||||
5. Accepter le contrat de licence et renseigner les identifiants de la session AVL créée. Les identifiants doivent être gérés dans RDM.
|
||||
6. Ouvrir le dossier de démarrage de la session et y copier les raccourcis vers SRVLOC et GeoLocAntares :
|
||||
|
||||
```text
|
||||
C:\Users\AVL\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
|
||||
```
|
||||
|
||||
Adapter `AVL` au nom réel de la session. Le dossier peut être ajouté à 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.
|
||||
|
||||
## 8. Vérifier les partages et tâches planifiées
|
||||
|
||||
Sur l'ancien serveur AVL, relever les partages SMB et les tâches planifiées. Recréer sur la nouvelle infrastructure ceux qui sont nécessaires, après validation avec l'équipe concernée. Exemple : tâche de purge de la base `LOC`.
|
||||
|
||||
## Points à confirmer
|
||||
|
||||
Les captures de la procédure d'origine contenaient des valeurs détaillées pour les propriétés de la carte INPT, les options de restauration SQL et les paramètres ODBC. Elles n'étant pas transcrites dans le texte, les reprendre depuis le DCSR ou la configuration de l'ancien serveur avant toute modification.
|
||||
@@ -0,0 +1,522 @@
|
||||
# Configuration d'un serveur BD_SQL
|
||||
|
||||
## Prérequis
|
||||
|
||||
Suivre la procédure **Exporter et importer une VM depuis la plateforme de Production** pour importer les VM BDx (SQL) et SQLWitness dans l'environnement client.
|
||||
|
||||
### Préparer les serveurs
|
||||
|
||||
Suivre la procédure **Préparation d'un serveur Windows** pour les serveurs BD. La VM SQLWitness utilise Windows Server Core.
|
||||
|
||||
### Fichier d'échange (SWAP)
|
||||
|
||||
Configurer le fichier d'échange des serveurs BD sur le disque `F:` avec une taille de `4096 Mo`. Après Sysprep, vérifier que ce paramètre est toujours appliqué.
|
||||
|
||||
|
||||
|
||||
## Configurer la VM SQLWitness
|
||||
|
||||
Après l'import, ouvrir la VM en mode console depuis l'hyperviseur.
|
||||
|
||||
### Configuration réseau
|
||||
|
||||
Dans l'interface de configuration, saisir `15` pour ouvrir la ligne de commande.
|
||||
|
||||
|
||||
Exécuter `Get-NetAdapter` et `ipconfig` afin de relever l'index (`ifIndex`), l'adresse IP et la passerelle de l'interface :
|
||||
|
||||
|
||||
Supprimer la configuration actuelle de la carte en remplaçant l'index et les valeurs par les informations relevées précédemment :
|
||||
|
||||
```powershell
|
||||
Remove-NetIPAddress -InterfaceIndex 6 -IPAddress xxx.xxx.xxx.xxx -PrefixLength 24 -DefaultGateway xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
|
||||
Enregistrer la nouvelle configuration de la carte en remplaçant les valeurs par celles du DCSR :
|
||||
|
||||
```powershell
|
||||
New-NetIPAddress -InterfaceIndex 6 -IPAddress xxx.xxx.xxx.xxx -PrefixLength 24 –DefaultGateway xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
|
||||
Revenir à l'écran de configuration avec la commande :
|
||||
|
||||
```powershell
|
||||
sconfig
|
||||
```
|
||||
|
||||
|
||||
Saisir `8` afin de configurer l'interface réseau, puis sélectionner l'interface principale.
|
||||
|
||||
|
||||
|
||||
|
||||
Choisir `2` pour configurer les serveurs DNS associés à la carte réseau.
|
||||
|
||||
|
||||
### Joindre le domaine Active Directory
|
||||
|
||||
Dans `sconfig`, saisir `1` pour configurer le nom de domaine. Entrer les informations demandées, puis redémarrer le serveur.
|
||||
|
||||
|
||||
|
||||
|
||||
Après le redémarrage, se connecter en tant qu'administrateur du domaine. Ajouter le compte AD SQLWitness au groupe local **Administrateurs** du serveur, en remplaçant `xx` par le numéro de département :
|
||||
|
||||
```powershell
|
||||
Add-LocalGroupMember -Group "Administrateurs" -Member "CTAxx\SQLWitness"
|
||||
```
|
||||
|
||||
|
||||
Fermer ensuite la session d'administrateur du domaine et ouvrir une session avec le compte SQLWitness.
|
||||
|
||||
### Comptes locaux
|
||||
|
||||
Dans `sconfig`, saisir `15` pour ouvrir PowerShell.
|
||||
|
||||
|
||||
Le compte Administrateur est désactivé par défaut. Définir un nouveau mot de passe pour les comptes locaux concernés :
|
||||
|
||||
```powershell
|
||||
$Password = Read-Host "Enter the new password" -AsSecureString
|
||||
Set-LocalUser -name "AdminLocal" -Password $Password
|
||||
Set-LocalUser -name "Administrateur" -Password $Password
|
||||
```
|
||||
|
||||
### Créer le partage SQLWitness
|
||||
|
||||
Les commandes suivantes suppriment le partage existant et son contenu, puis recréent le partage `SQL_Witness` :
|
||||
|
||||
```powershell
|
||||
Remove-SmbShare -Name "SQL_Witness"
|
||||
Get-ChildItem C:\SQL_Witness\* | Remove-Item -recurse -force
|
||||
New-SmbShare -Name SQL_Witness -Path C:\SQL_Witness -FullAccess "Administrateurs"
|
||||
Grant-SmbShareAccess -Name "SQL_Witness" -AccountName "CTAXX\GRP_BD_T1" -AccessRight Full -Force
|
||||
```
|
||||
|
||||
|
||||
## Créer le cluster Windows
|
||||
|
||||
1. Sur un serveur AD, ouvrir le Gestionnaire DNS.
|
||||
2. Accorder au groupe **Utilisateurs authentifiés** les droits requis sur l'hôte `BDWINVIP`, conformément à la configuration de référence.
|
||||
3. Sur BD1, connecté avec un compte administrateur du domaine, ouvrir le **Gestionnaire du cluster de basculement**.
|
||||
4. Faire un clic droit sur **Gestionnaire du cluster**, puis choisir **Créer le cluster**.
|
||||
5. Sélectionner les deux serveurs SQL et exécuter les tests de validation.
|
||||
6. Nommer le cluster `BDWINVIP` et saisir l'adresse IP de sa VIP conformément au DCSR.
|
||||
7. Décocher l'option de stockage, puis terminer l'assistant.
|
||||
|
||||
### Ajouter le quorum (témoin de partage de fichiers)
|
||||
|
||||
1. Dans le Gestionnaire du cluster de basculement, ouvrir **Configurer les paramètres du quorum du cluster**.
|
||||
2. Sélectionner **Configuration avancée** et conserver tous les nœuds.
|
||||
3. Choisir **Configurer un témoin de partage de fichiers**.
|
||||
4. Parcourir les partages et sélectionner le partage créé sur SQLWitness.
|
||||
5. Valider la configuration et vérifier que le témoin apparaît en état opérationnel.
|
||||
|
||||
Sélectionner configuration avancée :
|
||||
|
||||
|
||||
Laisser à défaut avec tous les noeuds :
|
||||
|
||||
|
||||
Sélectionner Configurer un témoin de partage de fichiers :
|
||||
|
||||
|
||||
Via le bouton Parcourir, aller chercher le partage sur le serveur SQLWITNESS :
|
||||
|
||||
|
||||
Valider une fois effectué :
|
||||
|
||||
|
||||
Vous devriez obtenir un résultat similaire :
|
||||
|
||||
|
||||
## Configurer SQL Server
|
||||
|
||||
Reconnecter les serveurs BD concernés avec les comptes de domaine prévus et fermer les sessions ouvertes avec le compte Administrateur du domaine. SQL Server est préinstallé et configuré dans le modèle de VM.
|
||||
|
||||
1. Ouvrir **SQL Server Configuration Manager 2022** depuis le raccourci du bureau.
|
||||
2. Arrêter les trois services SQL.
|
||||
|
||||
|
||||
Configurer les comptes de service SQL du domaine avec leurs mots de passe à jour et vérifier que leur type de démarrage est **Automatique**.
|
||||
|
||||
|
||||
Activer également **Always On** sur le service SQL Server destiné au cluster de bases de données. Ne pas effectuer cette étape sur les serveurs BDF et BDT.
|
||||
|
||||
|
||||
Redémarrer **SQL Server** et **SQL Server Agent** depuis le gestionnaire de configuration.
|
||||
|
||||
|
||||
Une fois les serveurs redémarrés, ouvrir SQL Server Management Studio et se connecter avec le compte `sa`. Récupérer son mot de passe dans RDM; ne pas le conserver dans cette procédure.
|
||||
|
||||
|
||||
### Renommer l'instance SQL
|
||||
|
||||
Après le changement de nom du serveur, vérifier le nom configuré dans SQL Server :
|
||||
|
||||
```sql
|
||||
SELECT @@SERVERNAME AS NomServeurConfig,
|
||||
SERVERPROPERTY('MachineName') AS NomMachine,
|
||||
SERVERPROPERTY('ServerName') AS NomServeurComplet;
|
||||
```
|
||||
|
||||
Exécuter le script suivant sur chaque serveur pour remplacer l'ancien nom par le nom actuel de la machine :
|
||||
|
||||
```sql
|
||||
DECLARE @AncienNom NVARCHAR(128);
|
||||
DECLARE @NouveauNom NVARCHAR(128);
|
||||
|
||||
-- Récupération de l'ancien nom configuré dans SQL Server
|
||||
SET @AncienNom = @@SERVERNAME;
|
||||
|
||||
-- Récupération du hostname réel de la machine
|
||||
SET @NouveauNom = CAST(SERVERPROPERTY('MachineName') AS NVARCHAR(128));
|
||||
|
||||
PRINT 'Ancien nom du serveur : ' + ISNULL(@AncienNom, 'Non défini');
|
||||
PRINT 'Nouveau nom du serveur (hostname machine) : ' + @NouveauNom;
|
||||
|
||||
-- Supprimer l'ancien nom
|
||||
IF @AncienNom IS NOT NULL
|
||||
BEGIN
|
||||
EXEC sp_dropserver @server = @AncienNom;
|
||||
END
|
||||
|
||||
-- Ajouter le nouveau nom
|
||||
EXEC sp_addserver @server = @NouveauNom, @local = 'local';
|
||||
GO
|
||||
```
|
||||
|
||||
Redémarrer SQL Server, puis relancer la première requête pour vérifier que les noms correspondent.
|
||||
|
||||
|
||||
|
||||
## Restaurer la base StartDB
|
||||
|
||||
Restaurer la base `StartDB` à partir d'une sauvegarde du client. Cette restauration n'est pas nécessaire sur BD2.
|
||||
|
||||
|
||||
Sélectionner le fichier `.bak` du client.
|
||||
|
||||
|
||||
Dans **Fichiers**, cocher l'option permettant de déplacer les fichiers vers les répertoires appropriés.
|
||||
|
||||
|
||||
Dans **Options**, cocher **Remplacer**, décocher l'option de sauvegarde, puis valider avec **OK**.
|
||||
|
||||
|
||||
La restauration peut prendre quelques minutes.
|
||||
|
||||
|
||||
Dans les propriétés de `StartDB`, régler le mode de récupération sur **Complet** pour BD1/BD2 et sur **Simple** pour les autres serveurs.
|
||||
|
||||
|
||||
Si le niveau de compatibilité est inférieur à 2012, ouvrir `D:\Requetes` et exécuter `Migration_SQL_2012.sql`.
|
||||
|
||||
Si le niveau de compatibilité est 2012, il peut être porté à 2014, mais pas au-delà selon la consigne de cette procédure.
|
||||
|
||||
## Sauvegarder avant Always On
|
||||
|
||||
Effectuer une sauvegarde avant de configurer le cluster Always On. Dans SQL Server Management Studio, ouvrir **Sauvegarder** et renseigner les onglets **Général** et **Options de support** selon la configuration validée pour le client.
|
||||
|
||||
|
||||
Valider avec **OK**, puis suivre l'avancement dans **Progression**.
|
||||
|
||||
|
||||
|
||||
## Configurer le cluster SQL Always On (BD1/BD2 uniquement)
|
||||
|
||||
1. Sur un serveur AD, ouvrir le Gestionnaire DNS et supprimer l'hôte `BDSQLVIP`; il sera recréé automatiquement lors de la configuration du listener.
|
||||
2. Sur l'AD, ouvrir **Active Directory Users and Computers** et activer les **Fonctionnalités avancées**.
|
||||
3. Ouvrir les propriétés de l'OU `T1-SERVERS`.
|
||||
4. Dans l'onglet **Sécurité**, ajouter l'ordinateur `BDWINVIP` et lui accorder le contrôle total sur l'OU selon les autorisations validées.
|
||||
5. Sur BD2, supprimer la base `StartDB`.
|
||||
6. Sur BD1, dans SQL Server Management Studio, créer un nouveau groupe de disponibilité.
|
||||
|
||||
|
||||
Si l'erreur suivante apparaît (généralement suite à une recréation du cluster)
|
||||
|
||||
|
||||
Il sera nécessaire de désactiver puis de réactiver la fonctionnalité AlwaysOn en se basant sur la documentation Microsoft disponible ici :
|
||||
https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/enable-and-disable-always-on-availability-groups-sql-server?view=sql-server-ver16
|
||||
|
||||
Dans l'assistant, saisir `DBSQLHA` comme nom du groupe de disponibilité.
|
||||
|
||||
|
||||
Sélectionner la base `StartDB`, puis cliquer sur **Suivant**.
|
||||
|
||||
|
||||
Cliquer sur **Add Replica** et ajouter le serveur BD2.
|
||||
|
||||
|
||||
Activer **Automatic Failover** pour les deux serveurs.
|
||||
|
||||
|
||||
Dans l'onglet **Listener**, créer la VIP SQL `BDSQLVIP` avec l'adresse IP indiquée dans le DCSR, puis cliquer sur **Suivant**.
|
||||
|
||||
|
||||
Sélectionner **Amorçage automatique**, puis cliquer sur **Suivant**.
|
||||
|
||||
|
||||
Vérifier que tous les contrôles de validation sont réussis, puis cliquer sur **Suivant**.
|
||||
|
||||
|
||||
Une fois la configuration terminée et validée, cliquer sur **Close**.
|
||||
|
||||
|
||||
|
||||
Vérifier que le cluster SQL apparaît dans la section **HA**.
|
||||
|
||||
|
||||
Une fois le cluster créé, régler le paramètre concerné sur **Élevé** afin d'optimiser le temps de démarrage, conformément à la configuration de référence.
|
||||
|
||||
|
||||
## Configurer les comptes SQL
|
||||
|
||||
Trois comptes SQL sont utilisés :
|
||||
|
||||
- `start` : compte applicatif utilisé par les applications Start et associé à la base `StartDB`.
|
||||
- `admin` : compte utilisé pour administrer la base (configuration, requêtes, etc.).
|
||||
- `sa` : compte super-administrateur, à utiliser uniquement en dernier recours.
|
||||
|
||||
Dans l'onglet **General**, modifier les mots de passe `admin` et `sa`, puis les enregistrer dans RDM. Le mot de passe `sa` doit comporter 20 caractères avec des majuscules, des minuscules et des chiffres.
|
||||
|
||||
|
||||
### Créer le compte `start` sur BD1
|
||||
|
||||
Exécuter le script suivant sur BD1. Remplacer la valeur d'exemple de `@Password` par le mot de passe défini et stocké dans RDM, puis relever le SID retourné.
|
||||
|
||||
```sql
|
||||
USE [master];
|
||||
|
||||
DECLARE @UserName SYSNAME = N'start';
|
||||
DECLARE @Password NVARCHAR(128) = N'MonMotDePasseSécurisé';
|
||||
DECLARE @DBName SYSNAME = N'StartDB';
|
||||
|
||||
------------------------------------------------------------
|
||||
-- 1. Supprimer le login s'il existe déjà
|
||||
------------------------------------------------------------
|
||||
IF EXISTS (SELECT 1 FROM sys.server_principals WHERE name = @UserName)
|
||||
BEGIN
|
||||
EXEC(N'DROP LOGIN [' + @UserName + N']');
|
||||
PRINT 'INFO Ancien login supprimé.';
|
||||
END;
|
||||
|
||||
------------------------------------------------------------
|
||||
-- 2. Créer le login
|
||||
------------------------------------------------------------
|
||||
EXEC(N'CREATE LOGIN [' + @UserName + N']
|
||||
WITH PASSWORD = N''' + @Password + N''',
|
||||
CHECK_POLICY = OFF,
|
||||
CHECK_EXPIRATION = OFF;');
|
||||
|
||||
PRINT 'OK Login créé.';
|
||||
|
||||
------------------------------------------------------------
|
||||
-- 3. Supprimer l’utilisateur dans la base s’il existe
|
||||
------------------------------------------------------------
|
||||
DECLARE @SQL NVARCHAR(MAX);
|
||||
|
||||
SET @SQL = '
|
||||
USE [' + @DBName + '];
|
||||
|
||||
IF EXISTS (SELECT 1 FROM sys.database_principals WHERE name = ''' + @UserName + ''')
|
||||
BEGIN
|
||||
DROP USER [' + @UserName + '];
|
||||
PRINT ''INFO Ancien utilisateur supprimé.'';
|
||||
END;
|
||||
';
|
||||
EXEC(@SQL);
|
||||
|
||||
------------------------------------------------------------
|
||||
-- 4. Créer l’utilisateur lié au login
|
||||
------------------------------------------------------------
|
||||
SET @SQL = '
|
||||
USE [' + @DBName + '];
|
||||
|
||||
CREATE USER [' + @UserName + '] FOR LOGIN [' + @UserName + '] WITH DEFAULT_SCHEMA = [dbo];
|
||||
PRINT ''OK Utilisateur créé.';
|
||||
|
||||
-- Ajouter au rôle db_owner
|
||||
ALTER ROLE [db_owner] ADD MEMBER [' + @UserName + '];
|
||||
PRINT ''OK Utilisateur ajouté au rôle db_owner.'';
|
||||
';
|
||||
EXEC(@SQL);
|
||||
|
||||
------------------------------------------------------------
|
||||
-- 5. Récupérer le SID du login
|
||||
------------------------------------------------------------
|
||||
SELECT name, sid
|
||||
FROM sys.server_principals
|
||||
WHERE name = @UserName;
|
||||
```
|
||||
|
||||
Une fois le SID récupéré sur BD1, exécuter le script suivant sur BD2 pour recréer le login `start` avec le même mot de passe et le SID obtenu sur BD1. Remplacer les valeurs d'exemple avant l'exécution :
|
||||
|
||||
```sql
|
||||
USE [master];
|
||||
|
||||
DECLARE @UserName SYSNAME = N'start';
|
||||
DECLARE @Password NVARCHAR(128) = N'MonMotDePasseSécurisé';
|
||||
DECLARE @SID VARBINARY(85) = 0x5077C0831A396E4692011149BD90C403; -- Remplacer par le SID du 1er serveur
|
||||
DECLARE @DBName SYSNAME = N'StartDB'; -- Nom de la base à contrôler
|
||||
|
||||
------------------------------------------------------------
|
||||
-- 1. Supprimer et recréer le login avec le bon SID
|
||||
------------------------------------------------------------
|
||||
IF EXISTS (SELECT 1 FROM sys.server_principals WHERE name = @UserName)
|
||||
BEGIN
|
||||
EXEC(N'DROP LOGIN [' + @UserName + N']');
|
||||
PRINT 'INFO Ancien login supprimé.';
|
||||
END;
|
||||
|
||||
DECLARE @CreateLoginSQL NVARCHAR(MAX);
|
||||
|
||||
SET @CreateLoginSQL = N'CREATE LOGIN [' + @UserName + N']
|
||||
WITH PASSWORD = N''' + @Password + N''',
|
||||
CHECK_POLICY = OFF,
|
||||
CHECK_EXPIRATION = OFF,
|
||||
SID = ' + CONVERT(NVARCHAR(MAX), @SID, 1) + N';';
|
||||
|
||||
EXEC(@CreateLoginSQL);
|
||||
|
||||
PRINT 'OK Login recréé avec le SID du premier serveur.';
|
||||
|
||||
------------------------------------------------------------
|
||||
-- 2. Récupérer le SID du login
|
||||
------------------------------------------------------------
|
||||
SELECT name, sid
|
||||
FROM sys.server_principals
|
||||
WHERE name = @UserName;
|
||||
```
|
||||
|
||||
Le SID du login `start` sur BD2 doit correspondre au SID du login sur BD1.
|
||||
|
||||
Le script suivant compare le SID du login et celui de l'utilisateur `start` dans `StartDB`. Sur un réplica qui n'autorise pas la lecture de la base, le script renvoie un message d'information.
|
||||
|
||||
```sql
|
||||
USE [master];
|
||||
|
||||
DECLARE @UserName SYSNAME = N'start';
|
||||
DECLARE @DBName SYSNAME = N'StartDB';
|
||||
DECLARE @LoginSID VARBINARY(85);
|
||||
DECLARE @UserSID VARBINARY(85);
|
||||
DECLARE @SQL NVARCHAR(MAX);
|
||||
DECLARE @RoleDesc NVARCHAR(60);
|
||||
DECLARE @DbState NVARCHAR(60);
|
||||
|
||||
------------------------------------------------------------
|
||||
-- 1. Récupérer le SID du login (instance)
|
||||
------------------------------------------------------------
|
||||
SELECT @LoginSID = sid
|
||||
FROM sys.server_principals
|
||||
WHERE name = @UserName;
|
||||
|
||||
------------------------------------------------------------
|
||||
-- 2. Vérifier le rôle du réplica local (PRIMARY ou SECONDARY)
|
||||
------------------------------------------------------------
|
||||
SELECT @RoleDesc = rs.role_desc
|
||||
FROM sys.dm_hadr_availability_replica_states rs
|
||||
JOIN sys.availability_replicas r
|
||||
ON rs.replica_id = r.replica_id
|
||||
WHERE rs.is_local = 1;
|
||||
|
||||
------------------------------------------------------------
|
||||
-- 3. Vérifier l’accessibilité de la base
|
||||
------------------------------------------------------------
|
||||
SELECT @DbState = state_desc
|
||||
FROM sys.databases
|
||||
WHERE name = @DBName;
|
||||
|
||||
------------------------------------------------------------
|
||||
-- 4. Si la base est accessible (READ_WRITE ou READ_ONLY), comparer
|
||||
------------------------------------------------------------
|
||||
IF @DbState IN ('ONLINE')
|
||||
BEGIN
|
||||
BEGIN TRY
|
||||
SET @SQL = '
|
||||
SELECT @UserSID_OUT = sid
|
||||
FROM [' + @DBName + '].sys.database_principals
|
||||
WHERE name = @UserName_IN;
|
||||
';
|
||||
|
||||
EXEC sp_executesql
|
||||
@SQL,
|
||||
N'@UserName_IN SYSNAME, @UserSID_OUT VARBINARY(85) OUTPUT',
|
||||
@UserName_IN = @UserName,
|
||||
@UserSID_OUT = @UserSID OUTPUT;
|
||||
|
||||
SELECT
|
||||
@RoleDesc AS [ReplicaRole],
|
||||
@DBName AS [Base],
|
||||
@UserName AS [Nom],
|
||||
@LoginSID AS [SID_Login_Instance],
|
||||
@UserSID AS [SID_Utilisateur_Base],
|
||||
CASE
|
||||
WHEN @LoginSID IS NULL THEN 'NOK Le login n’existe pas sur l’instance'
|
||||
WHEN @UserSID IS NULL THEN 'NOK L’utilisateur n’existe pas dans la base'
|
||||
WHEN @LoginSID = @UserSID THEN 'OK : Login et utilisateur ont le même SID'
|
||||
ELSE 'WARNING Problème : SID différents (utilisateur orphelin)'
|
||||
END AS [Résultat];
|
||||
END TRY
|
||||
BEGIN CATCH
|
||||
SELECT
|
||||
@RoleDesc AS [ReplicaRole],
|
||||
@DBName AS [Base],
|
||||
@UserName AS [Nom],
|
||||
@LoginSID AS [SID_Login_Instance],
|
||||
NULL AS [SID_Utilisateur_Base],
|
||||
'INFO : Impossible de lire la base sur ce réplica (erreur capturée)' AS [Résultat];
|
||||
END CATCH
|
||||
END
|
||||
ELSE
|
||||
BEGIN
|
||||
SELECT
|
||||
@RoleDesc AS [ReplicaRole],
|
||||
@DBName AS [Base],
|
||||
@UserName AS [Nom],
|
||||
@LoginSID AS [SID_Login_Instance],
|
||||
NULL AS [SID_Utilisateur_Base],
|
||||
'INFO : Base non accessible en lecture sur ce réplica secondaire' AS [Résultat];
|
||||
END;
|
||||
```
|
||||
Si le résultat indique que le login et l'utilisateur ont le même SID, aucune action supplémentaire n'est nécessaire.
|
||||
|
||||
## Vérifier les jobs SQL
|
||||
|
||||
Les jobs SQL sont préconfigurés. Vérifier qu'ils sont activés et qu'ils s'exécutent correctement.
|
||||
|
||||
|
||||
|
||||
## Mettre à jour les paramètres en base
|
||||
|
||||
Les modèles de requêtes se trouvent dans `D:\Requetes`.
|
||||
|
||||
### `MiseAJourDesParametresEnBaseSTART.sql`
|
||||
|
||||
Avant l'exécution, remplacer les valeurs `XX` par les adresses IP ou noms correspondant à l'infrastructure. Comparer les valeurs avec celles déjà présentes dans `StartDB` et identifier les paramètres à modifier dans les tables concernées.
|
||||
|
||||
Exemple de vérification :
|
||||
|
||||
```sql
|
||||
SELECT * FROM PARAMETRES_CTA_COMPLEMENTAIRES;
|
||||
```
|
||||
|
||||
### `MiseAJourDesParametresPOSTES.sql`
|
||||
|
||||
Avant l'exécution, remplacer les valeurs `XX` par les adresses IP ou noms correspondant à l'infrastructure. Comparer les valeurs avec celles déjà présentes dans `StartDB`.
|
||||
|
||||
Exemple de vérification :
|
||||
|
||||
```sql
|
||||
SELECT * FROM UC;
|
||||
```
|
||||
|
||||
## Scripts d'import BDF
|
||||
|
||||
Ajouter le compte BDF au groupe local **Administrateurs** du serveur MULTIF, comme dans l'environnement de test. Cette autorisation permet au script d'import de fermer les applications.
|
||||
|
||||
Dans `D:\Import_PROD`, adapter `Restauration_base_OPE_vers_FORM.bat` aux noms des serveurs, applications, machines virtuelles et paramètres de l'infrastructure. Les mots de passe doivent être récupérés dans RDM et ne doivent pas être inscrits dans le script ou cette procédure.
|
||||
|
||||
Adapter également `D:\Requetes\MiseAJourDesParametresEnBaseSTART-FORM.sql`. Le script de production peut servir de base après adaptation à l'environnement de formation.
|
||||
@@ -0,0 +1,149 @@
|
||||
# Configuration d'un serveur Broker VerneMQ
|
||||
|
||||
## 1. Prérequis
|
||||
|
||||
- Suivre la procédure **Exporter et importer une VM depuis la plateforme de Production** pour importer la VM `BROKERx` dans l'environnement client.
|
||||
- Suivre la procédure **Préparation d'un serveur Linux** pour préparer le serveur.
|
||||
|
||||
## 2. Vérifier la configuration DNS
|
||||
|
||||
Sur un serveur AD de la plateforme cible, vérifier la présence des entrées DNS suivantes. Les créer si nécessaire :
|
||||
|
||||
- `AD1` : alias ou hôte vers AD1, utilisé pour le DNS et le NTP.
|
||||
- `AD2` : alias ou hôte vers AD2, utilisé pour le DNS et le NTP.
|
||||
- `SNMP` : alias ou hôte vers le serveur SNMP utilisé pour la supervision.
|
||||
|
||||
## 3. Vérifier les flux réseau
|
||||
|
||||
Sur le pare-feu, vérifier que les flux suivants sont autorisés. Demander leur ouverture au service réseau s'ils sont absents.
|
||||
|
||||
| Source | Destination | Protocole | Port |
|
||||
| --- | --- | --- | --- |
|
||||
| `BROKERx` | `AD1/2` | TCP et UDP | `53` / `123` |
|
||||
| `BROKERx` | `SNMP` | UDP | `161` / `162` |
|
||||
| `RPINT1/2/VIP` | `BROKERx` | TCP | `1883` / `10192` |
|
||||
| `TELEMW1/2` | `BROKERx` | TCP | `22` |
|
||||
|
||||
## 4. Configurer VerneMQ
|
||||
|
||||
Effectuer ces opérations sur chaque serveur Broker.
|
||||
|
||||
1. Se connecter au serveur en tant que `root`.
|
||||
2. Arrêter le service :
|
||||
|
||||
```bash
|
||||
service vernemq stop
|
||||
```
|
||||
|
||||
3. **Attention : la commande suivante supprime le contenu de `/var/lib/vernemq/`, y compris le fichier `.erlang.cookie`. Ne l'exécuter que pendant l'installation ou la réinitialisation prévue du Broker.**
|
||||
|
||||
```bash
|
||||
rm -r /var/lib/vernemq/* && rm /var/lib/vernemq/.erlang.cookie
|
||||
```
|
||||
|
||||
4. Vérifier que le répertoire est vide :
|
||||
|
||||
```bash
|
||||
ll /var/lib/vernemq/
|
||||
```
|
||||
|
||||
5. Dans `/etc/vernemq/vernemq.conf`, remplacer l'ancienne adresse IP `192.168.126.151` par l'adresse IP du Broker concerné :
|
||||
|
||||
```bash
|
||||
sed -i 's/192.168.126.151/IP_SERVEUR_BROKER/g' /etc/vernemq/vernemq.conf
|
||||
```
|
||||
|
||||
6. Vérifier la configuration :
|
||||
|
||||
```bash
|
||||
nano /etc/vernemq/vernemq.conf
|
||||
```
|
||||
|
||||
7. Si les mots de passe de l'ancienne infrastructure respectent déjà les exigences de sécurité, récupérer `/etc/vernemq/vmq.passwd` depuis l'infrastructure de production et le copier sur les Brokers de la nouvelle infrastructure. Sinon, suivre la section **Sécuriser les accès VerneMQ**.
|
||||
8. Démarrer VerneMQ :
|
||||
|
||||
```bash
|
||||
service vernemq start
|
||||
```
|
||||
|
||||
9. Vérifier l'état du service et du cluster :
|
||||
|
||||
```bash
|
||||
service vernemq status
|
||||
vmq-admin cluster show
|
||||
```
|
||||
|
||||
## 5. Créer le cluster VerneMQ
|
||||
|
||||
> Cette étape concerne uniquement les plateformes disposant de deux Brokers, généralement BROKER1 et BROKER2. Les plateformes de test ou de formation à un seul Broker ne sont pas concernées.
|
||||
|
||||
Sur BROKER2, en tant que `root`, rejoindre le nœud BROKER1. Remplacer `IP_BROKER1` par l'adresse IP de BROKER1 :
|
||||
|
||||
```bash
|
||||
vmq-admin cluster join discovery-node=VerneMQ@IP_BROKER1
|
||||
```
|
||||
|
||||
Sur les deux Brokers, vérifier que le cluster contient les deux nœuds :
|
||||
|
||||
```bash
|
||||
vmq-admin cluster show
|
||||
```
|
||||
|
||||
Pour afficher les connexions actives au serveur VerneMQ, utiliser :
|
||||
|
||||
```bash
|
||||
vmq-admin session show
|
||||
```
|
||||
|
||||
## 6. Sécuriser les accès VerneMQ
|
||||
|
||||
### 6.1 Modifier les mots de passe système
|
||||
|
||||
Modifier les mots de passe des comptes `systel` et `root` :
|
||||
|
||||
```bash
|
||||
passwd systel
|
||||
passwd root
|
||||
```
|
||||
|
||||
Générer des mots de passe robustes et les enregistrer dans RDM.
|
||||
|
||||
### 6.2 Configurer les mots de passe des comptes VerneMQ
|
||||
|
||||
Générer dans RDM les mots de passe requis pour les comptes VerneMQ. La liste des six identifiants n'étant pas transcrite dans le texte source, la reprendre depuis la configuration de référence ou auprès de l'équipe responsable.
|
||||
|
||||
Sur BROKER1, ouvrir le fichier de mots de passe :
|
||||
|
||||
```bash
|
||||
nano /etc/vernemq/vmq.passwd
|
||||
```
|
||||
|
||||
Pour chaque compte, saisir le mot de passe prévu après les deux-points. Ne pas inscrire les mots de passe dans cette procédure. Enregistrer et quitter avec **Ctrl+X**.
|
||||
|
||||
Hacher le fichier :
|
||||
|
||||
```bash
|
||||
vmq-passwd -U /etc/vernemq/vmq.passwd
|
||||
```
|
||||
|
||||
Redémarrer VerneMQ et vérifier son état :
|
||||
|
||||
```bash
|
||||
service vernemq restart
|
||||
service vernemq status
|
||||
```
|
||||
|
||||
Sur BROKER2, recopier à l'identique le contenu de `/etc/vernemq/vmq.passwd` depuis BROKER1, puis redémarrer et vérifier le service :
|
||||
|
||||
```bash
|
||||
service vernemq restart
|
||||
service vernemq status
|
||||
```
|
||||
|
||||
## 7. Vérifier le fonctionnement
|
||||
|
||||
Pour afficher les connexions actives :
|
||||
|
||||
```bash
|
||||
sudo vmq-admin session show
|
||||
```
|
||||
@@ -0,0 +1,123 @@
|
||||
# Configurer un serveur HYCU
|
||||
|
||||
## 1. Prérequis
|
||||
|
||||
- Disposer d'un serveur NAS Synology configuré. Suivre la [procédure d'installation d'un serveur NAS Synology](https://tfs2k18.systel-sa.com/tfs/Systel/Etudes/_wiki/wikis/Etudes.wiki/1648/Installation-serveur-NAS-Synology).
|
||||
- Disposer d'une licence HYCU.
|
||||
- Avoir accès au DCSR et aux coffres RDM appropriés pour les comptes et mots de passe.
|
||||
|
||||
## 2. Préparer le NAS Synology
|
||||
|
||||
### 2.1 Créer le compte de service HYCU
|
||||
|
||||
1. Dans le Panneau de configuration, ouvrir **Utilisateur et groupe**, puis choisir **Créer un utilisateur**.
|
||||
2. Créer le compte `HYCU` selon la convention de la plateforme.
|
||||
3. Générer un mot de passe sécurisé avec RDM et l'y enregistrer.
|
||||
4. Conserver les autres options par défaut, sauf indication contraire dans la configuration validée du NAS.
|
||||
|
||||
### 2.2 Créer le dossier partagé HYCU
|
||||
|
||||
1. Dans le Panneau de configuration, ouvrir **Dossier partagé**, puis choisir **Créer un dossier partagé**.
|
||||
2. Créer le partage utilisé par HYCU selon la convention de nommage de la plateforme.
|
||||
3. Accorder au compte `HYCU` les droits de lecture et d'écriture sur ce partage.
|
||||
4. Pour les autres paramètres, appliquer la configuration de référence du NAS; les valeurs de la procédure d'origine étaient uniquement visibles dans les captures.
|
||||
|
||||
## 3. Installer la machine virtuelle HYCU
|
||||
|
||||
### 3.1 Récupérer les fichiers d'installation
|
||||
|
||||
Récupérer la dernière version disponible sur le Cloud Systel :
|
||||
|
||||
```text
|
||||
\\cloud\Produits\Produits_tiers\HYCU\Releases\
|
||||
```
|
||||
|
||||
Pour une installation sur VMware ESXi, récupérer les fichiers `.ovf` et `.vmdk` de la dernière version. Pour une installation spécifique sur une infrastructure Nutanix, récupérer le fichier au format `.qcow2`.
|
||||
|
||||
### 3.2 Déployer la VM sur VMware ESXi
|
||||
|
||||
1. Dans l'interface VMware, lancer la création d'une machine virtuelle à partir d'un fichier OVF.
|
||||
2. Saisir `HYCU` comme nom et sélectionner les fichiers `.ovf` et `.vmdk` récupérés.
|
||||
3. Sélectionner le datastore prévu pour les machines virtuelles.
|
||||
4. Choisir le VLAN correspondant à la VM, le profil **HYCU Backup Controller**, le provisionnement dynamique et l'option de ne pas démarrer la VM à la fin de l'import.
|
||||
5. Dans **Network Settings**, ne pas renseigner les paramètres réseau dans l'assistant : la procédure source indique que ces valeurs ne sont pas transmises correctement à la VM et peuvent bloquer la configuration initiale.
|
||||
6. Terminer l'import.
|
||||
7. Une fois la VM importée, mettre à niveau sa compatibilité avec l'hôte ESXi et confirmer les avertissements affichés.
|
||||
8. Modifier les ressources CPU et mémoire selon le dimensionnement validé pour le client. Les valeurs du tableau d'origine étaient présentes uniquement dans les captures; les confirmer auprès de l'équipe infrastructure avant le démarrage.
|
||||
9. Démarrer la VM.
|
||||
|
||||
## 4. Effectuer la configuration initiale
|
||||
|
||||
1. Dans la console de la VM, sélectionner l'option `1`.
|
||||
2. Renseigner les paramètres réseau conformément au DCSR et à la configuration du client.
|
||||
3. Attendre la fin de la configuration automatique, puis valider avec **OK**.
|
||||
|
||||
## 5. Configurer le portail HYCU
|
||||
|
||||
Depuis un poste autorisé, ouvrir :
|
||||
|
||||
```text
|
||||
https://IP_SERVER_HYCU:8443
|
||||
```
|
||||
|
||||
Utiliser les identifiants initiaux fournis ou stockés dans le coffre sécurisé. Ne pas conserver les identifiants par défaut : modifier le mot de passe dès la première connexion et l'enregistrer dans RDM.
|
||||
|
||||
### 5.1 Modifier le mot de passe et désactiver SSH
|
||||
|
||||
Suivre l'assistant de première configuration pour modifier le mot de passe du compte d'administration, en générant le nouveau mot de passe dans RDM.
|
||||
|
||||
Désactiver ensuite les connexions SSH depuis les paramètres de sécurité, sauf besoin d'exploitation explicitement validé.
|
||||
|
||||
## 6. Créer les comptes de service sur les sources
|
||||
|
||||
Créer un compte de service HYCU sur chacun des environnements concernés :
|
||||
|
||||
- Prism Element;
|
||||
- Prism Central;
|
||||
- vCenter, si l'environnement VMware est utilisé.
|
||||
|
||||
Générer les mots de passe avec RDM et accorder aux comptes les permissions requises par HYCU selon la configuration validée de chaque plateforme. Les rôles et permissions détaillés n'étant pas transcrits dans le texte source, les reprendre depuis la documentation de référence ou auprès de l'équipe infrastructure.
|
||||
|
||||
## 7. Ajouter les sources Nutanix
|
||||
|
||||
1. Dans le portail HYCU, ouvrir la section d'ajout des sources.
|
||||
2. Ajouter chaque cluster Nutanix et renseigner les informations demandées à partir du DCSR.
|
||||
3. Si l'assistant détecte un Prism Central, saisir également les informations correspondantes.
|
||||
4. Enregistrer la source.
|
||||
5. Prendre en compte le message affiché par HYCU et appliquer la correction demandée à l'étape suivante.
|
||||
6. Sur le cluster Nutanix, ajouter l'adresse IP iSCSI. Si aucune adresse n'est indiquée dans le DCSR, choisir une adresse disponible à la suite de la plage prévue, après vérification qu'elle n'est pas déjà utilisée.
|
||||
7. Répéter ces étapes pour les autres clusters Nutanix.
|
||||
|
||||
## 8. Ajouter les sources VMware
|
||||
|
||||
Si l'environnement comporte VMware :
|
||||
|
||||
1. Dans la section des sources HYCU, ajouter chaque vCenter VMware.
|
||||
2. Renseigner les informations demandées à partir du DCSR et du coffre sécurisé.
|
||||
3. Cliquer sur **Next**, vérifier la configuration, puis sur **Save**.
|
||||
|
||||
## 9. Ajouter la destination de sauvegarde NAS
|
||||
|
||||
1. Dans HYCU, ouvrir **Target**, puis cliquer sur **Add**.
|
||||
2. Saisir le nom du NAS.
|
||||
3. Définir à `4` le nombre de tâches de sauvegarde simultanées et activer la compression.
|
||||
4. Renseigner le type de partage, le compte HYCU, l'adresse IP du NAS et le nom du partage créé précédemment.
|
||||
5. Enregistrer la destination et vérifier qu'elle est joignable.
|
||||
|
||||
## 10. Créer les tâches de sauvegarde
|
||||
|
||||
Pour créer les tâches et le plan de sauvegarde, suivre la procédure **HYCU : Mise en place du plan de sauvegarde**.
|
||||
|
||||
## 11. Activer la licence HYCU
|
||||
|
||||
1. Dans le portail HYCU, ouvrir **Options > Licensing**.
|
||||
2. Vérifier la cohérence des informations affichées, notamment le nombre de machines virtuelles et de CPU.
|
||||
3. Cliquer sur **Download Request** et récupérer le fichier `license.req`.
|
||||
4. Ouvrir le portail de licences : <https://licensing.hycu.com/>.
|
||||
5. Se connecter avec les identifiants indiqués dans le RDM commun.
|
||||
6. Saisir le numéro d'achat indiqué sur le document de licence. S'il est introuvable, contacter Philippe CUVELIER ou Sabrina BECHET.
|
||||
7. Charger le fichier `license.req`.
|
||||
8. Choisir le type de licence (nombre de CPU ou de VM), saisir la quantité correspondante, puis cliquer sur **Activate Licences**.
|
||||
9. Récupérer le fichier `hycu.lic` généré. Si la boîte de réception associée n'est pas accessible, demander le transfert du fichier à G. Foucard ou N. Padiolleau.
|
||||
10. Transférer le fichier sur la TELEMW du client, revenir dans le portail HYCU, cliquer sur **Upload Licence**, sélectionner le fichier et cliquer sur **Upload**.
|
||||
11. Vérifier que la licence est active dans HYCU.
|
||||
@@ -0,0 +1,124 @@
|
||||
# Configuration d'un serveur INTEROPE
|
||||
|
||||
## 1. Prérequis
|
||||
|
||||
- Suivre la procédure **Exporter et importer une VM depuis la plateforme de Production** pour importer la VM `INTEROPEx` dans l'environnement client.
|
||||
- Suivre la procédure **Préparation d'un serveur Windows** pour préparer le serveur.
|
||||
- Avoir accès à l'ancien serveur INTEROPE, au nouveau serveur, à SQL Server Management Studio et à RDM.
|
||||
|
||||
## 2. Migrer la configuration du registre
|
||||
|
||||
1. Sur l'ancien serveur INTEROPE, ouvrir l'éditeur du registre avec `regedit`.
|
||||
2. Exporter la clé Systel suivante :
|
||||
|
||||
```text
|
||||
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Systel
|
||||
```
|
||||
|
||||
3. Copier le fichier `.reg` généré sur le nouveau serveur INTEROPE et l'importer par double clic.
|
||||
4. Sur le nouveau serveur, ouvrir `regedit` et vérifier les clés et valeurs importées.
|
||||
5. Remplacer les anciennes adresses IP par celles du nouvel environnement. Les noms DNS ne doivent être utilisés qu'après validation de leur prise en charge par les applications concernées.
|
||||
|
||||
## 3. Migrer la base SQL Passerelle
|
||||
|
||||
### 3.1 Sauvegarder la base sur l'ancien serveur
|
||||
|
||||
Avec SQL Server Management Studio, effectuer une sauvegarde de la base `Passerelle`.
|
||||
|
||||
### 3.2 Copier et restaurer la sauvegarde
|
||||
|
||||
1. Copier le fichier `passerelle.bak` sur le nouveau serveur INTEROPE, dans :
|
||||
|
||||
```text
|
||||
D:\SQL_Backup
|
||||
```
|
||||
|
||||
2. Avec SQL Server Management Studio, restaurer la base `Passerelle` à partir de ce fichier.
|
||||
3. Vérifier les options de restauration avant de valider. Les options précises étaient indiquées dans les captures de la procédure d'origine; les confirmer selon la configuration SQL du client.
|
||||
|
||||
### 3.3 Configurer l'utilisateur SQL
|
||||
|
||||
Le compte `sa` est déjà créé. Modifier son mot de passe et générer un mot de passe fort, à enregistrer dans RDM. Ne pas conserver le mot de passe par défaut dans la procédure ou dans un fichier non sécurisé.
|
||||
|
||||
## 4. Migrer et nettoyer les applications Systel
|
||||
|
||||
1. Sur l'ancien serveur INTEROPE, récupérer le répertoire :
|
||||
|
||||
```text
|
||||
D:\Start\Progs
|
||||
```
|
||||
|
||||
2. Le copier sur le nouveau serveur au même emplacement.
|
||||
3. Nettoyer les fichiers et répertoires inutiles (journaux, fichiers `.old`, répertoires vides et scripts non utilisés).
|
||||
4. Mettre à jour, dans les fichiers de configuration concernés, les adresses IP et noms DNS pour correspondre au nouvel environnement.
|
||||
|
||||
Les paramètres exacts dépendant des applications et de la plateforme, les comparer à la configuration de l'ancien serveur et au DCSR.
|
||||
|
||||
### 4.1 GestionRC
|
||||
|
||||
La configuration de GestionRC est stockée dans le registre. Créer également le partage suivant et accorder les droits requis à tous les utilisateurs concernés :
|
||||
|
||||
```text
|
||||
D:\Start\Progs\GestionRC\Enregistrements
|
||||
```
|
||||
|
||||
### 4.2 ServeurSMS
|
||||
|
||||
La configuration du ServeurSMS est stockée dans le registre. Vérifier les valeurs reprises depuis l'ancien serveur et les adapter à la nouvelle infrastructure.
|
||||
|
||||
### 4.3 Passerelle TPL/BIRDY
|
||||
|
||||
Dans les répertoires et sous-répertoires de l'application, vérifier les fichiers de configuration et mettre à jour les paramètres nécessaires.
|
||||
|
||||
Récupérer également le répertoire suivant depuis l'ancien serveur et vérifier les fichiers qu'il contient :
|
||||
|
||||
```text
|
||||
C:\ProgramData\TPLSYSTEMES\PasserelleBIRDY
|
||||
```
|
||||
|
||||
## 5. Générer la clé KeySTARTDB
|
||||
|
||||
Lancer `KeySTARTDB.exe`, saisir le nom du connecteur ODBC et le mot de passe associé. Récupérer ce mot de passe dans RDM.
|
||||
|
||||
## 6. Configurer le compte de service et le démarrage automatique
|
||||
|
||||
Pour chaque serveur INTEROPE :
|
||||
|
||||
1. Sur le serveur Active Directory, créer un compte de service dédié, nommé selon la convention `INTEROPEx`.
|
||||
2. Générer son mot de passe et l'enregistrer dans RDM.
|
||||
3. Ajouter ce compte au groupe local **Administrateurs** du serveur concerné.
|
||||
4. Ouvrir une session sur le serveur avec ce compte.
|
||||
5. Ajouter au Bureau public les raccourcis des applications Systel présentes dans `D:\Start\Progs` :
|
||||
|
||||
```text
|
||||
C:\Users\Public\Desktop
|
||||
```
|
||||
|
||||
6. Exécuter en tant qu'administrateur :
|
||||
|
||||
```text
|
||||
D:\Install\System\sources\Autologon.exe
|
||||
```
|
||||
|
||||
7. Accepter le contrat de licence et saisir les identifiants de la session INTEROPE créée. Les identifiants doivent être stockés dans RDM.
|
||||
8. Ouvrir le dossier de démarrage de la session et y copier les raccourcis vers **Administration Passerelle BIRDY 3**, **PasserelleGSM**, **ServeurSMS** et **GestionRC** :
|
||||
|
||||
```text
|
||||
C:\Users\INTEROPEx\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
|
||||
```
|
||||
|
||||
Adapter `INTEROPEx` au nom de la session utilisé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.
|
||||
|
||||
## 7. Vérifier les partages et tâches planifiées
|
||||
|
||||
Sur l'ancien serveur INTEROPE, relever les partages SMB et les tâches planifiées. Recréer sur la nouvelle infrastructure ceux qui sont nécessaires.
|
||||
|
||||
Vérifier notamment le bon fonctionnement de la tâche **Purge et relance ServeurSMS**.
|
||||
|
||||
## 8. Convertisseur Moxa pour ServeurSMS
|
||||
|
||||
> **Attention :** lors d'un renouvellement d'infrastructure avec passage à un INTEROPE virtuel et utilisation d'un convertisseur Moxa, les noms de ports COM peuvent changer dans la configuration du ServeurSMS. La procédure source recommande de configurer le port COM 1.
|
||||
|
||||
Après avoir suivi la procédure **Installation-Convertisseur-MOXA**, identifier les liaisons entrantes et sortantes dans le schéma technique du Moxa et dans la configuration du registre de l'INTEROPE. Vérifier que les ports COM configurés correspondent au câblage réel.
|
||||
@@ -0,0 +1,150 @@
|
||||
# Configuration d'un serveur INTERSGO
|
||||
|
||||
## 1. Prérequis
|
||||
|
||||
- Suivre la procédure **Exporter et importer une VM depuis la plateforme de Production** pour importer la VM `INTERSGOx` dans l'environnement client.
|
||||
- Suivre la procédure **Préparation d'un serveur Linux** pour préparer la VM.
|
||||
- Disposer du DCSR et d'un accès à l'ancien serveur INTERSGO de production.
|
||||
|
||||
## 2. Configurer le DNS
|
||||
|
||||
Sur un serveur AD de la plateforme cible, vérifier la présence des entrées DNS ci-dessous et les créer si nécessaire :
|
||||
|
||||
- `AD1` : entrée ou alias vers AD1 pour DNS et NTP.
|
||||
- `AD2` : entrée ou alias vers AD2 pour DNS et NTP.
|
||||
- `ServeurActiveMQ1` : alias vers MULTI1 pour ActiveMQ.
|
||||
- `ServeurActiveMQ2` : alias vers MULTI2 pour ActiveMQ.
|
||||
- **SQL** : alias `ServeurBD` vers `BDSQLVIP` pour la connexion à la base de données.
|
||||
- **Oracle** : entrées `BD1` et `BD2` vers les serveurs correspondants pour la connexion à la base de données.
|
||||
|
||||
Adapter les noms et destinations selon qu'il s'agit d'une plateforme de production, de formation ou de test, en suivant le DCSR et la configuration de référence.
|
||||
|
||||
## 3. Vérifier les flux réseau
|
||||
|
||||
Sur le pare-feu, vérifier que les flux suivants sont autorisés. Demander leur ouverture au service réseau s'ils sont absents.
|
||||
|
||||
| Source | Destination | Protocole | Ports |
|
||||
| --- | --- | --- | --- |
|
||||
| `INTERSGOx` | `AD1/AD2` | TCP et UDP | `53`, `123` |
|
||||
| `INTERSGOx` | `MULTI1/MULTI2` | TCP | `61616` |
|
||||
| `INTERSGOx` | `BDVIP` (SQL) | TCP | `1433` |
|
||||
| `INTERSGOx` | `BD1/BD2` (Oracle) | TCP | `1521` |
|
||||
| `RPINT1/RPINT2/RPINT_VIP` | `INTERSGOx` | TCP | `443`, `18080`, `10443`, `1518`, `20443` |
|
||||
| `TELEMW1/TELEMW2` | `INTERSGOx` | TCP | `22`, `443`, `18080`, `4848` |
|
||||
|
||||
## 4. Récupérer les fichiers de l'ancien serveur
|
||||
|
||||
Depuis l'ancien serveur `INTERSGO1` de production, récupérer en SFTP avec FileZilla ou WinSCP les répertoires suivants :
|
||||
|
||||
```text
|
||||
/opt/glassfish3/keystore
|
||||
/opt/glassfish3/distribution/xsd
|
||||
```
|
||||
|
||||
Récupérer également les fichiers suivants :
|
||||
|
||||
```text
|
||||
/opt/glassfish3/glassfish/domains/domain1/config/cacerts.jks
|
||||
/opt/glassfish3/glassfish/domains/domain1/config/keystore.jks
|
||||
```
|
||||
|
||||
Transférer ces éléments vers le nouveau serveur aux mêmes emplacements. Avant le transfert, remplacer ou supprimer les fichiers déjà présents si nécessaire.
|
||||
|
||||
## 5. Configurer GlassFish depuis le portail d'administration
|
||||
|
||||
### 5.1 Se connecter
|
||||
|
||||
Depuis un serveur TELEMW Windows, ouvrir l'interface d'administration à l'adresse suivante :
|
||||
|
||||
```text
|
||||
https://INTERSGOx:4848
|
||||
```
|
||||
|
||||
Se connecter avec le compte d'administration prévu et récupérer son mot de passe dans RDM. Ne pas conserver de mot de passe en clair dans cette procédure.
|
||||
|
||||
### 5.2 Paramétrer Java
|
||||
|
||||
Ouvrir les paramètres Java dans le portail d'administration.
|
||||
|
||||
- Modifier `-Xmx5120m` pour définir la mémoire maximale de GlassFish à la mémoire totale de la VM moins 1 Go. Pour une VM de 6 Go, la valeur par défaut est `5120m`.
|
||||
- Conserver `-Xms1024m`, qui définit la mémoire minimale à 1 Go.
|
||||
- Le paramètre `-DACTIVEMQ_IP=ServeurActiveMQ1;ServeurActiveMQ2` correspond aux serveurs ActiveMQ. Le modifier uniquement pour les plateformes de test ou de formation, selon leur configuration.
|
||||
|
||||
### 5.3 Paramétrer la base de données
|
||||
|
||||
Ouvrir les paramètres de la base de données **StartPool**. Vérifier et adapter si nécessaire l'utilisateur, le mot de passe, le nom de la VM et la chaîne de connexion en fonction de l'environnement cible. Récupérer les identifiants dans RDM.
|
||||
|
||||
Pour tester la connexion, ouvrir l'onglet **General**, puis cliquer sur **Ping**.
|
||||
|
||||
La VM est préconfigurée pour une base SQL. Pour utiliser Oracle, adapter l'ensemble des paramètres à partir de la configuration de la VM existante.
|
||||
|
||||
### 5.4 Vérifier les paramètres du serveur
|
||||
|
||||
Ouvrir les paramètres du serveur et comparer leur configuration avec celle du serveur actuel. Reporter sur la nouvelle VM les paramètres validés pour le client.
|
||||
|
||||
### 5.5 Vérifier les processus d'écoute HTTP
|
||||
|
||||
Ouvrir les paramètres des processus d'écoute HTTP. Pour chaque port, vérifier la configuration de l'ancien serveur : activation, sécurisation et certificat. Si un port requis n'existe pas sur la nouvelle VM, le créer avec les paramètres validés.
|
||||
|
||||
## 6. Déployer l'application ServeurSGO
|
||||
|
||||
Récupérer sur le Cloud Systel la version de ServeurSGO correspondant à la version de Start utilisée.
|
||||
|
||||
Emplacement des versions de référence :
|
||||
|
||||
```text
|
||||
\\cloud\Qualité\Alerte\Version de référence SGO_11x\Version WebCIS\ServeurSGO\ServeurSGO_485.11x.xxxx-x.war
|
||||
```
|
||||
|
||||
Autre emplacement possible :
|
||||
|
||||
```text
|
||||
\\cloud\Qualité\Production_Version\Publiée\SGO_4.85.117\Archives
|
||||
```
|
||||
|
||||
Dans le portail GlassFish, ouvrir les paramètres **Applications**, puis cliquer sur **Déployer**. Charger le fichier `.war`, sélectionner le serveur et saisir `ServeurSGO` comme racine du contexte. Valider avec **OK**.
|
||||
|
||||
Vérifier le déploiement depuis un navigateur en utilisant l'URL correspondant à la plateforme :
|
||||
|
||||
```text
|
||||
http://INTERSGO1:18080/ServeurSGO/
|
||||
http://INTERSGO1:18080/ServeurSGO/fr/
|
||||
```
|
||||
|
||||
## 7. Mettre à jour les paramètres en base de données
|
||||
|
||||
Depuis un outil de requête SQL, par exemple SQL Server Management Studio sur un serveur BD ou TELEMW, consulter la table `SGO_DESCRIPTION` :
|
||||
|
||||
```sql
|
||||
SELECT * FROM SGO_DESCRIPTION;
|
||||
```
|
||||
|
||||
Mettre à jour les adresses IP du serveur INTERSGO ou du réseau associé selon les valeurs propres au client. Les modifications exactes doivent être déterminées à partir des paramètres existants et du DCSR.
|
||||
|
||||
Exemple de mise à jour des deux adresses IP :
|
||||
|
||||
```sql
|
||||
UPDATE SGO_DESCRIPTION SET ADRESSE_IP3 = '10.182.9.41' WHERE ID = '3';
|
||||
UPDATE SGO_DESCRIPTION SET ADRESSE_IP2 = '10.182.9.41' WHERE ID = '4';
|
||||
```
|
||||
|
||||
Ajouter les requêtes nécessaires dans le fichier suivant sur BD1 afin que les nouveaux paramètres soient appliqués lors de la bascule :
|
||||
|
||||
```text
|
||||
D:\Requetes\1- MiseAJourDesParametresEnBaseSTART.sql
|
||||
```
|
||||
|
||||
## 8. Gérer les comptes système
|
||||
|
||||
Modifier les mots de passe des comptes `systel` et `root` avec les commandes suivantes :
|
||||
|
||||
```bash
|
||||
passwd systel
|
||||
passwd root
|
||||
```
|
||||
|
||||
Générer des mots de passe robustes et les enregistrer dans RDM.
|
||||
|
||||
## 9. Dépannage : activer les journaux GlassFish
|
||||
|
||||
En cas de problème de fonctionnement, activer les journaux GlassFish depuis le portail d'administration et consulter les événements correspondant à l'incident. Les options exactes d'activation ne figurant que dans les captures d'origine, les confirmer selon la version installée ou auprès de l'équipe responsable.
|
||||
@@ -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,69 @@
|
||||
# Serveur TELEML
|
||||
|
||||
## Prérequis
|
||||
|
||||
* Suivre la procédure d'export d'une VM *202x-xx-xx TELEML* depuis la plateforme de production vers l'environnement du client.
|
||||
|
||||
## Préparation du serveur
|
||||
|
||||
* Suivre la procédure commune de préparation d'un serveur Linux.
|
||||
|
||||
## Comptes et mots de passe
|
||||
|
||||
* Modifier les mots de passe des comptes **systel** et **root** à l'aide des commandes `passwd systel` et `passwd root`.
|
||||
* Générer les mots de passe et les enregistrer dans RDM.
|
||||
|
||||
## Configuration de Nexus (si la VM héberge des conteneurs Docker)
|
||||
|
||||
### Mot de passe de l'administrateur
|
||||
|
||||
* Modifier le mot de passe de l'utilisateur **admin** de l'interface *Nexus Repository*. Le mot de passe par défaut est disponible dans RDM, à l'emplacement `PPR\Pré-production\PPR Clients\Serveurs PPR Clients\Credentials\CTAXX-TELEML - Nexus repository - admin`.
|
||||
* Pour cela, suivez les étapes ci-dessous :
|
||||
|
||||
1. Ouvrir l'interface de Nexus Repository à l'adresse [http://XX.XX.XX.XX:8081](http://XX.XX.XX.XX:8081), cliquer sur **Sign in** (1), puis se connecter avec le compte **admin** et son mot de passe par défaut (2). Cliquer ensuite sur **Sign in** (3).
|
||||
2. Cliquer sur l'icône en forme de rouage (1), ouvrir **Security**, puis **Users** (2), et sélectionner l'utilisateur **admin** (3).
|
||||
3. Sur la page de gestion de l'utilisateur **admin**, cliquer sur **Change password** (1), saisir et confirmer le nouveau mot de passe, puis cliquer sur **Change password** (2).
|
||||
4. Confirmer la modification en saisissant l'ancien mot de passe, disponible dans RDM.
|
||||
|
||||
### Images Docker
|
||||
|
||||
* Se connecter au bastion Systel avec un compte OPS (contacter le SI si nécessaire), puis ouvrir une session sur la VM **OPS-TELEML01** :
|
||||
[https://bastion-ops-t1.systel-sa.com](https://bastion-ops-t1.systel-sa.com)
|
||||
* Connectez-vous avec le compte **udocker**, disponible dans la section **COMMUN** de RDM.
|
||||
* Se connecter avec le compte **udocker**, disponible dans la section **COMMUN** de RDM.
|
||||
* Modifier le fichier **daemon.json** à l'aide de la commande suivante :
|
||||
|
||||
```bash
|
||||
nano /etc/docker/daemon.json
|
||||
```
|
||||
|
||||
* Ajoutez l'adresse IP de votre serveur TELEML à la fin du fichier. **Veillez à ajouter une virgule à la ligne précédente**, sinon le fichier JSON ne sera pas chargé. Enregistrez le fichier et quittez l'éditeur (**Ctrl+X**, puis **Y**).
|
||||
* Ajouter l'adresse IP du serveur TELEML à la fin du fichier. **Veiller à ajouter une virgule à la ligne précédente**, sinon le fichier JSON ne sera pas chargé. Enregistrer le fichier et quitter l'éditeur (**Ctrl+X**, puis **Y**).
|
||||
* Exécuter la commande suivante pour recharger la configuration. Il est possible de rester connecté avec l'utilisateur **udocker** (choix 2, puis saisie de son mot de passe) :
|
||||
|
||||
```bash
|
||||
service docker restart
|
||||
```
|
||||
|
||||
* Exécutez la commande suivante pour transférer les **images de base**, dans leur dernière version, du Nexus Systel vers le Nexus de votre VM TELEML. La VM **OPS-TELEML01** sert uniquement de relais entre les deux Nexus.
|
||||
* Exécuter la commande suivante pour transférer les **images de base** dans leur dernière version du Nexus Systel vers le Nexus de la VM TELEML. La VM **OPS-TELEML01** sert uniquement de relais entre les deux Nexus.
|
||||
* **Remplacer l'adresse IP `10.33.XX.3` par celle du serveur TELEML.**
|
||||
|
||||
```bash
|
||||
docker run -it --rm --name sendimage --privileged --pull always -e REMOTE_REPOSITORY_ADDRESS=10.33.XX.3:7777 -e GROUP=BASE nexus.systel.local:7777/tool/senddockerimages:latest
|
||||
```
|
||||
|
||||
* Cette commande transfère sur votre Nexus client les images de base dans leur dernière version.
|
||||
* Les images de base comprennent `portainer/agent`, `portainer/portainer-ce`, `traefik`, `stack-templates` et `bash`.
|
||||
|
||||
### Problème des images manquantes
|
||||
|
||||
* Certaines versions d'images peuvent ne pas être correctement associées au groupe d'images de base portant le tag `latest`.
|
||||
* Si le script **setupSwarm.sh** signale qu'une image est absente du Nexus, transférer manuellement l'image concernée.
|
||||
* **Remplacer l'adresse IP `10.33.XX.3` par celle du serveur TELEML.**
|
||||
* **portainer/agent :** `docker run -it --rm --name sendimage --privileged --pull always -e IMAGE=portainer/agent:X.X.X -e LOCAL_REPOSITORY_ADDRESS=nexus-docker.dev.systel.local -e REMOTE_REPOSITORY_ADDRESS=10.33.XX.3:7777 nexus.systel.local:7777/tool/senddockerimages:latest`
|
||||
* **portainer/portainer-ce :** `docker run -it --rm --name sendimage --privileged --pull always -e IMAGE=portainer/portainer-ce:X.X.X -e LOCAL_REPOSITORY_ADDRESS=nexus-docker.dev.systel.local -e REMOTE_REPOSITORY_ADDRESS=10.33.XX.3:7777 nexus.systel.local:7777/tool/senddockerimages:latest`
|
||||
* **traefik :** `docker run -it --rm --name sendimage --privileged --pull always -e IMAGE=traefik:vX.X.X -e LOCAL_REPOSITORY_ADDRESS=nexus-docker.dev.systel.local -e REMOTE_REPOSITORY_ADDRESS=10.33.XX.3:7777 nexus.systel.local:7777/tool/senddockerimages`
|
||||
|
||||
* Pour consulter les images disponibles, ouvrir l'interface Nexus suivante :
|
||||
[https://nexus.dev.systel.local](https://nexus.dev.systel.local)
|
||||
@@ -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.
|
||||
@@ -0,0 +1,163 @@
|
||||
# Préparation d'un serveur Windows Server Core
|
||||
|
||||
## 1. Prérequis et accès
|
||||
|
||||
1. Suivre la procédure d'export et d'import d'une VM depuis la plateforme de Production vers l'environnement client : **Exporter et importer une VM depuis la plateforme de Production**.
|
||||
2. Depuis l'hyperviseur, ouvrir la console de la VM.
|
||||
3. Envoyer la combinaison **Ctrl+Alt+Suppr**, puis s'authentifier avec le compte administrateur.
|
||||
4. Récupérer le mot de passe initial dans le coffre-fort sécurisé prévu à cet effet. Ne pas conserver de mot de passe en clair dans cette procédure.
|
||||
|
||||
Après l'import, ouvrir la VM en mode console depuis l'hyperviseur.
|
||||
|
||||
## 2. Exécuter Sysprep
|
||||
|
||||
1. Dans l'interface de configuration, saisir `15` pour ouvrir la ligne de commande.
|
||||
2. Lancer Sysprep :
|
||||
|
||||
```cmd
|
||||
C:\Windows\System32\Sysprep\sysprep.exe
|
||||
```
|
||||
|
||||
3. Après le redémarrage, définir le mot de passe du compte Administrateur lorsque Windows le demande.
|
||||
4. Pour l'envoi des données de diagnostic, sélectionner l'option `1`.
|
||||
|
||||
## 3. Configurer le réseau
|
||||
|
||||
Après le redémarrage et l'authentification, saisir `15` dans l'interface de configuration pour ouvrir la ligne de commande.
|
||||
|
||||
### 3.1 Identifier et renommer l'interface réseau
|
||||
|
||||
Afficher les interfaces et relever leur index (`ifIndex`) ainsi que leur nom :
|
||||
|
||||
```powershell
|
||||
Get-NetAdapter
|
||||
```
|
||||
|
||||
Renommer l'interface selon le VLAN, en adaptant le nom et la valeur d'exemple :
|
||||
|
||||
```powershell
|
||||
Rename-NetAdapter -Name "Ethernet" -NewName "NEXSIS_SERVEURS"
|
||||
```
|
||||
|
||||
### 3.2 Configurer l'adresse IPv4
|
||||
|
||||
Configurer l'adresse IP, le préfixe et la passerelle conformément au DCSR. Remplacer l'index et les valeurs d'exemple avant d'exécuter la commande :
|
||||
|
||||
```powershell
|
||||
New-NetIPAddress -InterfaceIndex 6 -IPAddress xxx.xxx.xxx.xxx -PrefixLength 27 -DefaultGateway xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
### 3.3 Configurer les serveurs DNS
|
||||
|
||||
1. Revenir à l'interface de configuration avec :
|
||||
|
||||
```powershell
|
||||
sconfig
|
||||
```
|
||||
|
||||
2. Choisir l'option `8` pour configurer l'interface réseau.
|
||||
3. Saisir l'index de l'interface concernée.
|
||||
4. Choisir l'option `2` pour configurer les serveurs DNS.
|
||||
5. Selon la procédure source, définir l'autre contrôleur de domaine comme DNS principal et `127.0.0.1` comme DNS secondaire.
|
||||
|
||||
Après cette première configuration réseau, il est possible de se connecter au serveur en Bureau à distance avec le compte Administrateur afin de poursuivre plus facilement.
|
||||
|
||||
### 3.4 Désactiver IPv6
|
||||
|
||||
Récupérer le nom de l'interface :
|
||||
|
||||
```powershell
|
||||
Get-NetAdapter
|
||||
```
|
||||
|
||||
Vérifier l'état de la liaison IPv6 :
|
||||
|
||||
```powershell
|
||||
Get-NetAdapterBinding -Name "NEXSIS_SERVEURS" -ComponentID ms_tcpip6
|
||||
```
|
||||
|
||||
Si `Enabled` vaut `True`, désactiver IPv6 :
|
||||
|
||||
```powershell
|
||||
Disable-NetAdapterBinding -Name "NEXSIS_SERVEURS" -ComponentID ms_tcpip6
|
||||
```
|
||||
|
||||
### 3.5 Renommer le serveur
|
||||
|
||||
Dans `sconfig`, choisir l'option `2` et attribuer au serveur le nom défini dans le DCSR.
|
||||
|
||||
## 4. Installer les outils de l'hyperviseur
|
||||
|
||||
### 4.1 Nutanix
|
||||
|
||||
Exécuter le script suivant pour désinstaller VMware Tools :
|
||||
|
||||
```powershell
|
||||
C:\SYSTEL\Install\Scripts\1-Remove_VMware_Tools.ps1
|
||||
```
|
||||
|
||||
Le script supprime les composants VMware Tools (service, fichiers et entrées de registre). En cas d'erreur, contacter l'équipe infrastructure.
|
||||
|
||||
Dans Prism Central, faire un clic droit sur la VM, ouvrir **Guest Tools**, puis choisir **Set Up NGT**. Sur le serveur Windows Core, vérifier qu'un lecteur CD est monté :
|
||||
|
||||
```powershell
|
||||
Get-WmiObject Win32_CDROMDrive | Select-Object Drive, MediaLoaded
|
||||
```
|
||||
|
||||
Si le média est monté sur `D:`, ouvrir le répertoire d'installation et en vérifier le contenu :
|
||||
|
||||
```powershell
|
||||
cd D:\installer\windows
|
||||
ls
|
||||
```
|
||||
|
||||
Lancer l'installateur correspondant et suivre l'assistant. Si les options proposées diffèrent, vérifier les paramètres attendus auprès de l'équipe infrastructure.
|
||||
|
||||
## 5. Joindre le domaine Active Directory
|
||||
|
||||
1. Dans `sconfig`, choisir l'option `1` pour configurer l'appartenance au domaine.
|
||||
2. Une fois le serveur joint au domaine, ajouter le compte ou le groupe Active Directory prévu au groupe local des administrateurs.
|
||||
|
||||
Exemple pour le compte `SPOOLER` du domaine `CTAxx` (remplacer `xx` par le numéro du département) :
|
||||
|
||||
```powershell
|
||||
Add-LocalGroupMember -Group "Administrateurs" -Member "CTAxx\SPOOLER"
|
||||
```
|
||||
|
||||
## 6. Activer Windows
|
||||
|
||||
> Les modèles sont en édition Windows Server Standard. Pour une licence Datacenter, consulter l'annexe ci-dessous.
|
||||
|
||||
1. Lancer `sconfig` et choisir l'option `11`.
|
||||
2. Choisir l'option `3`, puis saisir la clé de produit.
|
||||
3. La clé est disponible sur le Cloud Systel, dans le répertoire correspondant au client : `\\cloud\Licences` ou `\\cloud\Clients`.
|
||||
4. Une fois la clé validée, choisir l'option `2` pour activer Windows.
|
||||
|
||||
## 7. Annexe : corriger une incompatibilité d'édition Windows
|
||||
|
||||
Cette procédure concerne le cas où la licence Windows Server Datacenter ne correspond pas à l'édition Standard installée.
|
||||
|
||||
### 7.1 Méthode avec DISM
|
||||
|
||||
Remplacer les `X` par la clé de licence client, généralement une clé MAK, puis exécuter :
|
||||
|
||||
```cmd
|
||||
DISM /online /Set-Edition:ServerDatacenter /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula
|
||||
```
|
||||
|
||||
Lorsque l'invite le demande, saisir `Y` pour redémarrer.
|
||||
|
||||
### 7.2 Méthode de dernier recours avec le registre et le programme d'installation
|
||||
|
||||
N'utiliser cette méthode que si la méthode DISM échoue et après validation par l'équipe infrastructure. Avant toute modification du registre, effectuer une sauvegarde et prévoir une procédure de retour arrière.
|
||||
|
||||
1. Ouvrir `Regedit.exe` et accéder à :
|
||||
|
||||
```text
|
||||
Ordinateur\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
|
||||
```
|
||||
|
||||
2. Modifier la valeur d'édition `Standard` en `Datacenter` conformément à la procédure validée.
|
||||
3. Monter l'ISO correspondant à la version de Windows Server et lancer `Setup.exe` en tant qu'administrateur.
|
||||
4. Suivre l'assistant, saisir la clé Datacenter, choisir **Datacenter expérience de bureau**, accepter le contrat de licence et sélectionner **Conserver**, puis **Suivant**.
|
||||
5. Lancer l'installation et attendre sa fin.
|
||||
@@ -0,0 +1,163 @@
|
||||
## Prérequis
|
||||
|
||||
- Disposer d'un NAS Synology.
|
||||
- Disposer d'une licence Veeam Backup & Replication au format `.lic`.
|
||||
- Importer le modèle `TEMPLATE_WIN22` dans l'environnement client en suivant la procédure **Exporter et importer une VM depuis la plateforme de Production**.
|
||||
- Nommer la nouvelle machine virtuelle `VEEAM`.
|
||||
|
||||
### Préparer le NAS Synology
|
||||
|
||||
Suivre la [procédure d'installation d'un serveur NAS Synology](https://tfs2k18.systel-sa.com/tfs/Systel/Etudes/_wiki/wikis/Etudes.wiki/1648/Installation-serveur-NAS-Synology).
|
||||
|
||||
### Créer le compte de service Veeam
|
||||
|
||||
Dans le Panneau de configuration du NAS, ouvrir **Utilisateur et groupe > Créer un utilisateur**. Générer un mot de passe sécurisé avec RDM, l'y enregistrer, puis suivre l'assistant. Conserver les options par défaut sauf indication contraire de la configuration validée.
|
||||
|
||||
### Créer le partage Veeam
|
||||
|
||||
Dans le Panneau de configuration, ouvrir **Dossier partagé > Créer un dossier partagé**. Créer le partage selon la configuration validée du NAS, puis accorder au compte de service Veeam les droits de lecture et d'écriture.
|
||||
|
||||
## Préparer le serveur Veeam
|
||||
|
||||
Suivre la procédure **Préparation d'un serveur Windows**. Pour des raisons de sécurité, la VM Veeam ne doit pas être jointe au domaine Active Directory; ignorer cette étape dans la procédure de préparation Windows.
|
||||
|
||||
## Installer Veeam Backup & Replication
|
||||
|
||||
Récupérer l'image ISO depuis le Cloud Systel ou le site Veeam et la copier dans `D:\Install\Logiciels\Logiciels_Tiers`.
|
||||
|
||||
Le fichier du Cloud Systel suit ce chemin :
|
||||
|
||||
```text
|
||||
\\cloud\Produits\Produits_tiers\Veeam\Veeam Data Platform Foundation (Backup & Replication 12)\VeeamBackupReplication_XX.X.X.iso
|
||||
```
|
||||
|
||||
Le téléchargement Veeam est disponible à l'adresse <https://www.veeam.com/fr/backup-replication-vcp-download.html>.
|
||||
|
||||
Monter l'ISO, lancer l'installateur et suivre les étapes suivantes :
|
||||
|
||||
1. Cliquer sur **Install**, puis sélectionner **Install Veeam Backup & Replication**.
|
||||
2. Accepter les conditions d'utilisation avec **I Accept**.
|
||||
3. Cliquer sur **Browse licence file**, sélectionner le fichier de licence client `.lic`, puis cliquer sur **Next**.
|
||||
4. Laisser l'installateur vérifier et installer les composants requis. Si un redémarrage est demandé, cliquer sur **Reboot**. Si l'installation ne reprend pas automatiquement, relancer l'exécutable depuis l'ISO.
|
||||
5. Cliquer sur **Customize Settings** pour consulter les paramètres avancés.
|
||||
6. Conserver les paramètres par défaut pour l'intégration au domaine, PostgreSQL et le répertoire d'installation, sauf nécessité validée de les modifier.
|
||||
7. Cliquer sur **Install** et attendre la fin de l'installation.
|
||||
|
||||
À la fin, ouvrir la console **Veeam Backup & Replication Console** sur la machine.
|
||||
|
||||
## Installer le plug-in Nutanix AHV
|
||||
|
||||
Le plug-in **Nutanix AHV Plug-In for Veeam Backup & Replication** est nécessaire pour sauvegarder les VM hébergées sur Nutanix. Il est inclus par défaut dans certaines versions récentes de Veeam.
|
||||
|
||||
Vérifier sa présence dans **Paramètres > Applications et fonctionnalités**. S'il est absent ou doit être mis à jour, suivre la procédure d'installation du plug-in adaptée à la version déployée.
|
||||
|
||||
## Configurer l'infrastructure de sauvegarde
|
||||
|
||||
Depuis la console Veeam, ouvrir **Backup Infrastructure**. Cette section permet de configurer les dépôts NAS, les serveurs sources et les proxys de sauvegarde.
|
||||
|
||||
### Ajouter le NAS comme dépôt de sauvegarde
|
||||
|
||||
1. Faire un clic droit sur **Backup Repositories**, puis choisir **Add Backup Repository**.
|
||||
2. Sélectionner **Network attached storage**, puis **SMB share**.
|
||||
3. Saisir le nom du NAS, le chemin du partage et les identifiants du compte de service Veeam créé sur le NAS.
|
||||
4. Conserver les options par défaut pour les étapes suivantes, sauf indication contraire de la configuration validée.
|
||||
5. Cliquer sur **Apply**. Si les vérifications sont toutes vertes, cliquer sur **Next**, puis **Finish**. Si une demande de confirmation apparaît, vérifier le contexte avant de cliquer sur **Yes**.
|
||||
|
||||
## Configurer une infrastructure VMware (ESXi/vCenter)
|
||||
|
||||
### Ajouter un serveur ESXi ou vCenter
|
||||
|
||||
1. Dans **Backup Infrastructure**, faire un clic droit sur **Managed Servers**, puis choisir **Add Server**.
|
||||
2. Sélectionner **Virtualization Platforms > VMware vSphere > vSphere**.
|
||||
3. Saisir le nom DNS du vCenter ou de l'hôte ESXi, puis cliquer sur **Next**.
|
||||
4. Ajouter un compte disposant des droits d'administration nécessaires, puis cliquer sur **Apply**.
|
||||
5. Si une demande de validation du certificat apparaît, vérifier le certificat et cliquer sur **Continue** s'il est attendu.
|
||||
6. Une fois la connexion établie, cliquer sur **Next**, puis **Finish**.
|
||||
|
||||
### Créer un proxy de sauvegarde VMware
|
||||
|
||||
#### Prérequis
|
||||
|
||||
Importer le modèle `[202x-xx-xx]_TEMPLATE_UBUNTU22` en suivant la procédure **Exporter et importer une VM depuis la plateforme de Production**, puis préparer le serveur avec la procédure **Préparation d'un serveur Linux**. Configurer la VM selon le DCI.
|
||||
|
||||
#### Ajouter le proxy
|
||||
|
||||
1. Dans **Backup Infrastructure**, faire un clic droit sur **Backup Proxies**, puis choisir **Add proxy...**.
|
||||
2. Sélectionner **VMware backup proxy**, puis **Linux**.
|
||||
3. Cliquer sur **Add New...**, saisir le nom ou l'adresse IP du serveur, puis cliquer sur **Next**.
|
||||
4. Choisir **Add > SSH**, saisir le compte `systel` sécurisé, cocher **Elevate account privileges automatically**, puis valider.
|
||||
5. Si une demande de confirmation apparaît, vérifier le contexte avant de cliquer sur **Yes**.
|
||||
6. Cliquer sur **Apply** pour installer les composants Veeam sur le serveur Linux.
|
||||
7. Attendre la fin de l'installation et terminer l'assistant avec **Next** et **Finish**. Installer les composants complémentaires s'ils sont proposés.
|
||||
|
||||
## Configurer une infrastructure Nutanix (AOS)
|
||||
|
||||
### Créer un compte Veeam sur chaque cluster
|
||||
|
||||
Pour chaque cluster Nutanix, créer un compte Veeam avec les droits nécessaires :
|
||||
|
||||
1. Dans Prism Element, ouvrir **Settings > Local User Management**.
|
||||
2. Cliquer sur **+ New User**.
|
||||
3. Renseigner les champs demandés, cocher **Cluster Admin** et **Backup Admin**, puis cliquer sur **Save**.
|
||||
4. Générer et enregistrer le mot de passe du compte dans RDM.
|
||||
|
||||
### Ajouter un cluster Nutanix comme Managed Server
|
||||
|
||||
1. Dans **Backup Infrastructure**, faire un clic droit sur **Managed Servers**, puis choisir **Add Server**.
|
||||
2. Sélectionner **Virtualization Platforms > Nutanix AHV**.
|
||||
3. Saisir l'adresse IP du cluster Nutanix, puis cliquer sur **Next**.
|
||||
4. Renseigner les identifiants du compte Veeam créé sur ce cluster.
|
||||
5. Si un avertissement apparaît, vérifier son contenu avant de cliquer sur **Continue**.
|
||||
6. Saisir l'adresse IP de la VM d'assistance, généralement l'adresse suivant celle du proxy Veeam, puis poursuivre l'assistant.
|
||||
|
||||
> **À confirmer :** l'étape de configuration de la VM d'assistance est indiquée comme étant en cours de revue avec le support Veeam. Valider cette procédure avant son exécution.
|
||||
|
||||
7. Cliquer sur **Next**, puis **Finish**.
|
||||
8. Lorsque Veeam propose de créer un **Nutanix AHV Backup Proxy**, cliquer sur **Yes** pour lancer sa création.
|
||||
|
||||
### Créer un proxy de sauvegarde Nutanix
|
||||
|
||||
1. Conserver **Deploy a new proxy**, puis cliquer sur **Next**.
|
||||
2. Avec **Choose**, sélectionner le cluster et le conteneur de stockage.
|
||||
3. Dans **Advanced**, définir **Max concurrent tasks** et les ressources CPU/RAM conformément au DCI.
|
||||
|
||||
Pour Veeam Backup for Nutanix AHV 7, le dimensionnement indiqué est :
|
||||
|
||||
- `2 vCPU` et `2 Go` de RAM pour la gestion du proxy;
|
||||
- `1 vCPU` et `1 Go` de RAM par tâche de sauvegarde simultanée.
|
||||
|
||||
Ainsi, pour quatre tâches simultanées, prévoir `6 vCPU` et `6 Go` de RAM. Vérifier que ces valeurs correspondent à la version du plug-in installée.
|
||||
|
||||
4. Valider les ressources avec **OK**, puis cliquer sur **Next**.
|
||||
5. Créer des identifiants dédiés à la VM proxy, les enregistrer dans RDM et les saisir dans l'assistant.
|
||||
6. Configurer le réseau selon le DCI. La liste **Network** reprend les VLAN déclarés dans **Prism Element > Settings > Network > Network Configuration**.
|
||||
7. Dans **Networks**, renseigner les DNS; utiliser **Obtain automatically** si cette option correspond à la configuration prévue.
|
||||
8. Conserver les paramètres par défaut pour les étapes suivantes et cliquer sur **Apply**.
|
||||
9. Attendre la création de la VM `VEEAM-PROXY`, puis terminer avec **Next** et **Finish**.
|
||||
|
||||
Le proxy **Nutanix AHV Backup Proxy** dispose de sa propre interface Web.
|
||||
|
||||
### Ajouter un Gateway Server pour le dépôt NAS
|
||||
|
||||
Le proxy Nutanix utilise un worker pour traiter les sauvegardes à la source. Le transfert des sauvegardes vers le NAS nécessite le service **Veeam Data Mover**. Ce service étant présent par défaut sur les proxys VMware mais pas sur les proxys Nutanix, déployer une VM Windows dédiée près du NAS.
|
||||
|
||||
Préparer cette VM selon la procédure **Préparation d'un serveur Windows**. Comme pour le serveur Veeam, ne pas la joindre au domaine Active Directory; ignorer cette étape dans la procédure Windows.
|
||||
|
||||
#### Ajouter la VM comme serveur géré
|
||||
|
||||
Ajouter le serveur Windows dans **Managed Servers**. Veeam y installera les composants nécessaires.
|
||||
|
||||
#### Déclarer le serveur comme Gateway Server
|
||||
|
||||
Dans **Backup Infrastructure**, faire un clic droit sur le dépôt NAS concerné et choisir **Properties**. Dans **Share**, définir le **Gateway Server** sur le serveur Windows ajouté, valider puis attendre l'application des paramètres.
|
||||
|
||||
## Créer les tâches de sauvegarde Veeam
|
||||
|
||||
Configurer le nombre de tâches et leurs paramètres (sauvegardes complètes ou incrémentielles, calendrier et durée de rétention) conformément au plan de sauvegarde du DCI.
|
||||
|
||||
Créer les tâches requises pour les VM hébergées sur Nutanix et sur VMware. Les paramètres détaillés des tâches n'étant pas transcrits dans la procédure source, les reprendre du DCI et du plan de sauvegarde validé.
|
||||
|
||||
## Vérifier la licence
|
||||
|
||||
Dans le menu principal, ouvrir **License** pour consulter l'état et la date d'expiration de la licence, ainsi que le nombre de VM utilisées et disponibles.
|
||||
|
||||
Reference in New Issue
Block a user