Situation

J'ai récemment débuté un mini projet pour superviser mes serveurs et services avec Zabbix sur FreeBSD, le tout dans des jails. Un serveur chez kimsufi sera le Zabbix Server (dans un jail) et sur mon serveur principal chez OneProvider, j'ai mis en place un Zabbix Proxy (toujours dans une jail). J'ai rencontré deux problèmes bloquants avec la partie serveur et proxy : l'impossibilité de démarrer le serveur et d'importer le schéma de db pour le proxy.

Zabbix Server

Jail : cannot allocate shared memory

Dans une jail FreeBSD, j'ai donc installé le serveur Zabbix. Après avoir configuré la db, et crée le fichier de configuration du serveur (/usr/local/etc/zabbix42/zabbix_server.conf) lorsque je lançais le service, il ne démarrait simplement pas :

# /usr/local/etc/rc.d/zabbix_server start
# /usr/local/etc/rc.d/zabbix_server status
zabbix_server is not running.

Un coup d'œil dans les logs Zabbix : zabbix_server [2691]: cannot create locks: cannot allocate shared memory for locks

Après une recherche, je tombe sur une page du wiki de Zabbix qui explique qu'il faut augmenter des paramètres du kernel (shmall et shmmax) qui sont par défauts trop bas. Rapidement, je m'aperçois que leur documentation est trop vieille : les valeurs qu'ils conseillent d'appliquer sont plus bas que celles appliquées par défaut sur FreeBSD 12. Pour la pérennité, les valeurs par défaut :

# ipcs -M
shminfo:
    shmmax:    536870912    (max shared memory segment size)
    shmmin:            1    (min shared memory segment size)
    shmmni:          192    (max number of shared memory identifiers)
    shmseg:          128    (max shared memory segments per process)
    shmall:       131072    (max amount of shared memory in pages)

Celles conseillées par le how to :

 kern.ipc.shmall=2097152
 kern.ipc.shmmax=134217728

On voit clairement, comme dit plus haut, que les paramètres en place ont une valeurs bien plus élevés.

SYSV IPC

En continuant mes recherches, j'arrive par hasard sur la documentation PostgreSQL fait état des mêmes remarques que celle de Zabbix à un détail près : un paramètre spécifique à appliquer sur une jail dont je ne connaissais pas l'existence :

En cas d'exécution dans une cage FreeBSD en activant security.jail.sysvipc_allowed de sysctl, les postmaster exécutés dans différentes cages devront être exécutés par différents utilisateurs du système d'exploitation

Je tente en activant le paramètre allow.sysvipc dans la jail zabbix :

# vim /usr/local/etc/ezjail/zabbix
-export jail_zabbix_parameters="allow.raw_sockets=1"
+export jail_zabbix_parameters="allow.raw_sockets=1 allow.sysvipc=1"
# ezjail-admin restart zabbix

Et le service zabbix_server s'est lancé sans erreur :

# /usr/local/etc/rc.d/zabbix_server status
zabbix_server is running as pid 5815.

Après lecture d'un blogpost très intéressant SYSV IPC correpond au Shared Memory, Semaphores and Message Queue. Les jails se partageant le même kernel, quand elles ont besoin de SYSV IPC elles doivent demander l'autorisation de l'utiliser. Avant FreeBSD 11, on pouvait soit accorder les droits complets soit les refuser totalement via le paramètre que l'on a vu précédemment allow.sysvipc. Si deux jails ont ce partage de ressources, si l'une d'elle est comprise, elle peut compromettre l'autre également. Depuis FreeBSD 11 donc, on peut utiliser les paramètres sysvshm et sysvsem avec la valeur new (créer un nouveau namespace SYSV pour la jail). J'ai modifié la configuration de ma jail de cette façon :

# vim /usr/local/etc/ezjail/zabbix
-export jail_zabbix_parameters="allow.raw_sockets=1 allow.sysvipc=1"
+export jail_zabbix_parameters="allow.raw_sockets=1 sysvshm=new sysvsem=new"
# ezjail-admin restart zabbix

Le service démarre toujours et avec de la sécurité :).

Zabbix Proxy

Import SQL Row size too large (> 8126)

Une fois le paquet installé et la db crée, il faut importer les données sql du fichier schema.sql. Pas de bol une nouvelle fois :

# mysql -h 192.168.0.4 -uzabbix zabbix_proxy < /usr/local/share/zabbix42/proxy/database/mysql/schema.sql
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1118 (42000) at line 1284: Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.

Ce problème est connu : MariaDB ne calcule pas correctement la taille des lignes pendant l'exécution. Les calculs sont censés être corrigés entre autre en 10.4.7, j'ai pourtant la 10.4.11… :

# pkg info | grep mariadb
mariadb104-client-10.4.11      Multithreaded SQL database (client)
mariadb104-server-10.4.11      Multithreaded SQL database (server)

Le lien ci-dessus renvoie vers le bugreport MDEV-19292 où, mis à part désactiver innodb_strict_mode=OFF, passer la taille des varchar à 255 de la table host_inventory serait la solution :

Keep InnoDB strict mode enabled, but change some of those varchar(N) columns to varchar(N >= 256 bytes). If the table's default character set is utf8mb4, then that means that N would have to be 64 or more. i.e. this also succeeds in MariaDB 10.2.26.

Un coup de sed dans schema.sql :

$ cd /usr/local/share/zabbix42/proxy/database/mysql/schema.sql
$ sed -i.bak '/CREATE TABLE `host_inventory`/,/PRIMARY KEY/s/varchar([0-9]\{1,\})/varchar(255)/' schema.sql

Et effectivement l'import fonctionne sans faute !