"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.