ProHoster > Blog > Beheer > Buildroot: Het creƫren van cross-platform firmware met zabbix-server

Buildroot: Het creƫren van cross-platform firmware met zabbix-server

Buildroot: Het creƫren van cross-platform firmware met zabbix-server

Taakgeschiedenis

Kleinere bedrijven hebben aan de ene kant behoefte aan kwalitatieve monitoring van hun infrastructuur (vooral in het licht van de alomtegenwoordige virtualisatie), terwijl het aan de andere kant financieel zwaar voor hen is om nieuwe apparatuur aan te schaffen. Ook komen vaak problemen voor met servers/hardware: vaak staan er 1-3 tower-servers naast de werkplekken van gebruikers of in een kleine niche/hoek.

Het is eenvoudiger om een kant-en-klare distributie te gebruiken, die eenvoudig op een microSD-kaart kan worden gezet en in een veelgebruikte single-board computer (beaglebone, raspberry pi en orange pi-families, asus tinker board) kan worden geplaatst. Bovendien is deze apparatuur goedkoop en kan deze overal worden geĆÆnstalleerd.

Taakstelling

In veel opzichten ontwikkelde het project zich als een soort laboratoriumwerk met de mogelijkheid om de resultaten toe te passen.

Als monitoringsysteem is zabbix gekozen, omdat dit een krachtig, gratis en goed gedocumenteerd systeem is.

De vraag naar de hardwareplatformen deed zich scherp voor. Het installeren van een aparte machine voor monitoring is ook niet echt een goede oplossing ā€” of het is te duur om nieuwe apparatuur aan te schaffen, of je moet op zoek naar oude apparatuur + kleine bedrijven hebben vaak problemen met servers/hardware.

Het gebruik van het buildroot build-systeem maakt het mogelijk om gespecialiseerde oplossingen te creƫren die door personeel met minimale kennis van Linux-achtige besturingssystemen kunnen worden geƫxploiteerd. Dit systeem is gebruiksvriendelijk voor beginners, maar biedt tegelijkertijd brede mogelijkheden voor maatwerk in handen van een ervaren ontwikkelaar. Het is uitstekend geschikt voor de taak van goedkope, maar volledig functionele monitoring van IT-infrastructuur, waarbij minimale voorbereiding van het personeel dat het gebruikt vereist is.

Oplossingsstappen

Het werd aanvankelijk besloten om een firmware voor x86_64 te creƫren voor uitvoering in qemu, aangezien dit een handige en snelle oplossing is voor debugging. Daarna werd het geport naar een single-board computer arm (ik vond de asus tinker board leuk).

Als buildsysteem is buildroot gekozen. In eerste instantie ontbrak het zabbix-pakket hierin, dus het moest worden geporteerd. Er waren problemen met de Russische locale, die werden opgelost door de bijbehorende patches toe te passen (opmerking: in nieuwere versies van buildroot zijn deze patches niet meer nodig).

De portering van het zabbix-pakket zelf wordt in een apart artikel beschreven.

Aangezien alles als firmware (onveranderbaar systeembestand + herstelde configuratie/bestanden van de database) moet werken, was het nodig om eigen systemd-doelen, services en timers te schrijven (target, service, timer).

Er werd besloten om het medium op te splitsen in 2 partities - een partitie met systeembestanden en een partitie met wijzigbare configuraties en bestanden van de zabbix-database.

De oplossingen voor de database bleken wat gecompliceerder. Het plaatsen van de database direct op het medium wilde ik niet. Tegelijkertijd kan de grootte van de database de grootte van de mogelijke ramdisk overschrijden. Daarom werd er voor een compromisoplossing gekozen: de database wordt op de tweede partitie van de SD-kaart geplaatst (moderne SLC-kaarten hebben tot 30.000 schrijfcycli), maar er is een instelling die het mogelijk maakt om een extern medium (bijvoorbeeld een usb-hdd) te gebruiken.

Temperatuurmonitoring werd gerealiseerd via het apparaat RODOS-5. Natuurlijk is het mogelijk om de Dallas 1820 rechtstreeks te gebruiken, maar het was sneller en eenvoudiger om een USB-aansluiting te gebruiken.

Als opstarter voor x86_64 werd grub2 gekozen. Er was een minimale configuratie nodig om de opstart te realiseren.

