Buildroot: Plattformübergreifende Firmware mit zabbix-server erstellen


Aufgabenverlauf


Kleine 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 Geräte zu kaufen. Oft gibt es auch Probleme mit dem Server / der Hardware: Oft gibt es 1-3 Tower-Server neben Benutzerarbeitsplätzen oder in einer kleinen Nische / einem kleinen Schrank.


Es ist einfacher, eine fertige Baugruppe (Distribution) zu verwenden, die ausreicht, um sie auf eine microSD-Karte hochzuladen und in einen gewöhnlichen Einplatinencomputer (Beaglebone, Himbeer-Pi und Orange-Pi, Asus-Bastelkartenfamilien) einzulegen. Darüber hinaus ist eine solche Ausrüstung kostengünstig und kann überall installiert werden.


Erklärung des Problems


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


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


Bei der Hardware-Plattform stellte sich die Frage scharf: Es ist auch keine gute Lösung, eine separate Maschine zu überwachen - entweder ist es teuer, neue Geräte zu kaufen, oder in kleinen Unternehmen gibt es häufig Probleme mit dem Server / der Hardware.


Mit dem Buildroot-Build-System können Sie spezielle Lösungen erstellen, die von Mitarbeitern mit minimalen Kenntnissen der Linux-Betriebssystemfamilie bedient werden können. Dieses System ist für Anfänger freundlich, bietet aber gleichzeitig zahlreiche Möglichkeiten zur Anpassung in den Händen eines erfahrenen Entwicklers. Es ist perfekt für die Lösung der Aufgabe der nicht teuren, aber umfassenden Überwachung der IT-Infrastruktur, die bei der Schulung des Betriebspersonals nur minimale Anforderungen stellt.


Lösungsschritte


Es wurde beschlossen, zunächst eine Firmware für x86_64 zu erstellen, die in qemu ausgeführt werden soll, da dies eine praktische und schnelle Lösung für das Debuggen ist. Anschliessend an einen Single-Board-Computer anschließen (mir gefiel das Asus Tinker Board).


Als Build-System wurde die Build-Root ausgewählt. Anfangs fehlte das zabbix-Paket, daher musste ich es portieren. Es gab Probleme mit dem russischen Gebietsschema, die durch Anwenden der entsprechenden Patches behoben wurden (Hinweis: In neueren Versionen von Buildroot werden diese Patches nicht mehr benötigt).


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


Da alles als Firmware funktionieren sollte (unverändertes System-Image + wiederherstellbare Konfigurations- / Datenbankdateien), war es erforderlich, Ihre Systemziele, Dienste und Zeitgeber (Ziel, Dienst, Zeitgeber) zu schreiben.


Es wurde beschlossen, die Medien in zwei Abschnitte zu unterteilen - einen Abschnitt mit Systemdateien und einen Abschnitt mit veränderlichen Konfigurations- und Zabbix-Datenbankdateien.


Es stellte sich als etwas schwieriger heraus, die mit der Datenbank verbundenen Probleme zu lösen. Ich wollte es nicht direkt in den Medien platzieren. Gleichzeitig kann die Größe der Basis eine Größe erreichen, die die Größe einer möglichen Ramdisk überschreitet. Daher wurde eine Kompromisslösung gewählt: Die Datenbank befindet sich im zweiten Abschnitt der SD-Karte (moderne SLC-Karten haben bis zu 30.000 Schreibzyklen), es gibt jedoch eine Einstellung, mit der Sie externe Medien verwenden können (z. B. USB-Festplatte).


Die Temperaturüberwachung wurde über das RODOS-5-Gerät implementiert. Natürlich können Sie den Dallas 1820 direkt verwenden, aber es war schneller und einfacher, einen USB-Stick anzuschließen.


Als Bootloader für x86_64 wurde Grub2 ausgewählt. Ich habe eine minimale Konfiguration geschrieben, um sie auszuführen.


Nach dem Debuggen auf qemu wurde eine Portierung auf das Asus Tinker Board durchgeführt. In der Struktur meines Overlays war anfangs Cross-Platforming vorgesehen - Hervorhebung der für jede Karte spezifischen Konfigurationen (defconfig-Karten, Bootloader, Image-Generierung mit einer Systempartition) und maximale Einheitlichkeit bei der Abstimmung des Dateisystems / Erstellung eines Images mit Daten. Aufgrund dieser Vorbereitung war die Portierung schnell.


