Buildroot: Creación de firmware multiplataforma con zabbix-server

Historia de la tarea

Las pequeñas empresas, por un lado, necesitan monitorizar su infraestructura de manera efectiva (especialmente en el contexto de la virtualización generalizada), y por otro lado, les resulta difícil financiar la compra de nuevo hardware. Además, a menudo se presentan problemas con la parte de servidor/hardware: frecuentemente tienen 1-3 servidores de torre junto a los puestos de trabajo de los usuarios o en un pequeño nicho/armario.

Es más fácil utilizar una distribución lista para usar, que se puede cargar en una tarjeta microSD e insertar en un ordenador de placa única (beaglebone, las familias raspberry pi y orange pi, asus tinker board). Además, este tipo de hardware no es caro y se puede instalar en cualquier lugar.

Planteamiento del problema

En gran medida, el proyecto se desarrolló como un trabajo de laboratorio con la posibilidad de aplicar los resultados.

Se eligió zabbix como sistema de monitorización, ya que es potente, gratuito y bien documentado.

Se planteó urgentemente la cuestión de la plataforma de hardware. No es una buena solución dedicar una máquina solo para la monitorización, ya que implica un costo elevado para adquirir nuevo hardware o la búsqueda de equipos antiguos + en las pequeñas empresas hay a menudo problemas con el servidor/hardware.

El uso del sistema de construcción buildroot permite crear soluciones especializadas que pueden ser utilizadas por personal con conocimientos mínimos de sistemas operativos de la familia Linux. Este sistema es amigable para principiantes, pero ofrece amplias posibilidades de personalización en manos de un desarrollador experimentado. Es ideal para resolver el problema de un monitoreo de infraestructura de TI económico pero completo, con un requisito mínimo de preparación para el personal que lo explota.

Pasos para la solución

Se decidió inicialmente crear el firmware para x86_64 para ejecutarlo en qemu, ya que es una solución conveniente y rápida para depuración. Después se portó a un ordenador de placa única arm (me gustó el asus tinker board).

Se eligió buildroot como sistema de construcción. Inicialmente no tiene el paquete zabbix, por lo que fue necesario portarlo. Hubo problemas con la configuración regional en ruso, que se resolvieron aplicando los parches correspondientes (nota: en versiones más nuevas de buildroot, estos parches ya no son necesarios).

La portabilidad del propio paquete zabbix se describirá en un artículo separado.

Dado que todo debería funcionar como un firmware (imagen del sistema inmutable + archivos de configuración/bases de datos recuperables), fue necesario escribir mis propios objetivos systemd, servicios y temporizadores (target, service, timer).

Se decidió dividir el medio en 2 particiones: una partición para los archivos del sistema y otra para las configuraciones y archivos de base de datos de zabbix que se pueden modificar.

La solución a los problemas relacionados con la base de datos resultó ser un poco más complicada. No quería colocarla directamente en el medio. Al mismo tiempo, el tamaño de la base podría alcanzar dimensiones que superan el tamaño posible del ramdisk. Por lo tanto, se eligió una solución de compromiso: la base de datos se coloca en la segunda partición de la tarjeta sd (las tarjetas SLC modernas tienen hasta 30,000 ciclos de escritura), pero hay una configuración que permite utilizar un medio externo (por ejemplo, un usb-hdd).

La monitorización de la temperatura se realizó a través del dispositivo RODOS-5. Por supuesto, se puede utilizar dallas 1820 directamente, pero fue más rápido y fácil conectarlo por USB.

Se eligió grub2 como gestor de arranque para x86_64. Fue necesario escribir una configuración mínima para el arranque.

Después de depurar en qemu, se realizó la portabilidad a asus tinker board. En la estructura de mi overlay se había previsto desde el principio la multiplataforma: la asignación de configuraciones específicas para cada placa (defconfig de la placa, gestor de arranque, generación de la imagen con la partición del sistema) y la máxima uniformidad en la personalización del sistema de archivos/creación de una imagen con datos. Debido a esta preparación, la portabilidad se realizó rápidamente.

Se recomienda encarecidamente leer los artículos introductorios:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Cómo construir

El proyecto se almacena en github
Después de clonar el repositorio, obtenemos la siguiente estructura de archivos:

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

buildroot-2019.05.tar.gz — archivo de buildroot limpio
overlay — mi directorio con external-tree. Es aquí donde se almacena todo lo necesario para compilar el firmware utilizando buildroot
README.md — descripción del proyecto y guía en inglés.
run_me.sh — script que prepara el sistema de construcción. Despliega buildroot desde el archivo, conecta el overlay (a través del mecanismo external-tree) y permite seleccionar la placa objetivo para la compilación

