Menú
Correo vía web
Ayuda
Archivos
Conexión segura

syslog-ng

syslog-ng

En mis redes dispongo cada vez más de dispositivos con GNU/Linux que no disponen de una consola, dado que son muy especializados, y que de cuando en cuando presentan problemas que creo podría haber solucionado antes, en caso de disponer de algún aviso naturalmente.

Es por ello por lo que pretendo anotar aquí la forma de configurar el registro centralizado de mensajes. Sé que puede hacerse con syslogd, y que rsyslog está de moda, pero en Debian Etch actualmente está syslog-ng y es en el que quiero centrarme.

Configuración

El registro de mensajes se compone de tres partes: una fuente, un filtro y un destino. Todos ellos pueden aparecer varias veces, y se relacionan mediante la directiva log.

Fuente de los mensajes

Las fuentes se declaran mediante la directiva source con esta síntaxis:

source <nombre> { sourcedriver <parametros>; [ ... ] };

donde:

nombre es el identificador de la fuente.
sourcedriver: es el método para obtener los mensajes, estando disponibles los siguientes:
- file
- unix-dgram
- unixstream_
- udp
- tcp
- sun-streams

Destino de los mensajes

El destino de los mensajes, es decir, a dónde se envían, se declaran mediante la directiva destination con esta estructura:

destination <nombre> { destdriver <parametros>; [ ... ] };

donde:

nombre es el identificador del destino.
destdriver es el método empleado para registrar los eventos, y puede ser:
- file
- unix-dgram
- unix-stream
- udp
- tcp
- usertty

Filtros

PENDIENTE DE COMPLETAR

Registros

Los registros son los que realmente definen los flujos de información de --sg--, puesto que relacionan una fuente de eventos, un procesado de los mismos mediante filtros y un destino.

Se emplea la directiva log que puede tener la siguiente estructura:

log { 
    source <identificador_fuente>; [ ... ; ]
    filter <identificador_filtro>; [ ... : ]
    destination <identificador_destino>; [ ...; ]
    };

Los distintos filtros se encadenan entre sí mediante operadores AND.

Opciones globales

La directiva options abre un bloque de opciones que determinan el funcionamiento global del programa.

Existe un buen número de opciones, pero las que más nos pueden interesar son aquellas que controlan el flujo de información.

use_dns(): cuando se habilita se efectúan consultas DNS y --sg-- se bloquea mientras espera la respuesta; es un riesgo a tener en cuenta porque puede crear una denegación de servicio.
dns_cache(): emplear una caché para las consultas de nombres.

PENDIENTE DE COMPLETAR

Configurando un servidor

Para que --sg-- sirva como servidor de eventos para otras máquinas debemos hacer lo siguiente:

Definir una fuente de datos por red, bien por su cuenta, bien integrada en alguna otra:
```
source s_hosts {
    tpc();
    upd();
};
```
En este caso estamos activando también la entrada por UDP, necesaria si tenemos alguna máquina con un sistema de registro que sólo pueda emitir mediante ese protocolo.
Definir si lo necesitamos un filtro especial, en caso contrario podemos emplear cualquier otro disponible, ó aceptar todo lo que venga, puesto que es posible hacer lo mismo desde el lado del cliente.
Definir un destino para los eventos, haciendo uso de las macros para distribuir mejor la información.
```
destination d_hosts {
    file ("/var/log/HOSTS/$HOST/$FACILITY.log" 
    owner(root)
    group(adm)
    perm(0640)
    dir_perm(0750)
    create_dirs(yes) );
    };
```
En este caso estamos indicándole que lo distribuya sobre un árbol de directorios, cuyos nodos son el nombre del máquina que nos envía los mensajes (ó la dirección IP si no tenemos activa la opción use_dns()), y la categoría de dichas informaciones (facility).

Además, indicamos qué propiedad y permisos de acceso tienen los archivos, muy importante para no necesitar después revisarlos como superusuario.

Activar un registro uniendo lo anterior:

log {
    source(s_hosts);
    destination(d_hosts);
    };

Macros disponibles

--sg-- dispone de un buen número de macros de las que sólo voy a apuntar aquí las más útiles para mis propósitos:

FACILITY: traducible más ó menos por la categoría desde la que se origina el mensaje. Generalmente corresponde al origen del programa y contendrá valores como debug, kern, mail, ...
PRIORITY ó LEVEL: nivel de prioridad del mensaje, que suele estar en una de estas categorías: emerg, alert, crit, err, warning, notice, info y debug.
DATE: fecha en formato ISO
HOST: nombre de la máquina que envía el mensaje.
PROGRAM: nombre del programa que genera el mensaje.

Configurando un cliente

Desde el punto de vista del cliente la configuración para enviar a un registro central es bastante simple:

Definimos un destino para los datos:

destination d_logcentral {
        tcp( "nombre ó dirección IP" );
        };

Activamos un registro uniendo lo que queramos:
```
log {
    source(s_all);
    filter(f_logcentral);
    destination(d_logcentral);
};
```
Esto es, tenemos plena libertad para enviarle lo que queramos al servidor central, dado que éste podrá filtrar a su conveniencia aquello que le interese y descartar lo que no.

Otros aspectos

sysklogd

Si tenemos alguna máquina que emplea sysklogd, no podemos ó no queremos cambiarla, y deseamos registrar sus mensajes haremos:

Indicamos al servidor que acepte también conexiones UDP:
```
source s_hosts {
    tcp();
    udp();
};
```
Modificamos el archivo /etc/syslog.conf en la máquina cliente y le indicamos, por ejemplo, que envíe todo al registro central:
```
*.*     @log.venexma.int
```

Rotando los registros

El paquete Debian ya incluye un archivo de configuración para logrotate, pero únicamente cubre los archivos más básicos del sistema donde está funcionando, sin hacer mención a las capacidades extendidas como registro central de eventos.

Para que el rotado incluya también los registros de las otras máquinas añadimos algo como lo siguiente al archivo /etc/logrotate.d/syslog-ng: