"Después del juego es antes del juego"
Sepp Herberger

miércoles, 29 de junio de 2022

Problema con las firmas de paquetes en Manjaro.

Tras varios años sigo usando Manjaro Linux en muchos de mis PC personales, que llevan todo este tiempo sin una reinstalación ya que al ser una distribución rolling release siempre está a la última. Demasiado a la última algunas veces.

Esto no evita problemas con la paquetería, sobre todo si te quedas varios meses sin actualizar, pero hasta ahora siempre he salido airoso de los pequeños líos que se montan ocasionalmente.

Esta semana me puse a actualizar una máquina y me encontré con este nuevo error:
# pacman -Syyuu
....
....
error: Error de GPGME: No hay datos
error: no se pudo actualizar core (base de datos no válida o dañada (firma PGP))
....
....
Mirando en Internet vi muchos consejos: refresca la lista de mirrors, refresca los países desde dónde descargas, etc. Ninguna funcionaba hasta que encontre esta solución:
# rm -Rf /var/lib/pacman/sync
# rm -Rf /tmp/pamac/dbs/*  
# pacman -Syu
# pamac update
Y listo, funcionó.

Aunque pude actualizar luego me encontré con otro problemilla. La compilación-instalación del paquete:
# pamac build  mjpg-streamer-git 
Me daba de nuevo el error "error: 'mjpg-streamer-git-1:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst': paquete sin la firma exigida" cuando iba a instalarlo tras la descarga y compilación. Este tipo de problemas suelen ser cuestiones puntuales con los repositorios pero en este caso tenía prisa. Solución:
# pamac build  -k mjpg-streamer-git 
Esto descarga y compila el paquete, pero además deja una copia del paquete instalable binario en /var/cache/pamac/mjpg-streamer-git-1\:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst. Vamos a intentar instalarlo a mano:
# cp /var/cache/pamac/mjpg-streamer-git-1\:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst /root
# pacman -U /root/mjpg-streamer-git-1\:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst 
error: 'mjpg-streamer-git-1:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst': paquete sin la firma exigida
Nada, sigue fallando. Para saltar el problema hay que desactivar la comprobación de firmas para paquetes que se instalen localmente. Editamos el fichero /etc/pacman.conf y cambiamos la línea:
LocalFileSigLevel = Never
Tras esto, ya podemos instalar el paquete sin contratiempos con:
# pacman -U /root/mjpg-streamer-git-1\:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst 
Tras esto podemos poner LocalFileSigLevel con su valor anterior o dejarlo a Never, según nos parezca.

Out!

martes, 28 de junio de 2022

Gestión de fechas en fotos.

Voy a recopilar varios comandos y scripts para trabajar con las fechas de las fotos y facilitar su ordenación cuando trabajamos con gran cantidad de ellas. Supongamos un fichero denominado IMG20220414185751.jpg, en cuyo nombre aparece la fecha en que se tomó: 14/04/2022 a las 18:57:51 horas.

Aparte de en el nombre, la fecha se guarda en los metadatos EXIF de la foto, dentro de los metadatos binarios del fichero de imagen. Podemos consultarlo con:
# exiftool IMG20220414185751.jpg | grep "Create Date"
Create Date                     : 2022:04:14 18:57:51
Create Date                     : 2022:04:14 18:57:51.764000
Luego con "ls -l" podemos ver la fecha de modificación del fichero que contiene la foto (llamada ctime en el mundo Unix). Normalmente coincide con la fecha EXIF, pero si lo copiamos de un dispositivo a otro y/o lo modificamos con un editor de imágenes esta fecha puede cambiar, como vemos aquí:
$ ls -l IMG20220414185751.jpg
-rw-r--r-- 1 manjaro manjaro 2499469 jun 27 06:38 IMG20220414185751.jpg
Si queremos que la fecha EXIF se copie a la fecha ctime podemos usar el comando:
$ exiv2 -T rename IMG20220414185751.jpg
$ ls -l IMG20220414185751.jpg
-rw-r--r-- 1 manjaro manjaro 2499469 abr 14 18:57 IMG20220414185751.jpg
Si queremos que la fecha EXIF se copie al nombre del fichero podemos usar un formato como:
# exiv2  -r 'IMG%Y%m%d%H%M%S' rename fichero.jpg
# ls -l IMG20220414185751.jpg
-rw-r--r-- 1 manjaro manjaro 2499469 abr 14 18:57 IMG20220414185751.jpg
Por ultimo, si la fecha EXIF ha sido elminada y queremos cambiar el ctime del fichero extrayendolo de su nombre el comando sería:
# fichero="IMG20220414185751.jpg"
# fecha=$(echo ${fichero:3:8})
# touch -a  -m -t "${fecha}0100" $fichero
# ls -l IMG20220414185751.jpg
-rw-r--r-- 1 manjaro manjaro 2499469 abr 14 01:00 IMG20220414185751.jpg
Y aquí paro porque con estos comandos tenemos suficiente para clasificar cronológicamente la selección de fotos. Por supuesto hay muchas otras combinaciones que me quedo en el tintero, como escribir la fecha EXIF (usando exiftool) y operaciones por el estilo que quizá veamos en otra ocasión.

lunes, 6 de junio de 2022

