Curso Administracin UNIX

<http://www.iie.edu.uy/ense/asign/admunix/index.htm>

Syslog y Archivos de registro de eventos.

* Syslog y Archivos de registro de eventos <#Heading1>
o Rotacin de archivos de log <#Heading2>
o Dnde estn los logfiles? <#Heading3>
o Algunos archivos importantes <#Heading4>
+ wtmp y el comando who <#Heading5>
+ messages <#Heading6>
o Syslog <#Heading7>
+ El daemon syslogd <#Heading8>
# Configuracin de syslogd <#Heading9>
# Limitaciones y depuracin de errores <#Heading10>
* Ejercicios e Investigacin <#Heading11>
* Referencias y Bibliografa <#Heading12>

Syslog y Archivos de registro de eventos

Tanto el propio kernel del sistema operativo como los servicios de red o
aplicaciones que estn corriendo en forma permanente en un sistema Unix
mantienen archivos de registro de eventos (logfiles) para reportar
sucesos relevantes.
Estos registros son de gran utilidad para determinar a posteriori qu ha
sucedido en un sistema en caso de un malfuncionamiento y para detectar
en forma temprana eventuales fallas en el sistema. Forma parte de las
tareas del administrador revisar peridicamente estos logs.
Una particularidad comn a todos los archivos de registro de eventos es
que *crecen*, lo que obliga a definir alguna poltica para el manejo de
estos archivos para evitar que llenen el espacio en disco. La poltica a
seguir puede variar de acuerdo al esfuerzo de administracin y la
importancia que la organizacin preste a temas como la seguridad. Las
polticas ms comunes son:
No almacenar
Resetearlos peridicamente
Rotarlos, manteniendo datos por un perodo fijo de tiempo hacia atrs
Archivar en cinta u otro medio de respaldo toda la historia
El primer mtodo no es para nada recomendable dado que los logs son una
de las principales herramientas para determinar la causa de un
malfuncionamiento y para detectar algn acceso no autorizado al sistema.
La poltica de borrar los archivos de log cada vez que toman un tamao
que los hace molestos, si bien en la mayora de los casos nos permite
disponer de informacin, no nos garantiza disponer de los registros de
un tiempo hacia atrs. Por otra parte si el tamao de los logs crece
excesivamente puede hacerse inmanejable extraer de ellos informacin o
incluso pueden llegar a llenar el disco.

Rotacin de archivos de log

La prctica ms usual consiste en ir "rotando" los nombres de archivo
diariamente o semanalmente, de manera de ir descartando los archivos ms
antiguos y mantener informacin de una cantidad fija de das anteriores.
Un ejemplo elemental de un script que se podra lanzar desde *cron* para
realizar esto es el que sigue:
#!/bin/sh
cd /var/log
rm logfile.3
mv logfile.2 logfile.3
...
mv logfile logfile.0
cat /dev/null > logfile
La mayora de los sistemas Unix traen instalado alguna variante de un
script como el de arriba para ser ejecutados desde el cron. Como
habitualmente se utilizan para rotar los registros de eventos de
*syslog*, el administrador de registros de eventos que estudiamos ms
adelante en este documento, los scripts de este tipo suelen llevar por
nombre *newsyslog*.
Una versin ms compleja de este script es el comando *newsyslog* de
FreeBSD o el comando *logrotate* de algunas versiones de Linux. Se
describe a continuacin *newsyslog*, *logrotate* tiene prestaciones
similares.
Esta versin "potenciada" de newsyslog es lanzada peridicamente con
cron y lee de un archivo de configuracin (*/etc/newsyslog.conf*) cules
son los archivos que debe rotar. Para cada familia de archivos se
configura si la rotacin se realiza cada un lapso fijo o cuando el
archivo de log alcanza un determinado tamao.
Un archivo no termina de desaparecer hasta que se cierran todas las
referencias a l desde los procesos que estn corriendo. Si un programa
abre el archivo de log al inicio y luego lo mantiene abierto, aunque
borremos el archivo, la referencia que mantiene el programa sigue
apuntando al antiguo archivo que ya no existe.
Para instalar un nuevo logfile, dependiendo del programa, puede ser
necesario enviarle algn signal en particular o matar al programa y
volverlo a arrancar para lograr que el programa comience a escribir en
el nuevo archivo de log (por ej. para syslogd es necesario hacer kill -1
pid). Algunos programas necesitan que el archivo al cual escriben est
previamente creado. El comando newsyslog descripto anteriormente permite
especificar un nombre de archivo del cual tomar un Process ID para
enviar un kill -1 a ese proceso para que reabra los archivos de log
luego de la rotacin.
A menudo los archivos de log ms antiguos son poco consultados por lo
que pueden comprimirse para ahorrar espacio en disco. Los programas de
compresin ms comunmente utilizados son *compress* y *gzip*. Un ejemplo
tpico puede ser rotar los archivos diariamente, manteniendo los dos
das anteriores sin comprimir y los siguientes comprimidos con gzip
hasta completar una semana.
Por motivos de auditora o seguridad algunas organizaciones optan por no
destruir la informacin de los logs antiguos. En esos casos en general
los archivos de cierta antigedad se almacenan en algn medio removible
(cinta o CD) y se archivan por la eventualidad de que sean requeridos
ms adelante.

