Comprobación del estado de NFS, Samba, chrony, Unbound y Kea desde la línea de comandos: lista de verificación

Objetivo

Confirmar desde una shell que cada servicio de infraestructura tratado en esta serie está en ejecución, es accesible y se encuentra en el estado esperado. Es una comprobación de cinco minutos tras un despliegue o un reinicio, o antes de escalar un informe de caída.

Requisitos previos

Acceso por shell al servidor (y, para un par de comprobaciones, a un cliente que pueda alcanzarlo) y las herramientas de cliente correspondientes instaladas (rpcbind/nfs-utils, samba-common-bin, chrony, unbound, kea-*).

Pasos

1. NFS: en un servidor que todavía ofrece NFSv3, showmount -e <server> ejecutado desde un cliente muestra la lista de exportaciones del servidor NFS, y rpcinfo -p <server> puede mostrar la lista de todos los programas RPC registrados (nfs, mountd, nlockmgr). En un servidor solo NFSv4 ambos comandos fallan por diseño (no existe el protocolo MOUNT y rpcbind suele estar enmascarado); en su lugar, ejecute exportfs -v en el servidor y ss -tn state established '( sport = :2049 )' para ver los clientes conectados.
2. Samba, en el servidor como root: smbstatus es un programa muy sencillo que lista las conexiones actuales de Samba; ejecútelo sin argumentos para ver en vivo los clientes conectados, los archivos abiertos y los bloqueos. Un resultado vacío y sin errores en un servidor que nadie está usando en ese momento es un resultado correcto, no un problema.
3. Hora, en el servidor y en cualquier cliente: chronyc tracking es el comando que muestra parámetros sobre el rendimiento del reloj del sistema (ID de referencia, stratum, desfase). Conviene investigar si el desfase de System time crece en comprobaciones repetidas o si Leap status indica Not synchronised. En un servidor NTP, chronyc clients (como root) muestra qué hosts lo están consultando.
4. Resolución DNS, en el resolvedor como root: unbound-control status muestra el estado del servidor y termina con un código distinto de cero si el demonio no escucha en su puerto de control. Es una forma rápida de distinguir entre «Unbound está caído» y «Unbound está activo pero responde mal»; este último caso requiere en cambio una prueba con dig contra él.
5. DHCP, en el servidor: compruebe la fecha de modificación del archivo de concesiones y revise sus últimas entradas (el artículo de esta serie sobre Kea indica la ubicación predeterminada). kea-shell, que ofrece un cliente REST para los servidores Kea, puede además enviar al demonio en ejecución comandos como status-get si hay configurado un endpoint de control HTTP (el Control Agent o, en Kea 3.0 y posteriores, el socket de control HTTP del propio demonio); las consultas de concesiones requieren además el hook lease_cmds.
6. Registre el resultado de cada comprobación con una marca de tiempo en un lugar que pueda ver una segunda persona, antes de concluir que un servicio está sano o averiado a partir de una única ejecución.

Resultado esperado

Cada comando responde con rapidez y su salida coincide con el estado actual conocido del servicio. Un demonio detenido suele hacer fallar de inmediato su comprobación local (conexión rechazada), mientras que una comprobación que se queda colgada apunta más bien a un problema de cortafuegos o de enrutamiento.

Límites y base de verificación

Un estado correcto en una de estas herramientas confirma que el demonio está vivo y responde en su propia interfaz de control, no que funcionen todas las rutas que usan los clientes. Por ejemplo, showmount -e no demuestra que un montaje real tenga éxito, solo que se está sirviendo la lista de exportaciones. Cuando un informe indique que un servicio es inaccesible, ejecute estas comprobaciones desde más de un punto de observación (en local y desde un cliente), porque una comprobación local en el servidor puede tener éxito mientras un problema de cortafuegos o de enrutamiento sigue bloqueando a los clientes reales.