Buildroot: Creazione di un firmware multipiattaforma con zabbix-server

Storia del compito

Le piccole imprese, da una parte, hanno bisogno di un monitoraggio di qualità della loro infrastruttura (soprattutto alla luce della virtualizzazione diffusa), dall'altra, è finanziariamente difficile per loro acquistare nuova attrezzatura. Inoltre, spesso sorgono problemi con i server/ hardware: di solito ci sono 1-3 server tower vicino ai posti di lavoro degli utenti o in una piccola nicchia / scanalatura.

È più semplice utilizzare una distribuzione già pronta che può essere caricata su una scheda microSD e inserita in un computer a scheda singola diffuso (beaglebone, famiglie raspberry pi e orange pi, asus tinker board). Inoltre, tale attrezzatura ha un costo contenuto e può essere installata ovunque.

Definizione del compito

In gran parte, il progetto si è sviluppato come una sorta di lavoro di laboratorio con possibilità di applicazione dei risultati.

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

Si è posto in modo urgente il problema della piattaforma hardware. Installare una macchina separata per il monitoraggio non è una buona soluzione — o è costoso acquistare nuova attrezzatura, o si deve cercare materiale usato + nelle piccole aziende ci sono frequenti problemi con i server / hardware.

L'uso del sistema di costruzione buildroot consente di creare soluzioni specializzate che possono essere utilizzate da personale con conoscenze minime dei sistemi operativi della famiglia Linux. Questo sistema è amichevole per i principianti, ma allo stesso tempo offre ampie possibilità di personalizzazione nelle mani di uno sviluppatore esperto. È perfetto per risolvere la questione di un monitoraggio IT economico ma completo, con requisiti minimi per la preparazione del personale che lo utilizza.

Passi per la soluzione

