- 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.
---
## Installation & Configuration
## Mission I4 – Sécurisation et sauvegarde de la base de données
### Installation des composants principaux
### Objectifs de la mission
-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`)
-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`.
### Gestion des agents Zabbix
### Sécurisation de l'accès SSH
-Remplacement du `zabbix-agent` classique par `zabbix-agent2` permet une meilleure robustesse,et l’intégration professionnelle. pour corriger les problèmes liés au PID et aux permissions, il est 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
-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.
### Supervision réseau et services
### Sauvegarde automatisée de MariaDB sur `ap31-test`
-Vérification des accès SSH et HTTP via des vérifications simples dans Zabbix (Simple checks et HTTP checks)
-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`
## Supervision centralisée des logs avec journald-remote
- 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.
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
| 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
- 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
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.