Projet Centreon — Mise à disposition d'un service Solutech

Technicien : Lucas Dufosse — lot L1 « socle et installation »
Parcours : BTS SIO SISR 2e année — P2 « Projet de mise à disposition d'un service Solutech »
Durée : 20 h sur 4 séances (12/10, 16/10, 30/10, soutenance le 06/11/2026)
Commanditaire (fictif) : Léo Martin, responsable SI de Solutech (rôle tenu par le formateur)
Environnement : Proxmox, Debian 12, Centreon Open Source 25.10, MariaDB 10.11, Apache / PHP 8.2

Chez Solutech, les pannes (serveur arrêté, service tombé, disque plein) sont découvertes par les utilisateurs. Le service informatique n'a ni vue d'ensemble, ni alerte, ni historique. La demande de Léo Martin : mettre à disposition un outil de supervision qui signale les incidents avant qu'ils ne gênent les utilisateurs.

Nous avons mené ce projet à trois, en mode projet avec un dépôt GitLab commun (projet-service-g2). Cette page raconte le projet depuis ma place : mon lot, le socle et l'installation de Centreon, en est le centre.

Le découpage en lots (WBS) a été saisi en tickets GitLab et suivi dans un tableau Kanban. Mon lot fournit le serveur sur lequel s'appuient la supervision, les droits et la sauvegarde (L2) ainsi que l'API (L3).

Nous avons d'abord écarté Uptime Kuma, qui ne gère pas de vrais rôles ni de listes de contrôle d'accès. Nous avons ensuite comparé Centreon Open Source 25.10 et Checkmk Community en deux temps : critères éliminatoires, puis critères pondérés.

Zabbix figurant parmi les services déjà étudiés en cours, le formateur nous a accordé une dérogation pour un autre outil de supervision. Il nous a aussi demandé une installation native, sans Docker.

Détail de la comparaison : note de cadrage du dépôt du groupe projet-service-g2.

Ce que j'ai fait. J'ai créé la VM g2-centreon (ID 109) sur Proxmox, dans le pool projet-g2 :

• 4 vCPU, 4 Go de RAM, disque de 30 Go, bridge SwSolutech, IP fixe 10.2.2.30 (plage du groupe .30 à .49) ;
• installation depuis l'ISO Debian 12 : le modèle fourni était en Debian 13, que Centreon 25.10 ne prend pas en charge (vérifié sur la page Compatibilité officielle) ;
• partitionnement LVM (exigé par Centreon), réduit et justifié : racine 13 Go, volumes dédiés mysql 8 Go, centreon 3 Go, broker et engine 512 Mo, backup 2 Go, log 2 Go ; montages nodev/nosuid, et noexec sur /var/log et backup ;
• instantanés à chaque étape : s00-debian-propre, s01a-avant-centreon, s01b-centreon-installe.

J'ai ensuite durci le système avant d'y installer quoi que ce soit :

• SSH : connexion root interdite, MaxAuthTries 3, AllowUsers nominatif, bannière légale ;
• pare-feu nftables en politique drop : seuls 22, 80, 443 et 162/udp sont ouverts, 3306 ne l'est jamais ;
• fail2ban, avec un filtre corrigé (sous Debian l'unité s'appelle ssh.service) et 10.2.2.0/24 ignoré, car tout le trafic arrive NATé depuis 10.2.2.2 ;
• mises à jour de sécurité automatiques, paramètres sysctl réseau, umask 027, auditd, journald persistant et plafonné ;
• comptes nominatifs : admin-g2 et axel (sudo), aurelien sans sudo avec un dossier de travail /opt/g2/scripts ; j'ai vérifié qu'il ne peut pas écrire dans /etc/centreon.

Résultat. Un serveur Debian 12 minimal, durci, joignable uniquement sur les ports utiles, avec un point de retour propre avant l'installation de Centreon.

Ce que j'ai fait. J'ai installé Centreon 25.10.18 (Engine et Broker 25.10.13) depuis les dépôts officiels, avec une base MariaDB 10.11 locale qui n'écoute que sur 127.0.0.1, et PHP 8.2. L'installation s'est faite avec umask 022, le temps de l'installation des paquets.

J'ai déroulé l'assistant web jusqu'au bout, désactivé la télémétrie CEIP, puis créé les comptes Centreon : admin, axel (administrateur) et aurelien (non administrateur).

Résultat. Centreon opérationnel, configuration exportée sans erreur, base de données non exposée sur le réseau, et un instantané de l'état « Centreon installé ».

Ce que j'ai fait. J'ai mis l'interface Centreon en HTTPS sur Apache :

