Buildroot: Creazione di un firmware multipiattaforma con zabbix-server

Storia del task

Le piccole aziende, da un lato, hanno bisogno di monitorare efficacemente la propria infrastruttura (soprattutto in un contesto di virtualizzazione diffusa), dall'altro, affrontano difficoltà finanziarie nell'acquisto di nuove attrezzature. Si presentano spesso anche problemi con i server/hardware: frequentemente, ci sono 1-3 server tower posizionati vicino alle postazioni degli utenti o in una piccola nicchia/armadietto.

È più semplice utilizzare una build già pronta (distro) che basta caricare su una scheda microSD e inserire in un comune computer a scheda unica (beaglebone, della famiglia raspberry pi e orange pi, asus tinker board). Inoltre, tale attrezzatura ha un costo contenuto e può essere installata ovunque.

Definizione del compito

Il progetto si è sviluppato in gran parte come un lavoro di laboratorio con la possibilità di applicare i risultati.

Per il sistema di monitoraggio è stato scelto zabbix, poiché è un sistema potente, gratuito e ben documentato.

È emersa con urgenza la questione della piattaforma hardware. Installare una macchina separata per il monitoraggio non è una grande soluzione: o si spende molto per nuovo hardware, oppure si cerca vecchio, e nelle piccole aziende ci sono spesso problemi con i server/hardware.

L'uso del sistema di build buildroot consente di creare soluzioni specializzate, utilizzabili da personale con conoscenze minime del sistema operativo Linux. Questo sistema è amichevole per i neofiti, ma offre anche ampie possibilità di personalizzazione nelle mani di un sviluppatore esperto. È particolarmente adatto a risolvere il problema di un monitoraggio IT completo e funzionale, minimamente esigente in termini di preparazione del personale che lo utilizza.

Passi per la soluzione

