Buildroot: Erstellung einer plattformübergreifenden Firmware mit zabbix-server

Aufgabenverlauf

Kleinere Unternehmen benötigen einerseits eine qualitativ hochwertige Überwachung ihrer Infrastruktur (insbesondere im Kontext der weit verbreiteten Virtualisierung), haben andererseits jedoch oft Schwierigkeiten, neue Hardware anzuschaffen. Zudem treten häufig server- und hardwarebezogene Probleme auf: Oft stehen 1-3 Tower-Server neben den Arbeitsplätzen der Nutzer oder in einer kleinen Nische.

Es ist einfacher, eine bereits fertige Distribution zu verwenden, die man einfach auf eine microSD-Karte laden und in einen gängigen Einplatinencomputer (BeagleBone, Raspberry Pi, Orange Pi, Asus Tinker Board) einsetzen kann. Zudem sind solche Geräte kostengünstig und können überall installiert werden.

Problemstellung

Das Projekt entwickelte sich in vielerlei Hinsicht wie eine Laborarbeit, die die Möglichkeit bietet, die Ergebnisse anzuwenden.

Als Überwachungssystem wurde Zabbix gewählt, da es sich um ein leistungsfähiges, kostenloses und gut dokumentiertes System handelt.

Die Frage nach der Hardware-Plattform wird dringlich. Es ist auch keine gute Lösung, einen separaten Server für das Monitoring einzurichten – entweder ist der Kauf neuer Hardware teuer, oder man muss nach gebrauchter Hardware suchen. Zudem gibt es in kleinen Unternehmen häufig Probleme mit Servern und Hardware.

Die Verwendung des Buildroot-Bausystems ermöglicht die Erstellung spezialisierter Lösungen, die von Mitarbeitern mit minimalen Kenntnissen im Linux-Betriebssystem genutzt werden können. Dieses System ist anfängerfreundlich, bietet jedoch gleichzeitig umfangreiche Anpassungsmöglichkeiten für erfahrene Entwickler. Es eignet sich hervorragend zur Lösung der Herausforderung, ein kostengünstiges, aber voll funktionsfähiges Monitoring der IT-Infrastruktur bereitzustellen, das minimale Anforderungen an das geschulte Personal stellt.

Lösungsansätze

Es wurde zunächst beschlossen, ein Firmware-Image für x86_64 zu erstellen, um es in QEMU auszuführen, da dies eine bequeme und schnelle Lösung für das Debugging ist. Danach soll es auf einen Einplatinencomputer mit ARM-Architektur portiert werden (ich mag das Asus Tinker Board).

Für das Build-System wurde Buildroot ausgewählt. Ursprünglich fehlte das Zabbix-Paket, weshalb es portiert werden musste. Es gab Probleme mit der russischen Lokalisierung, die durch das Aufbringen der entsprechenden Patches gelöst wurden (Hinweis: In neueren Versionen von Buildroot sind diese Patches nicht mehr erforderlich).

Die Portierung des Zabbix-Pakets wird in einem separaten Artikel beschrieben.

Da alles wie eine Firmware funktionieren soll (unveränderliches System-Image + wiederherstellbare Konfigurationsdateien/Datenbanken), war es notwendig, eigene systemd-Ziele, Dienste und Timer zu schreiben (target, service, timer).

Es wurde beschlossen, das Medium in 2 Partitionen zu unterteilen – eine Partition für die Systemdateien und eine Partition für die veränderlichen Konfigurationen und Dateien der Zabbix-Datenbank.

Die Lösung der Aufgaben im Zusammenhang mit der Datenbank war etwas komplexer. Es war nicht wünschenswert, sie direkt auf dem Speichermedium zu platzieren. Gleichzeitig kann die Größe der Datenbank das Volumen eines möglichen RAM-Disks überschreiten. Daher wurde eine Kompromisslösung gewählt: Die Datenbank wird auf der zweiten Partition der SD-Karte platziert (moderne SLC-Karten haben bis zu 30.000 Schreibzyklen), es besteht jedoch die Möglichkeit, ein externes Medium (zum Beispiel ein USB-HDD) zu verwenden.

Die Temperaturüberwachung wurde über das Gerät RODOS-5 realisiert. Natürlich könnte man auch direkt einen Dallas 1820 verwenden, aber es war schneller und einfacher, USB anzuschließen.

Als Bootloader für x86_64 wurde grub2 gewählt. Es war notwendig, eine minimale Konfiguration für den Start zu erstellen.

