Tester un agent Zabbix sur des VM jetables : 10 pannes silencieuses trouvées pour quelques centimes

Un script d'installation d'agent Zabbix qui affiche « Installation terminée avec succès » ne prouve pas grand-chose. L'agent peut tourner, se connecter au serveur, et remonter des valeurs fausses ou rien du tout sur une partie des contrôles, sans le moindre message d'erreur.

C'est ce que nous avons constaté en testant le script d'installation de l'agent Logiserv sur des machines virtuelles neuves. Voici la méthode, ce qu'elle a coûté, et les dix problèmes trouvés. La plupart concernent n'importe quelle installation Zabbix, avec ou sans Logiserv.

La méthode : des VM qu'on supprime au lieu de les arrêter

Pour tester une première installation, il faut une machine vierge à chaque fois. Une VM réutilisée garde l'agent, sa configuration et ses droits : on teste une mise à jour, pas une installation. D'où trois règles :

• Supprimer plutôt qu'arrêter. Une instance arrêtée ne coûte plus de calcul, mais son disque reste facturé. Et une VM supprimée repart propre.
• Auto-destruction. Chaque VM est lancée avec shutdown -h +120 dans ses données utilisateur et le comportement d'arrêt réglé sur Terminate : oubliée, elle disparaît d'elle-même au bout de deux heures.
• Aucun port ouvert. Les commandes passent par AWS Systems Manager (Run Command) : pas de SSH, pas de clé à gérer. Le compte IAM utilisé ne peut lancer que de petites instances, uniquement avec une étiquette Purpose=agent-test, et ne peut supprimer que celles-là.

Coût total de la journée, cinq VM comprises : quelques centimes.

1. Tester une famille de distributions, pas une architecture

Le premier réflexe est de tester « un Linux ARM et un Linux x86 ». Mais le script ne distingue jamais l'architecture : c'est le dépôt Zabbix qui fournit le bon paquet. Il se divise en revanche par famille : Debian/Ubuntu (apt, dépôt construit avec $ID$VERSION_ID), RHEL et dérivés (dnf, dépôt el9, SELinux), Amazon Linux, SUSE.

La matrice retenue couvre les deux axes avec deux VM : Ubuntu 24.04 en ARM et Rocky Linux 9 en x86. Debian 12 est venue ensuite, et elle a révélé ses propres problèmes (point 7).

2. Les plus petites VM ont leurs propres pannes

Deux faux problèmes, qu'il faut savoir reconnaître :

• 512 Mo de mémoire ne suffisent pas à dnf sur Rocky Linux : le téléchargement de l'index des dépôts est tué faute de mémoire. Une instance à 1 Go règle le problème.
• Les crédits CPU. Une instance T3 en mode standard démarre sans crédit et retombe à 10 % d'un cœur dès qu'elle les épuise. Après quelques recompilations SELinux, nos commandes de comptage prenaient 13 secondes au lieu de 50 millisecondes, et l'agent les coupait au bout de 3 secondes : « Timeout while executing a shell script ». Ce n'était pas le script, c'était la VM.

3. Sous SELinux, des valeurs fausses sans aucune erreur

Rocky, AlmaLinux et RHEL activent SELinux en mode enforcing. La politique fournie pour l'agent (zabbix_agent_t) l'empêche de lire /var/log/secure, même avec une ACL, et de lancer ip, ss, systemctl ou rpm.

Le piège : un élément system.run["ss -tan state established | wc -l"] ne passe pas en erreur. ss est bloqué, wc -l compte zéro ligne, et Zabbix reçoit 0. Le tableau de bord affiche « 0 connexion établie », sans rien de rouge nulle part.

La seule manière de le voir est de chercher les refus :

sudo ausearch -m AVC -ts recent -c zabbix_agentd

4. systemd refuse aussi, et ailleurs

Un élément vérifiait l'état du pare-feu avec systemctl is-active firewalld. Il remontait : Failed to retrieve unit state: Access denied. Pourtant, aucun refus dans ausearch -m AVC.

Le refus ne venait pas du noyau, mais de systemd lui-même, qui consulte SELinux avant de répondre (init_t:system status). Il est journalisé sous un autre type :

sudo ausearch -m USER_AVC -ts recent | grep zabbix_agent_t

5. Des refus masqués par la politique de base

Même en passant le domaine de l'agent en mode permissif, certains refus n'apparaissaient pas. La politique SELinux contient des règles dontaudit qui bloquent sans journaliser. Pour les voir pendant un diagnostic :

sudo semodule -DB   # désactive les dontaudit
# reproduire, puis ausearch
sudo semodule -B    # les rétablit

