Buildroot: Skapar plattformsoberoende firmware med zabbix-server

Problemhistorik

Små företag behöver å ena sidan högkvalitativ övervakning av sin infrastruktur (särskilt i ljuset av utbredd virtualisering), å andra sidan är det ekonomiskt svårt för dem att köpa ny utrustning. Server/hårdvaruproblem är också vanliga: ofta finns det 1-3 tornservrar bredvid användararbetsstationer eller i en liten nisch/garderob.

Det är lättare att använda en färdig montering (distribution), som du bara behöver ladda upp till ett microSD-kort och sätta in i en vanlig dator med ett kort (beaglebone, raspberry pi och orange pi-familjer, asus tinkerboard). Dessutom är sådan utrustning billig och kan installeras var som helst.

Problem uttalande

På många sätt utvecklades projektet som ett slags laboratoriearbete med möjlighet att tillämpa resultaten.

Zabbix valdes som övervakningssystem eftersom det är ett kraftfullt, fritt och väldokumenterat system.

Problemet med hårdvaruplattformen har blivit akut, Att sätta en separat maskin under övervakning är inte heller en särskilt bra lösning - antingen är det dyrt att köpa ny utrustning, eller att leta efter gammal utrustning + i små företag är det frekventa problem med server/ hårdvara.

Genom att använda buildroot-byggsystemet kan du skapa specialiserade lösningar som kan användas av personal med minimal kunskap om Linux-operativsystem. Detta system är vänligt för nybörjare, men ger samtidigt stora anpassningsmöjligheter i händerna på en erfaren utvecklare. Det är perfekt för att lösa problemet med billig, men fullt fungerande övervakning av IT-infrastruktur, med minimala krav på utbildning av personalen som driver den.

Lösningssteg

Det beslutades att initialt skapa firmware för x86_64 för att köras i qemu, eftersom detta är en bekväm och snabb lösning för felsökning. Porta den sedan till en enkelarmsdator (jag gillade asus tinkerboard).

buildroot valdes som byggsystem. Till en början saknar det zabbix-paketet, så det måste porteras. Det fanns problem med den ryska lokalen, som löstes genom att applicera lämpliga patchar (observera: i nyare versioner av buildroot behövs inte längre dessa patchar).

Portering av själva zabbix-paketet kommer att beskrivas i en separat artikel.

Eftersom allt ska fungera som firmware (oföränderlig systembild + återställningsbara konfigurations-/databasfiler) var det nödvändigt att skriva dina egna systemmål, tjänster och timers (mål, tjänst, timer).

Det beslutades att dela upp media i 2 sektioner - en sektion med systemfiler och en sektion med ändringsbara konfigurationer och zabbix databasfiler.

Att lösa problem relaterade till databasen visade sig vara lite svårare. Jag ville inte placera det direkt i media. Samtidigt kan storleken på databasen nå en storlek som överstiger storleken på en möjlig ramdisk. Därför valdes en kompromisslösning: databasen finns på SD-kortets andra partition (moderna SLC-kort har upp till 30 000 skrivcykler), men det finns en inställning som tillåter användning av externa media (till exempel usb- hdd).

Temperaturövervakning implementerades genom RODOS-5-enheten. Självklart kan du använda Dallas 1820 direkt, men det var snabbare och lättare att koppla in en USB.

grub86 valdes som starthanterare för x64_2. Det var nödvändigt att skriva en minimal konfiguration för att starta den.

Efter felsökning på qemu, portades den till asus tinkerboard. Strukturen för mitt överlägg var från början tänkt att vara plattformsoberoende - allokera konfigurationer specifika för varje kort (board defconfig, bootloader, generering av en bild med en systempartition) och maximal enhetlighet i att anpassa filsystemet/skapa en bild med data. På grund av sådana förberedelser gick porteringen snabbt.

Det rekommenderas starkt att läsa de inledande artiklarna:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Hur man monterar

Projektet lagras på github
Efter kloning av förvaret erhålls följande filstruktur:

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

buildroot-2019.05.tar.gz - rent buildroot-arkiv
overlay är min katalog med externt träd. Det är här allt du behöver för att bygga firmware med buildroot lagras i.
README.md - beskrivning av projektet och manual på engelska.
run_me.sh är ett skript som förbereder byggsystemet. Expanderar buildroot från arkivet, fäster ett överlägg till det (via extern-trädmekanismen) och låter dig välja målkortet för montering

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

Efter detta går du bara till katalogen buildroot-2019.05 och kör kommandot make.
När bygget är klart kommer alla byggresultat att finnas i katalogen 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ödvändiga filer:

• sdcard.img - mediabild för inspelning på ett SD-kort (via dd eller rufus under wibdows).
• qemu.qcow2 - mediabild som ska köras i qemu.
• external.qcow2 - extern mediebild för databasen
• monitor-0.9-beta.tar.gz - arkiv för uppdatering via webbgränssnittet

Generering av guider

Det är ingen idé att skriva samma instruktioner flera gånger. Och det mest logiska är att skriva det en gång i markdown och sedan konvertera det till PDF för nedladdning och html för webbgränssnittet. Detta är möjligt tack vare Pandoc-paketet.

Samtidigt måste alla dessa filer genereras innan systemavbildningen sätts ihop; dessa efterbyggda skript är redan värdelösa. Därför görs genereringen i form av ett manualpaket. Du kan titta på överlägg/paket/manualer.

Manuals.mk-filen (som gör allt)

