Product SiteDocumentation Site

9.5. syslog Eventos de sistema

9.5.1. Principio y mecanismo

El demonio rsyslogd es responsable de recolectar los mensajes de servicio que provienen de aplicaciones y el núcleo para luego distribuirlos en archivos de registros (usualmente almacenados en el directorio /var/log/). Obedece a su archivo de configuración: /etc/rsyslog.conf.
Cada mensaje de registro es asociado con un subsistema de aplicaciones (llamados «facility» en la documentación):
  • auth y authpriv: para autenticación;
  • cron: proviene servicios de programación de tareas, cron y atd;
  • daemon: afecta un demonio sin clasificación especial (DNS, NTP, etc.);
  • ftp: el servidor FTP;
  • kern: mensaje que proviene del núcleo;
  • lpr: proviene del subsistema de impresión;
  • mail: proviene del subsistema de correo electrónico;
  • news: mensaje del subsistema Usenet (especialmente de un servidor NNTP — protocolo de transferencia de noticias en red, «Network News Transfer Protocol» — que administra grupos de noticias);
  • syslog: mensajes del servidor syslogd en sí;
  • user: mensajes de usuario (genéricos);
  • uucp: mensajes del servidor UUCP (programa de copia Unix a Unix, «Unix to Unix Copy Program», un protocolo antiguo utilizado notablemente para distribuir correo electrónico);
  • local0 a local7: reservados para uso local.
Cada mensaje tiene asociado también un nivel de prioridad. Aquí está la lista en orden decreciente:
  • emerg: «¡Ayuda!» Hay una emergencia y el sistema probablemente está inutilizado.
  • alerta: apúrese, cualquier demora puede ser peligrosa, debe reaccionar inmediatamente;
  • crit: las condiciones son críticas;
  • err: error;
  • warn: advertencia (error potencial);
  • notice: las condiciones son normales pero el mensaje es importante;
  • info: mensaje informativo;
  • debug: mensaje de depuración.

9.5.2. El archivo de configuración

La sintaxis del archivo /etc/rsyslog.conf está detallada en la página del manual rsyslog.conf(5), pero también está disponible la documentación en HTML en el paquete rsyslog-doc (/usr/share/doc/rsyslog-doc/html/index.html). El principio general es escribir pares de «selector» y «acción». El selector define los mensajes relevantes y la acción describe qué hacer con ellos.

9.5.2.1. Sintaxis del selector

El selector es una lista separada por punto y coma de pares subsistema.prioridad (por ejemplo: auth.notice;mail.info). Un asterisco puede representar todos los subsistemas o todas las prioridades (por ejemplo: *.alert o mail.*). Puede agrupar varios subsistemas separándolos con una coma (por ejemplo: auth,mail.info). La prioridad indicada también incluye los mensajes de prioridad igual o mayor; por lo tanto, auth.alert indica los mensajes del subsistema auth de prioridad alert o emerg. Si se agrega un signo de exclamación (!) como prefijo, indica lo contrario; en otras palabras, prioridades estrictamente menores. Por lo tanto, auth.!notice sólo incluye los mensajes del subsistema auth con prioridades info o debug. Si se agrega un signo igual (=) como prefijo corresponde única y exactamente con la prioridad indicada (auth.=notice sólo incluye los mensajes del subsistema auth con prioridad notice).
Cada elemento en la lista del selector reemplaza elementos anteriores. Así es posible restringir un conjunto o excluir ciertos elementos del mismo. Por ejemplo, kern.info;kern.!err significa los mensajes del núcleo con prioridades entre info y warn. La prioridad none indica el conjunto vacío (ninguna prioridad) y puede servir para excluir un subsistema de un conjunto de mensajes. Por lo tanto *.crit;kern.none indica todos los mensajes con prioridad igual o mayor a crit que no provengan del núcleo.

9.5.2.2. Sintaxis de las acciones

VOLVER A LOS CIMIENTOS La tubería («pipe») con nombre, una tubería persistente

Una tubería con nombre es un tipo particular de archivo que funciona como una tubería tradicional (la tubería que crea con el símbolo «|» en una consola), pero a través de un archivo. Este mecanismo tiene la ventaja de poder relacionar dos procesos que no están relacionados. Todo lo que se escriba en una tubería con nombre bloquea el proceso que escribe hasta que un proceso intente leer los datos escritos. Este segundo proceso lee los datos escritos por el primero, que puede luego continuar ejecutando.
Puede crear estos archivos con el programa mkfifo.
Las acciones posibles son:
  • agregar el mensaje a un archivo (ejemplo: /var/log/messages);
  • enviar el mensaje a un servidor syslog remoto (ejemplo: @log.falcot.com);
  • enviar el mensaje a una tubería con nombre existente (ejemplo: |/dev/xconsole);
  • enviar el mensaje a uno o más usuarios si tienen una sesión iniciada (ejemplo: root,rhertzog);
  • enviar el mensaje a todos los usuarios con sesiones activas (ejemplo: *);
  • escribir el mensaje en una consola de texto (ejemplo: /dev/tty8).

SEGURIDAD Reenvío de registros

Es buena idea grabar los registros más importantes en una máquina separada (tal vez dedicada a este propósito), ya que evitará que cualquier intruso elimine los rastros de su intromisión (a menos, por supuesto, que también comprometa este otro servidor). Lo que es más, en el caso de un problema mayor (como un fallo abrupto del núcleo) tendrá disponible los registros en otro equipo, lo que aumenta sus probabilidades de determinar la secuencia de eventos que llevó al fallo.
Para aceptar mensajes de registro enviados por otras máquinas debe reconfigurar rsyslog: en la práctica es suficiente activar las líneas ya preparadas en el archivo /etc/rsyslog.conf ($ModLoad imudp y $UDPServerRun 514).