Nach den Tests unter QEMU wurde die Portierung auf das ASUS Tinker Board durchgeführt. In der Struktur meines Overlays war von Anfang an die Plattformunabhängigkeit eingeplant – die Bereitstellung spezifischer Konfigurationen für jede Platine (Defconfig der Platine, Bootloader, Erstellung eines Abbilds mit Systempartition) und maximale Vereinheitlichung bei der Feinabstimmung des Dateisystems/Erstellung eines Abbilds mit Daten. Aufgrund dieser Vorbereitung verlief die Portierung zügig.

Es wird dringend empfohlen, die Einführungsthemen zu lesen:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Wie man zusammenstellt

Das Projekt wird auf github gespeichert
Nach dem Klonen des Repositories ergibt sich folgende Verzeichnisstruktur:

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

buildroot-2019.05.tar.gz – Archiv des reinen Buildroots
overlay – mein Verzeichnis mit external-tree. Hier wird alles gespeichert, was benötigt wird, um das Firmware-Image mit Buildroot zu erstellen
README.md – Projekterklärung und Anleitung in Englisch.
run_me.sh – Skript zur Vorbereitung des Build-Systems. Entpackt Buildroot aus dem Archiv, fügt overlay (über den external-tree-Mechanismus) hinzu und ermöglicht die Auswahl der Zielplatine für den Build.

[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Wählen Sie defconfig, drücken Sie A zum Abbrechen. Standard [0]

Danach genügt es, in das Verzeichnis buildroot-2019.05 zu wechseln und den Befehl make auszuführen.
Nach Abschluss des Builds befinden sich alle Ergebnisse im Verzeichnis 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

Benötigte Dateien:

• sdcard.img – Abbild des Mediums zur Aufnahme auf die SD-Karte (über dd oder rufus unter Windows).
• qemu.qcow2 – Abbild des Mediums zum Starten in QEMU.
• external.qcow2 – Abbild des external-Mediums für die Datenbank.
• monitor-0.9-beta.tar.gz — Archiv für das Update über die Web-Oberfläche

Erstellung von Anleitungen

Es lohnt sich nicht, dieselbe Anleitung mehrfach zu schreiben. Es ist sinnvoller, sie einmal in Markdown zu verfassen und dann in PDF für den Download und HTML für die Web-Oberfläche zu konvertieren. Dies ist dank des Pakets pandoc möglich.

Darüber hinaus müssen all diese Dateien erstellt werden, bevor das System-Image erstellt wird; die post-build-Skripte sind dann nutzlos. Daher erfolgt die Generierung in Form eines Pakets namens manuals. Das kann im overlay/package/manuals eingesehen werden.

Die Datei manuals.mk (die die gesamte Arbeit erledigt)

################################################################################
#
# 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

Die Linux-Welt wechselt aktiv zu systemd, also musste ich das auch tun.
Eine angenehme Neuerung ist die Einführung von Timern. Über sie (und nicht nur über sie) wird in einem separaten Artikel geschrieben, aber ich möchte kurz darauf eingehen.

Es gibt Aktionen, die regelmäßig ausgeführt werden müssen. Ich musste logrotate zur Bereinigung von Protokollen in lighttpd und php-fpm starten. Am gewohnlichsten wäre es gewesen, die Befehle in cron zu schreiben, aber ich habe mich entschieden, den systemd-Monotimer zu verwenden. So wird logrotate in festen Zeitintervallen gestartet.

Natürlich besteht die Möglichkeit, Timer zu erstellen, die an bestimmten Daten auslösen, aber das benötigte ich nicht.
Beispiel für einen Timer:

• Timer-Datei

  
  [Unit]
  Description=RODOS Temp-Daemon-Timer

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target

- Dienstdatei, die vom Timer aufgerufen wird:
```bash
[Unit]
Description=RODOS Temp-Daemon

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

Unterstützte Boards

Asus Tinker Board — das Hauptboard, auf dem alles funktionieren sollte. Es wurde als kostengünstig und leistungsstark ausgewählt.

Beaglebone Black — das erste Board, auf dem die Funktionalität getestet wurde (während der Suche nach einem leistungsstärkeren Board).

Qemu x86_64 — wird für Entwicklungs- und Debugging-Zwecke verwendet.

Wie es funktioniert

Bei der Starts erfolgt eine zweistufige Wiederherstellung der Einstellungen:

• Start des Skripts settings_restore (über den Dienst). Es stellt die grundlegenden Systemeinstellungen wieder her — Zeitzone, Locale, Netzwerkeinstellungen usw.
• Start des Skripts prepare (über den Dienst) — hier wird Zabbix vorbereitet, die Datenbank eingerichtet und die IP wird in der Konsole ausgegeben.

Beim ersten Start wird die Größe der zweiten Partition der SD-Karte bestimmt. Falls noch unpartitionierter Speicherplatz vorhanden ist, wird das Medium neu partitioniert, und die Datenpartition nimmt den gesamten freien Speicherplatz ein. Dies geschieht, um die Größe des Installationsabbilds (sdcard.img) zu reduzieren. Darüber hinaus wird in diesem Moment das Arbeitsverzeichnis für PostgreSQL erstellt. Aus diesem Grund dauert der erste Start mit einem neuen Medium länger als die nachfolgenden.

Beim Anschluss einer externen Festplatte wird beim Start nach einem freien Laufwerk gesucht und dieses in ext4 mit dem Label 'external' formatiert.

Achtung! Beim Anschluss einer externen Festplatte (sowie beim Trennen oder Ersetzen) müssen Sie ein Backup erstellen und die Einstellungen wiederherstellen!

Zur Temperaturoberwachung wird das Gerät RODOS 5 verwendet. Der Hersteller stellt die Quellcodes seines Dienstprogramms zur Verfügung, um mit dem Gerät zu arbeiten. Bei Systemstart wird ein Timer für RODOS aktiviert, der diese Anwendung einmal pro Minute startet. Die aktuelle Temperatur wird in die Datei /tmp/rodos_current_temp geschrieben, sodass Zabbix diese Datei als Sensor überwachen kann.

Das Medium für die Speicherung der Konfiguration wird im Verzeichnis /data eingehängt.

Beim Start des Systems und der Vorbereitung zur Nutzung erscheint folgende Meldung in der Konsole:

System startet, bitte warten

Nach Abschluss der Vorbereitungen wechselt die Meldung zu der IP-Adresse:

aktuelle IP 192.168.1.32
Bereit zur Nutzung

Einrichten von Zabbix zur Temperaturüberwachung

Für die Temperaturüberwachung sind nur 2 Schritte erforderlich:

• das Gerät RODOS an den USB-Anschluss anschließen
• Ein Data Item in Zabbix erstellen

Öffnen Sie die Weboberfläche von Zabbix:

• Gehen Sie zu den Einstellungen → Hosts
• Klicken Sie auf Items in der Zeile unseres Zabbix-Servers
• Klicken Sie auf 'Item erstellen'

Geben Sie die folgenden Daten ein:

• Name — nach Ihrem Ermessen (z.B. serverRoomTemp)
• Typ — Zabbix-Agent
• Schlüssel — rodos
• Typ — numerisch
• Einheiten — °C
• Historischer Speicherzeitraum — Zeitraum für die Speicherung der Historie. Ich habe 10 Tage eingestellt
• Trend-Speicherzeitraum — Zeitraum für die Speicherung der Trends. Ich habe 30 Tage eingestellt
• Neue Anwendung — Serverraumtemperatur

Und klicken Sie auf die Schaltfläche HINZUFÜGEN.

Verwaltung der Einstellungen über die Weboberfläche

Die Weboberfläche ist in PHP geschrieben. Es gibt grundlegende Funktionen:

• Überwachung des Gerätestatus
• Änderung der Netzwerkeinstellungen
  
• Änderung des Benutzepassworts
• Auswahl der Zeitzone
• Backup/Wiederherstellung/Zurücksetzen auf die Werkseinstellungen
• Möglichkeit, eine externe Festplatte anzuschließen
• Systemaktualisierung
  

Der Zugang zur Weboberfläche ist passwortgeschützt. Die Startseite ist eine Anleitung.

Adresse der Zabbix-Oberfläche: ${ip/dns}/zabbix
Adresse der Verwaltungsoberfläche: ${ip/dns}/manage

Starten in 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

Dieser Befehl startet das System mit 4 Kernen, 2048 RAM, aktiviertem KVM, einer Netzwerkkarte im Bridge-Modus bridge0 und zwei Festplatten: eine für das System und eine externe für PostgreSQL.

Die Images können auch in VirtualBox konvertiert und gestartet werden:

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

Anschließend importieren Sie sie in VirtualBox und verbinden Sie sie über SATA.

Fazit

Ich hatte während des Prozesses das Interesse, ein einsatzbereites Produkt zu schaffen – mit einer nicht sehr ansprechenden Benutzeroberfläche (ich mag es nicht, sie zu erstellen), aber funktional und einfach zu konfigurieren.

Mein letzter Versuch, die Zabbix-Appliance in KVM zu installieren, bestätigte diesen Schritt (nach dem Abschluss der Installation startet das System nicht). Möglicherweise mache ich etwas falsch 😉

Materialien

https://buildroot.org/

Quelle: habr.com