🥇Buildroot: Paglikha ng cross-platform firmware gamit ang zabbix-server

Kasaysayan ng problema

Ang mga maliliit na kumpanya, sa isang banda, ay nangangailangan ng mataas na kalidad na pagsubaybay sa kanilang imprastraktura (lalo na sa liwanag ng laganap na virtualization), sa kabilang banda, mahirap sa pananalapi para sa kanila na bumili ng mga bagong kagamitan. Karaniwan din ang mga problema sa server/hardware: kadalasan mayroong 1-3 tower server sa tabi ng mga workstation ng user o sa isang maliit na niche/closet.

Mas madaling gumamit ng isang handa na pagpupulong (pamamahagi), na kailangan mo lamang i-upload sa isang microSD card at ipasok sa isang karaniwang single-board na computer (beaglebone, raspberry pi at orange pi na mga pamilya, asus tinker board). Bilang karagdagan, ang naturang kagamitan ay mura at maaaring mai-install kahit saan.

Pahayag ng problema

Sa maraming paraan, binuo ang proyekto bilang isang uri ng gawaing laboratoryo na may posibilidad na ilapat ang mga resulta.

Napili ang Zabbix bilang monitoring system dahil ito ay isang malakas, libre at mahusay na dokumentado na sistema.

Ang isyu sa platform ng hardware ay naging talamak. Ang paglalagay ng isang hiwalay na makina sa ilalim ng pagsubaybay ay hindi rin isang napakahusay na solusyon - maaaring mahal ang pagbili ng mga bagong kagamitan, o upang maghanap ng mga lumang kagamitan + sa maliliit na kumpanya ay may mga madalas na problema sa server/ hardware.

Ang paggamit ng buildroot build system ay nagpapahintulot sa iyo na lumikha ng mga espesyal na solusyon na maaaring patakbuhin ng mga tauhan na may kaunting kaalaman sa mga operating system ng Linux. Ang system na ito ay palakaibigan sa mga nagsisimula, ngunit sa parehong oras ay nagbibigay ng sapat na pagkakataon sa pagpapasadya sa mga kamay ng isang may karanasang developer. Ito ay perpekto para sa paglutas ng problema ng mura, ngunit ganap na gumaganang pagsubaybay sa imprastraktura ng IT, na may kaunting mga kinakailangan para sa pagsasanay ng mga tauhan na nagpapatakbo nito.

Mga hakbang sa solusyon

Napagpasyahan na unang lumikha ng firmware para sa x86_64 upang tumakbo sa qemu, dahil ito ay isang maginhawa at mabilis na solusyon para sa pag-debug. Pagkatapos ay i-port ito sa isang arm single-board computer (nagustuhan ko ang asus tinker board).

buildroot ay pinili bilang ang build system. Sa una, kulang ito sa zabbix package, kaya kinailangan itong i-port. Nagkaroon ng mga problema sa lokal na Russian, na nalutas sa pamamagitan ng paglalapat ng naaangkop na mga patch (tandaan: sa mga mas bagong bersyon ng buildroot, hindi na kailangan ang mga patch na ito).

Ang pag-port mismo ng zabbix package ay ilalarawan sa isang hiwalay na artikulo.

Dahil dapat gumana ang lahat bilang firmware (hindi nababagong imahe ng system + nare-recover na configuration/database file), kinailangan na isulat ang sarili mong mga target, serbisyo at timer ng systemd (target, serbisyo, timer).

Napagpasyahan na hatiin ang media sa 2 seksyon - isang seksyon na may mga file ng system at isang seksyon na may mga nababagong config at mga file ng database ng zabbix.

Ang paglutas ng mga problema na nauugnay sa database ay naging medyo mas mahirap. Hindi ko nais na ilagay ito nang direkta sa media. Kasabay nito, ang laki ng database ay maaaring umabot sa laki na lumampas sa laki ng posibleng ramdisk. Samakatuwid, napili ang isang solusyon sa kompromiso: ang database ay matatagpuan sa pangalawang partition ng SD card (ang mga modernong SLC card ay may hanggang 30 write cycle), ngunit mayroong isang setting na nagpapahintulot sa paggamit ng panlabas na media (halimbawa, usb- hdd).

Ang pagsubaybay sa temperatura ay ipinatupad sa pamamagitan ng RODOS-5 device. Siyempre, maaari mong gamitin ang Dallas 1820 nang direkta, ngunit mas mabilis at mas madaling magsaksak ng USB.

Ang grub86 ay napili bilang bootloader para sa x64_2. Ito ay kinakailangan upang magsulat ng isang minimal na config upang ilunsad ito.

Pagkatapos mag-debug sa qemu, na-port ito sa asus tinker board. Ang istraktura ng aking overlay ay unang inilaan upang maging cross-platform - paglalaan ng mga config na tiyak sa bawat board (board defconfig, bootloader, pagbuo ng isang imahe na may partition ng system) at maximum na pagkakapareho sa pag-customize ng file system/paglikha ng isang imahe na may data. Dahil sa naturang paghahanda, mabilis na napunta ang porting.

Inirerekomenda na basahin ang mga panimulang artikulo:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Paano mag-ipon

Ang proyekto ay naka-imbak sa github
Pagkatapos ng pag-clone ng repositoryo, ang sumusunod na istraktura ng file ay nakuha:

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

buildroot-2019.05.tar.gz - malinis na buildroot archive
Ang overlay ay ang aking direktoryo na may panlabas na puno. Dito naka-imbak ang lahat ng kailangan mo para buuin ang firmware gamit ang buildroot.
README.md - paglalarawan ng proyekto at manwal sa Ingles.
Ang run_me.sh ay isang script na naghahanda ng build system. Pinapalawak ang buildroot mula sa archive, ikinakabit ang isang overlay dito (sa pamamagitan ng mekanismo ng panlabas na puno) at pinapayagan kang pumili ng target na board para sa pagpupulong

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

Pagkatapos nito, pumunta lamang sa direktoryo ng buildroot-2019.05 at patakbuhin ang make command.
Kapag kumpleto na ang build, ang lahat ng resulta ng build ay nasa direktoryo ng 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

Mga kinakailangang file:

sdcard.img - imahe ng media para sa pag-record sa isang SD card (sa pamamagitan ng dd o rufus sa ilalim ng wibdows).
qemu.qcow2 - imahe ng media na tatakbo sa qemu.
external.qcow2 - panlabas na imahe ng media para sa database
monitor-0.9-beta.tar.gz - archive para sa pag-update sa pamamagitan ng web interface

Pagbuo ng mga Gabay

Hindi sulit na isulat ang parehong mga tagubilin nang maraming beses. At ang pinaka-lohikal na bagay ay isulat ito nang isang beses sa markdown, at pagkatapos ay i-convert ito sa PDF para sa pag-download at html para sa web interface. Ito ay posible salamat sa pandoc package.

Kasabay nito, ang lahat ng mga file na ito ay kailangang mabuo bago ang imahe ng system ay binuo; ang mga post-build na script ay wala nang silbi. Samakatuwid, ang henerasyon ay ginagawa sa anyo ng isang pakete ng mga manwal. Maaari mong tingnan ang overlay/package/manual.

Ang manuals.mk file (na gumagawa ng lahat ng gawain)

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

Ang mundo ng Linux ay aktibong lumilipat sa systemd, at kailangan ko ring gawin ito.
Ang isa sa mga kaaya-ayang pagbabago ay ang pagkakaroon ng mga timer. Sa pangkalahatan, isang hiwalay na artikulo ang isinusulat tungkol sa kanila (at hindi lamang tungkol sa kanila), ngunit sasabihin ko sa iyo nang maikli.

May mga aksyon na dapat gawin pana-panahon. Kailangan kong magpatakbo ng logrotate upang i-clear ang lighttpd at php-fpm logs. Ang karaniwang bagay ay isulat ang mga utos sa cron, ngunit nagpasya akong gamitin ang systemd monotonic timer. Kaya ang logrotate ay tumatakbo sa isang mahigpit na agwat ng oras.

Siyempre, posible na lumikha ng mga timer na nagpaputok sa ilang mga petsa, ngunit hindi ko ito kailangan.
Halimbawa ng timer:

Timer file


[Unit]
Description=RODOS temp daemon timer

[Timer] OnBootSec=1min
OnUnitActiveSec=1min

[I-install] WantedBy=timers.target

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

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

Mga suportadong board

Ang Asus tinker board ay ang pangunahing board kung saan dapat gumana ang lahat. Napili bilang mura at napakalakas.

Ang itim na Beaglebone ay ang unang board kung saan sinubukan ang operasyon (sa panahon ng pagpili ng isang mas malakas na board).

Qemu x86_64 - ginagamit para sa pag-develop ng pag-debug.

Paano ito gumagana

Sa pagsisimula, nangyayari ang dalawang yugto ng pagpapanumbalik ng mga setting:

pagpapatakbo ng settings_restore script (sa pamamagitan ng serbisyo). Ibinabalik nito ang mga pangunahing setting ng system - time zone, lokal, mga setting ng network, atbp.
pagpapatakbo ng script ng paghahanda (sa pamamagitan ng serbisyo) - dito ang zabbix at ang database ay inihanda, ang IP ay output sa console.