Inizialmente si è deciso di creare un firmware per x86_64 da avviare in qemu, poiché rappresenta una soluzione comoda e veloce per il debug. Successivamente, si procederà con la portabilità su un singolo computer ARM (ho trovato interessante l'Asus Tinker Board).

È stato scelto buildroot come sistema di build. Inizialmente non era presente il pacchetto zabbix, quindi è stato necessario portarlo. Ci sono stati problemi con la localizzazione russa, risolti mediante l'applicazione di patch corrispondenti (nota: nelle versioni più recenti di buildroot queste patch non sono più necessarie).

Il porting del pacchetto zabbix stesso sarà descritto in un articolo separato.

Poiché tutto deve funzionare come un firmware (un'immagine di sistema non modificabile + file di configurazione/ database ripristinabili), è stato necessario scrivere i propri target systemd, servizi e timer (target, service, timer).

È stata presa la decisione di suddividere il supporto in 2 partizioni: una partizione con i file di sistema e una partizione con i file di configurazione modificabili e i file di database zabbix.

Si è rivelata un po' più complessa la soluzione dei problemi legati al database. Non era molto desiderabile posizionarlo direttamente sul supporto. Allo stesso tempo, le dimensioni del database possono superare quelle del possibile ramdisk. Pertanto, è stata scelta una soluzione di compromesso: il database viene posizionato sulla seconda partizione della scheda sd (le moderne schede SLC hanno fino a 30.000 cicli di scrittura), ma c'è un'impostazione che consente di utilizzare un supporto esterno (ad esempio, un usb-hdd).

Il monitoraggio della temperatura è stato implementato tramite il dispositivo RODOS-5. Certo, si può utilizzare il Dallas 1820 direttamente, ma è stato più veloce e semplice collegare una USB.

Come bootloader per x86_64 è stato scelto grub2. È stato necessario scrivere una configurazione minimale per l'avvio.

Dopo il debugging su qemu, è stata effettuata la portabilità sulla scheda asus tinker board. Nella struttura del mio overlay era stata inizialmente prevista la cross-platformità: separazione delle configurazioni specifiche per ciascuna scheda (defconfig della scheda, bootloader, generazione dell'immagine con partizione di sistema) e massimo uniformità nella configurazione del filesystem/la creazione dell'immagine con i dati. Grazie a tale preparazione, la portabilità è avvenuta rapidamente.

Si raccomanda vivamente di leggere gli articoli introduttivi:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Come assemblare

Il progetto è ospitato su github
Dopo aver clonato il repository, si ottiene la seguente struttura di file:

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

buildroot-2019.05.tar.gz — archivio di buildroot pulito
overlay — la mia cartella con external-tree. È qui che si trova tutto il necessario per assemblare il firmware utilizzando buildroot
README.md — descrizione del progetto e guida in inglese.
run_me.sh — script che prepara il sistema di build. Estrae buildroot dall'archivio, collega l'overlay (attraverso il meccanismo external-tree) e consente di scegliere la scheda target per l'assemblaggio

[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Seleziona defconfig, premi A per annullare. Predefinito [0]

Dopo di che, è sufficiente entrare nella cartella buildroot-2019.05 e eseguire il comando make.
Una volta completata l'assemblaggio, tutti i risultati saranno nella cartella 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

File necessari:

• sdcard.img — immagine del supporto da scrivere su sd-card (tramite dd o rufus su windows).
• qemu.qcow2 — immagine del supporto per l'esecuzione in qemu.
• external.qcow2 — immagine del supporto esterno per il database
• monitor-0.9-beta.tar.gz — archivio per l'aggiornamento tramite interfaccia web

Generazione di manuali

Non ha senso scrivere più volte la stessa istruzione. È più logico scrivere una volta in markdown, per poi convertirla in PDF per il download e in html per l'interfaccia web. Questo è possibile grazie al pacchetto pandoc.

Inoltre, tutti questi file devono essere generati prima che venga creato l'immagine del sistema, quindi gli script post-build diventano già inutili. Pertanto, la generazione è stata effettuata sotto forma di pacchetto manuals. Può essere visualizzato in overlay/package/manuals.

Il file manuals.mk (che esegue tutto il lavoro)

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

Il mondo Linux sta attivamente passando a systemd, quindi ho dovuto farlo anche io.
Tra le novità interessanti c'è la presenza di timer. Di solito si scrive un articolo separato su di essi (e non solo), ma vi farò un breve riassunto.

Ci sono attività che devono essere eseguite periodicamente. Ho avuto bisogno di avviare logrotate per la pulizia dei log di lighttpd e php-fpm. Sarebbe stato più abituale scrivere i comandi in cron, ma ho deciso di utilizzare il timer monotono di systemd. In questo modo, logrotate viene eseguito in un intervallo di tempo rigoroso.

Naturalmente, è possibile creare timer che scattano in date specifiche, ma per me non ne ho avuto bisogno.
Esempio di timer:

• File del timer

  
  [Unit]
  Description=Timer del demone RODOS

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target

- File del servizio chiamato dal timer:
```bash
[Unit]
Description=Demone RODOS

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

Schede supportate

Asus tinker board — scheda principale sulla quale tutto deve funzionare. Scelta per il suo costo contenuto e prestazioni elevate.

Beaglebone black — prima scheda sulla quale è stata testata la funzionalità (mentre si cercava una scheda più potente).

Qemu x86_64 — utilizzata per lo sviluppo e il debug.

Come funziona

All'avvio avviene un ripristino delle impostazioni in due fasi:

• esecuzione dello script settings_restore (attraverso il servizio). Ripristina le impostazioni principali del sistema — fuso orario, locale, impostazioni di rete, ecc.
• esecuzione dello script prepare (attraverso il servizio) — qui si prepara zabbix, il database, e si visualizza l'IP nella console.

All'avvio iniziale, viene determinata la dimensione della seconda partizione della scheda SD. Se c'è ancora spazio non allocato, il supporto viene riformattato e la partizione per i dati occupa tutto lo spazio libero. Questo è fatto per ridurre le dimensioni dell'immagine di installazione (sdcard.img). Inoltre, in questo momento viene creato il catalogo di lavoro di postgresql. Per questo motivo, il primo avvio con un nuovo supporto sarà più lungo rispetto ai successivi.

Quando si collega un'unità esterna, all'avvio cerca un disco libero e lo formatta in ext4 con l'etichetta external.

Attenzione! Quando si collega un'unità esterna (così come quando viene disconnessa o sostituita), è necessario eseguire un backup e ripristinare le impostazioni!

Per monitorare la temperatura viene utilizzato il dispositivo RODOS 5. Il produttore fornisce il codice sorgente della propria utility per interagire con il dispositivo. All'accensione del sistema, si avvia un timer rodos, che attiva questa utility ogni minuto. La temperatura attuale viene registrata nel file /tmp/rodos_current_temp, dopodiché zabbix può monitorare questo file come sensore.

Il supporto per la memorizzazione della configurazione viene montato nella directory /data.

All'avvio del sistema e durante la preparazione per il lavoro, appare un messaggio nella console:

Sistema in avvio, attendere prego

Una volta completati i lavori preparatori, verrà sostituito con l'output dell'indirizzo IP:

ip attuale 192.168.1.32
Pronto per lavorare

Impostazione di zabbix per il monitoraggio della temperatura

Per monitorare la temperatura, è sufficiente seguire 2 passi:

• collegare il dispositivo RODOS alla porta usb
• creare un data item in zabbix

Apriamo l'interfaccia web di zabbix:

• Andiamo nella sezione Configurazione → Host
• Clicchiamo su Items nella riga del nostro server zabbix
• Clicchiamo su Crea item

Inseriamo i seguenti dati:

• name — a vostra discrezione (ad esempio, serverRoomTemp)
• Tipo — zabbix agent
• Chiave — rodos
• Tipo — numerico
• Unità — C
• Periodo di conservazione della storia — periodo di archiviazione della storia. Ho lasciato 10 giorni
• Periodo di conservazione della tendenza — periodo di archiviazione delle dinamiche di cambiamento. Ho lasciato 30 giorni
• Nuova applicazione — server Room Temp

E clicchiamo sul pulsante ADD.

Gestione delle impostazioni tramite l'interfaccia web

L'interfaccia web è scritta in php. Ha funzioni principali:

• visualizzazione dello stato del dispositivo
• modifica delle impostazioni di rete
  
• modifica della password dell'utente
• selezione del fuso orario
• backup/ripristino/ripristino delle impostazioni di fabbrica
• possibilità di collegare un'unità esterna
• Aggiornamento del sistema
  

L'accesso all'interfaccia web è protetto da password. La pagina iniziale è la guida.

Indirizzo dell'interfaccia di zabbix: ${ip/dns}/zabbix
Indirizzo dell'interfaccia di gestione: ${ip/dns}/manage

Avvio 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

Questo comando avvierà il sistema con 4 core, 2048 RAM, KVM attivato, una scheda di rete sul bridge0 e due dischi: uno per il sistema e uno esterno per postgresql.

Le immagini possono essere convertite e avviate in Virtualbox:

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

Dopo di che, importarle in virtualbox e collegarle tramite sata.

Conclusione

Durante il processo mi è venuta l'idea di creare un prodotto pronto all'uso — con un'interfaccia non molto bella (non mi piace scriverle), ma funzionante e facile da configurare.

L'ultimo tentativo di installare zabbix-appliance in KVM ha dimostrato la correttezza di questo passo (dopo il completamento dell'installazione, il sistema non si avvia). Forse sto facendo qualcosa di sbagliato 😉

Materiali

https://buildroot.org/

Fonte: habr.com