################################################################################
#
# 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-världen går aktivt över till systemd, och jag var tvungen att göra det också.
En av de trevliga innovationerna är närvaron av timers. I allmänhet skrivs en separat artikel om dem (och inte bara om dem), men jag ska berätta kort.

Det finns åtgärder som måste utföras med jämna mellanrum. Jag behövde köra logrotate för att rensa lighttpd- och php-fpm-loggarna. Det vanliga skulle vara att skriva kommandona i cron, men jag bestämde mig för att använda systemd monoton timer. Så logrotate körs med ett strikt tidsintervall.

Visst går det att skapa timers som tänds på vissa datum, men jag behövde inte detta.
Exempel på timer:

• Timer fil

  
  [Unit]
  Description=RODOS temp daemon timer

[Timer] OnBootSec=1min
OnUnitActiveSec=1min

[Installera] WantedBy=timers.target

- Файл сервиса, вызываемого таймером:
```bash
[Unit]
Description=RODOS temp daemon

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

Brädor som stöds

Asus tinkerboard är huvudkortet där allt ska fungera. Vald som billig och mycket kraftfull.

Beaglebone black är det första brädet som man testade på (vid valet av en kraftfullare bräda).

Qemu x86_64 - används för felsökningsutveckling.

Hur fungerar det?

Vid start sker en tvåstegsåterställning av inställningarna:

• kör skriptet settings_restore (via tjänsten). Det återställer grundläggande systeminställningar - tidszon, lokal, nätverksinställningar, etc.
• köra prepare script (via tjänsten) - här förbereds zabbix och databasen, IP:n matas ut till konsolen.

När du först startar den bestäms storleken på SD-kortets andra partition. Om det fortfarande finns oallokerat utrymme partitioneras media om och datasektionen tar upp allt ledigt utrymme. Detta görs för att minska storleken på installationsbilden (sdcard.img). Dessutom skapas postgresql-arbetskatalogen vid denna tidpunkt. Det är därför den första lanseringen med en ny operatör kommer att vara längre än de efterföljande.

När du ansluter en extern enhet söker den vid starttillfället efter en ledig enhet och formaterar den till ext4 med den externa etiketten.

Uppmärksamhet! När du ansluter en extern enhet (liksom när du kopplar bort eller byter ut den) måste du göra en säkerhetskopia och återställa inställningarna!

RODOS 5-enheten används för temperaturövervakning. Tillverkaren tillhandahåller källkoden för dess verktyg för att arbeta med enheten. När systemet slås på startar rodos-timern, som kör detta verktyg en gång i minuten. Den aktuella temperaturen skrivs till filen /tmp/rodos_current_temp, varefter zabbix kan övervaka denna fil som en sensor.

Konfigurationslagringsmediet är monterat i katalogen /data.

När du startar systemet och förbereder det för drift, visas följande meddelande i konsolen:

System starting, please wait

Efter att ha slutfört det förberedande arbetet kommer det att ändras till att visa IP-adressen:

current ip 192.168.1.32
Ready to work

Ställa in zabbix för temperaturövervakning

För att övervaka temperaturen, ta bara två steg:

• anslut RODOS-enheten till USB-porten
• skapa dataobjekt i zabbix

Öppna zabbix webbgränssnitt:

• Öppna avsnittet Konfiguration → Värdar
• Klicka på Objekt i raden på vår zabbix-server
• Klicka på Skapa objekt

Ange följande data:

• namn - efter eget gottfinnande (till exempel serverRoomTemp )
• Typ - zabbix agent
• Nyckel - Rodos
• Typ-numerisk
• Enheter - C
• Historik lagringsperiod — historik lagringsperiod. kvar 10 dagar
• Trendlagringsperiod – lagringsperiod för dynamiken i förändringar. 30 dagar kvar
• Ny applikation - server Rumstemp

Och tryck på ADD-knappen.

Hantera inställningar via webbgränssnitt

Webbgränssnittet är skrivet i PHP. Det finns huvudfunktioner:

• visa enhetens status
• ändra nätverksinställningar
  
• ändra användarlösenord
• val av tidszon
• säkerhetskopiering/återställning/fabriksåterställning
• möjlighet att ansluta en extern enhet
• Systemuppdatering
  

Inloggning till webbgränssnittet är lösenordsskyddad. Startsida - manual.

Zabbix gränssnittsadress: ${ip/dns}/zabbix
Hanteringsgränssnittsadress: ${ip/dns}/manage

Springer 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 -enhet fil=utgång/bilder/qemu.qcow2,format=qcow2,aio=trådar -enhet virtio-scsi-pci,id=scsi0 -enhet fil=utgång/bilder/external.qcow2,format=qcow2,aio=trådar

Detta kommando kommer att starta ett system med 4 kärnor, 2048 RAM, KVM aktiverat, ett nätverkskort på bridge0 och två diskar: en för systemet och en extern för postgresql.

Bilder kan konverteras och köras i Virtualbox:

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

Importera dem sedan till virtualbox och anslut via sata.

Slutsats

Under processen blev jag intresserad av att göra en färdig att använda produkt - med ett inte särskilt vackert gränssnitt (jag gillar inte att skriva dem), men ett som fungerar och är lätt att konfigurera.

Det senaste försöket att installera zabbix-appliance i KVM visade att detta steg var korrekt (efter att installationen är klar startar inte systemet). Jag kanske gör något fel 😉

material

https://buildroot.org/

Källa: will.com