Zabbix (III): creación de plantilla con items y triggers para agentes Linux.

Después de tener montado el Zabbix, van surgiendo nuevas necesidades para monitorizar nuestros clientes. En esta entrada voy a ver como he creado una plantilla para los Linux del IES, que me permite monitorizar varias cosas no previstas en la plantilla por defecto. Lo que haremos en primer lugar es crear la plantilla "Template IES Linex"
A continuación vamos definir los ítems que extraigan datos del cliente. Estos ítems son pequeños fragmentos de código con comandos de terminal Unix. Lo podemos hacer de dos maneras:
  1. Definir el código en el cliente dentro de /etc/zabbix/zabbix_agentd.conf.d/blablaba.conf y luego referenciarlo en el servidor Zabbix.
  2. Definir el código en el servidor Zabbix, dentro del mismo item usando system.run[...]
En el primer caso vamos a crear, por ejemplo, un ítem llamado "puppetcheck" que nos diga si la última ejecución de puppet ha acabado con éxito. Para ello lo primero es programar las instrucciones que hagan eso. Hay varias maneras de averiguarlo, como por ejemplo esta:
# cat /var/lib/puppet/state/last_run_report.yaml | grep -i -e "failed: true" -e "status: failed" | wc -l 
Esto nos devolverá 0 si no hay ningún error y >0 si hay algun error en la última ejecución de puppet. Esta secuencia de comandos ejecutada como usuario root funciona, pero hay que tener en cuenta que el agente Zabbix se ejecuta con el usuario zabbix y eso nos puede causar problemas. En este caso concreto el problema era el acceso al fichero /var/lib/puppet/state/last_run_report.yaml del cliente.

Para que el agente Zabbix pueda llegar hasta allí tenemos que echar mano de sudoers:
# cat /etc/sudoers.d/puppetcheck
Cmnd_Alias CHECKPUPPET = /bin/cat /var/lib/puppet/state/last_run_report.yaml
zabbix ALL=(ALL) NOPASSWD: CHECKPUPPET
Una vez hecho esto, ya podemos definir el parámetro que usará el ítem en el cliente:
# cat /etc/zabbix/zabbix_agentd.conf.d/checkpuppet.conf
UserParameter=system.puppetcheck,sudo cat /var/lib/puppet/state/last_run_report.yaml | grep -i -e "failed: true" -e "status: failed" | wc -l
. Una vez definido el item en los clientes, lo añadimos a la plantilla en el servidor Zabbix:
Además de crear el ítem, le añadimos una regla de preprocesamiento llamada "Discard unchanged with a heartbeat" que evita que se guarden valores repetidos consecutivos del ítem en el registro histórico. De esta manera solo guardamos el ítem cuando cambia su valor respecto a la actualización anterior (o, en este caso concreto, han pasado 12 horas desde la última actualización). La finalidad de esto es evitar guardar valores repetidos consecutivos de los ítems en toda la base de datos histórica.
Finalmente creamos un trigger para que avise cuando hay un error. En este caso vemos si hay error en puppet durante las 3 últimas actualizaciones del ítem:



Con esto tenemos el pack completo: parámetro defínido en el cliente Zabbix, asociado a un ítem en el servidor Zabbix y con un trigger que nos avisa este tiene un valor determinado.

La otra otra opción consiste en definir en el servidor Zabbix el ítem con el código a ejecutar en el cliente remoto. Por ejemplo, un ítem que muestre en cada momento que usuario ha hecho login en la máquina, definido así:
Parent items: Template Linux IES
Name: LoggedUser
Type: Zabbix agent
Uptdate time: 1m
Key: system.run["who | grep -v root | cut -d' ' -f1"]
El problema de este tipo de ítems es que debemos estar seguros de que el cliente Zabbix permite la ejecución remota de comandos, ya que si no es así el ítem no se actualizará nunca. De igual manera, si el agente se ejecuta en una máquina que está detrás de un firewall o un NAT tampoco podremos llegar a ella para ejecutar el comando desde el servidor Zabbix.

En este ítem LoggedUser tambien añadiremos una regla de preprocesamiento del tipo "Discard unchanged", para evitar guardar de forma repetida el usuario logado cada vez que se actualiza el ítem, y solo guardarlo cuando cambia entre una actualización y la siguiente.

Por último, comentar que una vez hemos definido los ítems tenemos la posibilidad de probarlos desde la línea de comandos para ver que tal funcionan. En el cliente local:
# zabbix_agentd -t system.puppetcheck
O de forma remota:
# zabbix_get -s 172.X.Y.Z -p 10050 -k system.puppetcheck
Bueno, pues con esto ya tenemos el armazón para añadir ítems y triggers a saco en nuestros clientes.
Aquí están los 3 camaradas taikonautas que han subido estos días en la Shenzou 14 para finalizar el montaje de la Estación Espacial China. Recordemos que esta estación existe porque USA se negó a dar acceso a China a la Estación Espacial Internacional, por lo que los chinos decidieron montarse su propia estación mastodóntica (que a diferencia de la de Bender, no tendrá casinos ni furcias (*)) adquiriendo en el proceso una experiencia y know-how que les vendrá de perlas.

Es lo que pasa cuando no se quiere colaborar internacionalmente. Avisados quedamos.

(*)