lunes, 8 de junio de 2020

Siguiendo los pasos de la semana pasada he consultado mi buzón de entrada del usuario root centralizado y hay cuarenta mensajes del tipo automático.

Excepto un par de ellos que ya me avisan de que vamos a morir todos (y de verdad porque el RAID de backups va empeorando) el resto siguen siendo tontadas que me he propuesto corregir para reducir el ratio ruido-información.

tigercron en barbacana

tiger realiza tareas de seguridad en el sistema. Generalmente no informa si no hay nada de que informar, muy al estilo UNIX, pero lleva tiempo empeñado en el siguiente correo:

--CONFIG-- [con010c] Filesystem 'nsfs' used by 'nsfs' is not recognised as a valid filesystem

Que entiendo entre poco y nada. Buscando información he visto que hay que tocar el archivo /usr/lib/tiger/systems/Linux/2/gen_mounts y va a ser que no. Entiendo que es inofensivo pero dado que existe un archivo (/etc/tiger/tiger.ignore) para ignorar en el informe este tipo de mensajes voy a emplearlo:

Login ID nobody is disabled, but still has a valid shell (/bin/sh)
Login ID mail's home directory (/var/mail) has group mail' write access\. Login ID \w+'s parent directory \(/home\) has groupstaff' write access.
…
Filesystem 'nsfs' used by 'nsfs' is not recognised as a valid filesystem

Ya veremos mañana si ha servido de algo.

Purga de paquetes en sigfrido

Un servidor demasiado antiguo y que se ha ido actualizando y sufriendo cambios en la configuración que hacen que sea difícil entender si en realidad hay problemas y de dónde vienen.

• He purgado todos los paquetes relacionados con zfs y con munin; voy a intentar que todo lo que instale lo emplee ya y no el futuro, así como a documentar el proceso porque tengo la sensación de estar en terreno desconocido en muchas ocasiones.
• También he eliminado el trabajo cron del paquete certbot porque no sé por qué razón se estaba lanzando. Estaba situado en /etc/cron.d/certbot y dentro del mismo ya se avisaba de que era mejor eliminarlo si se empleaba systemd para gestionar el sistema. Y eso es posible que sea el motivo por lo que días atrás tuve problemas por discrepancias entre servidores.

helena

La máquina más longeva de la empresa, aún usada como consulta tres años después de darla de baja como base de la gestión comercial, está ahora quejándose también.

rsync: getaddrinfo: mirror 873: Name or service not known rsync error: error in socket IO (code 10) at clientserver.c(97)

Y ciertamente la máquina mirror.venexma.net ya no existe. Creo que es la única que la usaba y eliminé el registro CNAME en la última purga del DNS interno.

Ahora el problema es otro cuando intento conectar con ella vía SSH:

victor@sarajevo:~$ ssh helena
Unable to negotiate with 192.168.100.4 port 22: no matching host key type found. Their offer: ssh-dss
victor@sarajevo:~$ 

Y es que el sistema es una Suse 7 y creo que apenas se ha actualizado el servidor SSH. Para paliar este problema se puede añadir una excepción en los parámetros de conexión según esta entrada:

victor@sarajevo:~$ ssh -oHostKeyAlgorithms=+ssh-dss helena

Y para que sea más cómodo de emplear se puede definir en el archivo de configuración. La razón de que no esté presente allí me indica que la migración que hice al nuevo disco meses atrás no fue todo lo completa que debía.

Host helena
HostName helena.venexma.net
User ulises
HostKeyAlgorithms +ssh-dss

Respecto al problema inicial con esta máquina es que no encuentra la máquina mirror.venexma.net que alojaba un servidor rsync y que creo (creo) que ahora ese papel lo tiene backups.venexma.net. A ver, digo creo porque aunque estoy seguro de que el servicio está y funciona no tengo idea de si la configuración es la correcta para aceptar conexiones desde helena. Mañana lo veré.

erp.venexma.net

Esta máquina ha presentado los siguientes problemas esta mañana:

• Avisos del programa ocsinventory-agent: purgado también hasta que no pueda centrarme en ello.
• Los correos enviados a root lo hacían hacía root@venexma.es. Corregido.
• monit ha dado un aviso de falta de conexión con el servicio SSH el viernes noche y ha tenido que reiniciarlo.

El mensaje de error de monit ha sido

failed protocol test [SSH] at [localhost]:22 [TCP/IP] -- SSH: error receiving identification string -- Resource temporarily unavailable

Y el problema con el usuario root es que el sistema es un Ubuntu (desactualizado también desde hace años) y que emplea postfix para enviar el correo. Según este artículo se debe efectuar un cambio en el archivo /etc/aliases -como es costumbre- y luego llamar de verdad al programa newaliases.

Digo de verdad porque en los sistemas con Exim4 los alias se cargan cuando se necesitan y no se mantienen una base de datos extra. Por eso basta con tocar el archivo de texto para que los cambios sean utilizados en la siguiente operación.

Correos internos largos

Pues sí, algo que advertí la semana pasada y que cambié para que se aceptasen ya está funcionando. Los mensajes de hoy han debido ser (espero) notificaciones de antiguos envíos fallidos.

Ahora bien, para que los informes de logwatch sean útiles es preciso retocarlos porque son un muro de textos y cifras con pocas secciones jugosas.