Buildroot : Création d'un firmware multiplateforme avec zabbix-server

Historique de la tâche

Les petites entreprises, d'une part, ont besoin d'une surveillance de qualité de leur infrastructure (surtout à l'ère de la virtualisation), et d'autre part, il leur est financièrement difficile d'acheter du nouveau matériel. Des problèmes de serveur/matériel se posent également fréquemment : il y a souvent 1 à 3 serveurs en tour placés à proximité des postes de travail des utilisateurs ou dans une petite niche/caniveau.

Il est plus simple d'utiliser un assemblage (distributif) déjà prêt, qu'il suffit de copier sur une carte microSD et d'insérer dans un ordinateur monocarte courant (beaglebone, familles raspberry pi et orange pi, asus tinker board). De plus, ce type de matériel est peu coûteux et peut être installé n'importe où.

Définition du problème

En grande partie, le projet s'est développé comme un travail de laboratoire avec la possibilité d'appliquer les résultats.

Pour le système de surveillance, zabbix a été choisi, car c'est un système puissant, gratuit et bien documenté.

La question de la plateforme matérielle s'est posée de manière aiguë. Installer une machine séparée pour la surveillance n'est pas non plus la meilleure solution — soit il est coûteux d'acheter nouveau matériel, soit il faut chercher de l'ancien + dans les petites entreprises, il y a souvent des problèmes de serveur/matériel.

L'utilisation du système de construction buildroot permet de créer des solutions spécialisées, pouvant être exploitées par du personnel avec des connaissances minimales sur les systèmes d'exploitation de la famille Linux. Ce système est convivial pour les débutants, tout en offrant de larges possibilités de personnalisation entre les mains d'un développeur expérimenté. Il est idéal pour répondre à la nécessité d'une surveillance IT fonctionnelle et peu coûteuse, avec un minimum d'exigences pour la formation du personnel qui l'exploite.

Étapes de la solution

Il a été décidé de créer initialement un firmware pour x86_64 pour le faire fonctionner dans qemu, car c'est une solution pratique et rapide pour le débogage. Ensuite, il a fallu le porter sur un ordinateur monocarte arm (j'ai préféré l'asus tinker board).

Le système de construction choisi est buildroot. Au départ, il ne contenait pas le paquet zabbix, donc il a fallu le porter. Il y a eu des problèmes avec la locale russe, qui ont été résolus par l'application de patches correspondants (note : dans les versions plus récentes de buildroot, ces patches ne sont plus nécessaires).

Le portage du paquet zabbix lui-même sera décrit dans un article séparé.

Puisque tout doit fonctionner comme un firmware (image système immutable + fichiers de configuration/base de données récupérables), il a été nécessaire d'écrire ses propres cibles, services et minuteries systemd (target, service, timer).

Il a été décidé de diviser le support en 2 partitions — une partition pour les fichiers système et une autre pour les configurations modifiables et les fichiers de base de données de Zabbix.

La solution des problèmes liés à la base de données s'est révélée un peu plus complexe. J'avais peu d'envie de la placer directement sur le support. En même temps, la taille de la base de données peut atteindre des dimensions dépassant celles du ramdisk possible. Par conséquent, une solution de compromis a été choisie : la base de données est placée sur la deuxième partition de la carte SD (les cartes SLC modernes ont jusqu'à 30 000 cycles d'écriture), mais il y a une configuration permettant d'utiliser un support externe (par exemple, un disque dur USB).

La surveillance de la température a été réalisée via le dispositif RODOS-5. Bien sûr, on peut utiliser le Dallas 1820 directement, mais il était plus rapide et plus simple de le brancher en USB.

Le chargeur de démarrage pour x86_64 choisi est grub2. Il a été nécessaire d'écrire une configuration minimale pour le démarrage.

Après le débogage sur QEMU, le portage a été effectué sur l'ASUS Tinker Board. Dans la structure de mon overlay, la multiplateforme a été initialement prévue — la distinction de configurations spécifiques à chaque carte (defconfig de la carte, chargeur, génération de l'image avec la partition système) et le maximum d'homogénéité dans le réglage du système de fichiers/creation d'une image avec les données. Grâce à cette préparation, le portage s'est bien déroulé.

Il est fortement recommandé de lire les articles d'introduction :
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Comment assembler

Le projet est stocké sur GitHub
Après avoir cloné le référentiel, la structure des fichiers suivante est obtenue :