Kapag una mong sinimulan ito, ang laki ng pangalawang partition ng SD card ay tinutukoy. Kung mayroon pa ring hindi nakalaang espasyo, ang media ay muling hahatiin, at ang seksyon ng data ay kumukuha ng lahat ng libreng espasyo. Ginagawa ito upang bawasan ang laki ng imahe ng pag-install (sdcard.img). Bilang karagdagan, ang postgresql working directory ay nilikha sa puntong ito. Iyon ang dahilan kung bakit ang unang paglulunsad na may bagong carrier ay magiging mas mahaba kaysa sa mga kasunod.

Kapag kumokonekta sa isang panlabas na drive, sa sandali ng pagsisimula ay naghahanap ito ng isang libreng drive at i-format ito sa ext4 na may panlabas na label.

Pansin! Kapag kumokonekta sa isang panlabas na drive (pati na rin ang pagdiskonekta o pagpapalit nito), kailangan mong gumawa ng backup at ibalik ang mga setting!

Ginagamit ang RODOS 5 device para sa pagsubaybay sa temperatura. Ibinibigay ng manufacturer ang source code ng utility nito para sa pagtatrabaho sa device. Kapag naka-on ang system, magsisimula ang rodos timer, na nagpapatakbo ng utility na ito minsan sa isang minuto. Ang kasalukuyang temperatura ay isinulat sa file /tmp/rodos_current_temp, pagkatapos ay masusubaybayan ng zabbix ang file na ito bilang sensor.

Ang configuration storage media ay naka-mount sa /data directory.

Kapag sinimulan ang system at inihahanda ito para sa operasyon, lilitaw ang sumusunod na mensahe sa console:

System starting, please wait

Pagkatapos makumpleto ang gawaing paghahanda, ito ay magbabago sa pagpapakita ng IP address:

current ip 192.168.1.32
Ready to work

Pag-set up ng zabbix para sa pagsubaybay sa temperatura

Para subaybayan ang temperatura, gumawa lang ng 2 hakbang:

ikonekta ang RODOS device sa USB port
lumikha ng data item sa zabbix

Buksan ang web interface ng zabbix:

Buksan ang seksyong Configuration → Hosts
Mag-click sa Mga Item sa linya ng aming zabbix server
Mag-click sa Lumikha ng item

Ipasok ang sumusunod na data:

pangalan - sa iyong paghuhusga (halimbawa, serverRoomTemp )
Uri - ahente ng zabbix
Susi - Rodos
Uri-numeric
Mga Yunit - C
Panahon ng imbakan ng kasaysayan — panahon ng imbakan ng kasaysayan. natitira ng 10 araw
Panahon ng imbakan ng uso—panahon ng pag-iimbak para sa dynamics ng mga pagbabago. Umalis ng 30 araw
Bagong application - server Room Temp

At pindutin ang ADD button.

Pamahalaan ang mga setting sa pamamagitan ng web interface

Ang web interface ay nakasulat sa PHP. Mayroong mga pangunahing pag-andar:

tingnan ang katayuan ng device
pagbabago ng mga setting ng network
pagpapalit ng password ng user
pagpili ng time zone
backup/restore/factory reset
kakayahang kumonekta sa isang panlabas na drive
Pag-update ng system

Ang pag-login sa web interface ay protektado ng password. Panimulang pahina - manwal.

Address ng interface ng Zabbix: ${ip/dns}/zabbix
Address ng interface ng pamamahala: ${ip/dns}/manage

Tumatakbo sa 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

Ang utos na ito ay magsisimula ng isang system na may 4 na core, 2048 RAM, KVM na pinagana, isang network card sa bridge0 at dalawang disk: isa para sa system at isang panlabas para sa postgresql.

Ang mga imahe ay maaaring ma-convert at tumakbo sa Virtualbox:

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

Pagkatapos ay i-import ang mga ito sa virtualbox at kumonekta sa pamamagitan ng sata.

Konklusyon

Sa proseso, naging interesado ako sa paggawa ng isang handa nang gamitin na produkto - na may hindi masyadong magandang interface (hindi ko gusto ang pagsusulat ng mga ito), ngunit isa na gumagana at madaling i-configure.

Ang huling pagtatangka na mag-install ng zabbix-appliance sa KVM ay nagpakita na ang hakbang na ito ay tama (pagkatapos makumpleto ang pag-install, ang system ay hindi magsisimula). Baka may ginagawa akong mali 😉

kagamitan

https://buildroot.org/

Pinagmulan: www.habr.com

Buildroot: Paglikha ng cross-platform firmware gamit ang zabbix-server