Si è deciso inizialmente di creare un firmware per x86_64 da eseguire in qemu, poiché è una soluzione comoda e rapida per il debug. Dopodiché, è stato portato su un computer a scheda singola arm (mi è piaciuta l'asus tinker board).

Come sistema di costruzione è stato scelto buildroot. Inizialmente non conteneva il pacchetto zabbix, quindi è stato necessario portarlo. Ci sono stati problemi con la localizzazione russa, che sono stati risolti applicando le 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 (immagine di sistema immutabile + file di configurazione / database ripristinabili), è stato necessario scrivere i propri target, servizi e timer per systemd (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.

Sono risultate più complesse le attività legate al database. Non si desiderava posizionarlo direttamente sul supporto. Allo stesso tempo, la dimensione del database potrebbe superare le dimensioni del potenziale ramdisk. Pertanto è stata scelta una soluzione di compromesso: il database è posizionato sulla seconda partizione della scheda SD (le schede SLC moderne hanno fino a 30.000 cicli di scrittura), ma c'è una configurazione che consente di utilizzare un supporto esterno (ad esempio, un usb-hdd).

Il monitoraggio della temperatura è stato realizzato tramite il dispositivo RODOS-5. Certo, si potrebbe utilizzare il dallas 1820 direttamente, ma era più veloce e semplice collegare USB.

Come bootloader per x86_64 è stato scelto grub2. È stata necessaria la scrittura di una configurazione minima per l'avvio.

Dopo la fase di debug su qemu, è stato effettuato il porting su asus tinker board. Nella struttura del mio overlay era stata originariamente prevista la cross-platform compatibility: l'assegnazione di configurazioni specifiche per ogni scheda (defconfig della scheda, bootloader, generazione dell'immagine con la partizione del sistema) e la massima uniformità nella personalizzazione del file system / creazione dell'immagine con i dati. Grazie a tale preparazione, il porting è avvenuto rapidamente.

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

Come compilare

Il progetto è ospitato su github
Dopo aver clonato il repository, si ottiene la seguente struttura dei 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 compilare il firmware utilizzando buildroot
README.md — descrizione del progetto e guida in inglese.
run_me.sh — script che prepara il sistema di costruzione. Estrae buildroot dall'archivio, lo attacca a overlay (attraverso il meccanismo external-tree) e consente di scegliere la scheda target per il build

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

Dopo di ciò, è sufficiente passare alla cartella buildroot-2019.05 ed eseguire il comando make.
Al termine della compilazione, tutti i risultati della compilazione 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 sulla scheda SD (tramite dd o rufus su Windows).
• qemu.qcow2 — immagine del supporto da avviare 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 delle guide

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

Allo stesso tempo, è necessario generare tutti questi file prima che venga creato l'immagine del sistema, quindi gli script post-build sono già inutili. Pertanto, la generazione è stata effettuata sotto forma di pacchetto manuals. Puoi visualizzarlo in overlay/package/manuals.

Il file manuals.mk (che svolge 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 passando attivamente a systemd, quindi ho dovuto farlo anche io.
Tra le novità piacevoli c'è la disponibilità di timer. In effetti, di questo (e non solo) viene scritta un articolo separato, ma vi spiegherò brevemente.

Ci sono azioni che devono essere eseguite periodicamente. Avevo bisogno di avviare logrotate per la pulizia dei log di lighttpd e php-fpm. Sarebbe stato più abituato scrivere i comandi in cron, ma ho deciso di utilizzare il timer monotono di systemd. In questo modo, logrotate viene avviato a intervalli di tempo rigorosi.

Certo, c'è la possibilità di creare timer che scattano in date specifiche, ma non ne avevo bisogno.
Esempio di timer:

• File del timer

  
  [Unit]
  Description=RODOS temp daemon timer

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target

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

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

Schede supportate

Asus tinker board — la scheda principale su cui tutto dovrebbe funzionare. Scelta come economica e piuttosto potente.

Beaglebone black — la prima scheda su cui è stata testata la funzionalità (nel periodo di ricerca di 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 (tramite servizio). Ripristina le impostazioni di base del sistema — fuso orario, locale, impostazioni di rete e così via.
• lancio dello script prepare (tramite servizio) — qui viene preparato zabbix, il database, viene visualizzato l'IP nella console.

Al primo avvio viene determinata la dimensione della seconda partizione della scheda sd. Nel caso ci sia ancora spazio non partizionato — il supporto viene ripartizionato, la partizione per i dati occupa tutto lo spazio libero. Questo è stato fatto per ridurre la dimensione dell'immagine di installazione (sdcard.img). Inoltre, in questo momento viene creato un catalogo di lavoro per postgresql. Ecco perché il primo avvio con un nuovo supporto sarà più lungo degli avvii successivi.

Collegando un disco esterno, al momento dell'avvio cerca un disco libero e lo formatta in ext4 con l'etichetta external.

Attenzione! Quando si collega un disco esterno (e anche durante lo scollegamento o la sostituzione), è necessario eseguire un backup e ripristinare le impostazioni!

Per monitorare la temperatura viene utilizzato il dispositivo RODOS 5. Il produttore fornisce le sorgenti della propria utility per lavorare con il dispositivo. Quando il sistema viene acceso, parte il timer rodos, che avvia questa utility una volta al minuto. La temperatura attuale viene registrata nel file /tmp/rodos_current_temp, dopo di che zabbix può monitorare questo file come sensore.

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

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

Sistema in avvio, attendere

Dopo il completamento dei lavori preparatori, questo cambierà in visualizzazione dell'indirizzo IP:

ip corrente 192.168.1.32
Pronto a lavorare

Configurazione di zabbix per monitorare la temperatura

Per monitorare la temperatura è sufficiente seguire 2 passaggi:

• collegare il dispositivo RODOS alla porta usb
• creare un elemento dati in zabbix

Apriamo l'interfaccia web di zabbix:

• Apriamo la sezione Configurazione → Host
• Clicchiamo su Items nella riga del nostro server zabbix
• Clicchiamo su Crea elemento

Inseriamo i seguenti dati:

• name — a vostra discrezione (ad esempio, serverRoomTemp)
• Type — zabbix agent
• Key — rodos
• Type — numerico
• Units — C
• Periodo di conservazione della storia — periodo di conservazione della storia. ho lasciato 10 giorni
• Periodo di conservazione delle tendenze — periodo di conservazione della dinamica delle variazioni. Ho lasciato 30 giorni
• Nuova applicazione — server Room Temp

E clicchiamo sul pulsante ADD.

Gestione delle impostazioni tramite interfaccia web

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

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

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

Indirizzo dell'interfaccia 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 ponte bridge0 e due dischi: uno per il sistema e l'altro 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 bisogna importarle in virtualbox e collegarle via sata.

Conclusione

Durante il processo mi è venuto in mente di realizzare 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