• certificat auto-signé RSA 2048 avec subjectAltName IP:10.2.2.30 (pas de nom DNS disponible) ;
• redirection permanente (301) du port 80 vers le 443 ;
• en-tête HSTS ; TLS 1.0 et 1.1 refusés.

Chaque point est prouvé par une commande curl, consignée dans exploitation/preuves-socle.md du dépôt du groupe.

Résultat. L'interface n'est plus accessible en clair. Le navigateur signale un certificat « non sécurisé » parce qu'il est auto-signé : c'est attendu dans le labo, la connexion reste chiffrée.

Sur ce socle, Axel a configuré les listes de contrôle d'accès Centreon (lot L2) : Aurélien peut consulter la supervision et les rapports, mais pas la configuration. Ce n'est pas mon travail ; je le cite parce qu'il repose sur les comptes que j'ai créés et qu'il complète le moindre privilège mis en place au niveau du système.

• Problème : après l'installation, le collecteur Central apparaissait arrêté dans Centreon.
• Diagnostic : systemctl status centengine montrait le service en échec. J'avais redémarré centengine avant que l'assistant génère sa configuration, puis exporté en mode Reload, qui ne relance pas un service en échec.
• Solution : contrôle de la configuration avec centengine -v (0 avertissement, 0 erreur), puis redémarrage du service.
• Vérification : le collecteur passe à « Is running ? YES ».

• Problème : en contrôlant les droits, j'ai trouvé que les fichiers /etc/centreon-broker/*.json, qui contiennent les identifiants MariaDB, étaient en 664, donc lisibles par n'importe quel compte du serveur.
• Diagnostic : avec ces droits, un compte non administrateur comme aurelien pouvait lire le mot de passe de la base.
• Solution : chmod o-r sur ces fichiers (passage en 660).
• Vérification : refus de lecture pour aurelien, et droits conservés après un nouvel export de configuration depuis Centreon.

• Problème : mon premier essai de partitionnement n'utilisait pas LVM, alors que Centreon l'exige.
• Diagnostic : en recommençant avec LVM, l'installeur Debian demande la quantité du groupe de volumes à utiliser ; saisie sans unité, « 14 » est compris comme 14 Mo et non 14 Go.
• Solution : nouveau partitionnement LVM, en saisissant la taille avec son unité (« 14 GB »).
• Vérification : volumes logiques créés aux tailles prévues.

• Problème : le groupe a alloué 62 Go de disque pour un quota de 50 Go.
• Diagnostic : la VM cible a été clonée depuis un modèle de 32 Go, et Proxmox ne sait pas réduire un disque.
• Solution : dépassement présenté au formateur, qui l'a accepté ; il est documenté au § 10 de la note de cadrage.
• Leçon : dimensionner les disques au plus juste dès la création, car on ne peut que les agrandir.

Le dépassement sur L1.2 vient du collecteur arrêté et de la correction des droits des fichiers broker. L1.3 a été plus rapide que prévu, ce qui a compensé une grande partie de l'écart.

• Debian 12 plutôt que 13 : c'est la version prise en charge par Centreon 25.10.
• Installation native plutôt que Docker : demandée par le formateur.
• LVM réduit au lieu des quelque 200 Go de la documentation : moins de 10 hôtes supervisés et une rétention courte.
• MariaDB non exposée sur le réseau : elle n'écoute qu'en local et le port 3306 reste fermé.
• Certificat émis pour l'IP, faute de nom DNS dans le labo.
• Moindre privilège : un compte nominatif par personne, aucun compte partagé.

• Contrôler les droits des fichiers sensibles juste après l'installation, et pas après coup.
• Ne pas toucher aux services avant la fin de l'assistant de configuration.
• Dimensionner les disques au plus juste dès la création des VM.

• 4.1 Analyser les objectifs et les modalités d'organisation d'un projet : cadrage du besoin et choix comparé Centreon / Checkmk.
• 4.2 Planifier les activités : WBS et Kanban GitLab.
• 5.2 Déployer un service : déploiement natif de Centreon 25.10 sur Debian 12 durci, en HTTPS.

À confirmer après la recette du 30/10/2026 : 5.1 (tests d'intégration et d'acceptation), 5.3 (accompagnement des utilisateurs) et 2.2 (traitement des demandes réseau et système).

• Sauvegarde et restauration de Centreon (lot d'Axel) — à compléter
• Scripts d'API et automatisation (lot d'Aurélien) — à compléter
• Cahier de tests — à compléter
• Documentation utilisateur — à compléter
• Recette croisée et tickets du 30/10/2026 — à compléter
• Soutenance du 06/11/2026 — à compléter
• Bilan prévu / réel du projet complet — à compléter