Sysklogd proporciona dos utilidades de sistema que proporcionan soporte para el registro del sistema y la captura de mensajes del núcleo. El soporte tanto de Internet como de los sockets de dominio Unix permite que este paquete de utilidades soporte tanto el registro local como el remoto.
El registro del sistema es proporcionado por una versión de syslogd (8) derivada de las fuentes BSD del stock. El soporte para el registro del núcleo lo proporciona la utilidad klogd (8) que permite que el registro del núcleo se realice de forma independiente o como cliente de syslogd.
Syslogd proporciona un tipo de registro que muchos programas modernos utilizan. Cada mensaje registrado contiene al menos un campo de tiempo y un campo de nombre de host, normalmente también un campo de nombre de programa, pero eso depende de cuán confiable sea el programa de registro.
Mientras que las fuentes syslogd han sido fuertemente modificadas, un par de notas están en orden. En primer lugar ha habido un intento sistemático de asegurar que syslogd siga su comportamiento estándar por defecto, el comportamiento de BSD. El segundo concepto importante a tener en cuenta es que esta versión de syslogd interactúa de forma transparente con la versión de syslog que se encuentra en las bibliotecas estándar. Si un binario vinculado a las bibliotecas compartidas estándar no funciona correctamente, nos gustaría tener un ejemplo de comportamiento anómalo.
El archivo de configuración principal /etc/syslog.conf o un archivo alternativo, dado con la opción -f , se lee al inicio. Cualquier línea que empiece con la marca hash («`#») y las líneas vacías son ignoradas. Si se produce un error durante el análisis, se ignora toda la línea.
Índice de contenidos
Sinopsis
syslogd [ -a socket ] [ -d ] [ -f config file ] [ -h ] [ -l hostlist ] [ -m interval ] [ -n ] [ -p socket ] [ -].r ] [ -s domainlist ] [ -v ] [ -x ]
Opciones
-a socket
Usando este argumento puede especificar sockets adicionales desde que syslogd tiene que escuchar. Esto es necesario si va a permitir que algún demonio se ejecute dentro de un entorno chroot(). Puede utilizar hasta 19 tomas adicionales. Si su entorno necesita aún más, debe aumentar el símbolo MAXFUNIX dentro del archivo fuente syslogd.c. Un ejemplo de un demonio chroot() es descrito por la gente de OpenBSD en http://www.psionic.com/papers/dns.html.
-d
Activa el modo de depuración. Usando esto el demonio no procederá a una bifurcación (2) para colocarse a sí mismo en segundo plano, sino al contrario, permanecer en primer plano y escribir mucha información de depuración en la tty actual. Consulte la sección DESINFECTADO para obtener más información.
-f config file
Especifique un archivo de configuración alternativo en lugar de /etc/syslog.conf, que es el predeterminado.
-h
Por defecto syslogd no reenviará los mensajes que recibe de hosts remotos. Si se especifica este parámetro en la línea de comandos, el demonio de registro reenviará todos los mensajes remotos que reciba a los hosts de reenvío que se hayan definido.
-l hostlist
Especifique un nombre de host que debe ser registrado sólo con su nombre de host simple y no con el fqdn. Se pueden especificar varios hosts usando el separador de dos puntos («:»).
-m interval
El syslogd registra una marca de tiempo regularmente. El intervalo por defecto entre dos — MARK —líneas es de 20 minutos. Esto se puede cambiar con esta opción. Si se pone a cero el intervalo se desactiva por completo.
-n
Evite el autofondo. Esto es necesario especialmente si el syslogd es iniciado y controlado por init (8).
-p socket
Puede especificar un socket de dominio unix alternativo en lugar de /dev/log.
-r
Esta opción permitirá a la instalación recibir un mensaje de la red utilizando un socket de dominio de Internet con el servicio syslog (ver (5)). El valor predeterminado es no recibir ningún mensaje de la red.
Esta opción se introduce en la versión 1.3 del paquete sysklogd. Tenga en cuenta que el comportamiento predeterminado es el contrario del comportamiento de las versiones anteriores, por lo que es posible que tenga que activarlo.
-s domainlist
Especifique un nombre de dominio que se debe eliminar antes de iniciar sesión. Se pueden especificar múltiples dominios usando el separador de dos puntos («:»). Tenga en cuenta que no se puede especificar ningún subdominio, sino sólo dominios enteros. Por ejemplo, si -s north.de está especificado y el registro del host se resuelve a satu.infodrom.north.de no se cortará ningún dominio, tendrá que especificar dos dominios como: -s north.de:infodrom.north.de .
-v
Imprimir versión y salir.
-x
Deshabilitar la búsqueda de nombres al recibir mensajes remotos. Esto evita bloqueos cuando el servidor de nombres se está ejecutando en la misma máquina que ejecuta el demonio syslog.
Señales
Syslogd reacciona a un conjunto de señales. Puede enviar fácilmente una señal a syslogd usando lo siguiente:
kill -SIGNAL `cat /var/run/syslogd.pid`
Sighup
Esto permite syslogd realizar una reinicialización. Todos los archivos abiertos se cierran, el archivo de configuración (por defecto es /etc/syslog.conf) se relee y la función syslog (3) se inicia de nuevo.
SIGTERM
El syslogd morirá.
SIGINT , SIGQUIT
Si la depuración está habilitada, se ignoran, de lo contrario syslogd morirá.
SIGUSR1
Activar/desactivar la depuración. Esta opción sólo se puede utilizar si syslogd se inicia con la opción -d debug.
SIGCHLD
Esperar a los niños si nacieron algunos, debido a los mensajes de la pared.
Diferencias en la sintaxis del archivo de configuración
Syslogd usa una sintaxis ligeramente diferente para su archivo de configuración que las fuentes originales de BSD. Originalmente, todos los mensajes de una prioridad específica y superior se enviaban al archivo de registro.
Por ejemplo, la siguiente línea causó que TODA la salida de los dæmons que usan las instalaciones de los dæmons (depurar es la prioridad mÆs baja, por lo que todos los superiores tambiØn coinciden) entraran en /usr/adm/daemons:
# Ejemplo syslog.conf
> Ejemplo de syslog.conf daemon.debug /usr/adm/daemonsBajo el nuevo esquema, este comportamiento sigue siendo el mismo. La diferencia es la adición de cuatro nuevos especificadores, el asterisco ( * ), el signo de ecuación ( = ), el signo de exclamación ( ! ), y el signo menos ( - ).
* especifica que todos los mensajes para la instalación especificada deben dirigirse al destino. Tenga en cuenta que este comportamiento es degenerado al especificar un nivel de prioridad de depuración. Los usuarios han indicado que la notación asterisco es más intuitiva.
El comodín = se utiliza para restringir el registro a la clase de prioridad especificada. Esto permite, por ejemplo, enrutar sólo los mensajes de depuración a una fuente de registro en particular.
Por ejemplo, la siguiente línea en syslog.conf dirigiría los mensajes de depuración de todas las fuentes al archivo /usr/adm/debug.
# Ejemplo syslog.conf
> Ejemplo de syslog.conf *.=debug /usr/adm/debugEl ! se utiliza para excluir el registro de las prioridades especificadas. Esto afecta a todas (!) las posibilidades de especificar prioridades.
Por ejemplo, las siguientes líneas registrarían todos los mensajes del correo de la instalación excepto aquellos con la información de prioridad en el archivo /usr/adm/mail . Y todos los mensajes de news.info (incluyendo) a news.crit (excluyendo) serán registrados en el archivo /usr/adm/news.
# Ejemplo syslog.conf
> Ejemplo de syslog.conf mail.*;mail.!=info /usr/adm/mail
news.info;news.!crit /usr/adm/newsPuede utilizarlo intuitivamente como prescriptor de excepciones. La interpretación anterior es simplemente invertida. Hacer lo que puede usar
mail.none
o
mail. *o
mail.!debug
para omitir todos los mensajes que vienen con un servicio de correo. Hay mucho espacio para jugar con él. :-)
El - sólo se puede utilizar para prefijar un nombre de archivo si desea omitir la sincronización del archivo después de cada escritura en él.
Esto puede tomar algo de aclimatación para aquellos individuos acostumbrados al comportamiento puro de BSD pero los probadores han indicado que esta sintaxis es algo más flexible que el comportamiento de BSD. Tenga en cuenta que estos cambios no deberían afectar a los archivos syslog.conf estándar (5). Debe modificar específicamente los archivos de configuración para obtener el comportamiento mejorado.
Soporte para el registro remoto
Estas modificaciones proporcionan soporte de red a la instalación syslogd. El soporte de red significa que los mensajes pueden ser reenviados desde un nodo ejecutando syslogd a otro nodo ejecutando syslogd donde serán realmente registrados en un archivo de disco.
Para habilitarlo, debe especificar la opción -r en la línea de comandos. El comportamiento por defecto es que syslogd no escucha la red.
La estrategia es que syslogd escuche en un socket de dominio unix los mensajes de registro generados localmente. Este comportamiento permitirá a syslogd interoperar con el syslog que se encuentra en la biblioteca C estándar. Al mismo tiempo syslogd escucha en el puerto syslog estándar los mensajes reenviados desde otros hosts. Para que esto funcione correctamente, los archivos services (5) (típicamente encontrados en /etc) deben tener la siguiente entrada:
syslog 514/udp
Si falta esta entrada syslogd no puede recibir mensajes remotos ni enviarlos, porque el puerto UDP no puede abrirse. En su lugar, syslogd morirá inmediatamente, haciendo sonar un mensaje de error.
Para hacer que los mensajes se reenvíen a otro host, sustituya la línea de archivo normal del archivo syslog.conf por el nombre del host al que se van a enviar los mensajes, precedido de una @.
Por ejemplo, para reenviar TODOS los mensajes a un host remoto utilizando la siguiente entrada syslog.conf:
#. # mensajes a un host remoto reenviar todos.
*.* @nombre de hostPara reenviar todos los mensajes del kernel a un host remoto, el archivo de configuración sería el siguiente:
# Ejemplo de archivo de configuración para reenviar todo el kernel
>. # mensajes a un host remoto.
kern.* @nombre de hostSi el nombre de host remoto no se puede resolver al iniciar, porque el servidor de nombres puede no estar accesible (puede iniciarse después de syslogd), no tiene que preocuparse. Syslogd reintentará resolver el nombre diez veces y luego se quejará. Otra posibilidad para evitar esto es colocar el nombre de host en /etc/hosts.
Con syslogd normal s obtendría syslogs si enviara mensajes que fueron recibidos desde un host remoto al mismo host (o más complicado a un tercer host que los devuelve al primero, y así sucesivamente). En mi dominio (Infodrom Oldenburg) accidentalmente obtuvimos uno y nuestros discos se llenaron con el mismo mensaje único. :-(
Para evitar esto, en el futuro, ningún mensaje que se haya recibido de un host remoto se enviará a otro (o al mismo) host remoto. Si hay escenarios en los que esto no tiene sentido, por favor envíame (Joey) una línea.
m
