Monitorizando los mensajes del sistema en la consola y en las X
Si queremos tener una ventana mostrándonos en todo momento los mensajes del sistema, el xconsole
es la aplicación que necesitamos:
En los escritorios moderno, es fácil configurar la ventana para mantener el xconsole
en primer plano.
Aunque la documentación de xconsole
diga que accede a /dev/console
, en muchas distribuciones (Make xconsole work), para evitar multitud de problemas que ocasiona engancharlo al /dev/console
relacionados con la no posibilidad de teclear en las ventanas (sólo con hacer un “xconsole -file /dev/console
“, se puede comprobar inmediatamente), normalmente las distribuciones crean una named pipe en /dev/xconsole
:
# ll /dev/xconsole prw-r----- 1 root adm 0 2007-12-08 12:27 /dev/xconsole|
en la que el syslogd
escribe, como vemos en el /etc/syslog.conf
de Debian:
# The named pipe /dev/xconsole is for the `xconsole' utility. To use it, # you must invoke `xconsole' with the `-file' option: # # $ xconsole -file /dev/xconsole [...] # # NOTE: adjust the list below, or you'll go crazy if you have a reasonably # busy site.. # daemon.*;mail.*;\ news.err;\ *.=debug;*.=info;\ *.=notice;*.=warn |/dev/xconsole
Si queremos que algún usuario distinto de root
pueda usar el xconsole
, habrá que asignarlo al grupo adm
(al menos en Debian), pero parece más conveniente simplemente crear un acceso directo usando kdesu
o gksu
para que nos pregunte el password de root
antes de ejecutar el xconsole
:
Para limpiar los mensajes actuales de la ventana del xconsole
, podemos hacer un CONTROL+C sobre ella, como descubrimos en el fichero /etc/X11/app-defaults/XConsole
:
*text.baseTranslations: #override\ Ctrl<KeyPress>C: Clear() \n\ <KeyPress>Clear: Clear()
Si queremos una especie de equivalente al xconsole
en la consola de texto, el syslog.conf
estándar de Debian ya nos ofrece una configuración perfectamente válida. Descomentando estas las líneas que envían varias áreas de syslog
al /dev/tty8
podremos verlos simplemente pulsando ALT+8 o ALT+CONTROL+8 si estamos en las X:
# # I like to have messages displayed on the console, but only on a virtual # console I usually leave idle. # daemon,mail.*;\ news.=crit;news.=err;news.=notice;\ *.=debug;*.=info;\ *.=notice;*.=warn /dev/tty8
Tras los cambios al syslog.conf
, podemos hacer un /etc/init.d/sysklogd reload
para que el cambio tenga efecto.
Hay que tener en cuenta que cualquiera con acceso físico a la máquina (incluso sin usuario válido) podrá ver estos mensajes que pueden llevar información sensible, de forma que hay que usarlo con mucha precaución. Por eso está deshabilitado por defecto.
:wq
Hace unos días estuve unas tardes buscando información sobre consolas y mensajes del kernel, y hoy me encuentro en tu blog artículos sobre acceso por modem, /dev/console, netconsole y syslog. Uaooo!!! Muchas gracias.
Unos matices.
No entiendo cuando dices que es preferible usar xconsole enganchado al pipe /dev/xconsole “para evitar multitud de problemas que ocasiona engancharlo al /dev/console relacionados con la no posibilidad de teclear en las ventanas”. Por lo que yo entiendo, /dev/console NO está pensado para poder escribir sobre ella mediante teclado.
Los permisos de /dev/console (rw–w–w-) me hacen dudar. Parece que /dev/console esté ideado para que las aplicaciones puedan escribir logs sobre ella y que dichos mensajes sólo pueda leerlos root. Pero por otro lado, ¿/dev/console no es únicamente para mensajes del kernel?, ¿por qué debería una aplicación escribir sobre él?.
La utilización de syslog+/dev/xconsole es una manera de puentear los permisos de /dev/console.
PD: recuerdo en la época de RedHat 5.x cómo en las salas de ordenadores de mi universidad se mostraba la cajita login/password en modo gráfico, con xconsole en la esquina inferior derecha, y al loguearte entrabas con el gestor de ventanas FVWM2, y se mantenía xconsole en pantalla. Tendré que revisar mis viejos CDs y hacer una instalación de prueba, para comprobar como gestionaban los permisos en aquella época.
@AlBundy Me alegro de que te haya parecido interesante y/o útil.
Respecto a:
puedes probarlo tú mismo fácilmente. Ejecuta “
xconsole -file /dev/console
” como root dentro de las X y si tu entorno se comporta como el mío, el ratón te seguirá funcionando pero dejarás de poder escribir texto en las ventanas. No me preguntes por qué sucede eso, porque no estoy seguro, pero así es. En el enlace del párrafo anterior también lo cuentan.Sobre el
/dev/console, en el
Documentation/devices.txt
de las fuentes del kernel nos aclara para qué sirve:Por tanto, sirve para mandar los mensajes del sistema y para hacer login en single-user mode.
Sobre los permisos, parece que en mi Debian no son tan flexibles como los tuyos:
La fecha es reciente porque el fichero de dispositivo es el creado por el udev, pero el fichero de dispositivo estático también tiene los mismos:
Por tanto, no parece ser un fichero que debiera ser accesible por los usuarios en general...
Por cierto, yo también he visto esa pantallita del
xconsole
a menudo. Ahora ya no se estilan esas cosasMuchas cosas que comentar, intentaré condensarlas y que no queden muy confusas.
Para mis pruebas utilizo un kernel 2.4.x con directorio /dev estático sin udev, y sin syslogd (soy un poco rarito, lo reconozco), pero los resultados deberían ser extrapolables a sistemas más modernos.
Lo que intento es usar /dev/console sin syslogd, pero sospecho que es algo imposible sin abrir pequeños agujeros de seguridad
Lo que aparece en la carpeta Documentation de las fuentes del kernel es francamente mejorable. Cuando tenga tiempo intentaré enviar algunos parches y que me los acepten.
Dicen que los “system messages” *deberían* ir a /dev/console; pero no aclaran qué son los “system messages” (NO son todos los mensajes del kernel, tampoco son todos los mensajes de las aplicaciones).
Sobre los permisos de /dev/console… sería una discusión larga. Durante muchos años han sido crw–w–w-. Otra cosa es que hayan decidido ahora que para más seguridad sea mejor reducirlos a crw——-, y que se pueda hacer un apaño con syslogd.
También hay que mencionar que el hecho de que los mensajes de las aplicaciones aparezcan en /dev/console o en syslog es cosa del código interno de la aplicación, y no de nuestra configuración. Supongo que será una buena práctica de programación el intentar usar siempre syslogd (que creo recordar que se limita a leer mensajes de /dev/log).
El init (SysVinit de Miquel van Smoorenburg) que se ha usado tradicionalmente en Linux hace uso de /dev/console y no puede usar syslog (y por cierto, esto me recuerda que te ponga otro comentario en tu otro artículo sobre el usar console=ttyS0,9600n8).
Y es cierto que ahora no se estila el uso de XDM+xconsole, pero todavía quedan rastros en los ficheros de config de X11. He destripado el paquete XFree86 que venía en una vieja RedHat 6.1, y las cosas NO son muy distintas de los paquetes Xorg actuales.
El programa xdm era ejecutado por el superusuario desde inittab, y por tanto no tenía problemas de acceso a /dev/console. Cuando el usuario se logueaba con éxito, se ejecutaba un script Xstartup, que a su vez llamaba a un script GiveConsole como este:
[PS1]% cat /etc/X11/xdm/GiveConsole:
#!/bin/sh
# Assign ownership of the console to the invoking user
# $XConsortium: GiveConsole,v 1.2 93/09/28 14:29:20 gildea Exp $
#
# By convention, both xconsole and xterm -C check that the
# console is owned by the invoking user and is readable before attaching
# the console output. This way a random user can invoke xterm -C without
# causing serious grief.
#
chown $USER /dev/console
/usr/X11R6/bin/sessreg -a -w "/var/log/wtmp" -u "/var/run/utmp"\
-x "/etc/X11/xdm/Xservers" -l $DISPLAY -h "" $USER
que soluciona el problema de acceso a /dev/console a lo bestia: cambiando su propietario.
Cuando terminaba la sesión X11, se ejecutaba el script Xreset, que a su vez llamaba a TakeConsole:
[PS1]% cat /etc/X11/xdm/TakeConsole:
#!/bin/sh
# Reassign ownership of the console to root, this should disallow
# assignment of console output to any random users's xterm
# $XConsortium: TakeConsole,v 1.2 93/09/28 14:30:29 gildea Exp $
#
chmod 622 /dev/console
chown root /dev/console
/usr/X11R6/bin/sessreg -d -w "/var/log/wtmp" -u "/var/run/utmp" \
-x "/etc/X11/xdm/Xservers" -l $DISPLAY -h "" $USER
que trataba de arreglar el estropicio en usuario y permisos de /dev/console.
De los comentarios de GiveConsole, podemos ver que si damos permisos peligrosos a /dev/console podemos prescindir incluso de xconsole, ejecutando:
xterm -C -e bash
(ó xterm -C simplemente), de manera que los mensajes dirigidos a /dev/console aparezcan en el propio xterm.
Con permisos peligrosos en /dev/console podemos hacer
echo "Hello wolrd" >/dev/console
y aparece “Hello world” en el xconsole, o en el xterm -C.
Sólo se permite el acceso de un xconsole a /dev/console. Si intentamos acceder con varios a la vez, no nos deja.
Conclusiones:
*Los usuarios distintos de root sólo pueden acceder directamente a /dev/console si dicho fichero especial tiene permisos peligrosos.
*La manera segura de que cualquier usuario visualice mensajes dirigidos a /dev/console es usar syslogd y un FIFO accesorio, tal y como ha explicado Super Coco
*Ya es hora de que me cree mi propio blog y no envíe comentarios tan largos a los blogs de los demás X-D
@AlBundy Muchas gracias por tan detallado e informativo comentario. No te lamentes por enviar comentarios largos porque son muy bienvenidos. Todo lo que sea complementar la información de la entrada se agradece enormemente. Por supuesto, si decides empezar un blog, viendo la calidad de tus reflexiones, no dudes de que aquí tienes al primer subscriptor.
Respecto al
syslogd
, como muy bien dices, lee de/dev/log
, que no es un fichero de dispositivo sino un socket UNIX:Respecto a lo que comentas de qué son los “system messages”, yo pienso que son los del kernel, los que salen en el
dmesg
. ¿Qué te hace pensar que “NO son todos los mensajes del kernel”?Sobre la buena práctica de usar el syslogd, la verdad es que usando el
/dev/xconsole
te puedes pesonalizar los mensajes que quieres ver y no limitarte a los que el kernel quiera mandar a/dev/console
. Si, como dices, no vas a usar elsyslogd
, te perderás todos los mensajes que las aplicaciones hubieran enviado a dicho demonio, que pueden ser cosas muy importantes, como ya sabes.Finalmente, gracias por la muestra de arqueología del software libre al mostrarnos la cómo lo hacía el RH 6.1, que es realmente curioso y, sobre todo, por hablarnos de esa opción -C del
xterm
que parece muy interesante. Tengo que probarla más detenidamente.Gracias por compartir tus experiencias aquí