Na het debuggen op qemu werd het porteren naar de asus tinker board uitgevoerd. In de structuur van mijn overlay was oorspronkelijk cross-platform functionaliteit opgenomen - het Š²Ń‹Š“ŠµŠ»ŠµŠ½ŠøŠµ van specifieke configuraties voor elk bord (defconfig van het bord, opstarter, generatie van een afbeelding met een systeempartitie) en maximale uniformiteit in de fine-tuning van het bestandssysteem / creatie van een afbeelding met gegevens. Vanwege deze voorbereiding ging de portering snel.

Het wordt ten zeerste aanbevolen om de inleidende artikelen te lezen:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Hoe te bouwen

Het project wordt opgeslagen op github
Na het klonen van de repository ontstaat de volgende bestandsstructuur:

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

buildroot-2019.05.tar.gz - archief van een schone buildroot
overlay - mijn map met external-tree. Hierin staat alles wat nodig is om de firmware met buildroot te bouwen.
README.md - beschrijving van het project en handleiding in het Engels.
run_me.sh - script dat het bouwsysteem voorbereidt. Het pakt buildroot uit het archief, verbindt het met de overlay (via het external-tree mechanisme) en maakt het mogelijk om het doelbord voor de bouw te selecteren.

[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Selecteer defconfig, druk op A om af te breken. Standaard [0]

Daarna is het voldoende om naar de map buildroot-2019.05 te gaan en het commando make uit te voeren.
Na het voltooien van de build, zullen alle buildresultaten in de map output/images staan:

[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

Benodigde bestanden:

  • sdcard.img ā€” een schijfimage voor het schrijven naar een sd-kaart (via dd of rufus onder Windows).
  • qemu.qcow2 ā€” een schijfimage voor het opstarten in qemu.
  • external.qcow2 ā€” een externe schijfimage voor de database
  • monitor-0.9-beta.tar.gz ā€” een archief voor updates via de webinterface

Generatie van handleidingen

Het is niet nodig om dezelfde instructie meerdere keren te schrijven. Het is logischer om het Ć©Ć©n keer in markdown te schrijven en dit vervolgens naar PDF voor download en HTML voor de webinterface te converteren. Dit is mogelijk dankzij het pandoc-pakket.

Tegelijkertijd moeten al deze bestanden gegenereerd worden vĆ³Ć³rdat het systeemimage is opgebouwd, anders zijn de post-build scripts al nutteloos. Daarom is de generatie uitgevoerd als een pakket manuals. Dit kan bekeken worden in overlay/package/manuals.

Het bestand manuals.mk (dat al het werk doet)

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

De wereld van Linux stapt actief over op systemd, dat moest ik ook doen.
Een aangename vernieuwing is de aanwezigheid van timers. Er wordt eigenlijk een apart artikel aan hen (en niet alleen aan hen) gewijd, maar ik zal het kort uitleggen.

Er zijn acties die periodiek moeten worden uitgevoerd. Ik moest logrotate starten voor het opruimen van de logboeken van lighttpd en php-fpm. Het zou het meest logisch zijn om de commando's in cron te schrijven, maar ik besloot gebruik te maken van de monotone systemd-timer. Op deze manier wordt logrotate na een strikte tijdsinterval gestart.

Natuurlijk is er de mogelijkheid om timers te maken die op bepaalde data afgaan, maar dat was voor mij niet nodig.
Voorbeeld van een timer:

  • Timerbestand
    
[Unit]
Description=RODOS temp daemon timer

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target

- Servicebestand dat door de timer wordt aangeroepen:
```bash
[Unit]
Description=RODOS temp daemon

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

Ondersteunde borden

Asus tinker board ā€” het belangrijkste bord waarop alles zou moeten werken. Gekozen vanwege de lage kosten en de behoorlijke kracht.

Beaglebone black ā€” het eerste bord waarop de functionaliteit werd getest (in de periode van het selecteren van een krachtiger bord).

Qemu x86_64 ā€” wordt gebruikt voor ontwikkeling en debugging.

Hoe het werkt

Bij de start vindt er een tweefasig herstel van de instellingen plaats:

  • het uitvoeren van het script settings_restore (via de service). Dit herstelt de basisinstellingen van het systeem ā€” tijdzone, locale, netwerkinstellingen, enz.
  • het uitvoeren van het script prepare (via de service) ā€” hier worden zabbix, de database voorbereid en het IP in de console weergegeven.

Bij de eerste opstart wordt de grootte van de tweede partitie van de sd-kaart bepaald. Als er nog onbenutte ruimte is, wordt het apparaat opnieuw gepartitioneerd, waarbij de datapartitie alle vrije ruimte in beslag neemt. Dit is gedaan om de grootte van het installatie-imago (sdcard.img) te verkleinen. Bovendien wordt op dit moment de werkmap voor postgresql aangemaakt. Daarom zal de eerste opstart met een nieuw apparaat langer duren dan de volgende.

Wanneer een externe schijf wordt aangesloten, zoekt het systeem tijdens de opstart naar een vrije schijf en formatteert deze als ext4 met het label external.

Let op! Bij het aansluiten van een externe schijf (en ook bij het ontkoppelen of vervangen ervan) is het noodzakelijk om een back-up te maken en de instellingen te herstellen!

Voor het monitoren van de temperatuur wordt het apparaat RODOS 5 gebruikt. De fabrikant biedt de bronbestanden van zijn hulpprogramma aan voor gebruik met het apparaat. Bij het inschakelen van het systeem start de timer rodos, die dit hulpprogramma elke minuut uitvoert. De huidige temperatuur wordt opgeslagen in het bestand /tmp/rodos_current_temp, waarna zabbix dit bestand kan monitoren als een sensor.

Het opslagapparaat voor de configuratie wordt gemonteerd in de map /data.

Bij het opstarten van het systeem en het voorbereiden op gebruik verschijnt er een bericht in de console:

Systeem wordt gestart, even geduld

Na het voltooien van de voorbereidingswerkzaamheden verandert dit in de weergave van het IP-adres:

huidig ip 192.168.1.32
Klaar voor gebruik

Configuratie van zabbix voor temperatuurmonitoring

Voor het monitoren van de temperatuur zijn slechts 2 stappen nodig:

  • sluit het apparaat RODOS aan op de usb-poort
  • maak een data-item in zabbix

Open de webinterface van zabbix:

  • Open de sectie Configuratie ā†’ Hosts
  • Klik op Items in de regel van onze zabbix-server
  • Klik op Maak item aan

Buildroot: Het creƫren van cross-platform firmware met zabbix-server

Vul de volgende gegevens in:

  • naam ā€” naar eigen keuze (bijvoorbeeld, serverRoomTemp)
  • Type ā€” zabbix agent
  • Sleutel ā€” rodos
  • Type - numeriek
  • Eenheden ā€” C
  • Geschiedenis opslagperiode ā€” periode voor het opslaan van geschiedenis. heb 10 dagen behouden
  • Trend opslagperiode ā€” periode voor het opslaan van veranderingsdynamiek. Heb 30 dagen behouden
  • Nieuwe applicatie ā€” server Room Temp

En klik op de knop ADD.
Buildroot: Het creƫren van cross-platform firmware met zabbix-server

Beheer van instellingen via de webinterface

De webinterface is geschreven in php. Er zijn enkele basisfuncties:

  • weergeven van de status van het apparaat
  • wijzigen van netwerkinstellingen
    Buildroot: Het creƫren van cross-platform firmware met zabbix-server
  • wachtwoord van de gebruiker wijzigen
  • kies tijdzone
  • back-up / herstellen / resetten naar fabrieksinstellingen
  • mogelijkheid om een externe schijf aan te sluiten
  • Systeemupdate
    Buildroot: Het creƫren van cross-platform firmware met zabbix-server

Toegang tot de webinterface is beveiligd met een wachtwoord. De startpagina is de handleiding.

Adres van de zabbix-interface: ${ip/dns}/zabbix
Beheerinterface adres: ${ip/dns}/manage
Buildroot: Het creƫren van cross-platform firmware met zabbix-server

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

Dit commando start het systeem met 4 kernen, 2048 RAM, geactiveerde KVM, een netwerkaart op bridge0 en twee schijven: voor het systeem en extern voor postgresql.

Afbeeldingen kunnen worden geconverteerd en uitgevoerd in Virtualbox:

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

Daarna kunnen ze in Virtualbox worden geĆÆmporteerd en via SATA worden aangesloten.

Conclusie

Tijdens dit proces raakte ik geĆÆntrigeerd om een werkend product te maken ā€” met een niet al te mooie interface (ik hou er niet van om ze te schrijven), maar werkend en eenvoudig in te stellen.

De laatste poging om zabbix-appliance in KVM te installeren toonde de juistheid van deze stap aan (na het voltooien van de installatie start het systeem niet op). Misschien doe ik iets verkeerd šŸ˜‰

Materialen

https://buildroot.org/

Bron: habr.com

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers šŸ”„ Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster