🌐 Aussi en: English · Deutsch · Español
L’heure des aveux. Il y a quelque temps, j’ai découvert que fail2ban était mort sur mon serveur depuis deux jours, et je n’en avais aucune idée. Un fichier de configuration pointait vers un chemin de log qui n’existait plus, fail2ban refusait de démarrer, systemd haussait les épaules, et le tout restait juste… là. Sans bannir personne. En silence. 🙈 Le plus effrayant, ce n’est pas qu’un service soit mort : les services meurent. Le plus effrayant, c’est que rien ne m’a prévenu. Une mesure de sécurité peut tomber en laissant tout ouvert, et vous ne le saurez jamais avant d’aller vérifier. J’ai donc fait la chose raisonnable : ajouter un chien de garde dont le seul travail est de remarquer quand quelque chose cloche et de me crier dessus.🤔 Pourquoi Monit (et pas un script fait maison)
Mon premier réflexe a été d’écrire un petit script bash lancé par cron. Puis je me suis souvenu : c’est un problème résolu, et réinventer la supervision, c’est le meilleur moyen de finir avec un chien de garde qui tombe lui-même en silence. Il existe des outils éprouvés : Prometheus + Alertmanager (génial si vous vivez déjà dans cet univers), Icinga/Zabbix (excellents, mais disproportionnés pour une machine de loisir) et Monit, un minuscule démon spécialisé qui fait exactement une chose, et bien : surveiller services et ressources, et alerter (ou redémarrer automatiquement) quand ils se comportent mal. Pour un blog de niveau homelab, Monit l’a emporté pour une raison avant tout : il ne se contente pas d’alerter, il sait s’auto-réparer. Si fail2ban meurt, Monit le redémarre et m’envoie un e-mail. La panne de deux jours aurait été un hoquet de deux minutes, avec un avertissement en prime.📦 Prérequis & installation
- AlmaLinux 9 avec EPEL activé (c’est là que vit Monit) :
dnf install monit, et vous obtenez Monit 6.0. - Un relais de messagerie fonctionnel. J’avais déjà
msmtpconfiguré vers mon fournisseur pour les alertes rkhunter/ClamAV, Monit a donc pu réutiliser les mêmes identifiants. - Root, parce qu’il vérifie les services système, le pare-feu et le disque.
/etc/monitrc principal (réglages du
démon + relais mail) et un fichier de vérifications dans /etc/monit.d/.⚙️ Ce qu’il vérifie vraiment
La philosophie : silencieux tant que tout va bien. Monit n’envoie d’e-mail que lors d’un changement d’état : quelque chose de sain commence à échouer, ou quelque chose en échec se rétablit. Une boîte de réception calme signifie une machine en bonne santé, donc un mail de Monit n’est jamais du bruit.- 🥷 fail2ban, l’invité d’honneur. Redémarrage automatique via systemd ; s’il refuse de rester debout, Monit arrête de faire le yo-yo et envoie à la place une alerte « j’abandonne ». La panne exacte à l’origine de tout ceci serait désormais détectée.
- 🔌 sshd, k3s, node_exporter, Prometheus, Grafana : alerte si l’unité systemd n’est pas active.
- 🧱 Pare-feu : pas seulement « l’unité tourne-t-elle ? », mais « la chaîne input de nftables est-elle réellement en default-drop ? ». Un pare-feu chargé mais vidé est pire qu’inutile, alors je vérifie la réalité.
- 📦 Pods K3s : tout ce qui est bloqué en CrashLoopBackOff / ImagePullBackOff / OOMKilled / Error.
- 💽 Disque, charge, mémoire : les ressources ennuyeuses qui tuent les serveurs en silence à 3 h du matin.
check process fail2ban with pidfile /run/fail2ban/fail2ban.pid
start program = "/usr/bin/systemctl start fail2ban"
if does not exist then restart
if 3 restarts within 5 cycles then timeout
check program firewall with path "/usr/local/sbin/monit-check-firewall.sh"
if status != 0 then alert📧 Le piège du mail (une bonne heure de ma vie)
Voici la partie qui va vous faire gagner du temps. Ma configurationmsmtp fonctionnelle utilisait STARTTLS sur le port 587. Tout naturellement, j’ai configuré Monit de la même
façon. Monit a aussitôt échoué avec :Mail: Authentication failed -- no supported authentication methods foundusing
ssl signifie SSL implicite, dont le port standard est le 465,
pas le 587. Sur le 587, Monit parlait en clair, le serveur ne proposait aucun AUTH avant
STARTTLS (qui n’a jamais eu lieu), et Monit en a conclu qu’il n’y avait « aucune méthode
d’authentification prise en charge ». 🤦 Pour prouver que le relais lui-même allait bien (et ne pas courir après un fantôme), j’ai testé
les identifiants directement avec quelques lignes de Python smtplib :
la connexion a réussi proprement sur les deux ports et le serveur annonçait AUTH PLAIN
LOGIN. Donc : relais bon, configuration Monit fausse. La correction tenait en un mot et un
nombre :set mailserver smtp.example.com port 465
username "..." password "..."
using ssl🧪 Comment je l’ai testé (honnêtement)
Un chien de garde que vous n’avez jamais entendu aboyer n’est qu’une décoration. Alors je l’ai fait aboyer. J’ai arrêté un service sans danger et non critique (node_exporter), forcé une
vérification immédiate avec monit validate au lieu d’attendre le
cycle suivant, et j’ai observé. Puis j’ai relancé le service pour confirmer le
chemin de rétablissement. Voici ce qui est réellement arrivé dans ma boîte de réception : une
panne, un rétablissement et (lors d’un second passage) une autre panne :Monit on www.apt-upgrade.me reported:
Status failed: svc_node_exporter
at Tue, 28 Jul 2026 08:33:52
Action: alert
status failed (1) -- systemd service 'node_exporter' is inactive (expected: active)
-- Monit watchdogMonit on www.apt-upgrade.me reported:
Status succeeded: svc_node_exporter
at Tue, 28 Jul 2026 08:35:53
Action: alert
status succeeded (0) -- no output
-- Monit watchdogMonit on www.apt-upgrade.me reported:
Status failed: svc_node_exporter
at Tue, 28 Jul 2026 08:37:04
Action: alert
status failed (1) -- systemd service 'node_exporter' is inactive (expected: active)
-- Monit watchdog
