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

Aufgabenhistorie

Kleinere Unternehmen benötigen einerseits eine qualitativ hochwertige Überwachung ihrer Infrastruktur (insbesondere angesichts der weit verbreiteten Virtualisierung), andererseits ist es für sie finanziell schwierig, neue Hardware zu erwerben. Auch treten häufig Probleme mit Server-/Hardware auf: Oft stehen 1-3 Tower-Server neben den Arbeitsplätzen der Benutzer oder in einer kleinen Nische.

Es ist einfacher, ein bereits fertiges Build (Distribution) zu verwenden, das einfach auf eine microSD-Karte geladen und in einen gängigen Einplatinencomputer (Beaglebone, Raspberry Pi- und Orange Pi-Familie, Asus Tinker Board) eingesetzt werden kann. Zudem ist diese Hardware kostengünstig und kann überall installiert werden.

Aufgabenstellung

In vielerlei Hinsicht entwickelte sich das Projekt wie eine Art Laborarbeit mit der Möglichkeit, die Ergebnisse anzuwenden.

Als Überwachungssystem wurde Zabbix gewählt, da es ein leistungsstarkes, kostenloses und gut dokumentiertes System ist.

Die Frage nach der Hardwareplattform wurde dringend. Eine separate Maschine zur Überwachung einzurichten, ist ebenfalls keine besonders gute Lösung – entweder ist es teuer, neue Hardware zu beschaffen, oder man muss nach alter suchen + in kleinen Firmen gibt es häufig Probleme mit Server-/Hardware.

Die Verwendung des Buildroot-Bausystems ermöglicht die Erstellung spezialisierter Lösungen, die von Personal mit minimalen Kenntnissen der Linux-Betriebssystemfamilie verwendet werden können. Dieses System ist anfängerfreundlich, bietet jedoch umfangreiche Anpassungsmöglichkeiten in den Händen eines erfahrenen Entwicklers. Es eignet sich hervorragend für die Lösung der Aufgabe einer kostengünstigen, aber voll funktionsfähigen Überwachung der IT-Infrastruktur, die minimale Anforderungen an die Schulung des betreuenden Personals stellt.

Lösungsansätze

Es wurde beschlossen, zunächst eine Firmware für x86_64 zu erstellen, um sie in QEMU auszuführen, da dies eine bequeme und schnelle Lösung für das Debugging ist. Danach wurde die Portierung auf einen ARM-Einplatinencomputer durchgeführt (ich mochte das Asus Tinker Board).

Als Buildsystem wurde Buildroot gewählt. Zunächst war das Zabbix-Paket darin nicht enthalten, daher musste es portiert werden. Es gab Probleme mit der russischen Lokalisierung, die durch die Anwendung entsprechender Patches gelöst wurden (Anmerkung: 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 sollte (unveränderliches Systemabbild + wiederherstellbare Konfigurations-/Datenbankdateien), war es notwendig, eigene systemd-Ziele, Dienste und Timer zu schreiben (Target, Service, Timer).

Es wurde beschlossen, das Medium in zwei Partitionen zu unterteilen – eine Partition für die Systemdateien und eine Partition für die veränderlichen Konfigurationen und Datenbankdateien von Zabbix.

Die Lösung der Probleme, die mit der Datenbank verbunden sind, erwies sich als etwas komplizierter. Es war nicht besonders wünschenswert, sie direkt auf dem Medium zu platzieren. Gleichzeitig kann die Datenbankgröße die Größe des möglichen RAM-Disk übersteigen. 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), aber es gibt eine Einstellung, die die Verwendung eines externen Mediums (zum Beispiel USB-HDD) ermöglicht.

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

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

Nach der Fehlersuche mit qemu wurde die Portierung auf das Asus Tinker Board durchgeführt. In der Struktur meines Overlays wurde von Anfang an die Plattformunabhängigkeit berücksichtigt – spezifische Konfigurationen für jede Platine (defconfig der Platine, Bootloader, Generierung des Abbildes mit dem Systembereich) und maximale Einheitlichkeit bei der Feineinstellung des Dateisystems/Erstellung des Abbildes mit Daten wurden festgelegt. Aufgrund dieser Vorbereitung verlief die Portierung schnell.

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

Wie man es 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 Buildroot
overlay — mein Verzeichnis mit dem External-Tree. Dort befindet sich alles, was benötigt wird, um die Firmware mit Hilfe von Buildroot zusammenzustellen.
README.md — Projektbeschreibung und Anleitung auf Englisch.
run_me.sh — Skript zur Vorbereitung des Build-Systems. Entpackt Buildroot aus dem Archiv, verbindet es mit dem Overlay (über den External-Tree-Mechanismus) und ermöglicht die Auswahl des Zielboards 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. Standardmäßig [0]

Nach diesem Schritt reicht es aus, in das Verzeichnis buildroot-2019.05 zu wechseln und den Befehl make auszuführen.
Nach Abschluss des Builds befinden sich alle Build-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 — ein Abbild des Datenträgers zum Schreiben auf die SD-Karte (über dd oder rufus unter Windows).
• qemu.qcow2 — ein Abbild des Datenträgers zum Starten in qemu.
• external.qcow2 — Abbild des External-Datenträgers für die Datenbank
• monitor-0.9-beta.tar.gz — Archiv für das Update über die Web-Oberfläche

Generierung der Manuals

Es ist nicht sinnvoll, dieselbe Anleitung mehrmals zu schreiben. Am logischsten ist es, sie einmal im Markdown zu schreiben und anschließend in PDF zum Herunterladen und HTML für die Web-Oberfläche zu konvertieren. Dies ist dank des Pakets pandoc möglich.

Außerdem müssen all diese Dateien generiert werden, bevor das System-Image erstellt wird, da die post-build Skripten dann nutzlos sind. Daher erfolgt die Generierung als Paket manuals. Man kann es in overlay/package/manuals einsehen.

