4.3.1.1. Sistema tradicional

En este sistema los registros se almacenan bajo /var/log a través de una doble vía:

1. Los mensajes de algunas aplicaciones se envían a un demonio encargado de procesarlos para que este los escriba en el log correspondiente.

2. Otras aplicaciones escriben directamente los mensajes en sus propios ficheros de registro (que, por lo general, también están bajo /var/log).

En los sistemas debian este demonio se llama rsyslog, que es una variante avanzada del tradicional syslogd. El resto del epígrafe se dedicará a describir cómo se clasifican los logs y qué hace con ellos el deminio que los gestiona.

4.3.1.1.1. Clasificación

Es obvio que todos los mensajes ni tienen la misma naturaleza ni tienen la misma gravedad. Por este motivo, cada mensaje es de una determinada facility (o sea, de una determinada categoría o naturaleza, si queremos traducir libremente al término inglés) y de un determinado nivel.

Según su naturaleza los mensajes pueden ser de los siguientes tipos:

Categorías (facility)

Código	Término	Linux	Descripción
0	kern	Sí	Mensajes del núcleo
1	user	Sí	Mensajes de procesos de usuario
2	mail	Sí	Mensajes del sistema de correo
3	daemon	Sí	Mensajes de los demonios del sistema
4	auth	Sí	Mensajes de procesos de autenticación[1]
5	syslog	Sí	Mensajes del propio sistema de logs
6	lpr	Sí	Mensajes del sistema de impresión
7	news	Sí	Mensajes del sistema encargado de acceder a USENET[2]
8	uucp	Sí	Mensajes relacionados con el antiguo protocolo UUCP
9	cron	Sí	Mensajes de los demonios de planificación de tareas.
10	authpriv	Sí	Mensajes de procesos de autenticación
11	ftp	Sí	Mensaje del servicio de FTP.
12	ntp	No	Mensajes del servicio NTP.
13	logaudit	No	Mensajes del servicio audit.
14	logalert	No	log alert
15	clock	No	Mensajes del demonio del reloj.
16	local0	Sí	Uso local (0)
17	local1	Sí	Uso local (1)
18	local2	Sí	Uso local (2)
19	local3	Sí	Uso local (3)
20	local4	Sí	Uso local (4)
21	local5	Sí	Uso local (5)
22	local6	Sí	Uso local (6)
23	local7	Sí	Uso local (7)

Y según su nivel:

Nivel (level)

Valor	Término	Descripción
0	emerg	Aciso de circunstancia que vuelve inservible el sistema.
1	alert	Aviso de circunstancia que debe ser inmediatamente subsanada.
2	crit	Aviso de error crítico.
3	err	Aviso de error.
4	warning	Advertencia de que algo puede ir mal o acabar mal.
5	notice	Notificación de que ocurre algo anormal.
6	info	Notificación de funcionamiento normal.
7	debug	Notificaciones para depurar el comportamiento de un programa.

4.3.1.1.2. Ficheros

Bajo /var/log hay distintos ficheros: algunos debidos a la activdad de servicios que escriben sus propios registros al margen de rsyslogd y otros debidos a la actividad de este.

En principio, rsyslog registra todos los mensajes en el fichero /var/log/syslog, pero mediante su configuración puede hacerse que los mensajes dependiendo de su categoría y nivel se escriban en uno u otro fichero particular. Lo habitual es lo siguiente:

syslog

Contiene todos los mensajes, excepto los de autenticación.

auth.log

Contiene los mensajes de autenticación.

kern.log

Contiene todos los mensajes del núcleo[3].

messages

Contiene los mensajes del núcleo de los niveles 4-6 (warning, notice e info).

daemon.log

Contiene los mensajes de la facility daemon.

mail.log

Contiene todos los mensajes relativos al funcionamiento del servicio de correo. Hay otros, mail.info, mail.err y mail.warn que almacenan su facility correspondiente.

user.log

Contiene todos los mensajes de las aplicaciones de usuario.

lpr.log

Contiene todos los mensajes referentes al servicio de impresión.

Esta es la configuración pretederminada en debian. El resto de ficheros que encontramos, bien se debe a que se haya alterado esta configuración, bien a que haya otros servicios que registren por su cuenta. Dentro de /var/log y entre los ficheros que no gestiona rsyslog, se cuentan:

btmp

Que registra los accesos fallidos al sistema.

wtmp

Que registra los accesos al sistema.

Estos ficheros, a diferencia de los restantes, tienen un formato binario y pueden leerse a través del comando utmpdump:

# utmpdump /var/log/btmp | more

4.3.1.1.3. Consulta

Los registros son ficheros de texto plano de modo que el acceso a los mensajes se puede realizar con cualquier orden que permite acceder a su contenido. El simple cat (o more o less, si se quiere paginar) sirve para este propósito. Sin embargo, estos ficheros suelen contener gran cantidad de mensajes de distintos servicios, por lo que lo más adecuado es buscar herramientas que nos permitan filtrar mediante el uso de expresiones regulares.

Para esta labor de filtrado, conviene conocer cuál es el formato que el demonio da a estos mensajes. Tal formato se puede configurar al gusto, pero rsyslog tiene configuradas algunas plantillas de las cuales la predefinida en debian es RSYSLOG_TradicionalFileFormat, que presenta el siguiente aspecto:

<fecha y hora> <nombre_maquina> <nombre_proceso>[<PID>]: <texto del mensaje>

Cuando filtramos, necesitamos conocer cuál es el fichero adecuado y cuál es el conjunto de mensajes que deseamos ver. Por ejemplo, si nuestra intención fuera mirar los mensajes que genera el servidor DHCP, podríamos filtrar del siguiente modo:

# egrep '\bdhcpd\b' /var/log/syslog | more

La información que obtenemos de los registros puede ser muy precisa: basta con ser capaz de formar la expresión regular adecuada. Por ejemplo, todas las IP que ha concedido el servidor DHCP podrían mostrarse de esta forma:

$ sed -r '/\bdhcpd\b.*DHCPACK on/!d ; s:.*DHCPACK on ([^ ]+).*:\1:' /var/log/syslog | sort | uniq

Aunque hay que tener cierto espíritu crítico con lo obtenido. Saldrán en este listado todas las IPs concedidas desde que se empezó a escribir el fichero, con lo que el listado puede no coincidir en absoluto con direcciones IP ocupadas.

4.3.1.1.4. Configuración

Nota

Para hacer probaturas es muy útil el comando logger que permite enviar al demonio mensajes de la categoría y nivel que indiquemos:

$ logger -p mail.info -s "Esto es un mensaje manual que escribo yo"

El demonio lee su configuración del fichero /etc/rsyslog.conf. Sin embargo, puede tener una directiva IncludeConfig que permite leer el contenido de otros ficheros, de suerte que es común que también exista un directorio /etc/rsyslog.d, en el que incluir configuración adicional de forma modular.

Otro aspecto a tener en cuenta en la definición de este fichero es que desde la versión 6, hay dos sintaxis para el fichero, la tradicional y una nueva.

4.3.1.1.4.1. Tradicional

Existen tres tipos de líneas:

• Los comentarios, que todas aquellas líneas que empiezan por un asterisco.

• Las directivas que empiezan por un dolar.

• Las reglas que permiten indicar qué hacer con cada mensaje.

4.3.1.1.4.1.1. Directivas

Hay de muy diversos tipos. Algunas muy útiles son:

1. Hacer escuchar al demonio en un socket adicional (útil cuando tenemos demonios enjaulados):

   $AddUnixListenSocket /var/spool/postfix/dev/log
   

2. Define el propietario y los permisos de los ficheros (y directorios) que puedan crear las acciones:

   # Definimos esta máscara inicial para que
   # los permisos definidos a continuación sean
   # los que expresamente indicamos.
   $Umask 0000
   $FileOwner root
   $FileGroup adm
   $FileCreateMode 0640
   $DirCreateMode 0755
   

   Estas directivas afectan a todas las acciones que tengan por debajo. Pueden volver a definirse más adelante otra vez y, en ese caso, afectarán a las acciones que se añadan a continuación. Por ejemplo:

   $FileCreateMode 0640
   *.*     /var/log/log1
   
   $FileCreateMode 0644
   *.*     /var/log/log2
   

   log1 se creará con permisos 0640 y log2 con permisos 0644.

3. Cargar los ficheros contenidos en /etc/rsyslog.d:

   $IncludeConfig /etc/rsyslog.d/*.conf
   

4. Define una plantilla predeterminada para el formato de línea de los ficheros:

   $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
   

4.3.1.1.4.1.2. Reglas

Las reglas indican qué se hará con cada mensaje. Cada regla consta de dos partes: el selector, que indica a qué mensajes afecta; y la acción, qeu indica qué hacer (habitualmente, escribirlos en un fichero de registro bajo /var/log.

Para seleccionar mensajes se usan la categoría y el nivel:

• Todos los mensajes:

  *.*
  

• Todos los mensajes de nivel info:

  *.=info
  

• Todos los mensajes hasta el nivel info (es decir, que sólo quedan fuera los de nivel debug*):

  *.info
  

• Todos los mensajes de la categoría mail:

  mail.*
  

• Los mensajes de la categoría mail y la prioridad info:

  mail.=info
  

• Todos los mensajes de las categorías mail y news:

  mail,news.*
  

• Los mensajes de las categorías mail y news hasta notice:

  mail,news.notice
  

• Los mensajes de la categoría mail y nivel info, y de la categoría news y nivel err:

  mail.info;news.=err
  

Este último ejemplo muestra como hacer la unión de dos selectores independientes: separarlos con punto y coma. Ahora bien hay forma también de hacer la diferencia entre dos selectores. Para ello hay que seleccionar primero un conjunto de mensajes y, tras el punto y coma, seleccionar otro conjunto que lo contiene, añadiendo a la parte correspondiente al nivel la exclamación (!) o el nivel especial none, que implica que se desechan todos los mensajes de la categoría:

• Todos los mensajes exceptos los de authpriv y auth:

  *.*;auth,authpriv.none
  

• Todos los mensajes, excepto los de la depuración:

  *.*;*.!=debug
  

• Todos los mensajes, excepto los de news hay que estén entre el nivel emerg al nivel warning:

  *.*;*.!warning
  

Por su parte la acción, si lo que se quiere es enviar los ficheros exige escribir la ruta absoluta. Una regla completa quedaría pues así:

auth,authpriv.*       /var/log/auth.log

A veces se encuentra antepuesto un signo menos (-) a la ruta. Esto indicaba que se quería deshabilitar la sincronización del fichero en cada escritura. En las versiones modernas de rsyslog la sincronización está deshabilitada por defecto, con lo que el signo, no tiene ninguna relevancia.

Es importante tener presente que el hecho de que un mensaje se seleccione en una regla, no significa que el demonio ejecute la acción y deje de probar las reglas siguientes. Por ejemplo, las líneas:

auth,authpriv.*        /var/log/auth.log
*.*                    /var/log/syslog

provocarían que los mensajes relacionados con la autenticación se escribieran también en /var/sys/log. Ahora bien, si se usa como acción la virgulilla (~), entonces sí se desechan los mensajes:

auth,authpriv.*        /var/log/auth.log
auth,authoriv.*        ~
*.*                    /var/log/syslog

Sí impediría que se escribieran los mensajes en el segundo registro (y en todos los que se mentaran sucesivamente).

Además, se puede sustituir el selector por el ampersand (&), lo que significa que para la nueva acción se usará el mismo selector que para la anterior. las siguientes líneas tienen el mismo efecto que las anteriores:

auth,authpriv.*        /var/log/auth.log
      &                ~
*.*                    /var/log/syslog

Por último, para usar un formato de línea distinto en un fichero en particular puede usarse la siguiente sintaxis:

auth,authpriv.*        /var/log/auth.log;RSYSLOG_TraditionalFileFormat

4.3.1.1.4.1.3. Nuevo formato

A partir de su versión 6, rsyslog usa un nuevo formato (RainerScript) para escribir su configuración, aunque se puede seguir usando el antiguo e incluso incluir sentencias de uno u otro estilo dentro del mismo fichero.

4.3.1.1.5. Rotación

Los registros dentro de /var/log son persistentes, de manera que crecen indefinidamente, a menos que pongamos los medios para evitarlo. Con este propósito existe el servicio logrotate.

La rotación de logs consiste en copiar cada cierto tiempo los registros antiguos a otro fichero y vaciar el fichero de registro. Por ejemplo, supongamos que definimos que todos los días se realiza esta rotación. En ese caso ocurrirá lo siguiente:

• El primer día tendremos un único fichero syslog.

• El segundo día tendremos dos ficheros syslog.1, que contendrá los registros del día anterior; y syslog, sin estos registros, empezará a recoger los del día presente.

• El tercer día, se comprimirá y renombrará syslog.1 a syslog.2.gz, el contenido de syslog pasará a syslog.1 y, una vez vaciado syslog se comenzará a registrar en él.

• El proceso antes descrito se repite todos los días, de manera que cada vez aparecen más ficheros que almacenan registros antiguos de syslog. Sin embargo, al programa de rotación se le puede indicar un límite máximo de manera que, pasado este, se desecharán los registros. Si este límite fueran diez días, entonces nunca se llegaría a crear syslog.10.gz.

logrotate no es un demonio que se ejecute permanentemente en el ordenador, sino que en /etc/cron.daily hay un script que lo invoca a diario. Su configuración se hace en /etc/logrotate.conf o, de forma modular, en ficheros creados dentro de /etc/logrotate.d.

En logrotate.conf suele guardarse la configuración predeterminada para la rotación, mientras que en cada fichero de file:/etc/logrotate.d se guarda la configuración particular para un registro que no queremos que siga la predeterminada. Es bastante común que los paquetes de aplicaciones que generan logs incluyan un fichero particular para los suyos propios.

En /etc/logrotate.conf podríamos encontrar el siguiente contenido:

# Rotación semanal
weekly

# Conserva 4 semanas
rotate 4

# Compresión (con xz, pero no se comprime por defecto)
#compress
compresscmd /usr/bin/xz
compressext .xz

# Ficheros de configuración modular:
include /etc/logrotate.d

# Rotación para los ficheros wtmp y btmp
# [...]

La rotación de los registros de cada servicio es probable que la encontremos en un fichero propio dentro de /etc/logrotate.d. Por ejemplo:

# /etc/logrotate.d/apt

/var/log/apt/*.log {
   rotate 12
   monthly
   compress
   notifempty
}

En este ejemplo, cualquier fichero log dentro de /var/log/apt, queremos que rote mensualmente (monthly), que se compriman los registros rotados, y que si el fichero de log está vacío, no se realice rotación (notifempty).

Algunas de las directivas que podemos incluir son las siguientes:

hourly, daily, weekly, monthly, yearly

Frecuencia con la que se realizará la rotación.

copytruncate

En vez de mover el fichero y crear uno nuevo, hace copia y trunca a 0. Con esto se consigue que el fichero en el que el servicio apunta los registros sea el mismo, lo cual es necesario si el servicio está activo en todo momento y no podemos reiniciarlo.

create <permisos> <usuario> <grupo>

Indica cómo crear el nuevo fichero después de haber movido el anterior:

create 0640 root adm

delaycompress

Retrasa un ciclo la compresión. Esto hace que la rotación .1 no esté comprimida.

maxsize <tamaño>

Tamaño máximo en bytes que puede alcanzar el registro. Si lo alcanza, se rotará el fichero, aunque no se haya cumplido la frencuencia. Pueden usarse las unidades k, M o G:

maxsize 1M

minsize <tamaño>

Tamaño mínimo en bytes a partir del cual se procederá a la rotación. Si no se ha llegado a este tamaño, no se rotará, aunque toque según la frecuencia.

size <tamaño>

Tamaño a partir del cual se procederá a la rotación. La diferencia con maxsize es que con esta opción no se atiende a la frecuencia en absoluto.

missingok

Si no existe el fichero log no se produce ningún error.

rotate N

Número de rotaciones que sufren los registros.

prerotate/endscript

Ejecuta las órdenes entre estas dos directivas antes de proceder a la rotación.

postrotate/endscript

Ejecuta las órdenes entre estas dos directivas tras realizar a la rotación:

postrotate
   invoke-rc.d nginx rotate >/dev/null 2>&1
endscript

sharedscripts

Está relacionado con las dos directivas anteriores. Cuando se incluye, no ejecuta los comandos para la rotación de cada fichero, sino una sola vez para todos los ficheros que se han expresado en el bloque.

Nota

Es preciso indicar explícitamente a través de la configuración que se quiere rotar un fichero de registro. Dicho de otro modo, logrotate no rota cualquier fichero que se encuentre bajo /var/log, sino sólo aquellos explicitamente citados en su configuración.

Notas al pie

[1]

Citado en la página de manual de syslog.

[2]

Hay otra categoría, authpriv, para mensajes de este mismo tipo. La página de manual de syslog indica que se desaprueba el uso de auth en favor de authpriv.

[3]

USENET ha ido en los últimos años reduciendo significativamente su tráfico ante el empuje de la web (los foros ocupan su mismo nicho de servicio). Pero hemos de tener en cuenta que todo este sistema que se explica se ideó a principio de los años 80.

[4]

Los mensajes del núcleo también pueden ser revisados gracias al index:comando <dmesg> dmesg:

# dmesg

En Jessie, la consulta con dmesg puede realizarla cualquier usuario. Sin embargo, en Stretch requerirá los permisos de root.

Otro aspecto a tener en cuenta es que dmesg puede no mostrar todos los mensajes desde el arranque, ya que lo que hace es leer del buffer circular del núcleo. Como todo búffer circular, tiene un tamaño fijo, de manera que al llenarse por completo, comienza a reescribir las primeras entradas. Para ver todos los mensajes hay que recurrir a la lectura de /var/log/kern.log, que, además, al ser persistente, podrá contener mensajes de arranques anteriores.