logo zabbix

Mise à jour de Zabbix 4.4.10 vers Zabbix 5.2 (incluant un passage de Debian 9 à Debian 10)

Le défi du jour (ou de la semaine…) : passer mon serveur Zabbix de la version 4.4.10 à la version 5.2. Dans la mesure où il y a une version intermédiaire entre les deux, la 5.0 (une LTS), je vais passer par celle-ci avant de monter en 5.2. Les raisons sont que je vais en profiter pour vérifier que tout va bien en 5.0 avant de continuer la montée de version, mais aussi que les notes de montée de version 4.4 -> 5.0 comportent plusieurs mises en garde (comme nous allons le voir plus loin) , alors que la mise à jour 5.0 -> 5.2 semble n’être qu’une quasi-formalité.

Navigation

Upgrade de Debian 9 à Debian 10

Eeeeeh oui. Ça peut paraître un peu overkill, mais Zabbix, à partir de la version 5.0, requière php 7.2.0 minimum, hors la Debian 9 ne propose que php 7.0. C’est la première mise en garde. On pourrait essayer de bricoler avec des dépôts tiers, mais perso j’aime bien avoir des système Debian « vanille » dans la mesure du possible. De plus, c’est la voie recommandée dans la documentation, donc je vais commencer par cet upgrade, comme ça en plus, ça sera fait. Debian 10 propose php 7.3, ce qui est parfait, y compris en prévision de l’upgrade vers Zabbix 5.2 qui requière ici php 7.2.5 minimum.

J’ai donc suivi la procédure décrite dans cet excellent article décrivant la mise à jour d’un système Debian 9 vers Debian 10, non sans avoir au préalable fait un snapshot de ma VM Zabbix (tout est dedans, front-end php, serveur Zabbix, et base de données).

J’ai commencé par m’assurer que j’avais suffisamment de place disponible pour faire la mise à jour:

# df -h 

udev               992M       0  992M   0% /dev
tmpfs              201M    3,0M  198M   2% /run
/dev/vda1          7,4G    2,2G  4,9G  31% /
tmpfs             1003M       0 1003M   0% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs             1003M       0 1003M   0% /sys/fs/cgroup
/dev/vdb1           30G     18G   11G  62% /var/lib/mysql
tmpfs              201M       0  201M   0% /run/user/0

Il reste 4,9 Go sur /, ainsi que 11 Go sur le volume dédié à la base de données, ça devrait largement suffire. J’ai ensuite, comme décrit dans le tuto, modifié mon fichier /etc/apt/sources.list, mais comme ici, mon Zabbix est installé à partir des dépôts officiels du projet Zabbix, j’ai également modifié le fichier /etc/apt/sources.list.d/zabbix.list comme ceci:

# sed -i 's/stretch/buster/g' /etc/apt/sources.list.d/zabbix.list

Ce fichier pointe vers les dépôts de la version 4.4 de Zabbix, l’application ne fera pas de montée de version accidentelle pendant l’upgrade de ma Debian.

Le reste de la mise à jour s’est passé comme décrit dans l’article (apt update && apt full-upgrade après avoir mis à jour le fichier sources.list), et j’ai également du installer explicitement et activer php 7.3:

# apt install libapache2-mod-php7.3 php7.3-bcmath php7.3-cli php7.3-common php7.3-gd php7.3-json php7.3-ldap php7.3-mbstring php7.3-mysql php7.3-opcache php7.3-readline php7.3-xml

# apt purge php 7.0*

# a2enmod php7.3

# systemctl restart apache2

Il a quand même fallu que je réinstalle explicitement le paquet du serveur Zabbix, je pense que ça n’avait pas été fait comme il n’y avait pas de montée de version:

# dpkg -l |grep zabbix | awk  '{print $2}' | while read line; do apt install --reinstall $line;done

# systemctl restart zabbix-server

# systemctl enable zabbix-server

Un petit vidage du cache de mon navigateur pour faire disparaître les trucs bizarres et tout était OK, le Zabbix était pleinement fonctionnel. Sauf que le dashboard se plaignait que php n’avait pas de timezone configurée; qu’à cela ne tienne:

# vi /etc/php/7.3/apache2/php.ini

Insertion de le fichier php.ini, à la rubrique timezone de la directive suivante:

date.timezone = "Europe/Paris"

Puis un petit reload du démon apache pour prendre ça en compte:

# systemctl reload apache2.service

La mise à jour de ma Debian, de Stretch vers Buster est terminée, on est dans des conditions idéales de température et de pression pour s’attaquer à la mise à jour de Zabbix.

Mise à jour de Zabbix 4.4.10 vers Zabbix 5.0.6

Une deuxième mise ne garde des notes de montée de version nous alerte d’un probable échec de la mise à jour de la base de données si celle-ci a été créée avec mariadb en version inférieure ou égale à la 10.2.1 car le format de ligne par défaut avec ces versions était « compact »; hors pour que la mise à jour fonctionne, il faut passer ce format à « dynamic ». Une petite vérification s’impose, avec la commande sql suivante:

MariaDB [zabbix]> show create table hosts;

La fin du retour de la commande nous montre ceci:

ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin ROW_FORMAT=COMPRESSED

On le voit également avec cette requête:

MariaDB [zabbix]> show table status from zabbix where name='hosts';

Qui renvoie (entre autres):

row_format=COMPRESSED

Bon, du coup je ne semble pas être dans un cas problématique pour la mise à jour de la base de données (qui semble ne concerner que les tables créées avec un row_format=COMPACT), mais je me garde sous le coude cet article de la base de bug reports au cas où.

On peut donc y aller pour la mise à jour, en commençant par les commandes suivantes qui vont supprimer l’ancien fichier décrivant le dépôt de Zabbix, pour le remplacer par un nouveau:

# rm -Rf /etc/apt/sources.list.d/zabbix.list

# wget https://repo.zabbix.com/zabbix/5.0/debian/pool/main/z/zabbix-release/zabbix-release_5.0-1+buster_all.deb

# dpkg -i zabbix-release_5.0-1+buster_all.deb

Puis on rafraîchit la liste des paquets:

# apt update

Ensuite on met à jour le serveur Zabbix, l’agent, et les fichiers php du frontend:

# apt-get install --only-upgrade zabbix-server-mysql zabbix-frontend-php zabbix-agent

Dans mon cas, fichier /etc/zabbix/zabbix_server.conf a été customisé, j’ai donc répondu « N » à la question qui demandait si il fallait le remplacer par la version venant avec la mise à jour.

Il reste ensuite à mettre à jour la configuration apache, en mettant à jour le paquet qui s’en occupe:

# apt-get install zabbix-apache-conf

On procède au redémarrage de tous les éléments; en regardant les logs, on peut suivre la procédure de mise à jour de la base de données.

# systemctl restart zabbix-agent

# systemctl restart zabbix-server

# tail -f /var/log/zabbix/zabbix_server.log

...
9054:20201207:082112.026 completed 84% of database upgrade
9054:20201207:082112.034 completed 85% of database upgrade
9054:20201207:082112.057 completed 86% of database upgrade
9054:20201207:082112.064 completed 87% of database upgrade
9054:20201207:082112.082 completed 88% of database upgrade
9054:20201207:082112.108 completed 89% of database upgrade
9054:20201207:082112.117 completed 90% of database upgrade
9054:20201207:082112.126 completed 91% of database upgrade
9054:20201207:082112.268 completed 92% of database upgrade
9054:20201207:082112.323 completed 93% of database upgrade
9054:20201207:082112.347 completed 94% of database upgrade
9054:20201207:082113.638 completed 95% of database upgrade
9054:20201207:082113.747 completed 96% of database upgrade
9054:20201207:082113.763 completed 97% of database upgrade
9054:20201207:082113.779 completed 98% of database upgrade
...

Le passage à Zabbix 5.0.6 est quasiment terminé. Cependant, on remarque dans la rubrique « System information » du dashboard l’information suivante:

database history not upgraded
Il reste une mise à jour à faire sur la base de données.

En fait, à présent Zabbix supporte une plus grande précision dans les nombres réels (les FLOATS), il est donc nécessaire de mettre à jour les tables history et trends pour prendre en compte cette modification. Comme ce sont des tables qui contiennent potentiellement beaucoup de lignes, cette mise à jour n’est pas incluse dans la procédure standard, et doit-être effectuée plus tard, à la discretion de l’administrateur. L’opération doit s’effectuer après avoir arrêté le serveur Zabbix.

J’ai téléchargé le script sql de mise à jour pour mariadb dans ma machine Zabbix, puis je lance les commandes suivantes:

# systemctl stop zabbix-server

# mysql -u root -p zabbix < double.sql

Il faut enfin modifier la configuration de Zabbix pour lui indiquer que nous utilisons la double précision dans les tables, et redémarrer le serveur:

# sed -i "s/?>/\$DB['DOUBLE_IEEE754'] = 'true';\n?>/g" /etc/zabbix/web/zabbix.conf.php

# systemctl start zabbix-server

La mise à jour vers la version 5.0.6 de Zabbix est terminée.

Mise à jour de Zabbix 5.0.6 vers Zabbix 5.2

Dans la mesure où j’ai déjà fait le taf pour avoir une version suffisante de php pour Zabbix 5.2, et que les notes de version ne contiennent que des parties applicatives qui ne me concernent pas, je peux me lancer dans ce saut de version sans trop de précautions, avec un protocole identique au saut précédent, comme indiqué dans la documentation de mise à jour vers la version 5.2.

Les opérations sont donc identiques aux précédentes, à savoir le remplacement du fichier de configuration des dépôts Zabbix, et la mise à jour des paquets du serveur.

# rm -Rf /etc/apt/sources.list.d/zabbix.list

# wget https://repo.zabbix.com/zabbix/5.2/debian/pool/main/z/zabbix-release/zabbix-release_5.2-1+debian10_all.deb

# dpkg -i zabbix-release_5.2-1+debian10_all.deb

# apt update

# apt-get install --only-upgrade zabbix-server-mysql zabbix-frontend-php zabbix-agent

# apt-get install zabbix-apache-conf

# systemctl restart zabbix-agent

# systemctl restart zabbix-server

Deux trucs curieux à noter quand même: il a fallu que je redémarre apache après la mise à jour (j’avais des erreurs 500)

# systemctl restart apache2

Après ça, le front-end php était de retour. Mais vide, comme si je n’était pas connecté…Il a fallu que je me délogue / relogue à nouveau pour retrouver le contenu. Ca pourrait être du au fait qu’à présent, la session est maintenue par un cookie.

o/

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *