Empezamos fino. Tenía pensado dedicarme a cerrar asuntos de administración e infraestructuras (pomposo nombre) y resulta que tengo que apagar fuegos.

Servidor ss.venexma.net

Aquí sí que me he llevado una buena sorpresa. Estas máquinas llevan instalado un paquete mío llamado recolector que se encarga de recopilar información en un formato plano, o lo más plano posible, para que sean recuperadas por el sistema de copias de seguridad y estén más a mano.

Hasta ahora he tenido varios problemas de todo tipo con ellas pero eran más bien comprensibles. Hoy y ayer, sin embargo, veo que la recolecta que comienza a las nueve de la noche y que dura diez o quince minutos a lo sumo está atascada hasta la hora de inicio de trabajo o incluso más. Tanto que hay que matar los procesos. ¿ El atasco ? En el volcado de la base de datos de PostgreSQL y su proceso de compresión. Sin más pistas por ahora. No se me ocurre nada más que ver qué opciones estoy empleando con pg_dump y ver si es posible que se quede congelado por alguna otra circunstancia como un bloque a nivel de base de datos.

Una vez que he detenido el proceso de recolección me he dado cuenta de que la carga del sistema sigue estando disparada: entre 3,5 y 5,9 (más o menos). Me he puesto a investigar y he visto que es cosa del acceso a disco. CPU relajada y feliz, memoria más que descargada y procesos que no sobrepasan el 5% de uso. ¿ Entonces ? Pues observando con el programa iotop he visto cosas como la siguiente:

Esto es, el disco ocupado casi el 100% del tiempo y ráfagas de lecturas continuas que superan los 100M/s. Pues mira, ahí está el problema. O al menos el causante. Ahora a ver qué hace odoo, qué hace PostgreSQL o qué hacen los dos para estar continuamente así. Y supongo que el problema anterior viene de ahí.

Fotocopiadora Kyocera y el envío de correos desde el escáner

Este problema me lo comunicaron ayer. No es nuevo y tiene ya unos cuantos días pero cuando se es tímido no se puede esperar mucho más.

La fotocopiadora tiene la opción de escanear documentos, empaquetarlos en un PDF y enviarlos por correo electrónico. Esto es lo que falla. Y creo que falla desde que migré el servidor a Debian 11. No he querido que la máquina enviase directamente a Google por no tener que definir una cuenta de conexión. Me limito a enviarlo al servidor interno y de ahí, tras ser encolados, salen hacia Google.

Y, claro, Google como que pasa de nosotros y muchos de ellos vuelven a sufrir el misterioso corte en la transmisión TLS y nos dejan colgados. Supongo que tendré que desviar el correo hacia Google a través Gandi como he hecho en otras instalaciones. No me hace gracia porque pierdo control sobre entregas pero tampoco es que vea otra.

El caso es que algunos mensajes llegan. Otros no, se interrumpen.

Servidor sigfrido.venexma.net

Inspeccionando la cola de mensajes en el servidor interno de correo he visto que hay muchos que están atascados porque la dirección de entrega no existe. Y es verdad, son direcciones que en esa máquina no tienen ningún sentido. Al parecer algunos de los servidores virtuales no están correctamente configurados para enviar los correos hacia root. Lo hacen con la dirección root@$(hostname -f) en lugar de root@venexma.net que es la que recibe todos los mensajes de este tipo.

He alterado la configuración del programa nullmailer que utilizo en todas ellas para que envíen correctamente y sí que funcionan. Las máquinas afectadas son: monitor.venexma.net, docs.venexma.net y almacen.venexma.net. Esas por el momento. Ahora limpiaré la cola de mensajes lo más que pueda porque no veo otra forma (ni interés) en que se cambie la dirección de entrega de mensajes ya encolados.

La forma de limpiar los mensajes ha sido:

# exim4 -Mrm $(exiqgrep -z -i -r 'root')

Servidor docs.venexma.net

Estaba recibiendo mensajes de error del proceso que crea instantáneas del sistema de archivos btrfs en esta máquina pero veía que el trabajo se estaba haciendo. He descubierto que el que funcionaba era el trabajo de root. El que fallaba era una versión antigua en el directorio /etc/cron.d. He movido uno sobre otro y lo he retocado para añadir el usuario porque no entendía nada de lo que pasaba.

Servidor backups.venexma.net

• He desactivado la copia de seguridad de la máquina proyectos.venexma.net porque aún no quiero ponerla en marcha. Tampoco es que esté muy seguro, dado el ritmo que llevo últimamente, de que me haga falta un gestor de proyectos. Así que de momento parado.
• Las copias de docs.venexma.net están fallando continuamente. No me gusta un pelo porque los archivos y directorios están -son unas 450 gb extraídas- pero la copia falla de forma muy rara. Lo aparco de momento.

El registro de transferencia es la siguiente:

2022-01-12 06:00:00 Renaming /var/lib/backuppc/pc/docs.venexma.net/XferLOG.1.z -> /var/lib/backuppc/pc/docs.venexma.net/XferLOG.1.z.tmp
2022-01-12 06:00:09 incr backup started for directory /etc
2022-01-12 06:00:29 incr backup started for directory /usr/local/sbin
2022-01-12 06:00:29 incr backup started for directory /usr/local/bin
2022-01-12 06:00:30 incr backup started for directory /root
2022-01-12 06:00:30 incr backup started for directory /home
2022-01-12 06:00:31 incr backup started for directory /srv
2022-01-12 06:06:04 Got fatal error during xfer (rsync error: unexplained error (code 255) at io.c(226) [generator=3.1.3.0])
2022-01-12 06:06:09 Backup aborted (rsync error: unexplained error (code 255) at io.c(226) [generator=3.1.3.0])

Varios

• Recibo un mensaje de gandi con el aviso de la renovación del dominio suelaexpress.com. Como no tenemos una tarjeta de crédito asociada a la empresa (y mira que tenemos cuatro dominios con ellos y sería útil, pues no) he tenido que pagarla yo de mi bolsillo (14€) y pasarle la factura proforma al contable para que me la abone.

El modelo 347: la tragedia anual

Ya ni recuerdo el número de veces que me he enfrentado a este problema. No debería serlo porque en el fondo son habas contadas pero lo es. Este año he tenido que volver a ponerme a los mandos y ahora mismo estoy mentando a los antepasados de los mercenarios que montaron el pollo que tenemos montado. Como lo que más corre prisa es generar las cartas para avisar a clientes y proveedores de sus cifras y poder contrastarlas, así que me encuentro enfangado en el infierno de módulos y submódulos de odoo y su estúpido modelo orientado a objetos y no sé ni dónde estoy ni a dónde voy a llegar.

De momento me he dado cuenta de que tras la migración no funciona ninguno de los programas web de acceso a las bases de datos y, demonios, me hacen mucha falta.

Si esta tarde puedo avanzar lo apunto aquí.