C'est ainsi que sont apparus les refus de ss sur sa socket netlink et de rpm sur sa base. Le résultat final est un petit module SELinux qui n'accorde que ces lectures et ces exécutions, et qui laisse SELinux en enforcing.

6. Une ACL sur /etc/shadow disparaît au premier mot de passe changé

Pour détecter une modification de /etc/shadow, le modèle calculait une somme de contrôle du fichier. Sur RHEL, il n'y a pas de groupe shadow, et le fichier est en 0000. Une ACL semble fonctionner… jusqu'au premier passwd ou useradd : ces outils réécrivent le fichier (nouvel inode) sans recopier les ACL.

La solution est plus simple et plus sûre : suivre la date de modification (vfs.file.time[/etc/shadow,modify]), qui ne demande qu'un stat. L'agent n'a plus besoin de lire les empreintes des mots de passe, sur aucune distribution.

7. Debian 12 en cloud : ni journaux, ni cron

Les images cloud de Debian 12 n'installent ni rsyslog, ni cron. /var/log ne contient ni auth.log, ni syslog, ni kern.log : tout passe par journald.

Conséquence : les contrôles de connexions SSH échouées, de commandes sudo ou d'erreurs du noyau ne lisent rien. Et un élément vfs.file.cksum[/etc/crontab] échoue, puisque le fichier n'existe pas.

Un détail de test au passage : vérifiez la présence du démon (command -v rsyslogd), pas celle des fichiers. Après le retrait de rsyslog, un ancien auth.log reste en place, figé, et fait croire que tout va bien.

8. Un seul élément en échec suffit à faire tomber un score calculé

Les scores de sécurité sont des éléments calculés qui additionnent une dizaine de signaux. Si un seul de ces éléments est « non supporté », Zabbix ne calcule plus rien : « Cannot evaluate function: item … is not supported ».

Un fichier absent sur une distribution (/var/log/syslog sur RHEL, /etc/crontab sur Debian 12) suffit donc à faire disparaître le score entier. Deux corrections :

• lire les journaux avec une expression qui couvre les deux familles : logrt["/var/log/^(syslog|messages)$",...] ;
• pour un fichier légitimement absent, ajouter l'étape de prétraitement « Vérifier les valeurs non prises en charge », limitée à l'erreur No such file, qui remplace l'échec par 0. Les erreurs de droits restent, elles, visibles.

9. Passer de log[] à logrt[] ne suffit pas pour les agents déjà lancés

Après avoir remplacé log["/var/log/syslog",...] par logrt["/var/log/^(syslog|messages)$",...] dans le modèle, deux serveurs Ubuntu restaient en échec : « Cannot obtain information for file "/var/log/^(syslog|messages)$" ». L'agent lisait pourtant /var/log/syslog sans problème.

Il cherchait un fichier portant littéralement ce nom. L'élément avait gardé le même identifiant, et l'agent déjà lancé avait mis à jour la clé en conservant l'ancien mode log. Les nouveaux agents n'avaient pas le problème.

Correctif sans redémarrer les agents : désactiver les éléments, attendre une minute que l'agent les oublie, puis les réactiver.

10. Le journal de l'agent ne dit pas tout

Dernière leçon, la plus générale : le journal de l'agent ne suffit pas pour vérifier une installation.

• Le prétraitement s'applique côté serveur : l'agent peut journaliser une erreur que le serveur transforme ensuite en valeur valide.
• Certains échecs n'apparaissent que côté serveur, comme un logrt sans fichier correspondant.
• Les éléments découverts automatiquement (disques, cartes réseau) ne reçoivent les modifications du modèle qu'à la prochaine exécution de la découverte, une fois par heure ici.

La vérification fiable se fait par l'API Zabbix : item.get avec filter: {state: 1} liste tous les éléments en échec, sur tout le parc, en une requête.

Ce que nous en retenons

• Un test d'installation se juge côté serveur, élément par élément, pas sur le message de fin du script.
• SELinux ne casse pas bruyamment : il fait remonter des zéros. Cherchez AVC et USER_AVC, avec les dontaudit désactivés.
• Les VM jetables sont la bonne échelle de coût : une distribution de plus à tester coûte un centime et cinq minutes.

Toutes ces corrections sont intégrées au script d'installation de Logiserv et à ses modèles : module SELinux dédié, rsyslog installé quand aucun démon syslog n'est présent, /etc/shadow suivi par sa date de modification. Pour une installation manuelle, les guides Rocky Linux, Debian et Amazon Linux détaillent chaque commande.