119 lines
5.1 KiB
Markdown
119 lines
5.1 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 fonctionnement des services et des machines
|
||
|
||
---
|
||
|
||
# Mission I2 - Supervision des serveurs ap31-prod et ap31-test
|
||
|
||
## Objectifs de la mission
|
||
|
||
- Superviser les serveurs `ap31-prod` et `ap31-test` avec Zabbix installé sur `ap31-mon`.
|
||
- Vérifier la connectivité (ping), accès SSH, et service web pour `ap31-test`.
|
||
- Utiliser les agents `zabbix_agent2` et associer les templates `linux-server`.
|
||
- Envoyer des notifications en cas d’incident (non réalisé via Zabbix mais avec Uptime Kuma).
|
||
|
||
## Installation et configuration
|
||
|
||
- Installation via `apt` des paquets Zabbix serveur, frontend, agent2, et MariaDB.
|
||
- Création d’une base MariaDB dédiée à Zabbix avec utilisateur spécifique et import du schéma initial.
|
||
- Configuration de l’interface web Zabbix avec connexion à la base MariaDB locale.
|
||
- Activation automatique et vérification des services Zabbix.
|
||
|
||
## Déploiement et supervision
|
||
|
||
- Utilisation du wizard agent avec clés PSK pour déployer les agents sur `ap31-prod` et `ap31-test`.
|
||
- Association des templates `linux-server` aux agents.
|
||
- Difficultés rencontrées avec les templates ICMP (ping) et Apache2 web, non fonctionnels.
|
||
- Les templates SSH n’ont pas été utilisés faute d’accès SSH disponible.
|
||
- La gestion des alertes n’a pas été réalisée via Zabbix mais déléguée à Uptime Kuma.
|
||
|
||
---
|
||
|
||
# Mission I3 - Mise en place d'une infrastructure de gestion centralisée des logs
|
||
|
||
## Objectifs de la mission
|
||
|
||
- Centraliser les logs de plusieurs serveurs (`ap31-prod`, `ap31-test`, `gwsiox`) sur une machine dédiée (`ap31-mon`) via `systemd-journal-remote`.
|
||
- Mettre en place une politique de rotation et de rétention des logs syslog, avec une rotation hebdomadaire sur 4 semaines.
|
||
- Garantir la cohérence temporelle entre toutes les machines impliquées grâce à une synchronisation horaire fiable.
|
||
|
||
## Mise en œuvre
|
||
|
||
### Sur la machine centrale (réceptrice `ap31-mon`)
|
||
|
||
- Activation et configuration du service `systemd-journal-remote` pour recevoir les logs via HTTP.
|
||
- Création et gestion du répertoire `/var/log/journal/remote` avec les permissions appropriées.
|
||
- Rechargement des services systemd et vérification de l’écoute sur le port dédié.
|
||
|
||
### Sur les serveurs sources (`ap31-prod` et `ap31-test`)
|
||
|
||
- Installation du paquet `systemd-journal-remote` pour permettre l’envoi des logs.
|
||
- Configuration dynamique de l’adresse du serveur de réception dans `/etc/systemd/journal-upload.conf` via un script bash.
|
||
- Activation et démarrage du service `systemd-journal-upload` pour transmettre les journaux système vers `ap31-mon`.
|
||
|
||
### Gestion des logs et synchronisation
|
||
|
||
- Mise en place d’une rotation des logs syslog, configurée pour une périodicité hebdomadaire avec une conservation de 4 semaines.
|
||
- Utilisation de `timedatectl` pour définir le fuseau horaire et garantir la synchronisation temporelle sur toutes les machines.
|
||
|
||
---
|
||
|