En los centros que tienen Ciclos Formativos los tutores tienen que rellenar todos los años una extensa documentación que está disponible en formato ODT, DOC y PDF. Estos documentos están diseñados de una manera que deja bastante que desear en cuanto a usabilidad y portabilidad, con algunos detalles bastante irritantes. Todos los cursos hay problemas con estas plantillas a la hora de abrirlas entre distintos sistemas operativos y programas ofimáticos.
Para intentar evitar estas dificultades hemos hecho una version Google Doc de todos estos documentos que puede ser rellenada en de forma online usando el navegador. Este es el enlace a la carpeta compartida donde están los documentos: pulsa aquí. Se supone que esto los hace mas portables y reutilzables.
La carpeta de Google Drive compartida es de solo lectura, por lo que cada cual tendrá que hacer una copia de los documentos en su drive local para trabajar con ellos. A ver si ya nos quitamos este quebradero de cabeza de una vez.
Gran misterio de los que te asaltan a traición por los pasillos: "¿qué le has hecho a los ordenadores que se encienden solos cuando pasas al lado de ellos?". Sucedía en un aula de ciclos formativos con Windows 10. Investigando en este interesante mensaje sobre encendidos intempestivos veo que la única causa posible es que están configurados por defecto para salir de hibernación/suspensión ante eventos de teclado y/o ratón. En una consola de administrador, con el comando:
powercfg -devicequery wake_armed
Nos lista los dispositivos que están "armados" para despertar el equipo ante un estímulo externo. Supongamos que en ese listado aparecen teclado y/o ratón con las denominaciones "Teclado PS/2 estándar" y "Mouse compatible con HID". Con los comandos:
Desactivamos estos encendidos repentinos de forma permanente y el problema deja de suceder. El inconveniente es que si cambiamos el teclado y el ratón y pasan a llamarse de otra manera puede que vuelva a presentarse el problema.
¿Y por qué al pasar al lado del PC se producía un encendido causado por el ratón? Pues la única explicación que encuentro es que pasaban al trote y hacían vibrar el suelo, la mesa y el ratón.
Si queremos sacar la lista de interfaces de red que hay levantadas y con señal (LINK STATE UP) en el cable en un PC con Linux, podemos hacerlo con esta secuencia de comandos:
interfaces_up=$(ip link show | grep "state UP" | cut -d" " -f2 | grep -v "lo:" | tr -d ":" | tr "\n" " ")
echo $interfaces_up
Todo queda en una única línea para que, por ejemplo, podamos iterar por ellas mediante un comando for.
Ya tratamos el tema de los libros digitales Santillana en 2017 y 2018. En 2019 y 2020 Santillana no perpetró ninguna nueva versión, pero este año no ha podido evitar brindarnos una nueva edición de sus libros de Francés. Vemos que sigue apostando por la novedosa tecnología de Flash, aunque afortunadamente ya no incluye los audios en cintas de cassette.
Tenemos los libros de Parachute 1, 2, 3 y 4 para eso y C'est à dire para Bachillerato, distribuidos cada uno en un fichero .zip. Tras descomprimirlos vemos su contenido:
drwxrwsrwx 3 user user 4096 ene 16 2020 app.app
-rwxrwxrwx 1 user user 303687 jun 1 16:45 browser.swf
drwxrwsrwx 4 user user 53248 ago 10 2020 contenido
drwxrwsrwx 2 user user 36864 ago 10 2020 curso
-rwxrwxrwx 1 user user 1214 jun 1 16:45 exeBrowser.htm
-rwxrwxrwx 1 user user 11487542 jun 1 16:45 exeLinux
-rwxrwxrwx 1 user user 98 jun 1 16:56 exeMac
-rwxrwxrwx 1 user user 5547573 jun 1 16:45 exeWin.exe
-rwxrwxrwx 1 user user 1598 jun 1 16:45 lisez-moi.txt
drwxrwsrwx 3 user user 4096 ene 16 2020 macsc.app
drwxrwsrwx 2 user user 4096 ago 10 2020 modulos
drwxrwsrwx 2 user user 4096 ago 10 2020 recursos
-rw-rw-r-- 1 user user 328028 oct 19 09:41 strace.log
Me llama la atención que en 2018 habían quitado la versión web/flash (exeBrowser.htm) dejando solo las versiones basadas en un ejecutable (Linux, Windows y OSX), pero al parecer de nuevo la han recuperado.
Como nosotros tenemos sistemas Linux hay varias opciones para ejecutar este software:
Lanzando el ejecutable de Linux exeLinux directamente con un fichero .destkop como éste:
Para que funcione la versión de Linux hay que instalar con apt-get varias librerias de i386, como ya contamos aquí y ni aun así funciona siempre. Por ejemplo, en ciertos PC con tarjeta nVidia y driver nouveau me he encontrado con que fallan al ejecutarse, mostrando este mensaje y abortando:
libpng warning : Application jmp_buf size changed
Violacion de segmento
No he encontrado manera de hacerlo funcionar. Otro problema que tiene el exeLinux es que no puede mostrar los vídeos, teniendo que abrirlos aparte como ya indicamos aquí. Seguramente es un problema derivado del Flash embebido en el ejecutable.
Adicionalmente, si mostramos los vídeos aparte no se verán los subtítulos, ya que vienen en un formato particular. Como si no hubiera formatos de subtítulos previos, Santillana ha decidido brindar al mundo su propio formato.
Lanzando el ejecutable de Windows exeWin.exe mediante wine, con un .destkop como este:
En este caso el programa se abre bien a pantalla completa en todas las máquinas que he probado, pero al ir mediante wine es sensiblemente mas lento e inestable.
El exeWin.exe muestra el mismo problema que el caso anterior a la hora de mostrar los vídeos.
Lanzando el exeBrowser.htm, mediante un navegador que sopoorte Flash. Gracias a mis compañeros de otros centro supe que el navegador palemoon sigue dando soporte a la última versión de Flash que se liberó. Usaríamos este fichero .desktop:
De esta manera se abre bien, dentro de una ventana de navegador web y se reproducen los vídeos (y subtitulos) sin mayor problema. Es una pena que por necedad de Santillana tengamos que andar trabajando con navegadores antiguos, pero es lo que hay.
Para que se abra el .htm desde el navegador hay que dar permisos para que Flash pueda abrir la ruta (en nuestro ejemplo /home/ruta/PARACHUTE1) tal como contamos en esta entrada. Podéis ver allí con detalle como hacerlo.
El palemoon lo he descargado desde este enlace. El fichero palemoon_29.4.1-1.gtk2_amd64.deb se instala directamente en nuestro Ubuntu 18.04 mediante tarea puppet sin mayor problema.
Bueno, dentro de dos o tres años nos vemos de nuevo con un Ubuntu actualizado y un Santillana todavía con Flash. Eso si que es resistencia al cambio.
Ya comenté que tengo un repositorio local de paquetes construido con reprepro, que me viene muy bien para instalar paquetes de Ubuntu que no vienen en los repositorios oficiales y que habria que descargar e instalar de forma manual en cada máquina. Tambien ofrece muy buena integración con pkgsync, que lleva mal el usar paquetes ajenos a los repositorios.
Hace poco estaba quitando un paquete del repositorio y a mitad de proceso he tenido un problema de dificultades (como dijo el ministro) y se ha cerrado la conexión. El paquete ha quedado medio quitado, medio no, ya que al parecer la desinstalación no es un proceso transaccional. De esta manera, si hacia:
# cd /var/www/repositorio/centro
# reprepro list bionic
El paquete no aparecía en el repositorio, pero si en los clientes hacía:
# apt-cache search paquete-problematico
Si que aparecía y podía instalarlo. Por otro lado, si intentaba eliminar el paquete:
# reprepro remove bionic paquete-problematico
Not removed as not found: ...
Exporting indices...
Me decía que no estaba, pero si intentaba añadirlo de nuevo:
# reprepro --ask-passphrase includedeb bionic paquete-problematico-vX.Y.Z.deb
Within references.db subtable references at put: BDB0067 DB_KEYEXIST: Key/data pair already exists
Me decía que no podía añadirlo ya que el registro estaba duplicado. Reprepro utiliza internamente una base de datos en formato Berkeley DB que carece de herramientas sencillas para manejarla. ¿Cómo salir del atolladero y librarnos de este paquete de Schörindger?
Reprepro tiene poca documentación y soporte. Tras buscar en Google y encontrar gente con el mismo problema sin solución, he ido a leer la página de manual (lo último que se lee antes de que se explote todo) y he dado con los comandos:
# reprepro rereference
Con este comando anterior se reconcilian las bases de datos. Después de ejecutarlo podemos reinstalar y luego quitar el paquete normalmente, quedándolo fuera del repositorio. Con:
# reprepro clearvanished
Eliminamos el fichero .deb de la ruta donde está, ya que por defecto se quedan allí aunque ya no estén indexados. Con esto queda la tarea completada.
Los taikonautas chinos acaban de hacer el primer paseo espacial desde su flamante estación.
Recordemos que esa estación la ha construido China con sus propios medios, ya que tenían vetada por USA la entrada a la Estación Espacial Internacional. Ante este panorama, la Republica Popular de China ha optado constuirse su propia estación espacial, con casinos... y furcias.
Cuando se nos van los niños nos toca hacer una limpieza y actualización de los portátiles para quedarlo todo listo de cara al curso venidero. Voy a repasar las actuaciones que realizo para dejarlo todo en orden. Primero verifico en cada portátil que los paquetes están bien y actualizo todo:
Luego lanzo un script para limpiar los perfiles de los usuarios, borrar todas las conexiones wifi creadas excepto "educarex" y restaurar el background por defecto en el lightdm (en el caso de que la tengamos personalizada según conté en esta entrada antigua)
# cat limpiar-usuarios-y-wifi.sh
#!/bin/bash
#Limpia credenciales cacheadas
sss_cache -E
rm -rf /var/lib/sss/db/cache_LDAP.ldb
#Limpia conexiones wifi antiguas, excepto educarex
if [ -e /etc/NetworkManager/system-connections/educarex ]
then
cp /etc/NetworkManager/system-connections/educarex /tmp/educarex
rm /etc/NetworkManager/system-connections/*
cp /tmp/educarex /etc/NetworkManager/system-connections/
else
rm /etc/NetworkManager/system-connections/*
fi
#Limpia homes antiguos
rm -rf /home/alumnos/*
#Pone background por defecto.
cp -f /usr/share/xfce4/backdrops/linexEDU_2018_4_bak.png /usr/share/xfce4/backdrops/linexEDU_2018_4.png
Hacer esto en todos los portátiles uno a uno es un poco latoso. Para evitar esta tarea repetitva lo que hago es encenderlos por grupos, dejando que se conecten a la red wifi del centro de forma automática. Luego hago un nmap para localizar estos equipos y mostrar sus IP y nombres:
# cat escanear-educarex-nombres
#!/bin/bash
red="10.192.x.0" # Cambiar x por la subred de tu centro.
password="contraseña de root de portatiles"
machines=$(nmap -p 22 ${red}/24 | cut -d" " -f5 | grep 10)
for maquina in $machines
do
name=$(sshpass -p${password} ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@$maquina 'echo $HOSTNAME' 2> /dev/null)
echo "$maquina -> $name"
done
echo ""
En este listado anterior sacamos las IP de todos los dispositivos conectados a la red "educarex" que tienen el puerto 22 (ssh) abierto. Si son portátiles inicia sesión en ellos y muestra su nombre, lo cual nos permite identificar los equipos de forma fehaciente. Una vez tenemos este listado de IPs podemos hacer una conexión multiple hacia ellas con tmux-cssh:
Esto abre en paralelo un porrón de conexiones ssh que nos permiten trabajar con todos los portátiles a la vez, escribiendo comandos que se lanzan de forma simultánea en todos ellos. De esta manera puedo operar con 30, 50.. portátiles sin problema, avanzando rápidamente.
Otra cosa que me gusta hacer es verificar el estado de salud de la batería de los portátiles. Cuando los enciendo me cuido de que estén completamente cargados al máximo y una vez actualizados y limpios lanzo el siguiente comando usando la consola tmux-cssh:
# while true
do
uptime
upower -i /org/freedesktop/UPower/devices/battery_BAT0 | grep percen
sleep 10
done
Con esto lanzo simultaneamente un bucle infinito que muestra el tiempo de encendido y bateria restante, actualizándose cada 10 segundos. De esta manera, tras un rato podemos chequear como baja la batería en cada uno de los portátiles y hacernos una idea de su salud.
Una vez hecho esto ya podemos retornar los portátiles al armario y dejarlos ya listos para ser usados el próximo curso.
Alucinante video de la Zhurong en Marte. La primera vez que vemos un vídeo y oímos un rover movíendose por la superfice de Marte, con el aterrizador de fondo. Los camaradas chinos han vuelto a lucirse:
Bueno, pues por fin me he metido en el apasionante mundo de Zabbix. Con ayuda de mis compañeros he ido montando el sistema, los clientes y los templates para cada tipo de dispositivo que se puede encontrar en mi red. Es todo un universo nuevo, pero merece la pena sobradamente.
Una de las cosas que más me interesa monitorizar son las impresoras, tanto para llevar un control histórico del gasto como para recibir avisos de que queda poca tinta/tóner e ir encargando con repuestos tiempo. Para las impresoras HP y Epson que tenemos en los centros ya hay templates de monitorización que han compartido los compañeros, pero tengo por mi parte varias impresoras Brother láser color (DCP-9020CDW, HL-4140CN y alguna más) para las cuales el número de templates que se encuentran es bastante escaso. En la página de templates oficial de Zabbix aparecen apenas 3 plantillas, todas para láser monocromo, que se pueden importar (algunas con errores que hay que corregir editando a mano XML, pues son un poco antiguas), pero no nos dan toda la información que queremos sobre las impresoras láser en color.
Me ha tocado investigar un poco para crear una plantilla mezcla de las 3 existentes más items nuevos para obtener los datos que faltaban. Esta es la parte divertida de nuestro trabajo, no todo iba a ser azotar usuarios. No ha sido todo nuevo, puesto que las impresoras son interrogadas usando el protocolo SNMP y ya tenía experiencia al haberlo utilizado hace bastante tiempo para otra entrada del blog.
AVISO: tochazo inside.
1. Uso de snmpwalk para interrogar impresoras.
Para preguntar sobre toda la información que comparte de forma pública una impresora usamos el comando:
La lista es bastante grande y normalmente ahí hay información de sobra sobre el estado de nuestra impresora. Cada rama o nodo tiene un significado más o menos estándar (aunque recordemos el axioma que dice "lo bueno de los estándares es que hay varios donde elegir"). Por ejemplo, de la lista anterior el OID iso.3.6.1.2.1.1.6 se describe como:
Literalmente: "The physical location of this node (e.g., 'telephone closet, 3rd floor'). If the location is unknown, the
value is the zero-length string", es decir, la ubicación física de la impresora tal como está definida en su configuración. El valor de este campo se obtiene con:
# snmpwalk -v 2c -c public 172.a.b.c iso.3.6.1.2.1.1.6
iso.3.6.1.2.1.1.6.0 = STRING: "Sala de Profesores"
La información sobre el contenido cada OID (object identifier o Identificador de Objeto, que se define como una secuencia de números que se asignan jerárquicamente y que permite identificar objetos en la red, siendo usados con gran cantidad de protocolos) estándar se puede consultar en varios sitios de internet:
Hasta aqui todo sería estupendo si todas las impresoras respetasen los OID estándar. Con las HP y las Epson no hay problema, pero mis Brother son rebeldes. La mayoría de los OID (ubicación, status, páginas impresas, número de serie, etc) se ajustan al estándar definido y vale el mismo template que para cualquier otra impresora, pero aquellos que deben decirme el nivel de tóner restante mienten o son inexactos.
El estado de los consumibles se encuentra en la rama iso.3.6.1.2.1.43.11, prtMarkerSupplies. Vamos a husmear dentro (añado comentarios explicando el significado de las ramas):
prtMarkerSuppliesType, nodo iso.3.6.1.2.1.43.11.1.1.5: tipos de consumible. Por ejemplo, el valor 3 equivale a "tóner".
prtMarkerSuppliesDescription, nodo iso.3.6.1.2.1.43.11.1.1.6: descripción del consumible. Por ejemplo "Magenta Toner Cartridge".
prtMarkerSuppliesSupplyUnit, nodo iso.3.6.1.2.1.43.11.1.1.7: unidades de medida del consumible. Por ejemplo, el valor 13 equivale a "decígramos".
prtMarkerSuppliesMaxCapacity, nodo iso.3.6.1.2.1.43.11.1.1.8: valor máximo de capacidad del consumible: puede ser la cantidad de tóner o tinta que cabe en el cartucho, o el número máximo de páginas que tiene de vida útil un tambor/cinta de arrastre.
prtMarkerSuppliesLevel, nodo iso.3.6.1.2.1.43.11.1.1.9: nivel actual del consumible: puede ser la cantidad de tóner o tinta que resta en el cartucho (un %, un número estimado de páginas, etc), o el número de páginas que le quedan por imprimir a un tambor/cinta de arrastre.
Con estos indicadores se puede controlar cuanto consumible queda... en teoría. En el caso de las impresoras Brother el contenido de las ramas prtMarkerSuppliesMaxCapacity y prtMarkerSuppliesLevel no dan datos reales sobre los niveles de tóner, aunque si del estado de otros consumibles: almacén de tóner, cinta de arrastre y tambores. En ellas prtMarkerSuppliesMaxCapacity siempre tiene el valor -2 y prtMarkerSuppliesLevel lo he visto con únicamente dos valores distintos: -3 (hay toner) y 0 (no hay tóner), lo cual es muy poco informativo. En Internet se habla de otros posibles valores asociados a varios estados ("full", "almost empty", "empty" or "absent) pero en mis pruebas esos valores nunca han aparecido.
Cusiosamente, casi todos los otros parámetros estándar de impresoras si que están implementados para las Brother. Por ejemplo, hrPrinterStatus con los valores de estado de la impresora: other(1), unknown(2), idle(3), printing(4), warmup(5).
Buscando una solución encontré un parámetro llamado prtAlertcode en la rama iso.3.6.1.2.1.43.18.1.1.7 que nos devuelve un código de alerta si pasa algo en la impresora. Como se ve en el enlace anterior hay un buen número de códigos, incluido el 1104 que significa markerTonerAlmostEmpty: queda poco tóner. No nos dice el color, pero puede servir para alertar si no nos queda más remedio.
Evidentemente, con esta información es imposible poder monitorizar con detalle el nivel de los consumibles y planificar su adquisión. Pero esto no puede quedar aquí: si vamos al interface web o el panel de la impresora Brother vemos que si que conocen y muestran esos niveles. Es obvio que tiene que haber alguna manera de interrogar a la impresora para obtenerlos.
3. Buscando e interpretando los OID privados.
Mirando con mas detalle me encontré que hay ciertas ramas "ocultas" o privadas que dependen del fabricante del dispositivo y que no salen haciendo un snmpwalk normal. El nodo sysObjectID, con OID iso.3.6.1.2.1.1.2 contiene "The vendor's authoritative identification of the network management subsystem contained in the entity". En caso de las Brother su contenido es:
Es decir, ese nodo contiene una referencia a otra rama, que en el caso de la Brother es iso.3.6.1.4.1.2435. Esta es una rama oculta, que si consultamos directamente con:
Muestra mas de 5000 nodos con mucha información privada de la impresora Brother. El código 2435 corresponde a Brother, pero como se puede ver en este enlace hay códigos para todo tipo de fabricantes, asignados por IANA. Cada uno tendrá su rama privada colgando de ahí.
En https://oidref.com/ podemos perdernos husmeando dentro de esa rama. Yo he ido al grano, buscando valores que me interesaban para su monitorización con Zabbix, por ejemplo el nodo brBackLightColor, que tiene 4 posibles valores: 0:Off/1:Green/2:Orange/3:Red. Básicamente sirven para indicarnos el color que muestra led del panel de la impresora, 0 o 1 significa que bien, y 2 o 3 que hay problemas. Los templates de Zabbix que encontré para impresoras Brother monocromo usaban brBackLightColor en conjunción con prtAlertCode (visto anteriormente) para avisar de forma rudimentaria de que quedaba poca tinta.
Pero no olvidemos que la meta es saber los niveles de los 4 tóneres de color. No hallaba información alguna hasta que encontré pistas en este enlace, y sobre todo en este otro, donde se muestra un programa que lee los niveles reales de tóner de una Brother color. Los datos se leen por SNMP mediante este conjunto de scripts en Python. Indagando en el código veo que los niveles de tinta se sacan de la rama iso.3.6.1.4.1.2435.2.3.9.4.2.1.5.5.8.0, llamada brInfoMaintenance. ¿Qué hay allí?:
Mmmm, esto es una retahíla hexadecimal incomprensible...
4. Extrayendo información de brInfoMaintenance
Bueno, pues ahi dentro está la información. Y alguien ha hecho ingeniería inversa para extraerla. Tras leer dicha página comprendo que, para las impresoras que tengo, la información se organiza en septetos de bytes, asi que formateo la salida del comando para que salga en grupos de 7 valores::
A continuación vienen los valores fijos "01 04" y los cuatro últimos bytes son el valor del parámetro, por ejemplo:
71 01 04 00 00 23 F0
El "71" es VAL_MAGENTA_TONER_REMAIN, tóner restante magenta. El "01 04" lo ignoramos. Y el "00 00 23 F0" es el número hexadecimal 0x23F0, que en decimal es 9200. Ese 9200 se debe dividir por 100 y nos da el porcentaje de toner magenta restante: 9200/100=92% de tóner. ¡Ahí está la información!. Por tanto, en:
Podremos sacar el % de cada cartucho de tóner. Puñeteramente endiablado lo ha puesto Brother. Menos mal que un esforzado hacker de los buenos lo ha decodificado, Gloria y Honor para él.
5. El template Zabbix final.
Bueno, pues el template debe extraer el churro hexadecimal de iso.3.6.1.4.1.2435.2.3.9.4.2.1.5.5.8.0, buscar los códigos 6F, 70, 71 y 72 para cada cartucho de tóner y extraer el nivel en cada uno.
La manera mas sencilla que he encontrado es crear un item que lee la secuencia hexadecimal completa por SNMP y luego hace un preprocessing con Javascript (me encanta ese lenguaje) que busca el código identificador del cartucho en cuestión, extrae los dos bytes con el valor, los convierte de hexadecimal a decimal y lo divide por 100 para obtener el valor que será el mostrado por el item. El código para el tóner Cyan sería:
var pos = value.indexOf("70 01 04 00 00");
var res=0;
if (pos >=0 ) {
res=value.substring(pos+15, pos+20);
res=parseInt(res.replace(" ", ""),16)/100;
};
return res;
Como se puede ver añadimos un trigger que avisa cuando el tóner está por debajo del 10%. El resto de colores se haría con el mismo método.
Finalmente, incluyo enlace Template_Brother_Laser_Printers.xml con el template Zabbix final para impresoras Brother Láser Color, en formato XML listo para ser importado y leer bien todos los niveles de tóner, junto con varios valores más adicionales que me ha parecido interesante mantener o añadir. Algo me dice que este será el template Zabbix mas enrevasado que nunca escribiré.
Estamos que no paramos con Marte. Los camaradas de la República Popular de China ha aterrizado con la discreción que le caracteriza su rover Zhurong. Parece ser que para la civilización China a la primera va la vencida. Todavía no hay imágenes directas, pero esto nos sirve como adelanto:
Esperamos ansiosos las imágenes del rover trabajando.
Este asunto acerca de mostrar un mensaje en el escritorio desde una sesión de consola o ssh ya lo vimos en otra ocasión, pero he tenido que darle una vuelta más en los últimos tiempos por una petición de un profesor. Vamos a revisitarlo usando este script más afinado:
# cat /usr/bin/mensaje-escritorio.sh
#!/bin/bash
if [ $# -ne 1 ]
then
echo "Uso de parámetros incorrectos"
echo " $0 'Internet será cortado a las 12.30 durante media hora\'"
echo " Formato de mensaje en Pango Markup Language"
exit 1
fi
fecha=$(date "+%H:%M. %d-%m-%Y")
mensaje="\n\n\nAtención: \n\n$1."
DISPLAY=:0 XAUTHORITY=/var/run/lightdm/root/\:0 zenity --display=:0 --info --text="$mensaje" --title="Aviso ${fecha}" --width="800" --height="600" --ok-label="OK"
exit 0
Básicamente, desde consola o desde una conexión ssh mostramos en el escritorio gráfico un mensaje, que se pasa como parámetro y que ocupará la mayor parte de la pantalla. Si no hay sesión abierta el mensaje se mostrara en la pantalla de inicio de sesión. Por ejemplo:
# mensaje-escritorio.sh "Por favor, cierre la sesión ya que se va a reiniciar el servidor dentro de los próximos <span foreground='red'><b>5 minutos</b></span>"
Se mostrará:
Como podemos observar, el mensaje puede tener formato (negrita, tamaños, colores,...) usando el Pango Markup Language, un lenguaje de marcado sencillo que permite dar formato a textos al mostrarlos en pantalla.
Ahora bien, ¿que pasa si queremos enviar el mensaje a varias máquinas a la vez?. Pues sería con este script:
# cat /usr/bin/multi-mensajes.sh
#!/bin/bash
#Parametros
# $1=mensaje
# $2=lista maquinas
if [ $# -ne 2 ]
then
echo "Número incorrecto de parámetros"
echo " $0 \"Atencion, cierren sesión\" \"spro-o01 a02-pro a04-pro\""
echo " Formato de mensaje en Pango Markup Language"
exit 1
fi
clave="password1234"
for maquina in $2
do
sshpass -p${clave} ssh -o StrictHostKeyChecking=no root@$maquina "/usr/bin/mensaje-escritorio.sh \"$1\" > /dev/null 2>&1 " &
done
exit 0
Por ejemplo, para mostrar un mensaje en el escritorio de 4 máquinas:
# multi-mensajes.sh "Por favor, cierre la sesión ya que se va a reiniciar el servidor dentro de los próximos <span foreground='red'><b>5 minutos</b></span>" "spro-o01 spro-o02 a02-pro a05-pro"
Si lo hacemos muy a menudo podría ser interesante usar el comando dsh en lugar de hacer llamadas ssh individuales. Incluso podemos valorar establecer relaciones de confianza SSH para evitar tener que indicar la clave de root en cada llamada.
Bien, pues con esto tenemos una herramienta para mandar mensajes emergentes remotos desde una máquina a cualquier otra máquina del centro.
En esta ocasión el problema era algo distinto: por razones que no vienen a cuento se necesitaba capturar una foto con la webcam y enviarla por correo a una dirección predeterminada.
Para hacerlo usaremos 2 herramientas:
fswebcam: es una utilidad para sacar fotos con la cámara.
mailsend-go: versión actualizada de una utilidad para enviar correos (y ficheros adjuntos) usando un servidor SMTP externo, por ejemplo una cuenta de gmail. Como no está empaquetada en Ubuntu hay que descargar el ejecutable y copiarlo a mano en el equipo.
El script que usaremos será:
# cat /usr/local/bin/click-and-mail
#!/bin/bash
#Añadir el parametro /m si queremos enviar un correo con el resultado de la captura
REMITENTE="cuentaenvio@gmail.com"
DESTINATARIO="cuentadestino@gmail.com"
PASSWORD="password1234"
EQUIPO=$HOSTNAME
MAIL=$1 # "/m" enviar correo, vacio: no enviarlo
FECHA=$(date '+%Y-%m-%d-%H:%M')
LOG="/root/.picture"
mkdir -p $LOG
if [ -e /dev/video0 ]
then
/usr/bin/fswebcam -d /dev/video0 --scale "640x480" "/tmp/snapshot.jpg"
test "$MAIL" == "/m" && /usr/local/bin/mailsend-go -sub "Foto $HOSTNAME" -smtp smtp.gmail.com -port 587 \
auth -user $REMITENTE -pass "$PASSWORD" -from "$REMITENTE" -to "$DESTINATARIO" \
body -msg "Foto" attach -file "/tmp/snapshot.jpg"
mv -f "/tmp/snapshot.jpg" "${LOG}/s${FECHA}.jpg"
echo "Captura $FECHA" >> ${LOG}/capture.log
else
test "$MAIL" == "/m" && /usr/local/bin/mailsend-go -sub "Foto $HOSTNAME" -smtp smtp.gmail.com -port 587 \
auth -user $REMITENTE -pass "$PASSWORD" -from "$REMITENTE" -to "$DESTINATARIO" \
body -msg "Foto no posible, no camara"
echo "Fallo captura $FECHA" >> ${LOG}/capture.log
fi
exit 0
Comentemos:
El parámetro "/m" hace que la foto se envíe por correo. Si no se pone solamente se guardará en local.
El correo se envia a otra cuenta de Gmail o de cualquier otro correo, para eso no hay problema.
En la carpeta local /root/.picture se guardan todas las imágenes tomadas. En /root/.picture/capture.log un log del proceso.
Si la cámara está desactivada o no se encuentra, se comunica al usuario por correo.
¿Cómo y cúando ejecutamos el script?: eso ya depende de lo que queramos hacer. Podemos entrar por ssh en la máquina y ejecutarlo, lanzarlo desde el crontab cada cierto tiempo, lanzarlo al iniciar sesión o cuando haya algún evento que monitoricemos..
Esa máquina llamada OSIRIS-REx ha dado un piquito al asteroide Bennu y hace unas horas a emprendido su vuelta a la Tierra con unos gramos de polvo, piedras y otra materia de ese cuerpo celeste. Creo que así empezaba La Amenaza de Andrómeda. No tiren sus mascarillas aunque estén vacunados.
Cuando estamos en una videoconferencia a veces se nota un molesto parpadeo en las imágenes que toma nuestra cámara. La causa es que en España la red eléctrica funciona a 50hz (50 ciclos por segundo), pero si la cámara está configurada para trabajar a 60hz los focos de luz (bombillas, pantallas, etc) provocan ese parpadeo, conocido en inglés como flickering. El motivo es que no hay sincronización entre los fotogramas por segundo que adquiere la cámara con la frecuencia de señal eléctrica que provoca el el foco de luz.
Para evitarlo mi compañero Toní me descubrió que hay que configurar la webcam para funcionar a 50hz, ya que muchas veces viene por defecto a 60hz (que es la frecuencia en USA y en otros países). Hay varias maneras de hacerlo, usando las utilidades v4l2ucp y v4l2-ctl (paquete v4l2-utils).
La mas inmediata es hacerlo a mano, con el programa v4l2ucp:
O bien desde línea de comandos, con:
# v4l2-ctl --set-ctrl=power_line_frequency=1
El parámetro power_line_frequency admite tres valores:
0 para Desactivado.
1 para 50 Hz (casi todo el mundo)
2 para 60 Hz (USA y algún otro país)
La otra manera, más cómoda, es configurar el sistema para que ejecute el comando anterior automáticamente cada vez que se detecte una webcam. Para ello usamos una regla de rules.d:
# cat /etc/udev/rules.d/81-uvcvideo.rules
# Set power line frequency to European
ACTION=="add", SUBSYSTEM=="video4linux", DRIVERS=="uvcvideo", RUN+="/usr/bin/v4l2-ctl --set-ctrl=power_line_frequency=1"
De esta manera nuestro sistema estará siempre configurado para poner las cámaras a 50hz, listas para la videoconferencia.
La Starship SN15 ha aterrizado exitosamente. Estamos mas cerca de Marte:
El único problema es que, como no ha explotado, apenas le han dedicado tiempo en los Informativos. Esto es como la pandemia de COVID: solo se habla de lo que se puede criticar. Si no hablan de algo es que va bien. Me vale tanto para aterrizajes de la Starship como para ritmos de vacunación.
