Todos los éxitos del POP de los últimos 40 años se pueden tocar con los mismos 4 acordes:
[youtube=http://www.youtube.com/watch?v=QpB_40hYjXU]
Todos los éxitos del POP de los últimos 40 años se pueden tocar con los mismos 4 acordes:
[youtube=http://www.youtube.com/watch?v=QpB_40hYjXU]
Al que como yo se encuentre en un punto en donde se le vuelve tedioso ir servidor por servidor, dispositivo por dispositivo revisando los archivos de bitácora (logs) de cada uno, esto le resultará de utilidad.
syslog es un estándar de facto para el envío de mensajes de registro en una red informática IP. Por syslog se conoce tanto al protocolo de red como a la aplicación o biblioteca que envía los mensajes de registro.
Un mensaje de registro suele tener información sobre la seguridad del sistema, aunque puede contener cualquier información. Junto con cada mensaje se incluye la fecha y hora del envío.
En mi caso, mi servidor central corre Syslog-NG, pretendo recibir en este servidor todos los logs que generan otros servidores corriendo Linux y Windows, cámaras de seguridad, routers y puntos de acceso inalámbricos que controlo.
Syslog puede enviar información sobre TCP o UDP indistintamente. Por convención se usa el puerto 514 UDP. La mayoría de los dispositivos del tipo access points wireless o cámaras de seguridad no permiten especificar puerto o protocolo así que lo mejor es crear una regla en el firewall que reenvíe todo el tráfico del puerto 514 UDP que es la configuración por defecto a nuestro Syslog server:
iptables -A PREROUTING -t nat -i eth0 -p udp –dport 514 -j DNAT –to 192.168.1.150
Una vez hecho esto, habilitar Syslog-NG para que reciba tráfico por UDP editando el archivo /etc/syslog-ng/syslog-ng.conf:
source src {
unix-stream(«/dev/log» max-connections(256));
internal();
file(«/proc/kmsg»);
udp();
};
Con eso ya tenemos suficiente como para recibir todos los logs de otros servidores y dispositivos en la red o desde internet en nuestro servidor central syslog.
Todos estos logs se pueden consultar en diferido usando:
less /var/log/messages
O verlos en tiempo real desde una consola:
tail -f /var/log/messages
O traerlos desde tty12 a la tty1 para una cómoda visualización nuevamente editando /etc/syslog-ng/syslog-ng.conf:
# By default messages are logged to tty12…
destination console_all { file(«/dev/tty1«); };
El paso siguiente es traer todos los logs remotos a nuestro servidor central para poder administrarlos con mas comodidad. A continuación algunos ejemplos para diferentes escenarios.
En el caso de servidores que corren windows, bastará con instalar NTsyslog (requiere .NET 2.0 y windows installer 3.0) y configurarlo para que envíe los logs hasta nuestro syslogserver usando el número de IP o el nombre de dominio del mismo.
Cuando el servidor remoto corre syslog-ng, agregar en el archivo de configuración:
destination remote { udp(«mi.servidor.com» port(514)); };
Cuando el servidor remoto corre rsyslog o similares, agregar en /etc/rsyslog.conf:
*.* @mi.servidor.com
Dependerá del caso pero la gran mayoría de equipamiento de red de calidad permite el reenvío de logs a otros dispositivos, solo es cuestión de acceder a la página web de administración de los mismos y configurarlos según corresponda.
Por último, la frutillita del postre, acceder a estos logs usando un cliente web usando phpsyslogng, (requiere Apache/PHP/MySQL), eso lo dejo para la próxima entrada, que por hoy se me acabó el tiempo:
Sigue en la parte 2: [HowTo] Controlar los logs generados por syslog desde una página web
Otro título sugerido: Como hacer que Eric Clapton pase totalmente desapercibido al ponerle a Mark Knopfler tocando a la par.
La canción que sigue tiene la propiedad de dejar totalmente embelesada a mi hija Danae, que tiene 4 meses de vida. Durante todo el transcurso de la canción se queda hipnotizada escuchando. ¿Puede alguien mas hacer el experimento con su bebé?
[youtube=http://www.youtube.com/watch?v=5ywsxs5fZkA]
Dire Straits – Brothers in Arms – Youtube – 8 Minutos
Eric Clapton: ¡Ni se nota que estás en el escenario!
Toda una mañana perdida tratando de descubrir por que udev no poblaba el arbol de dispositivos en /dev.
El mensaje de error decía algo así como:
Assuming that something failed as /dev/zero does not exists
Como resultado, /dev/sda no existía, por lo tanto fsck no podía controlarlo y la PC se quedaba trabada durante el arranque… Lo raro es que ingresando al sistema y creando el dispositivo a mano todo funcionaba normalmente:
mknod b 8 0 /dev/sda
mknod b 8 1 /dev/sda1
La actualización a sys-apps/baselayout-1.12.13
Como se plantea en este bug, vaciar el contenido de /sys:
rm -fr /sys/*
De todas formas estoy seguro de que los usuarios de Windows se enojan mas veces al año que los de linux, así que una vez mas, Gentoo: Estás perdonado.