Es wird dringend empfohlen, die einleitenden Artikel zu lesen:
https://habr.com/de/post/448638/
https://habr.com/de/post/449348/


Wie man zusammenbaut


Das Projekt wird auf Github gespeichert
Nach dem Klonen des Repositorys wird die folgende Dateistruktur erhalten:


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

buildroot-2019.05.tar.gz - Archiv sauberer Buildroot
overlay ist mein verzeichnis mit external-tree. Es enthält alles, was Sie zum Erstellen der Firmware mit buildroot benötigen
README.md - Projektbeschreibung und Anleitung in Englisch.
run_me.sh ist ein Skript, das das Build-System vorbereitet. Erweitert Buildroot aus dem Archiv, fügt Overlay hinzu (über den External-Tree-Mechanismus) und ermöglicht die Auswahl der Zielplatine für den Zusammenbau


 [0] my_asus_tinker_defconfig [1] my_beaglebone_defconfig [2] x86_64_defconfig Select defconfig, press A for abort. Default [0] 

Wechseln Sie anschließend in das Verzeichnis buildroot-2019.05 und führen Sie den Befehl make aus.
Nach Abschluss der Assembly befinden sich alle Assemblyergebnisse 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 

Dateien benötigt:


  • sdcard.img - das Image des Mediums zum Schreiben auf die SD-Karte (über dd oder Rufus unter Wibdows).
  • qemu.qcow2 - Medienimage, das in qemu ausgeführt werden soll.
  • external.qcow2 - externes Medienbild für die Datenbank
  • monitor-0.9-beta.tar.gz - Archiv zur Aktualisierung über das Webinterface

Manuelle Generierung


Es lohnt sich nicht, die gleichen Anweisungen mehrmals zu schreiben. Und es ist am logischsten, einmal im Markdown zu schreiben und dann in PDF zum Herunterladen und in HTML für das Webinterface zu konvertieren. Dies ist dank des Pandoc-Pakets möglich.


Sie müssen jedoch alle diese Dateien generieren, bevor das System-Image zusammengestellt wird. Diese Postbuild-Skripts sind bereits unbrauchbar. Daher erfolgt die Generierung in Form des Manual-Pakets. Sie können es in Overlay / Paket / Handbüchern sehen.


Die manuals.mk-Datei (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 Welt von Linux bewegt sich aktiv zu systemd, und ich musste es auch tun.
Von den schönen Neuerungen - die Anwesenheit von Timern. Im Allgemeinen wird ein separater Artikel über sie (und nicht nur über sie) geschrieben, aber ich werde es Ihnen kurz erzählen.


Es gibt Aktionen, die regelmäßig durchgeführt werden müssen. Ich musste logrotate ausführen, um die Protokolle lighttpd und php-fpm zu löschen. Am häufigsten werden Befehle in Cron geschrieben, aber ich habe mich für den monotonen systemd-Timer entschieden. Daher beginnt die Logrotation in einem strengen Zeitintervall.


Natürlich gibt es die Möglichkeit, Timer zu erstellen, die an bestimmten Daten funktionieren, aber ich habe es nicht benötigt.
Beispiel Timer:


  • Timer-Datei
     [Unit] Description=RODOS temp daemon timer 

[Timer]
OnBootSec = 1min
OnUnitActiveSec = 1min


[Installieren]
WantedBy = timers.target


 -  ,  : ```bash [Unit] Description=RODOS temp daemon [Service] ExecStart=/usr/bin/rodos.sh 

Unterstützte Boards


Asus Bastelbrett - das Hauptbrett, auf dem alles funktionieren soll. Ausgewählt als preiswert und sehr leistungsfähig.


Beaglebone Black ist das erste Board, auf dem die Arbeit getestet wurde (bei der Auswahl eines leistungsstärkeren Boards).


Qemu x86_64 - dient zur Entwicklung von Debugging.


Wie funktioniert das?


Beim Start erfolgt eine zweistufige Wiederherstellung der Einstellungen:


  • Ausführen des settings_restore-Skripts (über den Dienst). Es stellt die grundlegenden Systemeinstellungen wieder her - Zeitzone, Gebietsschema, Netzwerkeinstellungen usw.
  • Ausführen des Vorbereitungsskripts (über den Dienst) - hier wird zabbix vorbereitet, die Datenbank und die IP-Adresse werden in der Konsole angezeigt.

Beim ersten Start wird die Größe des zweiten Abschnitts der SD-Karte bestimmt. Wenn noch nicht zugewiesener Speicherplatz vorhanden ist - der Datenträger wird neu partitioniert, der Datenabschnitt belegt den gesamten freien Speicherplatz. Dies geschieht, um das Installationsimage (sdcard.img) zu verkleinern. Außerdem wird zu diesem Zeitpunkt das postgresql-Arbeitsverzeichnis erstellt. Deshalb wird der erste Start mit einem neuen Medium länger dauern als die folgenden.


Wenn Sie ein externes Laufwerk anschließen, sucht es beim Start nach einem freien Laufwerk und formatiert es in ext4 mit der externen Bezeichnung.


Achtung! Wenn Sie ein externes Laufwerk anschließen (sowie es trennen oder austauschen), müssen Sie die Einstellungen sichern und wiederherstellen!


Zur Überwachung der Temperatur wird das Gerät RODOS 5 verwendet, dessen Verwendungszweck vom Hersteller angegeben wird. Wenn das System eingeschaltet wird, startet der Rodos-Timer, der dieses Dienstprogramm einmal pro Minute startet. Die aktuelle Temperatur wird in die Datei / tmp / rodos_current_temp geschrieben. Danach kann zabbix diese Datei als Sensor überwachen.


Das Speichermedium für die Konfiguration ist im Verzeichnis / data gemountet.


Wenn Sie das System starten und für die Arbeit vorbereiten, wird in der Konsole eine Meldung angezeigt:


 System starting, please wait 

Nach Abschluss der Vorbereitungsarbeiten wird die IP-Adresse angezeigt:


 current ip 192.168.1.32 Ready to work 

Zabbix für die Temperaturüberwachung konfigurieren


Um die Temperatur zu überwachen, gehen Sie einfach in zwei Schritten vor:


  • Verbinden Sie das RODOS-Gerät mit dem USB-Anschluss
  • Datenelement in zabbix erstellen

Öffnen Sie die zabbix-Weboberfläche:


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


Geben Sie folgende Daten ein:


  • Name - nach eigenem Ermessen (z. B. serverRoomTemp)
  • Geben Sie - zabbix agent ein
  • Key - Rodos
  • Typ- numerisch
  • Einheiten - C
  • Verlaufsspeicherdauer - die Laufzeit des Verlaufs. Noch 10 Tage
  • Trendspeicherzeitraum - Zeitraum der Speicherung der Dynamik von Änderungen. Noch 30 Tage
  • Neue Anwendung - Server Raumtemp

Und drücken Sie die ADD-Taste.


Web Based Management


Das Webinterface ist in PHP geschrieben. Es gibt Hauptfunktionen:


  • Gerätestatus anzeigen
  • Netzwerkeinstellungen ändern
  • Benutzerpasswort ändern
  • Zeitzonenauswahl
  • Sichern / Wiederherstellen / Zurücksetzen auf Werkseinstellungen
  • die Fähigkeit, ein externes Laufwerk anzuschließen
  • Systemaktualisierung

Die Anmeldung an der Weboberfläche ist passwortgeschützt. Startseite - Handbuch.


Zabbix-Schnittstellenadresse: \ $ {ip / dns} / zabbix
Adresse der Verwaltungsschnittstelle: \ $ {ip / dns} / manage


Führen Sie in Qemu


qemu-system-x86_64 -smp 4 -m 4026M -enable-kvm -machine q35, accel = kvm-service 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 ein System mit 4 Kernen, 2048 RAM, die von KVM aktiviert wurden, einer Netzwerkkarte auf bridge0 und zwei Festplatten: für das System und extern für postgresql.


Images können konvertiert und in Virtualbox ausgeführt werden:


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

Dann importiere sie in die virtualbox und verbinde dich über sata.


Fazit


Dabei war ich daran interessiert, ein Produkt einsatzbereit zu machen - mit einer nicht sehr schönen Oberfläche (ich schreibe sie nicht gern), aber funktionierend und einfach zu konfigurieren.


Der letzte Versuch, die zabbix-Appliance in KVM zu installieren, hat die Richtigkeit dieses Schritts gezeigt (das System startet nicht, nachdem die Installation abgeschlossen ist). Vielleicht mache ich was falsch;)




Material


https://buildroot.org/

Source: https://habr.com/ru/post/de477008/


All Articles