Pendant des années, nous avons proposé plusieurs AMIs Zabbix en même temps sur AWS Marketplace : 4.2, 4.4, 6.0, 6.4 et 7.0. L’idée était simple : certaines équipes ont des installations qui, à cause d’intégrations, de modèles ou par simple prudence, ne peuvent pas passer à une nouvelle version majeure, et nous voulions qu’elles disposent d’une image maintenue de leur version.
Ce n’est plus possible. De tout ce catalogue, seule notre AMI Zabbix 7.0 LTS reste sur le Marketplace, et ce n’est pas notre choix : AWS Marketplace refuse les autres. Voici pourquoi.
La règle : rien en fin de vie
AWS Marketplace examine chaque version d’une AMI avant de la publier. En plus de vérifier que l’image démarre et respecte les exigences techniques, il l’analyse à la recherche de vulnérabilités et de logiciels non supportés. La politique est claire : les produits qui utilisent un système d’exploitation ou un logiciel arrivé en fin de vie (end of life, EOL) ne sont pas acceptés.
Les deux moitiés de la phrase comptent. Il ne suffit pas que le système de base soit supporté ; le logiciel embarqué dans l’image compte aussi. Et le critère n’est pas « il est patché », mais « ceux qui le développent le maintiennent encore ».
Comment elle s’applique
En pratique, le contrôle arrive par deux voies :
- À la publication d’une nouvelle version. L’analyse signale le système ou le logiciel en fin de vie et la version est rejetée. Peu importe que le reste soit impeccable : reconstruire ne fait pas disparaître le problème.
- Sur un produit déjà publié. AWS peut passer le produit à l’état Restricted : il n’est plus proposé aux nouveaux acheteurs et n’accepte plus de nouvelles versions. Les abonnés existants gardent l’accès à leurs instances, mais le produit est gelé.
Les deux vont ensemble. Un produit restreint ne peut pas recevoir de version qui l’en sorte, et toute version construite sur la même base se heurtera à la même analyse.
Deux calendriers qui doivent coïncider
Une AMI Zabbix dépend de deux cycles de vie à la fois, et les deux doivent être dans leur période de support :
- Celui de Zabbix. Les versions standard (4.2, 4.4, 6.4…) ne sont maintenues que quelques mois, jusqu’à la sortie de la suivante. Les LTS (6.0, 7.0…) ont plusieurs années de support, mais elles expirent aussi.
- Celui d’Ubuntu. Chaque version de Zabbix ne publie des paquets que pour les releases d’Ubuntu qui existaient pendant son développement. Une ancienne version de Zabbix n’arrive jamais sur les nouvelles Ubuntu et reste liée à un système qui finira par perdre son support.
Avec ces deux calendriers, voici où en sont nos anciennes AMIs :
| AMI | Zabbix | Ubuntu | Pourquoi elle est refusée |
|---|---|---|---|
| Zabbix 4.2 | standard, non maintenue depuis 2019 | 18.04, sans support standard depuis 2023 | Zabbix et système en fin de vie. 4.2 n’a pas de paquets après Ubuntu 18.04 |
| Zabbix 4.4 | standard, non maintenue | 18.04, sans support standard depuis 2023 | Zabbix et système en fin de vie. 4.4 ne va que jusqu’à Ubuntu 20.04, lui aussi sans support |
| Zabbix 6.0 | LTS | 20.04, sans support standard depuis 2025 | Le système de base est en fin de vie |
| Zabbix 6.4 | standard, non maintenue | 22.04 | La version de Zabbix elle-même est en fin de vie |
La conclusion est inconfortable mais nette : la seule ligne qui respecte la politique dans la durée est la dernière LTS de Zabbix sur une Ubuntu LTS supportée. Aujourd’hui, c’est Zabbix 7.0 sur Ubuntu 24.04. Maintenir plus de lignes sur le Marketplace, c’est maintenir des produits qu’AWS retirera dès que le prochain calendrier expirera.
Le cas qui l’a révélé : Zabbix 4.2
Nous nous en sommes rendu compte en préparant la dernière version de l’AMI Zabbix 4.2. L’analyse d’AWS a remonté trois problèmes : utilisation d’un logiciel en fin de vie (Ubuntu 18.04) et deux CVE, CVE-2023-4863 dans libwebp et CVE-2023-44487 dans nghttp2.
Et si on applique les correctifs ?
C’est la première question, et la réponse est que cela ne sert à rien. Les correctifs de ces deux CVE pour Ubuntu 18.04 n’existent que dans ESM, c’est-à-dire dans Ubuntu Pro. Même en les appliquant, le problème principal resterait : le support étendu payant ne rend pas supportée une release sortie du support standard.
Et si on change de système ?
Pas davantage. Le dépôt officiel de Zabbix 4.2 ne publie des paquets que jusqu’à Ubuntu 18.04. Nous avons aussi exploré la piste Debian, qui mène au même point : la dernière Debian avec des paquets 4.2 n’est plus supportée, et sur les versions actuelles les paquets ne s’installent pas et le code ne compile pas sans réécrire la moitié du frontend. Et même en y parvenant, ce serait toujours Zabbix 4.2, un logiciel en fin de vie en soi.
Le même raisonnement, avec des nuances, s’applique au reste du tableau. C’est pourquoi nous avons retiré la page de Zabbix 4.2 et ne gardons que la 7.0 sur le Marketplace.
Ce que cela signifie pour vous
- Si vous avez déjà une instance avec une ancienne version, elle continue de fonctionner exactement comme avant. Rien ne s’éteint. En revanche, il n’y aura plus de nouvelles versions sur le Marketplace.
- Si vous pouvez mettre à jour, la voie recommandée est notre AMI Zabbix 7.0 LTS, sur Ubuntu 24.04. Sa page contient le guide de migration pour reprendre votre base de données sans perdre l’historique.
- Si vous devez rester sur une version antérieure, nous pouvons préparer une version sur mesure pour votre compte AWS, hors Marketplace, avec le même autoscaling et les mêmes notifications SNS. Écrivez à notre support et nous l’étudierons.
Une leçon qui dépasse Zabbix
Ce qui est arrivé à notre catalogue Zabbix arrivera tôt ou tard à toute image qui dépend d’une release précise. C’est pourquoi nos AMIs installent chaque composant depuis le dépôt officiel de son projet et suivent des lignes supportées, et pourquoi nous surveillons le calendrier de chaque produit avant qu’AWS ne le fasse : quand le système ou le logiciel approche de sa fin de vie, la migration doit être faite avant que l’analyse ne le signale.
