151 lines
6.8 KiB
Markdown
151 lines
6.8 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.
|
||
|
||
---
|
||
|
||
## Mission I4 – Sécurisation et sauvegarde de la base de données
|
||
|
||
### Objectifs de la mission
|
||
|
||
- Sécuriser l'accès SSH aux machines via authentification par clé publique uniquement.
|
||
- Mettre en place une **sauvegarde automatique, compressée et quotidienne** de la base MariaDB sur `ap31-test`.
|
||
- Conserver un **historique de 7 jours** de ces sauvegardes.
|
||
- Fournir un script permettant de **restaurer la dernière sauvegarde** sur `ap31-prod`.
|
||
|
||
### Sécurisation de l'accès SSH
|
||
|
||
- Utilisation exclusive de l’**authentification par clé publique** :
|
||
- Ajout des clés des administrateurs dans le fichier `~/.ssh/authorized_keys`.
|
||
- Désactivation de l’authentification par mot de passe dans `/etc/ssh/sshd_config` (`PasswordAuthentication no`).
|
||
- Configuration du fichier `~/.ssh/config` pour permettre la connexion via **nom de domaine personnalisé**, avec des alias pour simplifier l'accès aux serveurs (ex. : `ssh ap31-prod`).
|
||
- Redémarrage du service SSH pour prise en compte des modifications.
|
||
|
||
### Sauvegarde automatisée de MariaDB sur `ap31-test`
|
||
|
||
- Mise en place d’un **script bash exécuté quotidiennement** (via cron) pour :
|
||
- Effectuer un **dump** de la base `sdis29` avec l’utilisateur `adminBDsdis`.
|
||
- Compresser la sauvegarde (`gzip`).
|
||
- La stocker dans `/var/backups/mariadb` avec un nom de fichier horodaté.
|
||
- Supprimer les sauvegardes plus anciennes que 7 jours.
|
||
|
||
### Restauration de la dernière sauvegarde sur `ap31-prod`
|
||
|
||
- Un script permet de :
|
||
- **Décompresser** la dernière sauvegarde disponible.
|
||
- **Restaurer automatiquement** le fichier SQL dans la base `sdis29` sur `ap31-prod` à l’aide des identifiants fournis.
|
||
|
||
|