RTFM o de los malos hábitos

[ Advertencia: Esta es una entrada técnica. Absténganse de leerla los no interesados en los entresijos de Unix y sistemas afines. ]

Casi todo usuario de Linux o sistemas semejantes tiene que ser a la vez y en alguna medida ---lo quiera o no--- administrador de sus propias máquinas. Lo malo es que empieza a ser demasiado común emprender tales tareas administrativas con la mente idiotizada del luser, y así nos va, hasta que nos damos cuenta de nuestro pecado.

Os cuento un ejemplo de esto mismo que me acaba de suceder. Yo, convertido en luser, y perdiendo horas sin tino, por no darme cuenta, de que, cuando hay que ser admin, no hay coartadas que valgan.

Todo empezó con mi cortafuegos ...

El caso es que tengo una máquina independiente funcionando desde hace unas semanas como cortafuegos.

Una de las primeras cosas que quería hacer era que los logs del cortafuegos me llegasen a mi estación de trabajo, no sólo por razones de seguridad, sino también de comodidad. [ Sí, ya sé, lo mejor es que estén en un único servidor de logging, pero mi presupuesto no da para tanto, de momento ]. Además de eso quería utilizar logcheck ---por razones que omito--- como analizador de los registros.

El asunto no parecía difícil ---y no lo es, si uno se conforma con las configuraciones estándar. Pero a mí me interesaba una opción poco convencional.

logcheck envía mensajes de correo al administrador cada cierto tiempo (via cron), sobre los registros almacenados en los /var/log/* que uno desee analizar. En debian ---que es mi distro--- los ficheros de registro que se quiere que logcheck analice se definen en /etc/logcheck/logcheck.logfiles. Ahora bien, lo que a mí me interesaba es que logcheck me enviase mensajes diferentes para cada máquina, o sea, uno para la máquina local y otro distinto para el cortafuegos o cualquier otra máquina remota.

El problema empezaba con que los registros del cortafuegos iban al mismo fichero que el de mi máquina local. Lo primero que pensé fue en sustituir syslog por syslog-ng, el cual permite una definición más versátil de los ficheros de destino, por ejemplo, permite (gracias a la variable $HOST) crear ficheros de logs diferentes para distintas máquinas. Así lo hice, y tras configurar adecuadamente syslog-ng tenía un fichero de registro independiente para los logs procedentes de mi cortafuegos. Ya sólo faltaba que logcheck analizara también ese fichero y quedase configurado para que me enviase, además de un mail sobre mi máquina local, otro distinto sobre mi cortafuegos.

Hasta aquí los preliminares. Y ahora empieza la anécdota propiamente dicha. Busqué rápidamente en la documentación de mi distribución del paquete logcheck ---esto es lo primero que leo cuando instalo un paquete que no conozco--- por si existía alguna información para lograr mi objetivo. No encontré nada ahí, y me fui directamente a google. Y ya se sabe que googlear puede consumir mucho tiempo. El caso es que tampoco encontré nada en google. O sí, encontré un programa newlogcheck, que envía cada cierto tiempo un único mensaje con un sumario del análisis realizado, dividido en tantas secciones como máquinas emisoras de registros se quieran controlar; algo parecido, pues, a lo que yo pretendía.

Pensé para mis adentros que si alguien se había tomado la molestia de escribir esto, había pocas esperanzas de que logcheck, por sí mismo y sin modificaciones del código, pudiera hacer lo que yo deseaba. Parece que tenía sólo dos opciones: adoptar newlogcheck o desisitir. No me apetecía introducir un nuevo programa en la jerarquía de mi distribución, pero tampoco desistí. Porque, de repente, algo en mi interior se sublevó: "pero, chaval, si ni siquiera te has leído con atención la página de manual de logcheck. Quién te ha visto y quién te ve". Era mi propia conciencia BOFH irritada, con razón, contra la pereza y desidia de mi personalidad luser. Hice caso a mi BOFH y me leí con atención la página logcheck(8). Y ahí estaba la respuesta a golpe de vista. Con un poco más de trabajo, que consistió en pasar por las páginas cron(8) y crontab(5), tenía el problema resuelto. Algo que, si lo hubiese hecho desde el principio, me habría llevado no más de media hora de investigación y ese algo menos de un minuto que cuesta añadir esta línea a /etc/crontab [ Debe ser una única línea, aunque puede aparecer dividida en los navegadores. El nombre/IP real de la interfaz de red local del cortafuegos ha sido omitido ]:

4 * * * * logcheck if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck -l /var/log/[mi-firewall]/kern.log -H firewall; fi


La anécdota concreta es lo de menos, pero sí importa ---y mucho--- la moraleja: "el luser es el único ser que tropieza siempre en la misma piedra: no dejes que tu estúpido Jekyll se apodere de tu 'buen' Hyde". O, dicho de modo más lacónico, pero no menos expresivo: RTFM!!