Buildroot: Oprettelse af tværplatform firmware med zabbix-server

Opgavenes historie

Små virksomheder har på den ene side brug for kvalitetsmonitorering af deres infrastruktur (især i lyset af den udbredte virtualisering), mens det på den anden side er økonomisk udfordrende for dem at investere i nyt udstyr. Der opstår ofte også problemer med server- og hardware: ofte står der 1-3 tower-servere ved siden af arbejdspladserne eller i et lille skab.

Det er lettere at bruge en eksisterende distribution, som blot kan overføres til et microSD-kort og sættes i en almindelig en-boards computer (beaglebone, raspberry pi og orange pi, asus tinker board). Derudover er sådan hardware ikke dyr, og den kan installeres hvor som helst.

Problemformulering

Projektet udviklede sig i høj grad som en form for laboratoriearbejde med mulighed for at anvende resultaterne.

Zabbix blev valgt som overvågningssystem, fordi det er en kraftfuld, gratis og vel-dokumenteret løsning.

Der opstod et presserende spørgsmål om hardwareplatformen. At installere en separat maskine til overvågning er heller ikke en god løsning — enten er det dyrt at købe nyt udstyr, eller man må lede efter brugt + små virksomheder har ofte problemer med server- og hardware.

Brugen af buildroot byggeriet muliggør oprettelsen af specialiserede løsninger, der kan betjenes af personale med minimale Linux-baserede operativsystemkendsaber. Dette system er nybegyndervenligt, men det giver samtidig omfattende tilpasningsmuligheder for erfarne udviklere. Det er ideelt til opgaven med at implementere en billig, men fuldfunktionel monitorering af IT-infrastrukturen, som kræver minimal forberedelse af det personale, der driver det.

Løsningsskridt

Det blev besluttet oprindeligt at skabe en firmware til x86_64 for kørsel i qemu, da dette er en praktisk og hurtig løsning til fejlfinding. Derefter skal den porteres til en en-boards computer arm (jeg kunne godt lide asus tinker board).

Buildroot blev valgt som byggesystem. Oprindeligt er der ikke noget zabbix-paket inkluderet, så det måtte porteres. Der var problemer med den russiske lokalitet, som blev løst ved at anvende de relevante patches (note: i nyere versioner af buildroot er disse patches ikke længere nødvendige).

Porteringen af selve zabbix-pakken vil blive beskrevet i en separat artikel.

Da alt som alt skal fungere som en firmware (uændret systemafbildning + genoprettelige konfigurationsfiler/databaser), var det nødvendigt at skrive egne systemd mål, tjenester og timere (mål, tjeneste, timer).

Det blev besluttet at opdele mediet i 2 partitioner - en partition til systemfilerne og en partition til de ændrede konfigurationer og zabbix-databasefiler.

Det viste sig at være lidt mere kompliceret at løse de opgaver, der var relateret til databasen. Det var ikke ønskeligt at placere den direkte på mediet. Samtidig kan databasen nå en størrelse, der overstiger størrelsen på den mulige ramdisk. Derfor blev der valgt en kompromisløsning: databasen placeres på den anden partition af SD-kortet (moderne SLC-kort har op til 30.000 skrivecykler), men der er en indstilling, der gør det muligt at bruge et eksternt medie (f.eks. usb-hdd).

Temperaturmonitorering blev implementeret via en enhed, RODOS-5. Selvfølgelig kan man bruge dallas 1820 direkte, men det var hurtigere og lettere at tilslutte USB.

Som bootloader for x86_64 blev grub2 valgt. Det var nødvendigt at skrive en minimal konfiguration for opstart.

Efter debugging på qemu blev porteringen udført på asus tinker board. I strukturen af mit overlay blev der oprindeligt indtænkt cross-platform kompatibilitet - fremhævelse af specifikke konfigurationer for hver plade (defconfig for pladen, bootloader, generering af abbildning med systempartition) og maksimal ensartethed i justeringen af filsystemet/oprindelse af data. På grund af denne forberedelse gik porteringen hurtigt.

Det anbefales stærkt at læse de indledende artikler:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Sådan samles

Projektet opbevares på github
Efter kloning af repositoryet får man følgende filstruktur:

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

buildroot-2019.05.tar.gz - arkiv med ren buildroot
overlay - mit katalog med external-tree. Det er her, alt nødvendigt til at samle firmware ved hjælp af buildroot opbevares
README.md - projektbeskrivelse og vejledning på engelsk.
run_me.sh - script, der forbereder buildsystemet. Det udpakker buildroot fra arkivet, knytter det til overlay (gennem mekanismen external-tree) og giver mulighed for at vælge måltavlen til bygningen