Dnde estn los logfiles?

Dado que no existe un lugar fijo en el cual se creen los archivos de

log, enfrentados a un sistema Unix que no conocemos no siempre es
sencillo encontrarlos. Se enumeran a continuacin las situaciones ms
frecuentes.
Una buena parte de los programas manejan sus logs utilizando *syslogd*.
A otros programas se les especifica *con parmetros en la lnea de
comando* donde dejar los logs que generen durante su funcionamiento. En
otros casos esto es una *opcin de compilacin*.
Algunos sistemas como OSF/1 y AIX almacenan los errores del sistema en
archivos binarios y proveen alguna herramienta para listarlos (comando
*uerf* en OSF/1). En general estos comandos aceptan alguna opcin para
filtrar u ordenar los mensajes con algn criterio.
Cmo averiguar dnde estn los logs entonces?
en el archivo /etc/syslog.conf para ver donde se almacenan los
mensajes reportados a syslogd.
en los scripts de arranque para ver cmo son invocados los daemons
que almacenan directamente los mensajes en archivos propios.
en el man de los programas para ver donde almacenan los logs cuando
no es esto una opcin de lnea de comando.
Algunos de los lugares ms usuales son:
/var/log
/var/adm o /usr/adm
/var/<nombre_de_daemon>/log
/var/spool/<nombre_de_daemon>/log

Algunos archivos importantes

wtmp y el comando who

Para cada usuario del sistema Unix mantiene un registro en los archivos
*utmp *y *lastlog* que indica entre otra informacin si est logueado en
el sistema o no, y en caso afirmativo en cul terminal y desde que
fecha/hora. Estos archivos son actualizados en cada login y logout y
consultados por ejemplo por los comandos *w*, *who y lastlog*.
En cada login y logout adems de actualizarse el registro del usuario en
el archivo *utmp*, se hace un append del mismo en un archivo llamado
*wtmp*. Este archivo entonces es un registro histrico de los login y
logout al sistema. Va creciendo con cada login y logout por lo que debe
ser administrado con alguna de las polticas vistas.
El archivo est en formato binario, pero puede observarse con el comando
*who*. Este comando por defecto despliega los usuarios logueados al
sistema consultando al archivo *utmp*, pero se le puede pasar como
parmetro el nombre del archivo *wtmp* y en ese caso nos va a listar la
secuencia de login y logout.
La ubicacin de estos archivos vara de un sisetma a otro. El archivo
utmp habitualmente est en el directorio /etc o /var/run, el archivo
wtmp suele estar en /var/log o /var/adm.
Si bien tienen algunas similitudes con los archivos de log, debe
evitarse manipular los archivos *utmp* y *lastlog*. El archivo lastlog
est indexado por UID. Si en la asignacin de UIDs a los usuarios del
sistema se saltea algn intervalo, pueden quedar "huecos" en el archivo
que nunca son escritos y a los que nunca se les llega a asignar sectores
del disco. Algunos programas (ls -l) reportan el tamao completo del
archivo, otros comandos (du) reportan solamente el tamao efectivamente
utilizado por clusters asignados. Un problema que puede aparecer es que
al copiar un archivo con huecos se le asigne lugar en disco para los
registros correspondientes a los UID que no existen. Esto puede hacer
que el archivo destino de la copia sea mucho mayor que lo esperado,
eventualmente llenando el disco.

messages
Por lo general la mayora de los mensajes procesados por el daemon
syslog que se ve ms adelante se almacenan en un archivo llamado
*messages*, de modo que este archivo es uno de los primeros lugares a
los que recurrir en busca de informacin cuando se ha detectado un problema.

Syslog
El *syslog* es un sistema que procura centralizar (y en buena medida lo
logra) el manejo de los registros de eventos que generan los diversos
programas que corren en una mquina Unix. Por un lado facilita a los
desarrolladores de aplicaciones la generacin y el manejo de mensajes a
registrar, y por otro lado facilita a los administradores de sistema el
manejo en forma centralizada de los mensajes provenientes de diferentes
aplicaciones. Permite, clasificando los mensajes por origen e
importancia, enviarlos a diferentes destinos como archivos, a la
terminal de un operador, o eventualmente a un comando que lo reenve a
direcciones de correo electrnico o pagers.
El syslog tiene adems capacidad para manejar mensajes originados en
diferentes computadores en una red.
Los componentes ms importantes de *syslog* son:
*syslogd*: el daemon que recibe los mensajes y los almacena de
acuerdo a la configuracin almacenada en el archivo /etc/syslog.conf
*openlog()*, *syslog()* y *closelog()*: rutinas de la biblioteca C
estndar para comunicarse con syslog desde un programa.
*logger*: comando de usuario para agregar un mensaje a un log

El daemon syslogd
El daemon *syslogd* es uno de los primeros que se lanza a correr en los
scripts de arranque del sistema. Una vez arrancado queda esperando
recibir mensajes para procesarlos de acuerdo a la configuracin en
*/etc/syslog.conf*.
Syslogd reponde a la signal 1 (HUP) cerrando los logs, releyendo la
configuracin y reiniciando la operacin. Es por eso que si realizamos
algn cambio en la configuracin, o si rotamos o movemos los archivos de
log, es necesario enviarle una seal HUP a syslogd. Para facilitar esto
syslogd guarda al arrancar en un archivo de nombre predeterminado
(/etc/syslog.pid) el PID que le toc en suerte, de manera que el
siguiente comando rearranca a syslogd:
kill -1 `/bin/cat /etc/syslog.pid`

