153 lines
7.3 KiB
Markdown
153 lines
7.3 KiB
Markdown
# Projet AP3 2026 - SDIS29
|
||
## Partie Systèmes et Réseaux
|
||
|
||
---
|
||
|
||
## Contexte du Projet
|
||
|
||
Le projet SDIS29 vise à moderniser le système d’information du Service Départemental d’Incendie et de Secours du Finistère afin d’optimiser la gestion des alertes et la mobilisation des pompiers volontaires pour réduire les temps d’intervention.
|
||
|
||
La partie systèmes et réseaux consiste à déployer une infrastructure virtualisée sur les serveurs Proxmox VE 9, hébergeant les services nécessaires au développement, test, et supervision de l’application.
|
||
|
||
---
|
||
|
||
## Mission I1 — Mise en œuvre des serveurs ap31-prod et ap31-test
|
||
|
||
### Objectifs
|
||
|
||
- Déployer deux serveurs virtuels sur le serveur Proxmox `pxlab1` :
|
||
- `ap31-prod` pour la production
|
||
- `ap31-test` pour les tests
|
||
|
||
- Sur chaque serveur, installer et faire fonctionner via Docker :
|
||
- Serveur d’application Payara (version 6.2025.9, JDK 17)
|
||
- Gestionnaire de base de données MariaDB
|
||
|
||
- Sur `ap31-test`, installer l’outil PhpMyAdmin via Docker.
|
||
|
||
---
|
||
|
||
### Étapes réalisées
|
||
|
||
#### 1. Création des Templates Debian 12
|
||
|
||
- Utilisation du script `mktmpl` situé dans `/root/tools/` sur les serveurs `pxlab1`, `pxlab2` et `pxlab3`.
|
||
- Création des templates numérotés 2601, 2602, 2603 pour standardiser les VM Debian 12.
|
||
|
||
#### 2. Déploiement des VM
|
||
|
||
- Clonage des templates Debian 12 pour créer les machines virtuelles `ap31-prod` et `ap31-test`.
|
||
- Paramétrage cloud init des VMs avec leur adresse IP et le masque de sous réseau (172.16.0.10x/24), gateway
|
||
- Ajout du QEMU agent sur les machines permettant la communication entre la machine virtuelle et le serveur de virtualisation Proxmox.
|
||
- Mise en place d’accès SSH par clé publique depuis au moins deux postes de travail.
|
||
- Configuration initiale :
|
||
- Proxy configuré dans `/etc/apt/apt.conf` via `wget depl/sio/api/apt.conf`.
|
||
- Fuseau horaire correctement paramétré.
|
||
|
||
#### 3. Installation de Docker
|
||
|
||
- Installation de Docker sur les VM `ap31-prod` et `ap31-test`.
|
||
|
||
#### 4. Déploiement des services Docker
|
||
|
||
- Création et utilisation de fichiers `docker-compose.yml` pour déployer :
|
||
- Payara avec JDK 17
|
||
- MariaDB
|
||
- Sur `ap31-test` : déploiement de PhpMyAdmin.
|
||
|
||
#### 5. Tests
|
||
|
||
- Utilisation de Goss pour vérifier le bon focntionnement des services et des machines
|
||
|
||
|
||
|
||
## Mission I2 : Supervision avec Zabbix
|
||
|
||
## Objectif
|
||
|
||
Mettre en place une supervision centralisée des serveurs `ap3x-prod` et `ap3x-test` depuis la machine `ap3x-mon` à l'aide de Zabbix.
|
||
L’objectif est d’assurer une surveillance complète via plusieurs protocoles et services :
|
||
|
||
- Vérification de la disponibilité réseau (ping)
|
||
- Surveillance via **Zabbix Agent2** avec application de templates Linux standards
|
||
- Contrôle de l’accès SSH sur les serveurs
|
||
- Supervision de l’accès HTTP pour le serveur `ap3x-test`
|
||
- Mise en place d’un système d’alerte pour notifier automatiquement en cas de problème
|
||
- Extension de la supervision à d’autres équipements réseaux critiques (passerelle `gwsiox`, serveurs `px`, `pxlabx`, `gwlab`)
|
||
|
||
---
|
||
|
||
## ⚙️ Environnement Technique
|
||
|
||
| Élément | Description |
|
||
|---------------------|-----------------------------------|
|
||
| Système d’exploitation | Debian.12 Bookworm |
|
||
| Zabbix | Version 7.4. |
|
||
| Base de données | MariaDB 10.11 |
|
||
| Serveur Web | Apache2 + PHP 8.3 |
|
||
| Ports utilisés | 10050 (Zabbix agent), 10051 (Zabbix serveur), 3306 (journald-remote) |
|
||
|
||
---
|
||
|
||
## Installation & Configuration
|
||
|
||
### Installation des composants principaux
|
||
|
||
- Installation des paquets Zabbix serveur, frontend, agent2 et MariaDB via apt
|
||
- Configuration d’une base MariaDB dédiée à Zabbix avec création d’un utilisateur spécifique et import du schéma initial
|
||
- Mise en place de l’interface web Zabbix avec paramètres de connexion vers MariaDB (host `localhost`, port 3306 par défaut)
|
||
- Configuration des services Zabbix pour démarrer automatiquement et vérification de leur état (`systemctl status`)
|
||
|
||
### Gestion des agents Zabbix
|
||
|
||
- Remplacement du `zabbix-agent` classique par `zabbix-agent2` offre une architecture redondante et collaborative permettant une meilleure robustesse, adaptabilité et prise de décision face à des environnements complexes, contrairement à un agent simple limité et isolé. Cette modularité facilite aussi la scalabilité et l’intégration professionnelle. pour corriger les problèmes liés au PID et aux permissions, assurant un fonctionnement aussi plus récent
|
||
- Configuration des agents sur `ap3x-prod` et `ap3x-test` avec le template Linux standard afin d’avoir une collecte précise et homogène des métriques
|
||
|
||
### Supervision réseau et services
|
||
|
||
- Vérification des accès SSH et HTTP via des vérifications simples dans Zabbix (Simple checks et HTTP checks)
|
||
|
||
---
|
||
|
||
## Supervision centralisée des logs avec journald-remote
|
||
|
||
Pour aller au-delà de la simple supervision système, un serveur de logs centralisé a été mis en place sur `ap3x-mon` :
|
||
|
||
- Installation et configuration du service `systemd-journal-remote` pour recevoir les logs système des serveurs supervisés
|
||
- Script automatisé (`journald-rcv.sh`) pour configurer le serveur receveur avec les bons droits et paramètres (écoute HTTP sur le port 3306)
|
||
- Script client (`journald-snd.sh`) sur chaque serveur supervisé permettant d’envoyer leurs journaux via `systemd-journal-upload` vers le serveur central
|
||
- Cette centralisation facilite la collecte, l’analyse et la corrélation des événements pour une meilleure détection des incidents
|
||
|
||
---
|
||
|
||
## Problèmes rencontrés et solutions apportées
|
||
|
||
| Problème | Analyse | Solution appliquée |
|
||
|---------------------------------|-----------------------------------------|---------------------------------------------|
|
||
| Service `zabbix-agent` ne démarre pas | Problèmes liés au fichier PID, conflits avec agent2 | Migration vers `zabbix-agent2`, nettoyage des sockets, correction des droits |
|
||
| Connexion à MariaDB échoue | Mauvais mot de passe, base non initialisée | Réinitialisation du mot de passe, création manuelle de la base et import du schéma |
|
||
| Centralisation des logs non fonctionnelle | Mauvaise configuration ou absence de service `journald-remote` | Installation et configuration via scripts automatisés, activation du service socket |
|
||
|
||
---
|
||
|
||
## Résultats obtenus
|
||
|
||
- Interface Zabbix opérationnelle et accessible via navigateur web
|
||
- Serveur Zabbix et agents en état actif et fonctionnel
|
||
- Collecte fiable des métriques systèmes et réseau sur les serveurs supervisés
|
||
- Supervision des accès SSH et HTTP fonctionnelle
|
||
- Mise en place d’une infrastructure de logs centralisée opérationnelle avec réception régulière des journaux sur `ap3x-mon`
|
||
|
||
---
|
||
|
||
## Étapes suivantes
|
||
|
||
- Déploiement de `zabbix-agent2` et activation SNMP sur tous les serveurs ciblés
|
||
- Configuration de scénarios HTTP et vérifications spécifiques à `ap3x-test`
|
||
- Mise en place des alertes personnalisées (email, webhook, autres moyens)
|
||
- Ajout des équipements réseau supplémentaires à la supervision (passerelle, serveurs px, gwlab)
|
||
- Gestion des dépendances entre hôtes et services dans Zabbix pour éviter les alertes redondantes
|
||
|
||
---
|
||
|