[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Vælg defconfig, tryk A for at annullere. Standard [0]

Efter dette er det nok at gå ind i kataloget buildroot-2019.05 og køre kommandoen make.
Når byggeprocessen er afsluttet, vil alle bygge resultater være i kataloget 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

Nødvendige filer:

• sdcard.img — billede til skrivning på sd-kortet (via dd eller rufus under windows).
• qemu.qcow2 — billede til kørsel i qemu.
• external.qcow2 — billede af external-enhed til databasen
• monitor-0.9-beta.tar.gz — arkiv til opdatering via webgrænsefladen

Generering af vejledninger

Det er ikke nødvendigt at skrive den samme vejledning flere gange. Det er mest logisk at skrive det én gang i markdown og derefter konvertere det til PDF til download og HTML til webgrænsefladen. Dette er muligt takket være pandoc-pakken.

Samtidig skal alle disse filer genereres, inden systembilledet er bygget, da post-build scripts allerede er ubrugelige. Derfor er genereringen udført som en pakke manuals. Det kan ses i overlay/package/manuals.

Filen manuals.mk (som udfører alt arbejdet)

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

Linux-verdenen overgår aktivt til systemd, så jeg måtte også gøre det.
Blandt de behagelige nyheder er tilstedeværelsen af timere. Generelt skrives der en særskilt artikel om dem (og ikke kun om dem), men jeg vil kort fortælle.

Der er opgaver, der skal udføres regelmæssigt. Jeg havde behov for at køre logrotate for at rydde op i logfilerne for lighttpd og php-fpm. Det ville være mest almindeligt at skrive kommandoerne i cron, men jeg besluttede mig for at bruge den monotone systemd-timer. Dermed køres logrotate med et strengt tidsinterval.

Selvfølgelig er der mulighed for at oprette timere, der går i gang på bestemte datoer, men det var ikke nødvendigt for mig.
Eksempel på en timer:

• Timerfilen

  
  [Unit]
  Description=RODOS temp daemon timer

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target

- Tjenestefilen, der kaldes af timeren:
```bash
[Unit]
Description=RODOS temp daemon

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

Understøttede boards

Asus tinker board — hovedkortet, hvor alt skal fungere. Valgt som en billig og ret kraftfuld.

Beaglebone black — det første kort, hvor arbejdet blev testet (under søgningen efter et mere kraftfuldt kort).

Qemu x86_64 — bruges til udvikling og debugging.

Hvordan det fungerer

Ved opstart sker der en to-trins gendannelse af indstillingerne:

• kørsel af scriptet settings_restore (via tjenesten). Det gendanner de grundlæggende systemindstillinger — tidszone, lokalitet, netværksindstillinger osv.
• start af scriptet prepare (via tjenesten) – her forberedes zabbix, databasen, og IP-adressen vises i konsollen.

Ved første opstart bestemmes størrelsen af den anden partition på sd-kortet. Hvis der stadig er ikke-partitioneret plads, bliver mediet repartitioneret, og data-partitionen optager alt det ledige plads. Dette gøres for at mindske størrelsen af installationsbilledet (sdcard.img). Derudover oprettes der et arbejdsbibliotek for postgresql. Det er derfor, at første opstart med et nyt medie vil være længere end efterfølgende.

Når der tilsluttes en ekstern disk, søger systemet ved opstart efter en ledig disk og formaterer den til ext4 med etiketten external.

Advarsel! Ved tilslutning af en ekstern disk (samt ved frakobling eller udskiftning) er det nødvendigt at lave backup og gendanne indstillingerne!

Temperaturen overvåges af en RODOS 5-enhed. Producenten giver kildekoden til sit værktøj til arbejde med enheden. Når systemet tændes, starter rodos timeren, som kører dette værktøj hvert minut. Den aktuelle temperatur registreres i filen /tmp/rodos_current_temp, hvorefter zabbix kan overvåge denne fil som en sensor.

Mediet til opbevaring af konfigurationen monteres i kataloget /data.

Ved opstart af systemet og forberedelse til drift vises følgende meddelelse i konsollen:

Systemet starter, vent venligst

Når de forberedende arbejder er afsluttet, ændres meddelelsen til visningen af IP-adressen:

nuværende ip 192.168.1.32
Klar til at arbejde

Konfiguration af zabbix til temperaturovervågning

For at overvåge temperaturen skal du blot udføre 2 trin:

• tilslutte RODOS-enheden til USB-porten
• oprette et dataelement i zabbix

Åbn zabbix webgrænsefladen:

• Åbn sektionen Konfiguration → Værter
• Klik på Elementer i rækken af vores zabbix-server
• Klik på Opret element

Indtast følgende oplysninger:

• navn – efter eget valg (f.eks. serverRoomTemp)
• Type – zabbix agent
• Nøgle – rodos
• Type – numerisk
• Enheder – C
• Historisk opbevaringsperiode – perioden for opbevaring af historik. Jeg har sat det til 10 dage
• Trendopbevaringsperiode – perioden for opbevaring af ændringsdynamik. Jeg har sat det til 30 dage
• Ny applikation – serverrumstemperatur

Og klik på knappen TILFØJ.

Administrering af indstillinger via webgrænseflade

Webgrænsefladen er skrevet i php. Der er følgende hovedfunktioner:

• visning af enhedens tilstand
• ændring af netværksindstillinger
  
• ændring af brugernes adgangskode
• valg af tidszone
• backup/gendannelse/tilbage til fabriksindstillingerne
• mulighed for tilslutning af ekstern disk
• Systemopdatering
  

Adgang til webinterfacet er beskyttet med en adgangskode. Startside - vejledning.

Interface-adresse for zabbix: ${ip/dns}/zabbix
Administrationsinterfaceadresse: ${ip/dns}/manage

Start i 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

Denne kommando vil starte systemet med 4 kerner, 2048 RAM, aktiveret KVM, netværkskort på broen bridge0 og to diske: en til systemet og en ekstern til postgresql.

Billeder kan konverteres og køres i Virtualbox:

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

Derefter importer dem i virtualbox og tilslut via sata.

Konklusion

Undervejs blev jeg interesseret i at lave et færdigt produkt - med et ikke særligt flot interface (jeg bryder mig ikke om at skrive dem), men fungerende og let at konfigurere.

Det sidste forsøg på at installere zabbix-appliance i KVM viste rigtigheden af dette skridt (efter installationen starter systemet ikke). Måske laver jeg noget forkert 😉

Materialer

https://buildroot.org/

Kilde: habr.com