Die Datei manuals.mk (die die ganze 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, ich musste das auch tun.
Eine der erfreulichen Neuerungen ist das Vorhandensein von Timern. Über sie (und nicht nur darüber) wird ein separater Artikel geschrieben, aber ich werde kurz erzählen.

Es gibt Aktionen, die regelmäßig ausgeführt werden müssen. Ich musste logrotate starten, um die Protokolle von lighttpd und php-fpm zu reinigen. Es wäre am vertrautesten gewesen, die Befehle in cron zu schreiben, aber ich entschied mich, den monotonen systemd-Timer zu verwenden. Auf diese Weise wird logrotate in einem strengen Zeitintervall gestartet.

Natürlich gibt es die Möglichkeit, Timer zu erstellen, die an bestimmten Tagen ausgelöst werden, aber das benötigte ich nicht.
Beispiel eines Timers:

• Timer-Datei

  
  [Unit]
  Description=RODOS temp daemon timer

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target

- Die Dienstdatei, die durch den Timer aufgerufen wird:
```bash
[Unit]
Description=RODOS temp daemon

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

Unterstützte Platinen

Asus Tinker Board — die Hauptplatine, auf der alles funktionieren sollte. Ausgewählt als kostengünstige und leistungsstarke Option.

Beaglebone Black — die erste Platine, auf der die Funktion getestet wurde (während der Suche nach einer leistungsstärkeren Platine).

Qemu x86_64 — wird für Entwicklungsdebugging verwendet.

Wie es funktioniert

Bei Start erfolgt eine zweistufige Wiederherstellung der Einstellungen:

• Ausführen des Skripts settings_restore (über den Dienst). Es stellt die grundlegenden Systemeinstellungen wieder her — Zeitzone, Gebietsschema, Netzwerkeinstellungen usw.
• Start des Skripts prepare (über den Service) – hier wird Zabbix vorbereitet, eine Datenbank eingerichtet und die IP 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 Partition für Daten beansprucht den gesamten freien Platz. Dies geschieht, um die Größe des Installationsabbilds (sdcard.img) zu reduzieren. Zudem wird in diesem Moment das Arbeitsverzeichnis für PostgreSQL erstellt. Aus diesem Grund wird der erste Start mit einem neuen Medium länger dauern als die nachfolgenden.

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

Achtung! Beim Anschließen (sowie beim Trennen oder Ersetzen) einer externen Festplatte ist es notwendig, ein Backup zu erstellen und die Einstellungen wiederherzustellen!

Zur Temperaturüberwachung wird das Gerät RODOS 5 verwendet. Der Hersteller stellt die Quellcodes seines Tools zur Verfügung, um mit dem Gerät zu arbeiten. Bei Systemstart wird der Timer rodos aktiviert, der dieses Tool einmal pro Minute startet. Die aktuelle Temperatur wird in die Datei /tmp/rodos_current_temp geschrieben, nach der Zabbix diese Datei als Sensor überwachen kann.

Das Speichermedium für die Konfiguration wird im Verzeichnis /data eingebunden.

Beim Start des Systems und der Vorbereitung zu seiner Arbeit erscheint in der Konsole die Nachricht:

System startet, bitte warten

Nach Abschluss der Vorbereitungsarbeiten wird dies durch die Ausgabe der IP-Adresse ersetzt:

aktuelle ip 192.168.1.32
Bereit zum Arbeiten

Konfiguration von Zabbix zur Temperaturüberwachung

Um die Temperatur zu überwachen, sind lediglich 2 Schritte notwendig:

• das Gerät RODOS an den USB-Port anschließen
• ein Datenelement in Zabbix erstellen

Öffnen Sie die Weboberfläche von Zabbix:

• Öffnen Sie den Bereich Konfiguration → Hosts
• Klicken Sie auf Items in der Zeile unseres Zabbix-Servers
• Klicken Sie auf Element erstellen

Geben Sie die folgenden Daten ein:

• name – nach Ihrem Ermessen (z.B. serverRoomTemp)
• Typ – Zabbix-Agent
• Schlüssel – rodos
• Typ – numerisch
• Einheiten – C
• Historienaufbewahrungszeit – Zeitraum zur Aufbewahrung der Historie. Habe 10 Tage eingestellt.
• Trendaufbewahrungszeit – Zeitraum zur Speicherung von Trendänderungen. Habe 30 Tage eingestellt.
• Neue Anwendung – server Room Temp

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 die Hauptfunktionen:

• Überwachung des Gerätezustands
• Änderung der Netzwerkeinstellungen
  
• Änderung des Benutzerpassworts
• Auswahl der Zeitzone
• Backup/Wiederherstellung/Zurücksetzen auf die Werkseinstellungen
• Möglichkeit zum Anschließen einer externen Festplatte
• Systemaktualisierung
  

Der Zugang zur Weboberfläche ist durch ein Passwort geschützt. Die Startseite ist eine Anleitung.

Die Adresse der zabbix-Oberfläche: ${ip/dns}/zabbix
Die 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 am Bridge bridge0 und zwei Laufwerken: eines für das System und eines extern für PostgreSQL.

Images können konvertiert und in Virtualbox gestartet werden:

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

Danach importieren Sie sie in Virtualbox und verbinden sie über SATA.

Fazit

Dabei wurde ich neugierig, ein einsatzbereites Produkt zu erstellen – mit einer nicht besonders schönen Oberfläche (ich mag es nicht, sie zu schreiben), aber funktionsfähig und einfach einzurichten.

Der letzte Versuch, die zabbix-appliance in KVM zu installieren, hat die Richtigkeit dieses Schrittes gezeigt (nach Abschluss der Installation startet das System nicht). Möglicherweise mache ich etwas falsch 😉

Materialien

https://buildroot.org/

Quelle: habr.com