"Después del juego es antes del juego"
Sepp Herberger

martes, 25 de febrero de 2020

Monitorizando los portátiles del aula con monit (III)

Seguimos desde aquí.

Me interesaba saber en que momento en un aula concreta se habían conectado a la red los portátiles de los alumnos, con vistas a realizar unas comprobaciones y tareas en ellos con tmux-cssh.

La manera mas sencilla es usar monit para chequearlo y lanzar una alerta. Primero un script que encuentra todos los clientes conectados a la red del aula:
# cat /usr/local/bin/clientes-conectados.sh
#!/bin/bash
conectados=$(nmap -oG - -sP  192.168.0.200-253 | grep Up | awk '{print $2}')
total=$(echo $conectados | wc -w)
echo $conectados
exit $total
Ojo: para saber los clientes conectados escaneo el rango 192.168.0.200 a 253, que es el rango con el que se sirven IP a los portátiles en mis aulas. Cada cual debe adaptarlo a su caso.

El fichero de configuración de alerta de monit:
# cat /etc/monit/config.d/monitrc.clientes 
#Avisa cuando se conectan clientes a la wifi
check program clientes-conectados with path "/usr/local/bin/clientes-conectados.sh"
if status > 5  then alert
Por poner un límite inferior, he puesto que me avise cuando haya 5 o más portátiles conectados a la red wifi. En ese momento la alerta me llega con un correo tal como configuramos en entradas anteriores dedicadas a monit.

Out!

lunes, 24 de febrero de 2020

Notas sobre los tablet TECHcomputer F101 y Android en general.


Tengo acumuladas varias notas sobre trabajo con Android, tanto con los tablet TECHcomputer que nos mandaron como de varias Android Box que tengo por el IES para diversas funciones multimedia. Vamos a irlos guardando en este post.

1. Conectar a los dispositivos Andoid desde nuestro PC.

Como ya hemos comentado, lo ideal para bichear es conectar con la shell del dispositivo para escribir comandos.

La primera opción es conectar mediante cable USB, habilitando la depuración USB en el tablet como ya contamos aquí. Una vez configurados e instalados los paquetes, conectamos por USB el dispositivo Android encendido y tecleamos:
# adb shell
La primera vez que lo hacemos seguramente en el dispositivo aparezca una ventana solicitando autorización para permitir la conexión. Le decimos que si y ya no aparecerá más.


Otra opción muy interesante es conectar mediante TCP/IP, sin necesidad de cable USB. Normalmente hay que activar el USB sobre TCP/IP en el dispositivo Android. Antiguamente había que hacerlo mediante comandos, pero en los últimos Android se activa en "Ajustes->Opciones de Desarrollador->Debugging->ADB over network" o similar, reiniciando después.

Una vez activado hacemos:
# adb connect x.y.z.a
# adb shell
Y conectamos al dispositivo Android remotamente, siendo x.y.z.a su dirección IP. Si no conocemos la dirección IP podemos buscarla haciendo un barrido nmap por nuestra red interna buscando abierto el puerto 5555 (que es el usado por la conexion ADB sobre TCP/IP):
# nmap -n -Pn x.y.z.0/24 -p5555 -oG - | grep '/open/' | awk '/Host:/{print $2}'

2. Mas allá del shell: escritorio remoto.

No solo por shell, tambien podemos aprovechar la conexión ADB para contolar remotamente el interface gráfico usando ratón y teclado, como una conexión VNC, el dispositivo Android desde nuestro PC con toda la comodidad del mundo.

El truco está en instalar en nuestro pc la aplicación scrcpy. Luego simplemente con ejecutar:
# adb connect x.y.z.a
# scrcpy
Si la conexión es por cable USB la parte "adb connect x.y.z.a" no es necesaria, claro está. Nos aparecerá el escritorio Android remoto en una ventana:


Cuando usas adb shell y scrcpy todo cambia: ya no quieres volver a configurar un dispositivo Android tocándolo físicamente. Es mucho mas sencillo con estas herramientas.

3. Varios comandos y configuraciones.

Desde la conexión "adb shell" podemos configurar un montón de ajustes finos de Android que no suelen estar muy documentados. Toca buscar en Internet. Voy a poner los que vaya descubriendo:

  • Verificar si está rooteado (es decir, tenemos permisos de superusuario sobre el dispositivo Android): haciendo "su" y viendo si el prompt cambia a "#" sin error.
    KI_PRO_S905D:/ $ su
    KI_PRO_S905D:/ # 
    
  • Ver configuraciones y aplicarlas con "getprop" y "setprop". Por ejemplo, para ver el DNS configurado:
    # getprop | grep dns1
    [net.dns1]: [192.168.0.100]
    
    Al poner getprop/setprop sin parámetros vemos la lista completa de opciones.
  • Impedir el apagado/suspensión del dispositivo Android (útil por ejemplo si lo usamos con un panel informativo)
    # svc power stayon true
    
    Luego podemos comprobar si está activado con:
    # settings get global stay_on_while_plugged_in
    7
    
    El valor "7" significa "activado".
    Con el comando settings se puede acceder/modificar cientos de parámetros del sistema Android, que están escasamente documentados. Aquí hay alguna pista.
    KI_PRO_S905D:/ # settings                                                      
    usage:  settings [--user  | current] get namespace key
            settings [--user  | current] put namespace key value
            settings [--user  | current] delete namespace key
            settings [--user  | current] list namespace
    
    'namespace' is one of {system, secure, global}, case-insensitive
    If '--user  | current' is not given, the operations are performed on the system user.
    
Espero seguir aumentando esta lista de comandos últiles con el tiempo y hacer crecer este apartado.

4. Reinicios hacia recovery y bootloader.

Cuando queremos entrar tanto en el recovery como en el bootloader para hacer copias de seguridad, resetear el dispositivo o cargar una actualización, el método estándar es encender el aparato pulsando una combinación de botones físicos bastante puñetera. A veces tienes que hacer varios encendidos y apagados hasta dar con la tecla, nunca mejor dicho.

Una opción mas limpia es aprovechar que tenemos "adb shell" para reiniciar desde la línea de comandos de forma sencilla. Entramos en "adb shell" por USB y hacemos:
# reboot recovery
o
# reboot bootloader
Y entramos directamente al modo deseado de un manera limpia y directa.

Una método simple para saber en que estado está el dispositivo es usar el comando lsusb (con el aparato conectado por USB, of course). Por ejemplo, para nuestros TECHcomputer F101, con chipset Rockchip RK 3326 el resultado puede ser:
2207:330d Modo download/bootloader/fastboot
2207:0006 Modo normal
2207:0001 Modo recovery
Recordemos que el modo download normalmente muestra la pantalla en negro con un mensaje de texto, esperando órdenes desde el pc.

En cambio el modo recovery suele mostrar un menú con opciones para trastear, manejado por los botones físicos de volumen y power. En nuestras tablets F101 al entrar en el recovery aparece una pantalla con un muñeco de Android y el texto “No Command”. Para llegar al menú pulsamos sin soltar el botón Power y a continuación pulsamos Bajar Volumen una sola vez brevemente y soltamos. En otras ocasiones hace falta conectar un teclado externo para manejarlo.

Out!

domingo, 23 de febrero de 2020

Filtrando publicidad con powerdns (I)

Ya sabemos que la publicidad es necesaria para que se mantengan muchas páginas, lo que no me parece tolerable son los mensajes invasivos que hacen saltar banners, corta el flujo de texto con anuncios en medio o sobrecarga el navegador de forma excesiva haciendo lenta la navegación. Y esto empeora con los anticuados equipos que tenemos en muchos centros.

La solución habitual es usar un plugin de bloqueo de publicidad, como uBlock o Adblock, pero el resultado es que finalmente acaban sobrecargando también el navegador y, adicionalmente, muchos sitios detectan dichos plugins y te obligan a desactivarlos.

Hace unas semanas que llevo probando en mi Raspberry Pi de casa el proyecto pi-hole. Lo que hace, literalmente: "es una aplicación para bloqueo de anuncios y rastreadores en Internet a nivel de red en Linux que actúa como un sumidero de DNS​ (y opcionalmente como un servidor DHCP), destinado para su uso en una red privada". Básicamente monta un servidor dnsmasq que tiene una lista negra de dominios que no resuelve y, por tanto, bloquea. En nuestra red privada ponemos como servidor DNS primario la dirección de la Rasperry Pi donde está corriendo pi-hole y la mayoría de la publicidad desaparece de nuestros ojos de forma automática. Funciona de maravilla. Corta casi todo en PC, tablets, móviles, incluso en la Smart TV (si tuviera Smart TV).

En su momento pensé: ¿y si lo pruebo en la red del centro?. Pero no, es demasiado complicado: pi-hole está basado en dnsmasq y en los centros usamos powerdns. No tenía tiempo de meterme en esa camisa de once varas.

Pero hace unos días nos comunicaron que se había activado un sistema de bloqueo de sitios basado en powerdns-recursor, para filtrar a nivel de centro algunas páginas (juegos, redes sociales, etc) que nos pidiesen de forma interna. Simplemente hay editar /etc/powerdns/blocklist.lua, añadir en el array los dominios o subdominios que queramos filtrar y hacer un "systemctl restart pdns-recursor.service". Por ejemplo:
# cat /etc/powerdns/blocklist.lua
return{
"web.whatsapp.com",
"facebook.com",
}
Bueno, digo yo: ¿y si cojo la lista de bloqueo de pi-hole y la meto en blocklist.lua que pasaría?

Primero tuve que investigar como construye pi-hole su lista. Básicamente descarga ficheros de blacklist de una serie de sitios web actualizados con frecuencia:
root@DietPi:# cat /etc/pihole/adlists.list
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
https://mirror1.malwaredomains.com/files/justdomains
http://sysctl.org/cameleon/hosts
https://s3.amazonaws.com/lists.disconnect.me/simple_tracking.txt
https://s3.amazonaws.com/lists.disconnect.me/simple_ad.txt
https://hosts-file.net/ad_servers.txt
De todas estas fuentes se construye dominicalmente un fichero /etc/pihole/gravity.list con un listado de nombres DNS de sitios bloqueados.
# cat /etc/cron.d/pihole
...
# Pi-hole: Update the ad sources once a week on Sunday at a random time in the
#          early morning. Download any updates from the adlists
#          Squash output to log, then splat the log to stdout on error to allow for
#          standard crontab job error handling.
27 4   * * 7   root    PATH="$PATH:/usr/local/bin/" pihole updateGravity >/var/log/pihole_updateGravity.log || cat /var/log/pihole_updateGravity.log
...
Este crontab acaba finalmente llamando al script: /opt/pihole/gravity.sh, que construye gravity.sh desde /etc/pihole/gravity.list.

Lo único que tenía que hacer es coger este gravity.list y construir a partir de él un blocklist.lua. Este código lo hace:
# echo "return {" > blocklist.lua
# for i in $(cat gravity.list)
do
echo \"$i\", >> blocklist.lua
done
# echo "}" >> blocklist.lua
Nos queda algo así como:
# cat /etc/powerdns/blocklist.lua
return {
  "0.0.0.0",
  "0.nextyourcontent.com",
  "0.r.msn.com",
  "0.start.bz",
  "000.gaysexe.free.fr",
  "0000mps.webpreview.dsl.net",
  "0001.2waky.com",
  "000dom.revenuedirect.com",
  "000free.us",
  ....
El tamaño del fichero resultante es:
# wc -l /etc/powerdns/blocklist.lua     
125144 /etc/powerdns/blocklist.lua
125.000 dominios, ¡guau!. Un poco temeroso reinicio el powerdns-recursor, que arranca de forma inmediata y sin problemas. Después me voy a mi pc a cargar una página saturada de publicidad. Aparece limpia y despejada.

A modo de prueba lo he dejo varios días a ver si se nota ralentización o quejas de los usuarios. Pasado este tiempo puedo afirmar que no hay ningún problema: esto va de maravilla. Lo dejo instalado.

Me asigno como tareas pendientes 2 cosas:
  • Probar listas mas grandes, las hay de millones de dominios, simplemente para tantear los límites del sistema.
  • No depender del gravity.list de pi-hole. Escribir un script que baje cada día las listas enumeradas en adlists.list y construir un blocklist.lua.

Out!


Elon Musk sigue lanzando mediante SpaceX mas satélites de Starlink. Es mes pasado lanzó otros 60 con un Falcon 9, seguramente reutilizado. Una foto del impresionante pack de satélites antes del lanzamiento:


La semana pasada hicieron otro lanzamiento de mas satélites, con lo que ya suman 5 conjuntos que superan los 300 artefactos en órbita.

Como no han dicho nada en los informativos, seguramente aterrizó con normalidad. Es increíble como Musk ha hecho rutinario el lanzamiento y aterrizaje de cohetes. No tenemos coches voladores, pero tenemos cohetes que van y vuelven sin partes desechables.

De momento no voy a entrar en el debate sobre la contaminación lumínica que producirán la constelaciones de satélites, aunque los astrónomos están bastante preocupados (y enfadados) con el tema. Ahora solo me importa que me pille en el pueblo una noche despejada el paso de un tren de satélites tras un lanzamiento.

miércoles, 18 de diciembre de 2019

Demoras en el arranque de los PC "infolab"

Ya contamos como configurar como puestos multiseat los infolabs HP ProDesk 600 G1 SFF que tenemos, permitiendo que un mismo PC fuese usado por 2 usuarios a la vez de forma concurrente.

Había venido observando que el arranque de un PC infolab con multiseat era bastante mas lento (un minuto o más) que el de un infolab normal. En un primer momento lo achaqué a su condición de multiseat: al tener dos escritorios concurrentes quizá el arranque tarda más mientras preparaba el entorno. Pero como no estaba muy convencido he estado investigando.

Lo primero es medir los tiempos de arranque con systemd-analyze. Con:
# systemd-analyze blame
Nos sale una lista decreciente de tiempos y procesos, llamándome la atención esto:
54.4s dev-sda5.device
Comparando con otro infolab sin multiseat:
7.471s dev-sda5.device
Buscando en Internet veo que dev-sdaX.device no es nada en concreto, no se corresponde con ningún servicio y no hay manera de sacar información de ahí. Analizando con "systemd-analyze plot" y "systemd-analyze critical-chain" no saco nada más en claro.

Bueno, pues otra manera mas detallada de analizar el arranque es utilizar systemd-bootchart, que guarda una imagen SVG en /var/run con los tiempos y procesos de arranque más detallada que la de "systemd-analyze plot".


Analilzando veo que el proceso mas destacado es nvidia-smi lanzado desde systemd-udevd, el cual tarda 14s en ejecutarse. Si lo hago en un equipo sin multiseat veo que tarda menos de medio segundo.

Pensando entre las diferencias que hay entre infolabs con y sin multiseat recuerdo el tema de las tarjetas VGA. Un infolab trae 2 tarjetas VGA de serie:
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208B [GeForce GT 730] [10de:1287] (rev a1)
En el caso de un equipo multiseat ambas VGA están activas (ya que hacen falta para los 2 monitores). En un equipo normal tengo la tarjeta VGA Intel (la de la placa base) desactivada en la BIOS, ya que no me hace falta y la desactivo para evitar problemas.

Como ultima comprobación, mirando el syslog de arranque con dmesg encuentro que, cuando hay retraso, este mensaje aparece en el log:
watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [nvidia-smi:618]
Deduzco que es casi seguro que la combinación del programa nvidia-smi (que viene con el driver propietario nvidia) y la tarjeta VGA intel de la placa base son la causa del problema.

Consideremos estas pruebas y limitaciones:
  • No puedo prescindir de los drivers nvidia, ya que con nouveau no funciona el multiseat.
  • No puedo desactivar la tarjeta intel en la BIOS, ya que la necesito para seat-1 del multiseat.
  • He probado con distintos kernel 4.x y 5.x por si fuera un fallo del driver. No se arregla con ninguno.
  • He actualizado el driver propietario a la ultimísima versión (usando el PPA). No se arregla.
Cuando no se te ocurre nada nuevo es el momento de buscar en Internet. Buscando por el texto del error mostrado en el syslog encuentro:
  • Solución 1: Añadir nomodeset como parámetro de arranque del kernel en el grub. Se arregla el problema, pero no funciona el multiseat. El seat-1 no se levanta.
  • Solución 2: en el fichero /lib/udev/rules.d/71-nvidia.rules comentar la línea:
    ACTION=="add" DEVPATH=="/module/nvidia" SUBSYSTEM=="module" RUN+="/usr/bin/nvidia-smi"
    
Pues está última propuesta funciona. Comentando esa línea impedimos que nvidia-smi (el causante del problema) se ejecute en el arranque del sistema, al iniciar la tarjeta nvidia. Parece temerario pero resulta que al final que el arranque se acelera (dev-sda5.device dura unos segundos en lugar de casi un minuto) y el multiseat funciona. Hablando en plata: la ejecución inicial de nvidia-smi es prescindible.

Como colofón podemos decir que esto no es es solamente aplicable cuando hay multiseat (que es como me ha salpicado a mí): siempre que haya una demora en el arranque producido por un conflicto entre nvidia-smi y una tarjeta no nvidia en la placa madre la solución será comentar esta línea que ejecuta en el inicio nvidia-smi. Tomemos nota para el futuro.


Qué bonitos los robots de Boston Dynamics, no entiendo como a mi compañera Marisa le dan repelús:




martes, 17 de diciembre de 2019

Jkiwi en Ubuntu Bionic 18.04

Ya hicimos funcionar la aplicación de maquillaje y estilismo capilar jkiwi para una arquitectura de 64 bits aquí.

Cuando me han pedido instalarla en Ubuntu 18 me he encontrado con que da error de dependencias porque no encuentra la máquina virtual java. Necesita uno de los siguientes paquetes: sun-java6-jre | sun-java5-jre | icedtea-java7-jre | openjdk-6-jre para funcionar y al no encontrarlos se aborta la instalación.

El motivo es que en Ubuntu 18.04 el paquete con la máquina virtual java es openjdk-8-jre, que no existía cuando se creó el .deb de jkiwi. La solución pasa por editar el paquete .deb y añadir la dependencia de openjdk-8-jre.

El paquete .deb lo modificamos tal como contamos aquí:
# dpkg-deb  -R jkiwi_0.9.5_all.deb jkiwi
En jkiwi/DEBIAN/control hay que modificar la siguiente línea, añadiendo la parte en negrita:
Depends: sun-java6-jre | sun-java5-jre | icedtea-java7-jre | openjdk-6-jre | openjdk-8-jre
Y luego reconstruimos el paquete:
# dpkg-deb -b jkiwi/ jkiwi_0.9.5_all.deb
El recién creado jkiwi_0.9.5_all.deb (puedes descargarlo de aquí) es el que ya podremos instalar (en mi caso lo he metido en mí repositorio local para instalarlo mas cómodamente) al tener su dependencia openjdk-8-jre cumplida. La aplicación funciona perfectamente con este openjdk, aunque sea muy posterior a la propia aplicación.

jueves, 12 de diciembre de 2019

Sustitución del cable de teclado de Infolabs/Siatic HP-KUS1206.

Tenemos un montón de teclados HP KUS1206 con lector SmartCard de muy buena calidad y robustos, pero en mi caso adolecen de un punto débil: el cable USB tiene tendencia a "pelarse" y partirse en el punto donde entra en el teclado, seguramente por el trajineteo al que están sometidos por los múltiples usuarios. Otro problema es que el cable se ha ido deformando y endureciendo, perdiendo flexibilidad, a lo largo de los años.


Como estos teclados por todo lo demás están en perfecto estado y funcionan a las mil maravillas, me daba rabia tener que mandar a reciclar un teclado de 50 euros por un puñetero cable USB roto. Así que me dispuse a desmontar uno a ver como iba conexión del cable.

En algunos teclados/ratones este cable está soldado a una pequeña placa de circuito impreso, pero afortunadamente en estos teclados vienen unidos con un conector:


En un principio me puse muy contento pensando que era un conector de 5 pines Dupont de los usados para montajes electrónicos, ya que esos conectores son fáciles de encontrar y manejar.


Pero no, los pin housing de los conectores Dupont tienen un ancho de 0.1"/2.54mm cada uno, de tal manera que 10 pines ocupan una pulgada (2.54cm). En cambio el pin housing de este teclado tiene un ancho de 2mm, de tal manera que los 5 pines ocupan 1cm (y 10 pines ocupan 2.00cm). Esto es un pin housing:



Los pin housing de 2mm con esta forma no son nada fáciles de encontrar y al final salen caros por su rareza. Parecía que no había solución a no ser que cortásemos y soldásemos a ese pin housing otro cable USB en perfecto estado. Soldar cables USB requiere un grado de destreza y paciencia que no tengo.

Pero vaya, rebuscando entre chatarra encontré varios cables de antiguos ratones averiados o rotos:


Midiendo resulta que su pin housing tiene 1cm de ancho, coincidiendo con los pines macho de nuestro teclado. Hay un pequeño problema: la posición de los hilos es diferente en ambos cables, ya que en el cable del teclado es Negro-Negro-Verde-Blanco-Rojo, mientras que en el cable del ratón es Negro-Negro-Rojo-Blanco-Verde. El coloreado en los cables USB es uno de los pocos cableados que normalmente se respeta.

Con ayuda de un destornillador pequeño es sencillo levantar la pestañita de plástico y extraer el hilo con el "crimp connector" que lo hace encajar en el pinheader.


Intercambiamos los hilos Rojo y Verde del cable del ratón, lo encajamos en el housing y este lo acoplamos con cuidado, forzando suavecito, en los 5 pines macho del circuito impreso del teclado.





Enchufando el cable USB al PC compruebo que el teclado funciona. Cerramos todo y dejamos el teclado listo con el nuevo cable, que aunque no es tan grueso como el original me ha permitido recuperar la funcionalidad.

El cableado antes:


El cabledo ahora:


Como después de tantos años tenía un buen número de cables de ratón con ese conector, he podido reparar varios teclados que tenía desahuciados para piezas y darles una nueva vida.

Para cuando se me acaben los cables de ratón he visto que se pueden localizar cables sueltos "usb to housing 5pin cable for mouse keyboard" o, llegado el caso, comprar pin housings y crimp connectors de 2mm sueltos para hacer el montaje a partir de otros cables USB que hayamos guardado para reciclar.

La sonda solar Parker ha llegado a su destino y empezará a estudiar la corona solar, cayendo en algunos puntos por debajo de la órbita de Mercurio. Una auténtica proeza de precisión y resistencia a 1377º de temperatura.


Si todo sale bien, le quedan 7 años para hacer 24 órbitas en las que recopilará datos sobre viento solar, magnetismo y partículas emitidas por nuestra estrella. ¡Buena suerte!

miércoles, 4 de diciembre de 2019

Ratón por puerto serie

Haciendo limpieza me he encontrado varios ratones serie y de bola. Me ha entrado curiosidad por ver si funcionaban, pero al ser de una época donde el plug'n'play era desconocido no ha bastado con enchufarlos al puerto serie, además he tenido que configurar un par de cosas:

Crear el fichero /etc/X11/xorg.conf.d/01-serial.conf (o /usr/share/X11/xorg.conf.d/01-serial.conf, dependiendo del Linux que usemos) :
# cat /etc/X11/xorg.conf.d/01-serial.conf

Section "InputDevice"
   Identifier "Mouse0"
   Driver "mouse"
   Option "Protocol" "Microsoft"
   Option "Device" "/dev/ttyS0"
   Option "ZAxisMapping" "4 5"
   Option "Emulate3Buttons" "false"
EndSection
Y añadir en rc.local la línea:
inputattach --microsoft /dev/ttyS0
Recordemos que con systemd el fichero rc.local no funciona, hay que activarlo como cuentan aquí.

Los ratones, pasados 25 años o más de su fabricación siguen funcionando. Ya no se hacen ratones como los de antes.

martes, 3 de diciembre de 2019

Bloqueo de funciones en impresora multifunción Epson WF-8590.

No soy muy partidario de las impresoras de inyección, ya que solo las veo útiles en un entorno donde se imprime de forma constante y abundante durante todo el año, pero como nos enviaron unas cuantas a cada centro no nos queda otra que lidiar con ellas. Las Epson WF-8590 no han salido problemáticas, de momento aguantan con las recargas de tinta genérica y se estropean lo normal.

Debido a que permiten ser usadas como fotocopiadora de manera sencilla me encuentro con el problema de tener tentadoras fotocopiadoras de uso público en sitios no controlados. En un centro educativo eso no puede ser, ya que es fácil imaginar que pronto empieza a haber fotocopias de extranjis. Para evitarlo bloqueo las funciones de fotocopia e impresión desde pendrive si sé que va a estar en un sitio sin supervisión.

Para ello nos conectamos a la IP de la impresora, metemos la contraseña de administración y configuramos el bloqueo de control de acceso. Esto hará que no se puedan usar las opciones de fotocopiado e impresión usando pendrives desde panel táctil de la impresora.


Al restringir el acceso me veo obligado a crear un par de usuarios:


Un usuario "administrador" con todos los permisos:


Y un usuario "usuario" con permiso para escanear e imprimir. Este será el que utilicen los usuarios rasos:


Con esto queda bloqueado el acceso por el panel, pero al haber activado el control de acceso necesitamos configurar un usuario y contraseña en Windows (en Linux esto no es necesario), a pesar de haber indicado en la configuración anterior que se "Permite imprimir y digitalizar sin información de autenticación". Parece ser un bug del firmware.

Para ello, en las preferencias de la impresora en Windows configuramos el usuario que definimos anteriormente:


Esto realmente lo que hace es meter en el registro de Windows estas claves:


El inconveniente es que hay que hacerlo para todos los usuarios de Windows uno a uno en cada PC y como no nos gusta repetir una y otra vez la misma configuración hemos definido un script que añade esas claves al registro:
@echo off
rem claves-epson.bat
reg import c:\windows\epson-usuario.reg
El fichero c:\windows\epson-usuario.reg sería:
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\EPSON\PRINTER\EPSON WF-8590 Series]
"EPRFPW"="usuario"
"EPRFUM"="abcd1234"
Este último fichero lo mas adecuado es que lo creemos exportando desde regedit la clave "HKEY_CURRENT_USER\Software\EPSON\PRINTER\EPSON WF-8590 Series" desde un usuario con los datos configurados, ya que no es un fichero de texto ASCII al uso y tiene algunos bytes raros ocultos, por lo que no se puede crear con un editor de textos.