[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Selecciona defconfig, presiona A para abortar. Por defecto [0]

Después de esto, solo hay que ir al directorio buildroot-2019.05 y ejecutar el comando make.
Al finalizar la compilación, todos los resultados de la compilación estarán en el directorio 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

Archivos necesarios:

• sdcard.img — imagen del medio para grabar en una tarjeta SD (a través de dd o rufus en Windows).
• qemu.qcow2 — imagen del medio para ejecutar en qemu.
• external.qcow2 — imagen del medio externo para la base de datos
• monitor-0.9-beta.tar.gz — archivo para actualizar a través de la interfaz web

Generación de manuales

No vale la pena escribir la misma instrucción varias veces. Lo más lógico es escribirlo una vez en markdown, luego convertirlo a PDF para descargarlo y a HTML para la interfaz web. Esto es posible gracias al paquete pandoc.

Además, todos estos archivos deben generarse antes de que se compile la imagen del sistema, ya que los scripts post-build son inútiles. Por lo tanto, la generación se realiza en forma de un paquete de manuales. Se puede ver en overlay/package/manuals.

El archivo manuals.mk (que realiza todo el trabajo)

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

El mundo de Linux está cambiando activamente a systemd, y yo también tuve que hacerlo.
Entre las novedades agradables está la disponibilidad de temporizadores. En general, se escribe un artículo separado sobre ellos (y no solo sobre ellos), pero lo contaré brevemente.

Hay acciones que deben realizarse periódicamente. Necesitaba ejecutar logrotate para limpiar los registros de lighttpd y php-fpm. Lo más habitual hubiera sido escribir los comandos en cron, pero decidí usar el temporizador monótono de systemd. Así, logrotate se ejecuta a través de un intervalo de tiempo estricto.

Por supuesto, hay la posibilidad de crear temporizadores que se activen en fechas específicas, pero eso no lo necesité.
Ejemplo de temporizador:

• Archivo del temporizador

  
  [Unit]
  Description=Temporizador del daemon RODOS

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target

- Archivo del servicio llamado por el temporizador:
```bash
[Unit]
Description=Daemon temporal de RODOS

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

Tableros soportados

Asus tinker board — la placa principal en la que todo debe funcionar. Elegida por ser económica y bastante poderosa.

Beaglebone black — la primera placa en la que se verificó el funcionamiento (durante la búsqueda de una placa más potente).

Qemu x86_64 — utilizado para el desarrollo y depuración.

Cómo funciona

Al iniciar, se produce una restauración de configuración en dos etapas:

• ejecución del script settings_restore (a través del servicio). Este restaura la configuración principal del sistema: zona horaria, localización, configuraciones de red, etc.
• ejecución del script prepare (a través del servicio) — aquí se prepara Zabbix, la base de datos, se muestra la IP en la consola.

En el primer arranque, se determina el tamaño de la segunda partición de la tarjeta SD. Si aún hay espacio no asignado, el medio es reformateado, y la partición para datos ocupa todo el espacio libre. Esto se hace para reducir el tamaño de la imagen de instalación (sdcard.img). Además, en ese momento se crea el directorio de trabajo de PostgreSQL. Por eso, el primer arranque con un nuevo medio será más largo que los posteriores.

Al conectar un disco externo, al inicio busca un disco libre y lo formatea en ext4 con la etiqueta external.

¡Atención! Al conectar un disco externo (así como al desconectarlo o reemplazarlo), es necesario hacer una copia de seguridad y restaurar la configuración.

Se utiliza el dispositivo RODOS 5 para monitorear la temperatura. El fabricante proporciona los fuentes de su utilidad para trabajar con este dispositivo. Al encender el sistema, se inicia el temporizador rodos, que ejecuta esta utilidad cada minuto. La temperatura actual se registra en el archivo /tmp/rodos_current_temp, después de lo cual Zabbix puede monitorear este archivo como un sensor.

El medio para almacenar la configuración se monta en el directorio /data.

Al iniciar el sistema y prepararlo para el trabajo, aparece el siguiente mensaje en la consola:

El sistema está iniciando, por favor espere

Después de completar los trabajos preparatorios, se cambiará a la salida de la dirección IP:

ip actual 192.168.1.32
Listo para trabajar

Configuración de Zabbix para monitorear la temperatura

Para monitorear la temperatura, solo se requieren 2 pasos:

• conectar el dispositivo RODOS al puerto USB
• crear un elemento de datos en Zabbix

Abrimos la interfaz web de Zabbix:

• Abrimos la sección Configuración → Hosts
• Hacemos clic en Elementos en la fila de nuestro servidor Zabbix
• Hacemos clic en Crear elemento

Ingresamos los siguientes datos:

• nombre — a su elección (por ejemplo, serverRoomTemp)
• Tipo — agente Zabbix
• Clave — rodos
• Tipo — numérico
• Unidades — °C
• Período de almacenamiento del historial — período de conservación del historial. dejé 10 días
• Período de almacenamiento de tendencias — período de conservación de la dinámica de cambios. dejé 30 días
• Nueva aplicación — Temperatura de la sala del servidor

Y hacemos clic en el botón AÑADIR.

Gestión de la configuración a través de la interfaz web

La interfaz web está escrita en PHP. Tiene funciones básicas:

• visualización del estado del dispositivo
• cambio de la configuración de red
  
• cambio de la contraseña del usuario
• selección de la zona horaria
• copia de seguridad/restauración/restablecimiento a valores de fábrica
• posibilidad de conectar un disco externo
• Actualización del sistema
  

El acceso a la interfaz web está protegido por contraseña. La página de inicio es una guía.

Dirección de la interfaz de zabbix: ${ip/dns}/zabbix
Dirección de la interfaz de administración: ${ip/dns}/manage

Inicio en 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

Este comando iniciará el sistema con 4 núcleos, 2048 RAM, KVM activado, una tarjeta de red en el puente bridge0 y dos discos: uno para el sistema y otro externo para postgresql.

Las imágenes se pueden convertir y ejecutar en Virtualbox:

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

Después, impórtalas en Virtualbox y conéctalas por SATA.

Conclusión

En el proceso, me interesó hacer un producto listo para trabajar — con una interfaz no muy bonita (no me gusta escribirlas), pero funcional y fácil de configurar.

El último intento de instalar zabbix-appliance en KVM demostró la corrección de este paso (después de completar la instalación, el sistema no arranca). Tal vez estoy haciendo algo mal 😉

Materiales

https://buildroot.org/

Fuente: habr.com