Configuracin de syslogd
La configuracin de syslogd se hace a travs del archivo de texto
/etc/syslogd.conf. A travs de este archivo se especifica hacia dnde se
deben enrutar los diferentes mensajes. Se pueden dejar lneas en blanco
o comentar lneas enteras con el carcter "#" como primer carcter no
blanco. Cada lnea tiene el siguiente formato:
/selector <Tab> action/
La accin especificada se aplicar a todos los mensajes que verifiquen
las condiciones que se especifican con el selector. En algunos sistemas
solamente puede utilizarse tabuladores como separador entre el selector
y la accin, generndose un error muy difcil de descubrir si al editar
el archivo syslog.conf se insertan espacios en lugar de tabuladores.
El *selector* se especifica como un par *facility.level*. Cuando un
programa enva un mensaje al syslog, lo hace especificando un valor de
"facility" y un valor de "level".
El campo *facility* procura identificar al programa que origin el
mensaje, mientras que el campo *level* busca clasificar el nivel de
importancia o severidad del mismo.
Los valores posibles de *facility* estn prefijados en cada sistema.
Bsicamente permiten identificar mensajes del kernel, de varios de los
deaemons y servicios de mayor prosapia en Unix (mail, daemon, lpr, news,
uucp, cron, syslog, ftp), mensajes que tienen que ver con seguridad y
autenticacin de usuarios y una serie de valores que pueden ser usados
con cierta libertad para diferentes aplicaciones (local0 a local7, user).
Los valores posibles de *level* son en general 8 y van en orden de
severidad creciente desde DEBUG hasta EMERG. La accin especificada se
aplica a todos los mensajes del nivel especificado o mayor.
Se puede combinar varios selectores en una lnea separndolos por el
carcter punto y coma (";").
Se pueden especificar varias facilities para un mismo nivel separndolas
con el carcter coma (",").
La clave especial "*" puede utilizarse para especificar todos los
niveles o todas las facilities (excepto la facility "mark").
La clave especial "none" en el campo level puede especificarse para
excluir todos los niveles de una cierta facility al combinar varios
selectores.
La facility "mark" recibe mensajes a intervalos de 20 minutos. Esto
permite, en caso que el sistema se "cuelgue", determinar de manera
bastante precisa la hora a la que sucedi el problema aunque esto haya
sido a una hora de baja actividad en el syslog.
La *accin* puede ser una de las siguientes:
*guardar en un archivo*. Es la accin ms habitual. El archivo debe
estar creado de antemano. Se especifica simplemente escribiendo el
nombre del archivo con su path completo.
*reenviar hacia el syslogd de otra mquina*. Se especifica
escribiendo @<nombre de mquina o direccin IP>. El nombre de la
mquina origen se agrega al comienzo del mensaje junto con el
timestamp, pero solamente se conserva por un salto. En el syslog
original el nombre de la mquina que gener el mensaje no interviene
en el selector, de manera que no es posible desencadenar diferentes
acciones segn la mquina que origin el mensaje. Esto ltimo se ha
modificado en versiones ms nuevas de syslog.
*reenviar a la terminal de un usuario* si es que est logueado. Se
puede especificar una lista de usuarios separados por el carcter
coma (",") o un carcter "*" para especificar todos los usuarios
logueados.
en algunos sistemas es posible pasar el texto del mensaje *como
 entrada estndar a un comando*, escribiendo el comando precedido por
el carcter pipe ("|").
Los siguientes ejemplos tomados del man de syslogd.conf ilustran la
mayora de los casos.
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none /var/log/messages
# Everybody gets emergency messages, plus log them on another
# machine.
*.emerg *
*.emerg @arpa.berkeley.edu

El esquema descripto hasta ahora es estndar en la mayora de los syslog

y permite con un esquema simple configurar el sistema para las
necesidades de cada lugar. Para ello se utilizan en general los valores
local0-7 de facility. Estos valores debern administrarse asignndolos a
las diferentes fuentes de mensajes que no estn previstas en los daemons
originales. Estos programas por lo general permiten configurar el valor
de facility con el que etiquetan sus mensajes. As por ejemplo en un
sitio podra asignarse el valor local0 a los mensajes del popper
(consultas de casillas de correo electrnico con pop3) y el valor local1
para los mensajes de los routers de la red, dispositivos que por lo
general no tienen disco y permiten ser configurados para enviar los
mensajes al syslog de otra mquina.
En un sistema grande puede llegar a agotarse los valores disponibles de
facilities localx. Esto ha influido para que en nuevas versiones de
syslog aparezcan extensiones que hagan ms flexible la especificacin de
los selectores. En ese sentido algunas versiones de syslog identifican a
la primera palabra en el texto del mensaje como el nombre del programa
que lo origin, y permiten utilizar ese nombre de programa para
seleccionar la accin a aplicar sobre el mensaje.
Para ello en el archivo syslog.conf se definen secciones especiales para
cada programa que comienzan con una lnea de la forma #!programa o
!programa. En los casos en que el syslog del sistema acepta estas
extensiones hay que ser cuidadoso al agregar lneas al archivo
syslog.conf para estar seguro que la lnea insertada no queda dentro del
bloque definido para un programa en particular.
Otra mejora introducida en nuevas versiones de syslog es que es posible
agregar el modificador "=" al comienzo del nivel para especificar que el
nivel de severidad sea igual estricto en lugar de mayor o igual al nivel
especificado. En forma similar pueden usarse los modificadores "!"
(diferente) y "-" (menor). Esto puede verse en el siguiente ejemplo:
# Log daemon messages at debug level only
daemon.=debug /var/log/daemon.debug

Limitaciones y depuracin de errores

Luego de realizar alguna modificacin en el archivo syslog.conf y de
enviar una seal HUP a syslogd para que relea la configuracin, debe
testearse el funcionamiento enviando mensajes de test con el comando logger.
Un error comn es olvidar enviar la seal HUP. Otro error bastante comn
cuando la accin es guardar los mensajes en un archivo es no crear el
archivo previamente. Si el archivo destino no est creado syslogd no lo
crea.
En la mayora de las implementaciones de sylog solamente se aceptan
tabuladores como separador entre el selector y la accin. Algunas
versiones ms nuevas permiten indistintamente espacios y tabuladores.
Algunas versiones de syslog tienen limitado la cantidad de acciones a
especificar en syslog.conf a un valor constante fijo NLOGS que
usualmente era 20. En otras versiones hay una limitacin en la cantidad
de usuarios a los que es posible reenviar los mensajes a la consola.
Una herramienta bastante potente para depurar errores en la
configuracin de syslog es ejecutarlo en modo debug con el flag -d
(*syslog -d*). Ejecutado de este modo syslog despliega una tabla con una
columna por cada facility y un rengln por cada accin. Los nmeros en
la tabla indican a partir de cual nivel se aplica la accin para cada
facility. En el ejemplo se muestran 4 acciones diferentes (desplegar en
la consola, almacenar en el archivo /var/cron/log, reenviar a la mquina
de nombre ohm, desplegar en el terminal en que est logueado el usuario
root). En los sistemas que tienen limitado a NLOGS la cantidad de
acciones, la tabla tiene NLOGS renglones y aparecen los ltimos con la
accin UNUSED.
7 3 2 3 5 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 X X CONSOLE: /dev/console
X X X X X X X X X 8 X X X X X X X X X X X X X X X FILE: /var/cron/log
X X X X X X X X X X X X X X X X X X X X X X X 8 X FORW: ohm
3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 X USERS: root,
Cuando se ejecuta en modo debug syslogd no libera el terminal. Despus
de desplegar la tabla con el resumen de acciones queda desplegando en
pantalla cada mensaje que recibe y las acciones que se le aplican.
Una precaucin a tener cuando se envan mensajes a la consola es que si
alguien presiona la tecla de pausa del terminal (habitualmente
<Control-S>), entonces cada intento de syslog de sacar un mensaje en
consola queda bloquedo. Esto por lo general produce el efecto de
enlentecer violentamente el funcionamiento de la mquina, situacin que
se revierte si desbloqueamos el terminal con <Control-Q>.

Ejercicios e Investigacin
Determine en su sistema donde estn los diferentes archivos de
registro de eventos
Averige quin y desde qu terminal trabajo en el sistema el da
anterior
Identifique que poltica de rotacin de archivos de tiene
configurada su mquina (identifique el script peridico que se
encarga de eso, si utiliza algn comando especial para eso
(newsyslog p. ej.) lea el man de ese comando.
Modifique /etc/syslog.conf para hacer que determinados mensajes se
escriban tambin en la consola de su usuario. Prubelo usando el
comando logger. Retorne luego a la configuracin inicial!!!

Referencias y Bibliografa
Nemeth, Evi, "UNIX System Administration Handbook", cap. 12
*Comandos:* who, wtmp, utmp, newsyslog, compress, gzip, syslogd,
syslog.conf, logger.
------------------------------------------------------------------------
Julio Prez julio@iie.edu.uy <mailto: julio@iie.edu.uy>
Instituto de Ingeniera Elctrica <http://www.iie.edu.uy/> - Facultad de
Ingeniera <http://www.fing.edu.uy/> - Montevideo, Uruguay.