Para que se ejecute el script en el inicio de sesión de cada usuario de forma automática habría que ponerlo en la carpeta de scripts de inicio de todos los usuarios. En el caso de Windows 8 sería: "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp". En los otros Windows esta carpeta tiene ubicaciones distintas.

Y con esto tenemos la impresora controladita a nuestro gusto.

Es curioso que esto sea noticiable, pero es bueno saber que en SpaceX también explotan cosas:



La noticia es que un prototipo de la Starship ha explotado durante una prueba de presurización máxima. Cuando pruebas al máximo la presurización de un prototipo no es infrecuente que explote. De hecho, esa es la idea.

La Starship es bonita hasta cuando explota.

martes, 19 de noviembre de 2019

Avisos multicanal desde monit.

Aunque ya he usado monit para avisar de determinados eventos, hay veces que necesito una notificación inmediata. En concreto quería monitorizar punto wifi que sospechosamente perdía la conexión más de lo habitual.

Para ello decidí no limitarme a mandar un "alert" cuando se pierde el ping, sino que lanzo un script que hará más ruido:
check host punto-wifi with address 192.168.0.1
       if failed icmp type echo count 3 with timeout 5 seconds then exec "/usr/local/bin/aviso-wifi"
1. Avisos multicanal.

El script aviso-wifi usa distintos tipos de aviso por diferentes cauces:
# cat /usr/local/bin/aviso-wifi 
#!/bin/bash

MENSAJE="Otra vez desconectado $(date)!"

#Log del sistema
echo $MENSAJE >> /var/log/wifilog.log

#Correo
mailsend -to destinatario@gmail.com \
      -from emisor@gmail.com \
      -ssl -smtp smtp.gmail.com -port 465 \
      -sub "Aviso" \
      -M "$MENSAJE" \
      +cc +bc -q -auth -user "emisor@gmail.com" -pass "mipassword"

#Mensaje push al móvil android
PUSHKEY="APcdkK"
curl --data "key=$PUSHKEY&title=Aviso&msg=$MENSAJE" https://api.simplepush.io/send

#Mensaje SMS al móvil android
MOVIL="+34855123456"

curl -X POST https://textbelt.com/text \
       --data-urlencode phone="$MOVIL" \
       --data-urlencode message="$MENSAJE" \
       -d key=textbelt

exit 0
Los distintos métodos usados son:
  • Guarda un registro en /var/log/wifilog.log.
  • Envía un correo mediante gmail usando mailsend, que tendríamos que instalar previamente.
  • Envía un mensaje push a nuestro móvil mediante la aplicación simplepush.io, que saltará de forma inmediata. Es tan sencillo como instalar esta aplicación en el móvil y poner en el script la PUSHKEY que nos aparece al abrirla, que identifica nuestro móvil de forma única como destinatario.
    Como pequeño inconveniente tenemos que los mensajes son gratuitos los 7 primeros días, luego hay que comprar la aplicación (cuesta unos merkels) para poder recibir mensajes. Se pueden establecer alarmas sonoras distintas en función de diversos tipos de mensajes push.
  • Por último, por volver a los 90, mandamos un SMS a nuestro móvil (+34855123456, es un número ficticio, pon el tuyo empezando por +34). Este servicio de textbelt permte mandar un único SMS al día gratis, pero si nos resulta útil podemos comprar paquetes SMS prepago.

