Cómo mandar mensajes del Kernel de Linux por red

Una de las prácticas que más miedo le da a uno a la hora de trabajar con GNU/Linux es la actualización del Kernel... Dicha actualización siempre tiene cierta peligrosidad,especialmente si el kernel ha sido compilado a mano, ya que al final estamos metiendo una nuevo núcleo que va a soportar nuevos componentes de hardware, va a solucionar bugs, etc... pero que también puede generar ciertas incompatibilidades y puede tener algún problema con algún módulo o alguna función, llegando a generar, en casos extremos, los temidos 'Kernel panic'. Es por ello que puede ser interesante capturar los mensajes del kernel con el fin de ver la causa de un problema concreto; especialmente el mencionado kernel panic, ya que si hay un kernel panic y el sistema es reiniciado (cosa normal, ya que los pánicos suelen hacer que el ordenador se apague o reinicie), el problema no se registra en ninguna parte y lo único que ven los logs es el kernel panic en sí y no la causa del error. Además, al ser enviados los mensajes a otra máquina, podremos examinarlos tranquilamente pues la maquina receptora, en un principio, será un equipo estable.

Para ello lo que habría que tener claro es la esquemática de red que seguiremos... En este caso querremos que los mensajes a otro equipo que se encuentra en la misma red local; en concreto el escenario sería el siguiente:
Escenario transferencia de mensajes del kernel
Con esto claro, lo primero que tenemos que conocer es la MAC del equipo destino, MAC que usaremos más adelante para el envió de mensajes... Esto se puede conocer gracias a la tabla ARP que se puede consultar desde el equipo que va a enviar los mensajes. Para ello simplemente tendremos que usar dos comandos muy sencillos que se pueden usar en una consecución:
ping-c2 192.168.1.7 & arp -n|grep 192.168.1.7 |awk'{print $3}'
Con el primer comando, haríamos un simple ping al equipo al que queremos transferir los archivos, ping que haría que la IP y la MAC del equipo de destino se agregasen automáticamente a la tabla ARP (siempre y cuando no existiesen ya dichos datos). Con el segundo comando extraeríamos la MAC correspondiente a dicha IP; extracción que realizaríamos de la tabla ARP.
Ahora que conocemos la MAC del destinatario de nuestros mensajes, pasaremos a modificar el arranque del GRUB en el equipo A para que muestre todos los eventos del kernel durante el arranque, acción que realizaremos como root... Esto se puede hacer de dos formas, o de manera temporal o de manera permanente... En este caso lo haremos de forma permanente, para lo cual iremos al fichero /etc/default/grub y editaremos el parámetro GRUB_CMDLINE_LINUX_DEFAULT, borrando su contenido y haciendo que tenga el siguiente aspecto:
GRUB_CMDLINE_LINUX_DEFAULT="debug ignore_loglevel"
Tras dicho cambio, guardaríamos los cambios en el fichero y luego ejecutaríamos el comando:
update-grub
Tras realizar dicho cambio lo que haremos será que un módulo llamado netconsole cargue durante el arranque, dicho módulo permitirá el envío de eventos del kernel a través de la red, con lo que su importancia es fundamental. Para añadir dicho módulo simplemente habría que incluirlo dentro del fichero /etc/modules. Esto consiste simplemente en escribir el comando de a continuación:
echo'netconsole'>>/etc/modules
Aún así, con la carga de dicho módulo durante el arranque no vale, pues dicho módulo debe tener una configuración, en la que se especifique de donde a donde van a ir los paquetes, la interfaz por la que van a salir y la MAC del destinatario (para evitar posibles malentendidos o posibles ARP spoofing). Para dicha configuración habría que crear el fichero /etc/modprobe.d/netconsole.conf y añadirle lo siguiente:
options netconsole netconsole=10000@192.168.1.6/eth0,10000@192.168.1.7/08:00:27:e0:ad:30
Tal vez así escrito no quede demasiado claro, pero expuesto de forma genérica vendría a ser la estructura:
options netconsole netconsole=puerto_origen@ip_origen/nombre_interfaz_origen,puerto_destino@ip_destino/mac_destino
Es muy importante que todos los datos estén correctos, ya que en caso contrario el módulo no cargará y no podremos enviar los eventos.
Teniendo el emisor preparado, habría que preparar el receptor de dichos mensajes; preparación que afortunadamente no requiere gran esfuerzo; simplemente requiere tener netcat instalado. En caso de no tenerlo instalado haríamos:
apt-get install netcat
Netcat sería usado en este caso para ponernos a "escuchar" en el puerto que hemos especificado anteriormente en netconsole.conf; escucha necesaria para recibir los paquetes que el emisor va a lanzar. Para ponernos en escucha la sintaxis sería:
nc -l -u -p puerto > fichero &
Con esto no solo estaríamos poniéndonos en escucha, sino que además estaríamos almacenando lo recibido en un fichero y con el símbolo & al final estaríamos haciendo que el proceso corriese en segundo plano para que la consola no se sature con mensajes constantemente y para que simplemente leamos los susodichos cuando queramos. En este caso, al haber escogido el puerto 10000 lo que escribiríamos sería:
nc -l-u -p10000>/root/192.168.1.6_kernel.log &
Ahora, con tan solo reiniciar el equipo emisor, éste empezaría a mandar eventos; eventos que serían desde los generados en el propio arranque hasta cualquier evento generado por el kernel mientras el equipo está en marcha; gracias al comando anterior, la consola del receptor no se encontraría saturada de mensajes constantemente, sino que solamente tendríamos que consultar el fichero donde estamos volcando los susodichos... Al ser un fichero que suele recibir información con regularidad, lo ideal sería ver tanto el contenido de por sí añadido como el que se va añadiendo en tiempo real, con lo que la mejor forma de consultarlo sería mediante el comando:
tail-n100-f/root/192.168.1.6_kernel.log
A modo de ejemplo, nos podríamos encontrar con el contenido de a continuación:
Ejemplo mensajes del kernel
Los mensajes serían exactamente los mismos que los que mostraría el equipo emisor si introdujésemos en éste el comando dmesg, con la ventaja de que en caso de reiniciar el equipo, no perderíamos la información generada.
Como podéis ver, los mensajes del kernel pueden ser enviados por red con facilidad, mensajes que más adelante pueden ser analizados con tranquilidad para poder ver la causa los problemas, en caso de haberlos.
Espero que os haya resultado útil.
Saludos.