Durante anos mantivemos no AWS Marketplace várias AMIs do Zabbix ao mesmo tempo: a 4.2, a 4.4, a 6.0, a 6.4 e a 7.0. A ideia era simples: há equipas com instalações que, por integrações, templates ou simples prudência, não podem dar o salto para uma nova versão maior, e queríamos que tivessem uma imagem mantida da versão que usam.
Isso já não é possível. De todo esse catálogo, no Marketplace só resta a nossa AMI do Zabbix 7.0 LTS, e não por decisão nossa: o AWS Marketplace não aceita as restantes. Explicamos porquê.
A regra: nada em fim de vida
O AWS Marketplace revê cada versão de uma AMI antes de a publicar. Além de verificar que a imagem arranca e cumpre os requisitos técnicos, analisa-a à procura de vulnerabilidades e de software sem suporte. A política é clara: não são aceites produtos que utilizem um sistema operativo ou software que tenha chegado ao fim de vida (end of life, EOL).
As duas metades da frase importam. Não basta que o sistema base tenha suporte; também conta o software que a imagem traz. E o critério não é «tem as correções aplicadas», mas «quem o desenvolve continua a mantê-lo».
Como a aplica
Na prática, o controlo chega por dois caminhos:
- Ao publicar uma nova versão. A análise da imagem assinala o sistema ou o software em fim de vida e a versão é rejeitada. Não importa que o resto esteja impecável: o problema não desaparece reconstruindo.
- Sobre um produto já publicado. A AWS pode passar o produto ao estado Restricted: deixa de estar disponível para novos compradores e não aceita novas versões. Quem já tinha a subscrição mantém o acesso às suas instâncias, mas o produto fica congelado.
As duas coisas andam juntas. Um produto restrito não pode receber uma versão que o tire desse estado, e qualquer versão construída sobre a mesma base vai esbarrar na mesma análise.
Dois calendários que têm de bater certo
Uma AMI do Zabbix depende de dois ciclos de vida ao mesmo tempo, e ambos têm de estar dentro do suporte:
- O do Zabbix. As versões standard (4.2, 4.4, 6.4…) só são mantidas durante alguns meses, até sair a seguinte. As LTS (6.0, 7.0…) têm vários anos de suporte, mas também caducam.
- O do Ubuntu. Cada versão do Zabbix só publica pacotes para as releases do Ubuntu que existiam enquanto era desenvolvida. Uma versão antiga do Zabbix nunca chega aos Ubuntu novos e fica presa a um sistema que acabará por sair do suporte.
Com esses dois calendários, eis a situação de cada uma das nossas AMIs antigas:
| AMI | Zabbix | Ubuntu | Porque não passa |
|---|---|---|---|
| Zabbix 4.2 | standard, sem manutenção desde 2019 | 18.04, sem suporte padrão desde 2023 | Zabbix e sistema em fim de vida. A 4.2 não tem pacotes para nenhum Ubuntu posterior ao 18.04 |
| Zabbix 4.4 | standard, sem manutenção | 18.04, sem suporte padrão desde 2023 | Zabbix e sistema em fim de vida. A 4.4 chega no máximo ao Ubuntu 20.04, também sem suporte |
| Zabbix 6.0 | LTS | 20.04, sem suporte padrão desde 2025 | O sistema base está em fim de vida |
| Zabbix 6.4 | standard, sem manutenção | 22.04 | A própria versão do Zabbix está em fim de vida |
A conclusão é incómoda mas clara: a única linha que cumpre a política de forma sustentada é a última LTS do Zabbix sobre um Ubuntu LTS com suporte. Hoje isso é o Zabbix 7.0 sobre o Ubuntu 24.04. Manter mais linhas no Marketplace significa manter produtos que a AWS vai retirar assim que o próximo calendário caducar.
O caso que o revelou: Zabbix 4.2
Demos por isso ao preparar a última versão da AMI do Zabbix 4.2. A análise da AWS devolveu três problemas: utilização de software em fim de vida (Ubuntu 18.04) e duas CVE, CVE-2023-4863 na libwebp e CVE-2023-44487 na nghttp2.
E se aplicarmos as correções?
É a primeira pergunta, e a resposta é que não serve. As correções dessas duas CVE para o Ubuntu 18.04 só existem no ESM, ou seja, no Ubuntu Pro. Mesmo que as aplicássemos, o problema principal continuaria lá: o suporte alargado pago não torna suportada uma release que saiu do suporte padrão.
E se mudarmos de sistema?
Também não. O repositório oficial do Zabbix 4.2 só publica pacotes até ao Ubuntu 18.04. Experimentámos também a via do Debian e acaba no mesmo sítio: o último Debian com pacotes da 4.2 está sem suporte, e nos atuais nem os pacotes instalam nem o código compila sem reescrever metade do frontend. E mesmo que o conseguíssemos, continuaria a ser o Zabbix 4.2, que é por si só software em fim de vida.
O mesmo raciocínio, com nuances, aplica-se ao resto da tabela. Por isso retirámos a página do Zabbix 4.2 e no Marketplace deixamos apenas a 7.0.
O que significa para si
- Se já tem uma instância com uma versão antiga, continua a funcionar exatamente como antes. Nada se desliga. O que não vai haver são novas versões no Marketplace.
- Se pode atualizar, o caminho recomendado é a nossa AMI do Zabbix 7.0 LTS, sobre o Ubuntu 24.04. Na página tem o guia de migração para levar a base de dados sem perder o histórico.
- Se precisa de continuar numa versão anterior, podemos preparar uma versão à medida para a sua conta AWS, fora do Marketplace, com o mesmo autoscaling e as mesmas notificações por SNS. Escreva ao suporte e analisamos o caso.
Uma lição que vai além do Zabbix
O que aconteceu ao nosso catálogo do Zabbix vai acontecer, mais cedo ou mais tarde, a qualquer imagem que dependa de uma release concreta. Por isso as nossas AMIs instalam cada componente a partir do repositório oficial do seu projeto e seguem linhas com suporte, e por isso revemos o calendário de cada produto antes de a AWS o fazer: quando o sistema ou o software se aproximam do fim de vida, a migração tem de estar feita antes de a análise o dizer.