Tanto simplepush.io como textbelt son dos de los muchos servicios push y SMS que hay. Yo he puesto estos porque los encontré pronto y me resultaron fáciles de usar mediante sencillas peticiones web con el comando curl.

Por supuesto, se podría ampliar el script con otros medios de aviso, por ejemplo mensajes telegram o cualquier otro sistema que se pueda hacer mediante scripts.

2. Avisos sonoros.

Un escalón mas es hacer sonar un aviso por los altavoces del PC del aula donde se detecta el evento, para que si es especialmente grave el usuario tome medidas. El script sería:
# cat /usr/local/bin/aviso-audio 
#!/bin/bash

#Subimos el volumen al máximo en el alsamixer
amixer set Master unmute
amixer set Master 100%

#Si hay un usuario logado, conectamos con su pulseaudio para subir el volumen al máximo
user=$(who | grep "(:0)" | head -1 | cut -f1 -d" "); 
if  [ -n "$user" ]
then
  su $user -c "DISPLAY=:0 pactl set-sink-volume 0 150%"
  su $user -c "DISPLAY=:0 pactl set-sink-mute 0 0"
fi

#Si esta instalado placasiatic es una siatic y podemos encender por comando la barra de sonido.
test -f /usr/sbin/placasiatic && placasiatic sonido up

if  [ -n "$user" ]
then
  while true
  do
     ffplay /root/scripts/locucion.mp3 -nodisp -nostats -hide_banner 
     su $user -c "DISPLAY=:0 zenity --info  --width 400 --height 100  --title='Desconexion de sistema' --text='Avise al administrador informatico de forma urgente.'"
  done
else
   ffplay /root/scripts/locucion.mp3 -nodisp -nostats -hide_banner -loop 0
fi


exit 0
Comentamos:
  • Con amixer quitamos el mute (silencio) y subimos al 100% del volumen del canal de audio Master.
  • Si hay un usuario con sesión iniciada, conectamos con su instancia pulseaudio para subir al máximo el volumen allí mediante pactl y hacer unmute.
  • Si estamos en una Siatic encendemos la barra de sonido mediante el relé. Esto garantiza que si el usuario ha apagado la barra la encendemos de nuevo usando la utilidad placasiatic. Por supuesto, si los altavoces del PC son convencionales y están apagados físicamente en su interruptor, no saldrá nada de sonido. Es algo que puede pasar y para lo cual no tenemos solución.
  • Por último, se reproduce una locución en bucle infinito codificado en mp3 mediante ffplay. Si hay usuario con sesión iniciada se muestra además un mensaje de texto en su escritorio mediante zenity.
  • La locución se puede generar fácilmente con texttomp3.
Para ejecutar este script desde el del apartado anterior es suficiente con añadir:
nohup /usr/local/bin/aviso-audio >/dev/null 2>&1 &


Cuando lo extraordinario empieza a ser habitual es señal de que se está haciendo bien: SpaceX ha lanzado una nueva carga de satélites Starlink.


Se lanzan 60 microsatélites Starlink (que mientras se van desplegando en las próximas semanas se podrán ver como un tren por el cielo nocturno una vez más), la etapa inicial del Falcon reutilizado por cuarta vez aterriza en la plataforma barcaza Of Course I Still Love You y la cofia se reutiliza por primera vez y se recupera mediante un barco.

Y todavía hay gente que afirma que todo lo relacionado con Elon Musk es humo.

viernes, 15 de noviembre de 2019

Teamviewer en Manjaro Linux

Como cualquier informático me toca muchas veces dar soporte a familiares, amigos y arrimados usando teamviewer. Cuando tienes Ubuntu o Fedora están en la página de descarga los paquetes preparados para descargar e instalar, pero cuando trabajamos con otra distribución con sistema de paquetes propio no nos queda otra que bajar el fichero .tar.xz con el ejecutable y los ficheros necesarios, descomprimirlo a mano y ejecutarlo.

Exite un paquete AUR de teamviewer para Manjaro, pero la verdad es que la versión original se actualiza tanto que el paquete no va muy fino y muchas veces no funciona. Es mejor descargar el tar.xz y trabajar directamente con él.

Un problema frecuente es que al abrir el programa se nos queda en estado de "error de conexión" y no funciona. Suponiendo que tengamos red y que no haya problema en los servidores de Teamviewer la razón típica es la versión del programa que tenemos instalado. A día de hoy solo Teamviewer 14 me funciona en el Manjaro, las versiones anteriores no conectan. Desconozco si es algo propio de Manjaro o afecta a otras implementaciones.

El segundo problema que me pasa es que cuando lanzamos el ejecutable de teamviewer:
$ cd teamviewer
$ ./teamviewer
Init...
CheckCPU: SSE2 support: yes
Checking setup...
Launching TeamViewer ...
Starting network process (no daemon)
Network process started (3703)
Launching TeamViewer GUI ...
Y ahí se queda sin mostrar nada.

El motivo real es que faltan por instalar dependencias, pero resulta que el ejecutable es tan mudito que no da error ninguno. Esto me recuerda un programa de Indra que vi una vez cuyo código tenia:
Sub XXXX(....)
   Try
      ...
      ...
   Catch 
   End Try
End Sub
en todos los métodos. Nunca daba un error.

Bueno, pues investigando el paquete AUR de teamviewer se pueden ver las dependencias necesarias, que son:
qt5-webkit
qt5-quickcontrols
hicolor-icon-theme
qt5-x11extras
Si instalamos esos paquetes con pacman la cosa funciona sin problema.



El cometa interestelar 2I/Borisov. El segundo objeto extrasolar detectado en la historia, detectado el 30 de agosto de 2019 por el astrónomo aficionado Borisov en Crimea (Rusia, diga lo que diga Ucrania) con un telescopio modesto. Dado el aviso, la comunidad de aficionados se volcó en hacer seguimiento del objeto y determinar su órbita en los días siguientes, resultando que era un cuerpo que venía de fuera del Sistema Solar e iba a irse de nuestro lado. Ciencia ciudadana se llama.

La última noticia es una foto del Hubble y se ha confirmado que es un cometa que trae agua de otro sistema solar.


Teniendo en cuenta que 1I/ʻOumuamua se descubrió 2 años antes está claro que esos visitantes de fuera son mucho mas frecuentes de lo que podríamos pensar. Sería maravilloso ver llegar otro con tiempo para mandar una sonda...