[alexey@comp monitor]$ ls -1
buildroot-2019.05.tar.gz
overlay
README.md
run_me.sh

buildroot-2019.05.tar.gz — archive de buildroot propre
overlay — mon dossier avec external-tree. C'est là que se trouve tout ce qui est nécessaire pour assembler le firmware à l'aide de buildroot
README.md — description du projet et manuel en anglais.
run_me.sh — script préparant le système de construction. Il déploie buildroot à partir de l'archive, y attache l'overlay (via le mécanisme external-tree) et permet de choisir la carte cible pour la construction.

[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Sélectionnez le defconfig, appuyez sur A pour annuler. Par défaut [0]

Après cela, il suffit de se rendre dans le répertoire buildroot-2019.05 et d'exécuter la commande make.
Après la compilation, tous les résultats de la compilation seront dans le répertoire output/images :

[alexey@comp buildroot-2019.05]$ ls -1 output/images/
boot.img
boot.vfat
bzImage
data
data.img
external.img
external.qcow2
grub-eltorito.img
grub.img
intel-ucode
monitor-0.9-beta.tar.gz
qemu.qcow2
rootfs.cpio
sdcard.img
sys
update

Fichiers nécessaires :

• sdcard.img — image du support pour l'écriture sur une carte SD (via dd ou rufus sous Windows).
• qemu.qcow2 — image du support pour lancement dans qemu.
• external.qcow2 — image du support externe pour la base de données.
• monitor-0.9-beta.tar.gz — archive pour mise à jour via l'interface web.

Génération de guides

Il n'est pas nécessaire d'écrire plusieurs fois la même instruction. Il est plus logique d'écrire une fois en markdown, puis de convertir en PDF pour le téléchargement et en HTML pour l'interface web. Cela est possible grâce au paquet pandoc.

De plus, tous ces fichiers doivent être générés avant la compilation de l'image système, car les scripts post-build ne sont plus utiles. C'est pourquoi la génération est effectuée sous forme de paquet manuals. Vous pouvez le consulter dans overlay/package/manuals.

Le fichier manuals.mk (qui effectue tout le travail)

################################################################################
#
# manuals
#
################################################################################

MANUALS_VERSION:= 1.0.0
MANUALS_SITE:= ${BR2_EXTERNAL_monitorOverlay_PATH}/package/manuals
MANUALS_SITE_METHOD:=local

define MANUALS_BUILD_CMDS
    pandoc -s -o ${TARGET_DIR}/var/www/manual_en.pdf ${BR2_EXTERNAL_monitorOverlay_PATH}/../README.md
    pandoc -f markdown -t html -o ${TARGET_DIR}/var/www/manual_en.html ${BR2_EXTERNAL_monitorOverlay_PATH}/../README.md
endef

$(eval $(generic-package))

systemd

Le monde Linux passe activement à systemd, j'ai dû le faire aussi.
Parmi les nouveautés intéressantes — la présence de minuteurs. En général, à leur sujet (et pas seulement à leur sujet), un article séparé est écrit, mais je vais expliquer brièvement.

Il y a des actions qui doivent être effectuées périodiquement. J'avais besoin de lancer logrotate pour nettoyer les journaux de lighttpd et php-fpm. Il aurait été plus habituel d'écrire les commandes dans cron, mais j'ai décidé d'utiliser le minuteur systemd monotone. De cette façon, logrotate est lancé à intervalles de temps stricts.

Bien sûr, il est possible de créer des minuteurs qui se déclenchent à des dates spécifiques, mais je n'en avais pas besoin.
Exemple de minuteur :

• Fichier de minuteur

  
  [Unit]
  Description=RODOS temp daemon timer

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target

- Fichier de service appelé par le minuteur :
```bash
[Unit]
Description=RODOS temp daemon

[Service]
ExecStart=/usr/bin/rodos.sh

Cartes supportées

Asus tinker board — carte principale sur laquelle tout doit fonctionner. Choisie pour son faible coût et sa puissance.

Beaglebone black — première carte sur laquelle le fonctionnement a été testé (en attendant de trouver une carte plus puissante).

Qemu x86_64 — utilisé pour le développement et le débogage.

Comment ça fonctionne

Au démarrage, une récupération des paramètres en deux étapes a lieu :

• Exécution du script settings_restore (via le service). Il restaure les paramètres principaux du système — fuseau horaire, locale, paramètres réseau, etc.
• Exécution du script prepare (via le service) — ici se prépare zabbix, la base de données, l'IP est affichée dans la console.

Au premier démarrage, la taille de la deuxième partition de la carte sd est déterminée. Si de l'espace non alloué est encore disponible, le support est repartitionné, la partition de données occupant tout l'espace libre. Cela est fait afin de réduire la taille de l'image d'installation (sdcard.img). De plus, à ce moment-là, un répertoire de travail pour postgresql est créé. C'est pourquoi le premier démarrage avec un nouveau support sera plus long que les suivants.

Lors de la connexion d'un disque externe, au démarrage, il recherche un disque libre et le formate en ext4 avec l'étiquette external.

Attention ! Lors de la connexion d'un disque externe (et également lors de sa déconnexion ou de son remplacement), il est nécessaire de faire une sauvegarde et de restaurer les paramètres !

Pour la surveillance de la température, un appareil RODOS 5 est utilisé. Le fabricant fournit les sources de son utilitaire pour travailler avec l'appareil. Lorsque le système est allumé, un minuteur rodos démarre, qui exécute cet utilitaire une fois par minute. La température actuelle est enregistrée dans le fichier /tmp/rodos_current_temp, après quoi zabbix peut surveiller ce fichier en tant que capteur.

Le support pour le stockage de la configuration est monté dans le répertoire /data.

Au démarrage du système et lors de sa préparation, un message apparaît dans la console :

Système en cours de démarrage, veuillez patienter

Après l'achèvement des travaux préparatoires, il sera remplacé par l'affichage de l'adresse IP :

ip actuel 192.168.1.32
Prêt à travailler

Configuration de zabbix pour la surveillance de la température

Pour surveiller la température, il suffit de suivre 2 étapes :

• brancher l'appareil RODOS au port usb
• créer un élément de données dans zabbix

Ouvrons l'interface web de zabbix :

• Ouvrons la section Configuration → Hôtes
• Cliquons sur Éléments dans la liste de notre serveur zabbix
• Cliquons sur Créer un élément

Entrons les données suivantes :

• nom — à votre convenance (par exemple, serverRoomTemp)
• Type — agent zabbix
• Clé — rodos
• Type — numérique
• Unités — C
• Période de stockage de l'historique — durée de conservation de l'historique. J'ai laissé 10 jours
• Période de stockage de la tendance — durée de conservation de la dynamique des changements. J'ai laissé 30 jours
• Nouvelle application — température de la salle serveur

Et cliquons sur le bouton AJOUTER.

Gestion des paramètres via l'interface web

L'interface web est écrite en php. Elle dispose des fonctions principales :

• consultation de l'état de l'appareil
• modification des paramètres réseau
  
• changement de mot de passe utilisateur
• choix du fuseau horaire
• sauvegarde/restauration/réinitialisation aux paramètres d'usine
• possibilité de connecter un disque externe
• Mise à jour du système
  

L'accès à l'interface web est protégé par un mot de passe. La page de démarrage est le guide.

Adresse de l'interface zabbix : ${ip/dns}/zabbix
Adresse de l'interface de gestion : ${ip/dns}/manage

Lancement dans qemu

qemu-system-x86_64 -smp 4 -m 4026M -enable-kvm -machine q35,accel=kvm -device intel-iommu -cpu host -net nic -net bridge,br=bridge0 -device virtio-scsi-pci,id=scsi0 -drive file=output/images/qemu.qcow2,format=qcow2,aio=threads -device virtio-scsi-pci,id=scsi0 -drive file=output/images/external.qcow2,format=qcow2,aio=threads

Cette commande démarrera le système avec 4 cœurs, 2048 RAM, KVM activé, une carte réseau en pont bridge0 et deux disques : un pour le système et un externe pour postgresql.

Les images peuvent être converties et exécutées dans Virtualbox :

qemu-img convert -f qcow2 qemu.qcow2 -O vdi qcow2.vdi
qemu-img convert -f qcow2 external.qcow2 -O vdi external.vdi

Puis les importer dans Virtualbox et les connecter via SATA.

Conclusion

Au cours de ce processus, j'ai eu envie de créer un produit prêt à l'emploi - avec une interface pas très jolie (je n'aime pas les concevoir), mais fonctionnel et facile à configurer.

Le dernier essai d'installation de zabbix-appliance dans KVM a montré la justesse de cette étape (après l'installation, le système ne démarre pas). Peut-être que je fais quelque chose de mal 😉

Matériaux

https://buildroot.org/

Source : habr.com