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

jueves, 1 de diciembre de 2022

Interruptor casero USB.

Vamos a ver como construir un interruptor casero que se conecta por USB y que al pulsarse permite lanzar un evento en el ordenador, ejecutando un script.

Lo primero es construir el interruptor: ¿que usar si no tenemos ni idea de electrónica?. Pues no hace falta nada especial ya que con un ratón de ordenador es suficiente. Todos tenemos ratones USB rotos o antiguos que podemos reciclar. La idea es desmontar el ratón, sacar la placa, arrancar la luz led y verificar que el botón central (el asociado al click de la rueda) funciona y manda señal por el cable USB. Da igual el estado del resto de mecanismos.

Cogemos el ratón, lo metemos dentro de una cajita del tamaño adecuado y lo pegamos usando la pistola térmica de silicona que tenemos todos para las manualidades. En mi caso tenía una cajita que venía perfecta:
Nótese como buscamos que el interruptor del botón quede justo en el centro (marcado con el círculo amarillo). Luego he puesto una tapa de plástico agujereada para permitir llegar al interruptor y forrada con goma eva. Por último hago un interruptor externo con un tapón y un poco de espuma de embalaje. La idea es que el interruptor externo presione al interruptor interno del ratón.
Una vez pegado y montado todo:
Creo que es resultón para lo que yo quiero, pero si queremos hacerlo mas formal siempre podemos usar la impresora 3D para generar una cajita y botón con aspecto mas profesional.

Ya tenemos el hardware, vamos al software. Pinchamos el cable en un puerto USB y el Linux lo detecta como un ratón, pero como esta casi todo inutilizado tan solo recibirá eventos del botón central. Lo primero es encontrar el generador de eventos asociado al nuevo ratón:
# ls -l /dev/input/by-id
total 0
lrwxrwxrwx 1 root root  9 oct 27 09:34 usb-0461_USB_Optical_Mouse-event-mouse -> ../event2
lrwxrwxrwx 1 root root  9 oct 27 09:34 usb-0461_USB_Optical_Mouse-mouse -> ../mouse0
lrwxrwxrwx 1 root root  9 oct 27 09:34 usb-CHICONY_HP_Basic_USB_Keyboard-event-kbd -> ../event3
lrwxrwxrwx 1 root root 10 nov 29 13:32 usb-Logitech_USB-PS_2_Optical_Mouse-event-mouse -> ../event14
lrwxrwxrwx 1 root root  9 nov 29 13:32 usb-Logitech_USB-PS_2_Optical_Mouse-mouse -> ../mouse1
En nuestro caso sería /dev/input/event14. El paso siguiente es verificar que se detectan los eventos de pulsación. Para ello usamos triggerhappy:
# apt-get install triggerhappy
# thd --dump /dev/input/event14
Y pulsamos varias veces el interruptor para ver si se detecta. En consola debería mostrarse:
EV_KEY	BTN_MIDDLE	1	/dev/input/event14
# BTN_MIDDLE	1	command
EV_KEY	BTN_MIDDLE	0	/dev/input/event14
# BTN_MIDDLE	0	command
EV_KEY	BTN_MIDDLE	1	/dev/input/event14
# BTN_MIDDLE	1	command
thd --dump /dev/input/event14
EV_KEY	BTN_MIDDLE	0	/dev/input/event14
# BTN_MIDDLE	0	command
Perfecto: el evento generado por la pulsación del botón es "BTN_MIDDLE 1". Conviene recalcar en este momento que la pulsación del botón central del ratón puede ser también interceptado por nuestro entorno de escritorio Linux y provocar algún efecto asociado (por ejemplo, pegar el texto que hay en el portapapeles). Para evitar efectos colaterales recomendamos desactivar ese ratón en la configuración del entorno de escritorio:

Una vez tenemos el evento localizado, creamos la configuración que asocia dicho evento al lanzamiento de un script:
# cat /etc/triggerhappy/triggers.d/redbutton.conf
BTN_MIDDLE    1       /root/scripts/redbutton.sh
Después de este cambio de configuración se debe reiniciar el servicio triggerhappy, pero antes debemos configurarlo para que se ejecute como root (normalmente lo hace como nobody) y escuche solo los eventos que vengan de /dev/input/event14.

Inocente de mi, probé a modificar tanto /etc/default/triggerhappy como /etc/init.d/triggerhappy sin éxito. Seguia ejecutándose con el usario nobody y escuchando en /dev/input/event*. Esto lo podemos verificar haciendo:
# ps aux | grep thd
nobody   12523  0.1  0.0  43844  2852 ?        Ss   21:32   0:00 /usr/sbin/thd --triggers /etc/triggerhappy/triggers.d/ --socket /run/thd.socket --user nobody --deviceglob /dev/input/event*
La causa de esto es que en Ubuntu 18 el demonio triggerhappy se lanza realmente desde /lib/systemd/system/triggerhappy.service. Los otros dos ficheros están de adorno. No entiendo esta manía de tener servicios que están init.d y en systemd a la vez, es como si hubiesen quedado el trabajo a medias y se hubiesen ido de cañas.

Editamos /lib/systemd/system/triggerhappy.service y lo quedamos:
[Unit]
Description=triggerhappy global hotkey daemon
After=local-fs.target

[Service]
Type=notify
ExecStart=/usr/sbin/thd --triggers /etc/triggerhappy/triggers.d/ --socket /run/thd.socket --user root --deviceglob /dev/input/event14

[Install]
WantedBy=multi-user.target
Luego reiniciamos el servicio:
# service triggerhappy restart
Y bueno ahora nos falta escribir el script. Aqui podemos poner cualquier cosa, yo simplemente voy a hacer que se oiga un audio (descargado de Internet o generado con pico2wave) en el escritorio:
# cat /root/scripts/redbutton.sh 
#!/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"
  cp -f /root/scripts/no.wav /tmp/no.wav
  su $user -c  "DISPLAY=:0 aplay /tmp/no.wav"
else
  cp -f /root/scripts/no.wav /tmp/no.wav
  DISPLAY=:0 aplay /tmp/no.wav
fi

exit 0
Con esto ya tenemos todo funcionando. Bien, y ahora la pregunta: ¿Para qué carajos quiero esto?. Bueno, pues aparte de para enredar, para conectarlo a una Raspberry Pi o un OpenWRT sin teclado/ratón y poder lanzar eventos sobre ellos: apagar/encender la wifi, hacer una foto con la webcam, reiniciar un servicio o una aplicación, etc.

En mi caso tengo una Rasbperry Pi mostrando una página web en modo kiosko con información en tiempo real. A veces el navegador se bloquea y hay que cerrarlo y abrirlo de nuevo, teniendo que conectarme por VNC y hacer el proceso a mano. Con un botón de este tipo puedo lanzar un script que permite a cualquiera reiniciar el navegador en todo momento.

Out!

Directorio home de usuarios + nfs4: lentitud en el escritorio.

Una de las cosas que mas me gustan de Linux en un entorno de red es la capacidad de que los homes de los usuarios estén centralizados en un servidor de red común, de tal forma que siempre tenemos el mismo escritorio independientemente de la máquina usada. Esto facilita al usuario trabajar sin tener que andar subiendo ficheros a una nube o carpeta concreta de red, y a nosotros hacer copias de seguridad de sus datos y no preocuparnos de recuperar datos del usuario cuando falle físicamente el disco del equipo donde ha estado trabajando.

En nuestro caso siempre hemos usado NFS para montar estos homes, aunque hay mas alternativas. Nunca había habido problema pero cuando cambiamos hace unos años a usar Ubuntu 18 empezaron a aparecer problemas aleatorios de lentitud extrema en los escritorios/navegadores web. Una explicación común es que el aumento de complejidad de los navegadores en los últimos años (y eso es algo de lo que habrá que hablar algún día martillo en mano) los ha convertido en unos artefactos que con sus operaciones de entrada/salida acaban saturando el servidor NFS. Una pista en contra de esta hipótesis es que la lentitud va y viene sin correlación aparente con el número de usuarios instantáneos en la red del centro y que cuando una máquina va lenta, la de al lado no tiene por qué hacer lo mismo. Tenía que haber alguna explicación adicional.

Después de muchas pruebas hemos establecido que cambiar el sistema de montaje de los homes de los clientes de nfs4 a nfs3 mejora enormemente el problema, haciéndolo desaparecer en muchos casos. Vamos a ver las pruebas a realizar cuando tenemos un escritorio/navegador ralentizado para determinar si este cambio en el nfs solucionaría el problema.

Las pruebas que podemos realizar son las siguientes:
  • Entrar por ssh como root a un puesto donde el escritorio vaya lento y hacer el comando "time su <usuario>", siendo "usuario" un usuario que monta su home por NFS, claro está. Hacer lo mismo en un equipo no afectado por el problema. Si en el primero tarda 5 o mas veces que el segundo es un síntoma de que está afectado.
  • Entrar por ssh como root a un puesto donde el escritorio vaya lento y hacer "wget https://speed.hetzner.de/1GB.bin". Hacer lo mismo en un equipo no afectado por el problema. Es un fichero de prueba de 1Gb para hacer tests de velocidad desde consola. Si la velocidad es similar en ambos puestos podemos descartar que sea un problema de red (bucles de red, problemas de cableado, de switchs, de salida a Internet) y centrarnos en que es un problema de NFS.
  • Entrar por ssh como root a un puesto donde el escritorio vaya lento y mirar en el syslog buscando errores como:
    NFS: nfs4_reclaim_open_state: Lock reclaim failed!
    NFS: nfs4_reclaim_open_state: unhandled error -10026
    nfs4_reclaim_open_state: 3 callbacks suppressed
        
    Estos errores son síntomas de bloqueos y otros problemas en el montaje NFS.
  • Entrar en el servidor NFS y testear la carga con los comandos:
    # atop
    # iotop
    # nfsstat
      
    Buscando sobrecargas en el disco, red o en los procesos nfs.
  • Entrar por ssh como root a un puesto donde el escritorio vaya lento y hacer
    # nfsiostat
      
    Comparar el resultado con un equipo no afectado por el problema.
Después de todas estas pruebas, si sospechamos que las causas de la lentitud están relacionadas con el servidor NFS, el siguiente paso es verificar que tipo de montaje usamos en nuestros puestos. Para ello entramos por ssh como root en un equipo de usario y hacemos:
# automount -m

global options: none configured

  Mount point: /home

  source(s):

   type: ldap
   map: ldap:ou=auto.home,ou=Automount,dc=instituto,dc=extremadura,dc=es
   ....
   ....
   * | -fstype=nfs4,rw,hard,intr,nodev,nosuid,nolock,rsize=16384,wsize=16384 servidor:/&
La última línea nos dice que el montaje del home esta siendo realizado mediante nfs4. No tiene porque ser igual a la indicada, pero el "nfs4" es revelador. La idea es cambiarla por:
   * | -fstype=nfs,rw,fg,hard,intr,nodev,nosuid,async,ac,vers=3,fsc servidor:/home/&
que cambia el montaje del home para que se haga usando nfs3. Esta línea si que debemos ponerla de forma literal, tal cual aparece aquí.

El lugar donde se hace este cambio dependerá de donde configuremos el montaje en nuestro entorno. Para el caso de nuestros centros esto se hace en el directorio ldap, al que accedemos mediante phpldapadmin en el nodo:
cn=/,ou=auto.home,ou=Automount,dc=instituto,dc=extremadura,dc=es
Una vez allí localizamos el atributo "automountInformation", hacemos una copia de su contenido por si las moscas y lo sustitumos por:
* | -fstype=nfs,rw,fg,hard,intr,nodev,nosuid,async,ac,vers=3,fsc servidor:/home/&
Después de esto recargamos el servicio nfs en el servidor principal:
/etc/init.d/nfs-kernel-server reload
Y por último reiniciamos los clientes, dejando que trabajen durante varios días a ver si desaparecen los problemas. En bastantes casos con este sencillo cambio ha sido suficiente.

viernes, 11 de noviembre de 2022

Log histórico de portátiles encendidos cada día

Por una necesidad concreta he escrito un script que va rellenando un log de los portátiles de alumnas que se encienden cada día en el instituto. La finalidad es generar un listado tabulado como el siguiente:
...
2022/11/11-08:37:10	portinves-o11	10.192.55.97
2022/11/11-08:37:10	portinves-o12	10.192.54.74
2022/11/11-08:37:23	portinves-o04	10.192.54.91
2022/11/11-08:37:30	portlenovo-o02	10.192.55.106
2022/11/11-08:37:38	portinves-o01	10.192.54.115
2022/11/11-08:37:45	portinves-o09	10.192.54.114
2022/11/11-08:37:46	portinves-o10	10.192.54.159
2022/11/11-08:37:51	portinves-o15	10.192.54.110
2022/11/11-08:38:09	portinves-o05	10.192.54.78
2022/11/11-08:38:26	portinves-o02	10.192.54.116
...
Aunque esa información puede encontrarse en la herramienta "controlies", quería tenerla centralizada en un fichero de texto plano fácilmente procesable para hacer estadísticas. Para saber que portátiles se han encendido puedo consultar el fichero /var/log/syslog del servidor, filtrando por "DHCPACK" y por el nombre "port":
# grep DHCPACK /var/log/syslog | grep -i port
...
Nov 11 10:37:21 servidor dhcpd: DHCPACK on 10.192.54.196 to 28:e3:47:32:7e:0e (portinves-o16) via 10.192.54.1
Nov 11 10:58:53 servidor dhcpd: DHCPACK on 10.192.55.111 to 6c:62:6d:14:e4:36 (portmsi-o13) via 10.192.54.1
Nov 11 11:10:29 servidor dhcpd: DHCPACK on 10.192.55.112 to 6c:62:6d:15:14:b6 (portmsi-o02) via 10.192.54.1
...
En mi caso esto es sencillo porque todos los portátiles de alumnos se llaman "portXXX-oXX". Otro filtro que se puede usar es la MAC, ya que la mayoría de portátiles del mismo lote tiene un prefijo de MAC idéntico.

Una vez obtenido el listado lo manipulo uno poco con utilidades bash para extraer la marca de tiempo, nombre e IP. Luego se ordena y eliminan líneas duplicadas, llevando todo a /var/log/portatiles.log. El script queda:
#!/bin/bash

dhcp_hoy=$(mktemp)
log_portatiles_hoy=$(mktemp)
log_portatiles="/var/log/portatiles.log"

grep DHCPACK /var/log/syslog | grep -i port  > $dhcp_hoy

while read -r line
do
  fecha=$(echo $line | head -c 15)
  fecha=$(date -d"$fecha" +%Y/%m/%d-%H:%M:%S)
  ip=$(echo $line | cut -d" " -f8)
  mac=$(echo $line | cut -d" " -f10)
  nombre=$(echo $line | cut -d" " -f11 | tr -d "()")

  echo -e "${fecha}\t${nombre}\t${ip}" >> $log_portatiles
done < $dhcp_hoy

cat $log_portatiles_hoy >> $log_portatiles

sort -u  -o $log_portatiles $log_portatiles

exit 0
Todo esto se pone en un script del servidor que es invocado un par de veces al día usando crontab. Con eso tendremos el log preparado para consultar y disponer de esa información por si nos la requieren.


Los 同志 chinos han acabado de ensamblar en órbita su Estación Espacial:
Han tenido que montarse su propia estación debido a las reticencias de USA. Cuando no se quiere colaborar no queda otra que competir... y competir contra China es cada vez más complicado. No creo que hayamos aprendido la lección.

Zabbix (IV): creación de plantilla con items y triggers para agentes Linux.

En la primera entrada dedicada a Zabbix vimos templates para monitorizar impresoras Brother color. De todas las impresoras que tengo de esta marca he notado que la Broher DCP-9020CDW cada varios días se bloqueaba y me obligaba a reiniciarla. Si desactivaba la monitorización de Zabbix de esa impresora el problema desaparecía.

He deducido que alguno de los ítems que interrogaban a la impresora acababan finalmente provocando su cuelgue. Durante varios días he ido habilitando e inhabilitando ítems de la plantilla por grupos, mediante un divide y vencerás, hasta dar con el culpable: el "JetDirect Check".
Como es un ítem intrascendente que venía en la plantilla por defecto, lo he dejado desactivado (casilla "Enabled" desmarcada) y ya no ha vuelto a bloquearse:
¡Asunto solucionado!

viernes, 30 de septiembre de 2022

Filtrando publicidad con powerdns (III)

Nuestro filtro de publicidad basado en PowerDNS funciona bastante bien limpiando anuncios indeseados de las páginas y agilizando la navegación dentro de nuestra red.

El problema es que a veces filtra demasiado y nos quedamos sin ver cosas que pueden interesarnos (o no, como ATRESplayer). Esta semana me comunicaron que no se cargaban los contenidos de RTVE Play. Tras analizar el tráfico web con las opciones de desarrollador del navegador veo que se están cortando peticiones web a una serie de sitios con el nombre "gigya" y esto acababa repercutiendo en que no se cargaban los vídeos de RTVE.

La solución es no filtrar esos sitios, pero recordeoms que el script que construye la lista negra recopila los datos de varias ubicaciones web y no es sencillo quitar de esa lista uno a uno manualmente los sitios que si deseo permitir. Es el momento de implementar una "lista blanca" con patrones para identificar los sitios permitidos. El script blacklist-powerdns.sh quedaría:
# cat blacklist-powerdns.sh 
#!/bin/bash

#Crea fichero de bloqueos de publicidad y sitios web para powerdns.

#Descargamos listados de sitios web de publicidad a bloquear.
cp /dev/null /tmp/filter-hosts

wget -N -O /tmp/hosts https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
grep "^0.0.0.0" /tmp/hosts |  awk '{print $2}' >> /tmp/filter-hosts
echo "" >> /tmp/filter-hosts

wget -N -O /tmp/hosts http://sysctl.org/cameleon/hosts
grep "^127.0.0.1" /tmp/hosts | awk '{print $2}' >> /tmp/filter-hosts
echo "" >> /tmp/filter-hosts

wget -N -O /tmp/hosts https://mirror1.malwaredomains.com/files/justdomains
cat /tmp/hosts >> /tmp/filter-hosts
echo "" >> /tmp/filter-hosts

wget -N -O /tmp/hosts https://s3.amazonaws.com/lists.disconnect.me/simple_tracking.txt
cat /tmp/hosts >> /tmp/filter-hosts
echo "" >> /tmp/filter-hosts

wget -N -O /tmp/hosts https://s3.amazonaws.com/lists.disconnect.me/simple_ad.txt
cat /tmp/hosts >> /tmp/filter-hosts
echo "" >> /tmp/filter-hosts

#Este enlace está muerto
#wget -N -O /tmp/hosts https://hosts-file.net/ad_servers.txt
#cat /tmp/hosts >> /tmp/filter-hosts

#Añadimos lista negra de dominios mantenida por nosotros
if [ -f /etc/powerdns/bloqueados.list ]
then
   cat /etc/powerdns/bloqueados.list >> /tmp/filter-hosts
   echo "" >> /tmp/filter-hosts
fi

#Ordenamos y quitamos dominios repetidos. Borramos comentarios.
cp /tmp/filter-hosts /tmp/filter-hosts2
sort -u -o /tmp/filter-hosts /tmp/filter-hosts
sed -i '/^localhost$/d' /tmp/filter-hosts
sed -i '/^#/d' /tmp/filter-hosts

#Quitamos de la lista los que tienen las palabras en /etc/powerdns/permitidos.list
if [ -f /etc/powerdns/permitidos.list ]
then
   for cadena in $(cat /etc/powerdns/permitidos.list)
   do
     sed -i  "/$cadena/d" /tmp/filter-hosts
   done
fi

#Generamos el fichero blocklist.lua compatible con powerdns
echo "return {" > /tmp/blocklist.lua
for i in $(cat /tmp/filter-hosts)
do
   echo \"$i\", >> /tmp/blocklist.lua
done
echo "}" >> /tmp/blocklist.lua

#Copiamos fichero de bloqueo DNS y reiniciamos servicio.
/etc/init.d/pdns-recursor stop
/etc/init.d/pdns stop
cp -f /etc/powerdns/blocklist.lua /etc/powerdns/blocklist.lua.bak
cp -f /tmp/blocklist.lua /etc/powerdns/blocklist.lua
/etc/init.d/pdns start
/etc/init.d/pdns-recursor start

exit 0

En negrita está el código nuevo: una vez hecha la lista de sitios filtrados recorremos el contenido del fichero /etc/powerdns/permitidos.list y eliminamos de la lista los sitios que tienen las palabras/subcadenas encontradas allí. En principio he puesto en permitidos.list solo una línea con la cadena "gigya", pero seguramente en los próximos meses vaya añadiendo mas contrafiltros que hagan menos estricta la lista negra con la que venimos trabajando.


Espectacular petardazo de la NASA para desviar un asteroide con el impacto de la sonda DART. Esperemos que, como las armas nucleares, todo se quede en ensayos y no sea necesario usarlo nunca.

lunes, 26 de septiembre de 2022

Lanzar de forma remota una aplicación dentro de la sesión gráfica del usuario.

En diferentes escenarios puede ser que tengamos que abrir una aplicación gráfica dentro del escritorio del usuario que ha iniciado la sesión sin estar fisicamente presentes en ese puesto. Esto va desde mostrar un mensaje al usuario con "zenity" o "notify-send" a abrir una aplicación concreta de forma automática en su escritorio en un momento dado.

Esto nos permitiría abrir una aplicación "mágicamente" en el escritorio del usuario desde una conexión ssh remota o desde un script lanzado desde crontab.

El truco está en que antes de ejecutar el comando que lanza la aplicación asignamos a las variables XAUTHORITY y DISPLAY los valores adecuados para entrometerse en la sesión abierta por el usuario que ha iniciado sesión físicamente en la máquina.

Una primera aproximación, muy burda, sería ejecutar, con el usuario root, estos comandos desde consola:
# export XAUTHORITY=/run/lightdm/root/:0 
# DISPLAY=:0 zenity --info --text "Ola ke ase"

Esto conecta con la sesión X iniciada con lightdm (el gestor de inicios de sesión) y muestra la ventana. El peligro que tiene esta forma es que el comando (zenity en este caso) se ejecuta como root, con los riegos que esto conlleva. En el caso de zenity en principio no hay mucho peligro, pero un programa como geany o un explorador de archivos abiertos como root en una sesión de usuario raso es bastante mas arriesgado.

La ventaja que tiene esté metodo es que permite mostrar la aplicación incluso si ningún usuario ha iniciado sesión, en la pantalla de login. Por ejemplo, puede ser util para mostrar mensajes en el escritorio haya o no sesión iniciada.

La otra aproximación, más ortodoxa, pasa por averiguar que usuario ha iniciado sesión en el escritorio y conectarnos con su sesión X en concreto. Los pasos son:
# comando='zenity --info --text "Ola ke ase"' # Programa a ejecutar
# user=$(who | grep "(:0)" | awk '{print $1}')) # Averiguamos que usuario ha iniciado sesión en el ordenador, 
# home_user=$(su usuario -c 'echo $HOME') # Averiguamos cual es su directorio home. Otra forma: home_user=$(getent passwd  usuario | cut -d":" -f6)
# export XAUTHORITY="$home_user/.Xauthority" # Accedemos a su fichero .Xauthority
# DISPLAY=:0 su $user -c $comando # Lanzamos el programa con la identidad del usuario

Todo este código anterior lo podemos meter un script que lancemos desde nuestra conexión ssh o desde un crontab u otro sistema de ejecución en background y con ello lograremos nuestro objetivo, para desconcierto del usuario que verá como se abren cosas de forma inesperada.

viernes, 23 de septiembre de 2022

Cambiar hostname de un equipo de forma automática a partir de los datos de ldap.

Como todo principio de curso, andamos de mundanza moviendo equipos de unas aulas a otras. Eso implica cambiar su nombre según la nomenclatura que sigamos en nuestro centro, para tenerlo localizado ante cualquier alarma o incidencia.

En el árbol ldap de nuestra red tenemos una entrada en la que asociamos la MAC de cada equipo con su hostname. Una vez hemos cambiado el nombre allí luego toca ir fisicamente al propio equipo y cambiar dicho hostname otra vez a mano. Como esta parte es muy aburrida he escrito un script que toma la MAC del equipo, la busca en ldap y si la encuentra cambia el hostname al que allí aparece.
# cat set-hostname-from-mac.sh 

#!/bin/bash

#Busca las MACs en ldap y si tienen un nombre asociado, configura el equipo con dicha mac.

#Sacamos las MACs de las tarjetas de red del equipo
macs=$(cat /sys/class/net/*/address | grep -v "00:00:00:00:00:00")

for mac in $macs
do
   #Buscamos en la MAC en ldap en la rama de configuración DHCP
   name=$(ldapsearch -xLLL -h ldap -b cn=DHCP\ Config,dc=instituto,dc=extremadura,dc=es "(dhcpHWAddress=ethernet $mac)" "cn" | grep "^cn" | cut -d" " -f2)
   if [ -n  "$name" ]
   then
         echo "Nombre nuevo: $name"

         echo $name > /etc/hostname
         hostname -F /etc/hostname
         echo $name > /proc/sys/kernel/hostname
         sed -i "s/127.0.1.1.*/127.0.1.1 $name/g"  /etc/hosts

         exit 0
   fi
done
echo "MAC no encontrada"
exit

Este script podemos ejecutarlo desde una tarea puppet o en paralelo sobre muchos equipos a la vez usando tmux-cssh.


Bonita foto tomada desde la ISS del despegue de la Soyuz MS-22 hace un par de días, con un astronauta estadounidense y dos astronautas rusos. Al menos allí arriba no hay guerras.

Nunca había visto un chemtrail de una Soyuz. Los conspiranoicos correrían en círculos gritando si se enterasen.

miércoles, 29 de junio de 2022

Problema con las firmas de paquetes en Manjaro.

Tras varios años sigo usando Manjaro Linux en muchos de mis PC personales, que llevan todo este tiempo sin una reinstalación ya que al ser una distribución rolling release siempre está a la última. Demasiado a la última algunas veces.

Esto no evita problemas con la paquetería, sobre todo si te quedas varios meses sin actualizar, pero hasta ahora siempre he salido airoso de los pequeños líos que se montan ocasionalmente.

Esta semana me puse a actualizar una máquina y me encontré con este nuevo error:
# pacman -Syyuu
....
....
error: Error de GPGME: No hay datos
error: no se pudo actualizar core (base de datos no válida o dañada (firma PGP))
....
....
Mirando en Internet vi muchos consejos: refresca la lista de mirrors, refresca los países desde dónde descargas, etc. Ninguna funcionaba hasta que encontre esta solución:
# rm -Rf /var/lib/pacman/sync
# rm -Rf /tmp/pamac/dbs/*  
# pacman -Syu
# pamac update
Y listo, funcionó.

Aunque pude actualizar luego me encontré con otro problemilla. La compilación-instalación del paquete:
# pamac build  mjpg-streamer-git 
Me daba de nuevo el error "error: 'mjpg-streamer-git-1:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst': paquete sin la firma exigida" cuando iba a instalarlo tras la descarga y compilación. Este tipo de problemas suelen ser cuestiones puntuales con los repositorios pero en este caso tenía prisa. Solución:
# pamac build  -k mjpg-streamer-git 
Esto descarga y compila el paquete, pero además deja una copia del paquete instalable binario en /var/cache/pamac/mjpg-streamer-git-1\:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst. Vamos a intentar instalarlo a mano:
# cp /var/cache/pamac/mjpg-streamer-git-1\:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst /root
# pacman -U /root/mjpg-streamer-git-1\:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst 
error: 'mjpg-streamer-git-1:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst': paquete sin la firma exigida
Nada, sigue fallando. Para saltar el problema hay que desactivar la comprobación de firmas para paquetes que se instalen localmente. Editamos el fichero /etc/pacman.conf y cambiamos la línea:
LocalFileSigLevel = Never
Tras esto, ya podemos instalar el paquete sin contratiempos con:
# pacman -U /root/mjpg-streamer-git-1\:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst 
Tras esto podemos poner LocalFileSigLevel con su valor anterior o dejarlo a Never, según nos parezca.

Out!

martes, 28 de junio de 2022

Gestión de fechas en fotos.

Voy a recopilar varios comandos y scripts para trabajar con las fechas de las fotos y facilitar su ordenación cuando trabajamos con gran cantidad de ellas. Supongamos un fichero denominado IMG20220414185751.jpg, en cuyo nombre aparece la fecha en que se tomó: 14/04/2022 a las 18:57:51 horas.

Aparte de en el nombre, la fecha se guarda en los metadatos EXIF de la foto, dentro de los metadatos binarios del fichero de imagen. Podemos consultarlo con:
# exiftool IMG20220414185751.jpg | grep "Create Date"
Create Date                     : 2022:04:14 18:57:51
Create Date                     : 2022:04:14 18:57:51.764000
Luego con "ls -l" podemos ver la fecha de modificación del fichero que contiene la foto (llamada ctime en el mundo Unix). Normalmente coincide con la fecha EXIF, pero si lo copiamos de un dispositivo a otro y/o lo modificamos con un editor de imágenes esta fecha puede cambiar, como vemos aquí:
$ ls -l IMG20220414185751.jpg
-rw-r--r-- 1 manjaro manjaro 2499469 jun 27 06:38 IMG20220414185751.jpg
Si queremos que la fecha EXIF se copie a la fecha ctime podemos usar el comando:
$ exiv2 -T rename IMG20220414185751.jpg
$ ls -l IMG20220414185751.jpg
-rw-r--r-- 1 manjaro manjaro 2499469 abr 14 18:57 IMG20220414185751.jpg
Si queremos que la fecha EXIF se copie al nombre del fichero podemos usar un formato como:
# exiv2  -r 'IMG%Y%m%d%H%M%S' rename fichero.jpg
# ls -l IMG20220414185751.jpg
-rw-r--r-- 1 manjaro manjaro 2499469 abr 14 18:57 IMG20220414185751.jpg
Por ultimo, si la fecha EXIF ha sido elminada y queremos cambiar el ctime del fichero extrayendolo de su nombre el comando sería:
# fichero="IMG20220414185751.jpg"
# fecha=$(echo ${fichero:3:8})
# touch -a  -m -t "${fecha}0100" $fichero
# ls -l IMG20220414185751.jpg
-rw-r--r-- 1 manjaro manjaro 2499469 abr 14 01:00 IMG20220414185751.jpg
Y aquí paro porque con estos comandos tenemos suficiente para clasificar cronológicamente la selección de fotos. Por supuesto hay muchas otras combinaciones que me quedo en el tintero, como escribir la fecha EXIF (usando exiftool) y operaciones por el estilo que quizá veamos en otra ocasión.

lunes, 6 de junio de 2022

Zabbix (III): creación de plantilla con items y triggers para agentes Linux.

Después de tener montado el Zabbix, van surgiendo nuevas necesidades para monitorizar nuestros clientes. En esta entrada voy a ver como he creado una plantilla para los Linux del IES, que me permite monitorizar varias cosas no previstas en la plantilla por defecto. Lo que haremos en primer lugar es crear la plantilla "Template IES Linex"
A continuación vamos definir los ítems que extraigan datos del cliente. Estos ítems son pequeños fragmentos de código con comandos de terminal Unix. Lo podemos hacer de dos maneras:
  1. Definir el código en el cliente dentro de /etc/zabbix/zabbix_agentd.conf.d/blablaba.conf y luego referenciarlo en el servidor Zabbix.
  2. Definir el código en el servidor Zabbix, dentro del mismo item usando system.run[...]
En el primer caso vamos a crear, por ejemplo, un ítem llamado "puppetcheck" que nos diga si la última ejecución de puppet ha acabado con éxito. Para ello lo primero es programar las instrucciones que hagan eso. Hay varias maneras de averiguarlo, como por ejemplo esta:
# cat /var/lib/puppet/state/last_run_report.yaml | grep -i -e "failed: true" -e "status: failed" | wc -l 
Esto nos devolverá 0 si no hay ningún error y >0 si hay algun error en la última ejecución de puppet. Esta secuencia de comandos ejecutada como usuario root funciona, pero hay que tener en cuenta que el agente Zabbix se ejecuta con el usuario zabbix y eso nos puede causar problemas. En este caso concreto el problema era el acceso al fichero /var/lib/puppet/state/last_run_report.yaml del cliente.

Para que el agente Zabbix pueda llegar hasta allí tenemos que echar mano de sudoers:
# cat /etc/sudoers.d/puppetcheck
Cmnd_Alias CHECKPUPPET = /bin/cat /var/lib/puppet/state/last_run_report.yaml
zabbix ALL=(ALL) NOPASSWD: CHECKPUPPET
Una vez hecho esto, ya podemos definir el parámetro que usará el ítem en el cliente:
# cat /etc/zabbix/zabbix_agentd.conf.d/checkpuppet.conf
UserParameter=system.puppetcheck,sudo cat /var/lib/puppet/state/last_run_report.yaml | grep -i -e "failed: true" -e "status: failed" | wc -l
. Una vez definido el item en los clientes, lo añadimos a la plantilla en el servidor Zabbix:
Además de crear el ítem, le añadimos una regla de preprocesamiento llamada "Discard unchanged with a heartbeat" que evita que se guarden valores repetidos consecutivos del ítem en el registro histórico. De esta manera solo guardamos el ítem cuando cambia su valor respecto a la actualización anterior (o, en este caso concreto, han pasado 12 horas desde la última actualización). La finalidad de esto es evitar guardar valores repetidos consecutivos de los ítems en toda la base de datos histórica.
Finalmente creamos un trigger para que avise cuando hay un error. En este caso vemos si hay error en puppet durante las 3 últimas actualizaciones del ítem:



Con esto tenemos el pack completo: parámetro defínido en el cliente Zabbix, asociado a un ítem en el servidor Zabbix y con un trigger que nos avisa este tiene un valor determinado.

La otra otra opción consiste en definir en el servidor Zabbix el ítem con el código a ejecutar en el cliente remoto. Por ejemplo, un ítem que muestre en cada momento que usuario ha hecho login en la máquina, definido así:
Parent items: Template Linux IES
Name: LoggedUser
Type: Zabbix agent
Uptdate time: 1m
Key: system.run["who | grep -v root | cut -d' ' -f1"]
El problema de este tipo de ítems es que debemos estar seguros de que el cliente Zabbix permite la ejecución remota de comandos, ya que si no es así el ítem no se actualizará nunca. De igual manera, si el agente se ejecuta en una máquina que está detrás de un firewall o un NAT tampoco podremos llegar a ella para ejecutar el comando desde el servidor Zabbix.

En este ítem LoggedUser tambien añadiremos una regla de preprocesamiento del tipo "Discard unchanged", para evitar guardar de forma repetida el usuario logado cada vez que se actualiza el ítem, y solo guardarlo cuando cambia entre una actualización y la siguiente.

Por último, comentar que una vez hemos definido los ítems tenemos la posibilidad de probarlos desde la línea de comandos para ver que tal funcionan. En el cliente local:
# zabbix_agentd -t system.puppetcheck
O de forma remota:
# zabbix_get -s 172.X.Y.Z -p 10050 -k system.puppetcheck
Bueno, pues con esto ya tenemos el armazón para añadir ítems y triggers a saco en nuestros clientes.
Aquí están los 3 camaradas taikonautas que han subido estos días en la Shenzou 14 para finalizar el montaje de la Estación Espacial China. Recordemos que esta estación existe porque USA se negó a dar acceso a China a la Estación Espacial Internacional, por lo que los chinos decidieron montarse su propia estación mastodóntica (que a diferencia de la de Bender, no tendrá casinos ni furcias (*)) adquiriendo en el proceso una experiencia y know-how que les vendrá de perlas.

Es lo que pasa cuando no se quiere colaborar internacionalmente. Avisados quedamos.

(*)

viernes, 27 de mayo de 2022

Zabbix (II): quitar alertas insistentes de servicios no arrancados en Agentes Windows.

Poco a poco sigo poniendo en marcha mi servidor Zabbix. Tras poner en funcionamiento la monitorización de los equipos Windows usando el "Template Module Windows services by Zabbix agent" me encontré que el Dashboard se llenaba de alertas de "Problemas" con los servicios de los Windows.
Los mensajes en concreto eran del tipo:
  • 12:58:34 pc "BITS" (Servicio de transferencia inteligente en segundo plano (BITS)) is not running (startup type automatic delayed) 12m 23s No
  • 12:51:06 pc "BITS" (Servicio de transferencia inteligente en segundo plano (BITS)) is not running (startup type automatic delayed) 19m 51s No
  • 12:05:19 pc "OneSyncSvc_1265ec8f" (Sincronizar host_1265ec8f) is not running (startup type automatic delayed) 1h 5m 38s No
  • 12:05:18 pc "CDPUserSvc_1265ec8f" (Servicio de usuario de plataforma de dispositivos conectados_1265ec8f) is not running (startup type automatic)
Básicamente los que sucede es que hay varios servicios que, tras arrancar el equipo con Windows, tardan en arrancar o fallan y el Agente Zabbix nos informa de esa circunstancia. La plantilla usada realiza un descubrimiento de los servicios habilitados en la máquina y si tras 3 ciclos de actualización del agente no están en ejecución salta la alerta.
El mensaje que sale en la descripción del problema es "The service has a state other than "Running" for the last X times":
Al final, pasadas las horas, acaban por arrancar los servicios y desaparecen casi todas las alertas, pero no quita que en ciertos momentos se llene la pantalla de alertas sobre cosas que no me aportan nada.

Lo primero que intenté fue cambiar la plantilla para que en lugar de revisar el estado durante 3 ciclos lo hiciese durante 10, dando un poco más de margen de tiempo para que funcionen. No sirvió de nada.

Teniendo en cuenta que estos son servicios poco importantes (y que sospecho que algunos no funcionan bien por el firewall corporativo, que capa actualizaciones de Microsoft) la otra estrategía que podía aplicar es sencillamente dejar de monitorizar dichos servicios. ¿Se puede hacer eso? Pues gracias a la flexibilidad de Zabbix si se puede. Los pasos a seguir son:
  1. Vamos a Configuration->Templates.
  2. Buscamos Template OS Windows by Zabbix agent -> Template Module Windows services by Zabbix agent
  3. Vamos a Windows services discovery -> Filters.
  4. Añadimos un filtro para ignorar, filtrando por su nombre, los Servicios que dan problemas (como vemos la lista es bastante grande, y eso que sigo añadiendo más):
    {#SERVICE.NAME}
    does not match
    ^(MMCSS|TrustedInstaller|BITS|GISvc|gupdate|MapsBroker|WbioSrvc|sppsvc|RemoteRegistry|wuauserv|gupdate|SysmonLog|clr_optimization_v2.0.50727_32|clr_optimization_v4.0.30319_32)$
      
El filtro se añade a la lista de filtros colocándose, no se por qué, en el tercer lugar:
Una vez acabamos veo que las alertas siguen saltando. La causa es que aunque hayamos cambiado la plantilla esos cambios no se aplican a los hosts dados de alta con ellas. Desconozco si hay alguna manera de trasladar esos cambios, pero como no encontraba nada lo resuelvo de una forma más expeditiva: borro los hosts Windows y dejo que se autoregistren de nuevo, aplicándose la plantilla ya cambiada con los filtros. Fin del problema.
Esta foto es del helicóptero marciano Ingenuity fotografiando la cápsula que dejó el Perseverance (mirar la sombra del propio helicóptero en la imagen) en tierra de forma segura y luego se alejó para caer al suelo. Como vemos el litofrenado la ha dejado bastante maltrecha.

Para mi gozo absoluto, hace unas semanas pude ver una réplica a tamaño real de la Perserverance y la Ingenuity en Nueva York, ahí van unas fotos hechas por mi:
Que maravilla de la ingeniería. Un aparato pensado para realizar un puñado de vuelos de prueba en una atmósfera un 99% menos densa que en la Tierra sigue dandose garbeos por el planeta rojo meses después.
Estuve cerca de ellas, pero no pude tocar nada. Por fortuna si que pude sentarme dentro de una de esas latas de sardina que fueron las cápsulas Gemini de los años 60. Emocionante.

miércoles, 2 de marzo de 2022

Sincronizando directorios remotos entre Linux y OpenWRT mediante syncthing

Después de montar un NAS sobre OpenWRT he querido probar una herramienta a la que tenia puesto el ojo hace tiempo: syncthing.

Syncthing permite mantener sincronizados de forma automática directorios entre distintas máquinas, incluso si corren diferentes sistemas operativos. Cualquier cambio en uno de los ficheros o subcarpetas en una máquina será propagada hacia las demás mediante un sistema P2P en tiempo real o en intervalos de tiempo predefinidos. Puede ser útil para tener, por ejemplo, una copia de seguridad de los datos de nuestros usuarios o de directorios importantes.

Hacerlo funcionar entre dos Ubuntu es bastante sencillo, hay muchos manuales en Internet. La versión que viene con Ubuntu 18 es bastante antigua, así que nos descargamos la más moderna versión 1.19, añadiendo el repositorio de la aplicación y ejecutando los comandos:
# apt-get install curl
# curl -s https://syncthing.net/release-key.txt | sudo apt-key add -
# echo "deb https://apt.syncthing.net/ syncthing stable" | tee /etc/apt/sources.list.d/syncthing.list
# apt-get install apt-transport-https
# apt-get update
# apt-get install syncthing
# systemctl enable syncthing@root.service
# systemctl start syncthing@root.service
Una vez instalado, los pasos sigientes son:
  1. Con el navegador, en la URL http://127.0.0.1:8384 accedemos al entorno web de configuración de syncthing, un entorno muy sencillo y funcional. Lo primero a hacer es definir un usuario y contraseña de acceso en Actions/Settings/GUI/GUI Authentication User-Password.
    Luego lo que he hecho es eliminar la carpeta compartida "Default Folder" de la sección "Folder", ya que no me interesa para nada, y añadir una carpeta que si quiero compartir y sincronizar, por ejemplo "/media/sync" o la que nos interese en nuestro caso.
  2. A continuación, instalamos la aplicación en el otro PC, la abrimos con el navegador en http://127.0.0.1:8384 y definimos usuario/contraseña y borramos la carpeta "Default Folder". No definimos ninguna carpeta para sincronizar.
  3. Volvemos al primer PC, a la página http://127.0.0.1:8384, y le damos al botón "Añadir un dispositivo remoto", en la sección "Dispositivos". Esto nos pide el Device ID del otro ordenador (que encontramos en su menú Actions/Show ID), pero como syncthing es muy listo lo ha localizado el solo por nosotros y aparece para que pinchemos y lo seleccionemos sin tener que escribir nada.
    Además marcamos la carpeta que queremos sincronizar en un checkbox que aparece en la parte inferior de la siguiente pestaña.
  4. De nuevo en el PC secundario abrimos la página http://127.0.0.1:8384, esperamos unos instantes y nos saldrá la petición de que otro dispositivo quiere sincronizar con este pc. Aceptamos y esperamos otro ratito. Ahora nos dirá que quiere sincronizar la carpeta compartida desde el otro PC, aceptamos de nuevo e indicamos la ruta local sobre la que queremos ubicar esa carpeta. Fin.
Con esto, cualquier cambio que hagamos sobre las carpetas conectadas se propagará al poco tiempo al otro extremo. También podemos programarlo a nivel de carpeta para que no sea una sincronización inmediata y se haga a ciertos intervalos.

Una vez conseguido entre 2 PC con Ubuntu el siguiente paso es hacerlo con uno que tenga OpenWRT, por ejemplo nuestro NAS. Para ello me he guiado con este enlace. Los pasos seguidos son:
  • Descargamos la versión para procesador MIPS (nuestros DLink DIR-860L funcionan con CPU MIPS) de syncthing, en el enlace https://github.com/syncthing/syncthing/releases/download/v1.19.0/syncthing-linux-mipsle-v1.19.0.tar.gz
  • Descomprimimos el fichero y localizamos el ejecutable syncthing entre los ficheros extraídos, verificando que es un ejecutable para MIPS:
    # ls -l syncthing 
    -rwxr-xr-x 1 root root 23242371 feb  1 12:52 syncthing
    # file syncthing 
    syncthing: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, Go BuildID=34n17_AjfWP2w_vsWklx/00redfghuYoGTWmMPWQy/8T6vcQMJvHjNx9l6eQVF/zZyy9E8KKWjV03NfAwtN, not stripped
    
  • Copiamos el fichero a nuestro OpenWRT. Como ocupa 23MB y nuestro DLink solo tiene 16MB de disco interno no nos queda otra que copiarlo sobre el disco duro externo USB que montamos en el NAS, en la ruta /disco:
    # scp syncthing root@nas:/disco/syncthing 
    
    Una vez copiado, conectamos por ssh al OpenWRT y lo ejecutamos (/disco/syncthing) para verificar que funciona...es raro encontrar un ejecutable para OpenWRT aislado que funcione sin quejarse, pero este lo hace sin problema.
  • Ahora creamos un script de inicio para ejecutar syncthing como un servicio en el arranque:
    # cat /etc/init.d/syncthing
    #!/bin/sh /etc/rc.common
    # Copyright (C) 2015 brglng@github.com
    
    START=99
    STOP=99
    
    start() {
            service_start /disco/syncthing 2>&1 | logger -t syncthing &
    }
    
    stop() {
            service_stop /disco/syncthing
    }
    
    Activamos y lanzamos el servicio y creamos la carpeta donde haremos las sincronizaciones (dentro del disco USB, obviamente):
    # /etc/init.d/syncthing enable
    # /etc/init.d/syncthing start
    # mkdir /disco/sync
    
  • Ahora tenemos un problemilla: para configurar syncthing hay que entrar con navegador web en http://127.0.0.1:8384, pero OpenWRT no tiene entorno gráfico ni navegador web. Debemos entrar desde un PC externo a http://nas:8334, pero syncthing por defecto solo acepta conexiones http desde 127.0.0.1. Esto se corrige editando: /root/.config/syncthing/config.xml y localizando:
    ...
    <gui enabled="true" tls="false">
      <address>127.0.0.1:8384</address> 
    </gui>
    ...
    
    Que debe cambiar a:
    ...
    <gui enabled="true" tls="false">
      <address>0.0.0.0:8384</address> 
    </gui>
    ...
    
    Tras esto, reiniciamos el servicio syncthing y ya podremos conectar a http://nas:8334
  • Una vez conectados al entorno web los pasos son similares a cuando lo hicimos con dos PC con Ubuntu, solo que la ruta de la carpeta sincronizada será /disco/sync
Y con esto ya tenemos nuestro NAS sincronizado mediante un servicio syncthing. En las pruebas preliminares no parece que se haya cargado de forma apreciable la modesta CPU MIPS de nuestro OpenWRT. Lo observaremos con cuidado.

jueves, 24 de febrero de 2022

NAS sobre DLink DIR 860L-B1 y OpenWRT

Seguimos haciendo cosas con los puntos wifi DLink DIR 860L-B1. Ahora vamos a ver como montar un servidor NAS que tenga al menos los servicios samba y sshfs. Opcionalmente se podrían montar otros servicios adicionales como NFS, RemoteFS, SFTP...

La almacenamiento será sobre disco duro externo de 1TB conectado al puerto USB 3.0 del DLink.

En un principio he intentado hacerlo funcionar con OpenWRT 21.02.1, que ya había utilizado para el montaje del routed client, pero he tenido estos dos problemas:
  • Los paquetes de samba4 ocupan una burrada, no hay espacio en los 16Mb de memoria SD del dispositivo para ellos.
  • En esta versión de OpenWRT no hay samba3. Existe un paquete llamado ksmbd-server que emula samba v3 a nivel de módulo del nucleo. El problema es que en las pruebas que he hecho es inestable y se cae con frecuencia.
Visto lo visto, he vuelto a usar OpenWRT 15.05, que sigue siendo una versión muy estable con buen funcionamiento.

Una vez cargado el sistema y hechas las configuraciones iniciales básicas, veamos como queda. La red pide una IP por DHCP en el puerto "lan" (hemos dado de alta el equipo en el arbol ldap con el nombre "nas" y una IP fija)
# cat /etc/config/network 
config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fdda:86a9:b1ad::/48'

config interface 'lan'
	option ifname 'eth0.1'
	option force_link '1'
	option macaddr '9a:45:4e:fb:75:c1'
	option type 'bridge'
	option proto 'dhcp'
	
config interface 'wan'
	option ifname 'eth0.2'
	option force_link '1'
	option macaddr '9a:45:4e:fb:75:c2'
	option proto 'dhcp'

config interface 'wan6'
	option ifname 'eth0.2'
	option proto 'dhcpv6'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '1 2 3 4 6t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '0 6t'    
Los interfaces wifi quedan apagados:
# cat /etc/config/wireless 
config wifi-device  radio0
	option type     mac80211
	option channel  36
	option hwmode	11a
	option path	'pci0000:00/0000:00:00.0/0000:01:00.0'
	option htmode	VHT80
	# REMOVE THIS LINE TO ENABLE WIFI:
	option disabled 1

config wifi-iface
	option device   radio0
	option network  lan
	option mode     ap
	option ssid     OpenWrt
	option encryption none

config wifi-device  radio1
	option type     mac80211
	option channel  11
	option hwmode	11g
	option path	'pci0000:00/0000:00:01.0/0000:02:00.0'
	option htmode	HT20
	# REMOVE THIS LINE TO ENABLE WIFI:
	option disabled 1

config wifi-iface
	option device   radio1
	option network  lan
	option mode     ap
	option ssid     OpenWrt
	option encryption none
Creamos un usuario normal para usar luego en samba. En /etc/passwd añadimos el usuario "nas":
# cat /etc/passwd
root:x:0:0:root:/root:/bin/ash
daemon:*:1:1:daemon:/var:/bin/false
ftp:*:55:55:ftp:/home/ftp:/bin/false
network:*:101:101:network:/var:/bin/false
nobody:*:65534:65534:nobody:/var:/bin/false
nas:*:1000:65534:nas:/var:/bin/ash
Y definimos una contraseña para él:
# passwd nas
El montaje del disco externo USB necesita estos paquetes:
# opkg update
# opkg install fdisk block-mount e2fsprogs kmod-fs-ext4 kmod-usb-storage kmod-usb2 kmod-usb3
Formateamos el disco externo (aconsejamos usar formato ext3) y lo pinchamos en el puerto usb. Con:
# fdisk -l
Sacamos un listado de los discos conectados, nuestro disco duro debe aparecer como /dev/sdaX. A continuación creamos el punto de montaje:
# mkdir /disco
# chown nas: /disco
# chmod 777 /disco
Modificamos el fichero "fstab" para que se automonte el disco en el arranque:
# cat /etc/config/fstab 
...
config mount
	option enabled '1'
	option device '/dev/sda1'
	option target '/disco'
Instalamos paquetes para permitir conexiones y transferencia de datos con sshfs, scp y rsync:
# opkg update
# opkg install openssh-sftp-server rsync
Y vamos a la configuración de samba:
# opkg update
# opkg install kmod-usb-storage block-mount samba36-server luci-app-samba
La configuración sería:
# cat /etc/config/samba 
config samba
	option workgroup 'WORKGROUP'
	option homes '1'
	option name 'NAS'
	option description 'NAS'

config sambashare
	option name 'datos'
	option path '/disco'
	option read_only 'no'
	option guest_ok 'no'
	option create_mask '777'
	option dir_mask '777'
   	option users 'nas'
Hay que crear el usuario "nas" en samba, con la contraseña que nos pareza conveniente:
# smbpasswd -a nas
Tras esto reiniciamos y probamos a montar desde una maquina cliente. En una máquina Linux que hará de cliente vamos a probar a montar mediante sshfs:
# sshfs root@nas:/disco /mnt
# mount
....
root@nas:/disco on /mnt type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0)
# umount /mnt
Vamos a por samba. Samba casi siempre da problemas de permisos con el sistema de ficheros compartido. Para evitarlo, una vez montado el disco duro modificamos de nuevo los permisos de la carpeta (esto se debe a que cuando la partición montada es tipo extX no existe el parametro umask):
# chmod 777 /disco
Y ahora en un cliente Linux probamos a montar usando samba/cifs y creamos un directorio y un fichero para confirmar que todo va bien:
# mount -t cifs //172.19.231.150/datos /mnt -o username=nas,password=xxxx
# mount
....
//172.19.X.Y/datos on /mnt type cifs (rw,relatime,vers=1.0,cache=strict,username=nas,domain=NAS,uid=0,noforceuid,gid=0,noforcegid,addr=172.19.X.Y,unix,posixpaths,serverino,acl,rsize=1048576,wsize=1048576,actimeo=1)
# mkdir /mnt/prueba
# touch /mnt/prueba/test
# umount
Por último, para clientes Windows se realiza el montaje accediendo desde el explorador de archivos a la ruta "\\nas\disco". Pedirá usuario y contraseña y listo...excepto en Windows 10, que da un error derivado de que en dicho sistema se han puesto tiquismiquis con la versión de SMB soportada. Todo el asunto está descrito en este enlace, para que funcione simplemente hay que activar el soporte para SMB 1.0 siguiendo estos pasos:
  • Pulsar Windows Key + R, teclea "optionalfeatures.exe" y pulsa Enter. Sale una ventana muy años 90.
  • Buscar la sección "SMB 1.0/CIFS File Sharing Support" o similar, abrirla.
  • Marcar SMB 1.0/CIFS Client. Desmarcar MB 1.0/CIFS Automatic Removal y SMB 1.0/CIFS Server.
  • Reiniciar y acceder a "\\nas\disco" para verificar que funciona.
Por supuesto, todo esto es un ejemplo sencillo. Nada impide compartir distintas carpetas con distintos permisos de acceso dentro del disco externo, usando recursos samba diferentes. Eso queda al libre albedrío de cada cual.

Al ser un sistema donde el disco va por USB no es lo más rápido del mundo, pero queda ideal para copias de seguridad y tareas que no requieran una velocidad de transferencia excesiva.

Y poco mas se puede probar, simplemente estoy mirando la posibilidad de usar syncthing para mantener el disco NAS sincronizado con otor sistema de ficheros, en plan "copia de seguridad en tiempo real", a ver que tal rinde.

Ya iremos contando. До свидания!

viernes, 18 de febrero de 2022

Multiseat en Windows con Aster

Ya he tratado varias veces el tema del multiseat en este blog. En Linux no hay mayor problema ya que se soporta de forma nativa, sin añadir ningún software adicional, como ya vimos aquí.

En Windows por desgracia esto no es así y, por tanto, hay que usar un sofware comercial. He localizado varios que se han ido quedando por el camino a lo largo de los años, pero uno de ellos permanece y funciona perfectamente para Windows 11 y anteriores: el Aster de Ibik. Evidentemente es un software de pago, valiendo hoy unos 70€ la licencia para hacer un pc bipuesto y permitir trabajar a 2 usuarios simultáneamente, cada uno con su monitor, teclado y ratón. Debemos valorar si esa inversión de 70€ merecen la pena antes de comprar un nuevo PC o no.

Afortunadamente se puede bajar una versión de prueba que permite probarlo y evaluarlo durante un mes antes de tomar una decisión.

Antes de seguir hay que recordar que además de 2 monitores, 2 teclados y 2 ratones, el único PC donde montamos el multiseat debe tener suficiente RAM (8Gb está bien) y dos tarjetas gráficas, normalmente una en placa base y otra en un puerto PCIe. En estos tiempos revueltos donde las tarjetas gráficas cuestan una burrada gracias al burbujón de las criptomonedas y a la escasez de chips, he podido probar con una tarjeta gráfica USB3, que tengo para mis enredos, como esta:
... y puedo confirmar que funciona decentemente. El coste de este adaptador USB3-VGA Hagibis es de unos 15-20 euros.

Descargando la versión de prueba de la aplicación y configurándola según el manual verificamos que funciona. Podemos verlo en ambos puestos de la siguiente foto, cada uno con una sesión de usuario distinta y conectados al mismo PC:
Mostramos la parte trasera y delantera del PC para poder ver el cableado:
En la parte trasera tenemos un teclado y un ratón conectados a los puertos PS/2, un monitor conectado a la tarjeta VGA y el otro monitor conectado a la tarjeta USB3-VGA (la cual está enchufada a un puerto USB 3.0). En la parte delantera tenemos conectado el otro teclado y ratón USB.

La configuración de la aplicación Aster es muy intuitiva (a diferencia de Linux, donde teníamos que meternos con ficheros de configuración editados a mano) usando un interface gráfico y siguiendo el manual que hemos enlazado antes:
Por todo lo demás, he tenido a los usuarios trabajando durante un mes con este sistema, usando el navegador web y la aplicación Autocad 2019 y todo ha ido fluido, si notar ralentizamiento apreciable. Por tanto queda como una opción a considerar cuando queramos dotar o modernizar un aula. Lástima que no haya alternativa gratis como en en Linux....

Out!

martes, 15 de febrero de 2022

Configuración de DLink DIR 860L-B1 como "routed client" para conectar como cliente a una red wifi.

De este tema ya he hablado en anteriores posts:
  1. OpenWRT en DLink DIR 860L-B1: http://2tazasdelinux.blogspot.com/2020/11/instalar-openwrt-en-los-puntos-de.html
  2. Routed client con NAT: http://2tazasdelinux.blogspot.com/2017/03/configuracion-de-openwrt-como-routed.html
  3. Routed client con relayd: http://2tazasdelinux.blogspot.com/2017/04/configuracion-de-openwrt-como-routed.html
Pero ahora voy a documentar como hacerlo funcionar en nuestros famosos y ociosos DLink DIR 860L-B1.

Recapitulemos: un Routed Client es la configuración por defecto de OpenWRT. En ella el router interconecta la red inalámbrica con la red LAN del dispositivo. Como la mayoria de los drivers wifi no permiten hacer un "bridge" si el dispositivo se conecta a la red wifi en modo cliente, cuando queremos interconectar ambas redes tenemos que configurarlo a mano enrutando el tráfico entre uno y otro interfaz. Y como hacer eso es lo que contaremos aquí.

¿Qué utilidad tiene esto?: pues es algo similiar a una "tarjeta wifi" configurada y lista para usar en cualquier momento en un dispositivo que necesite conexión y no nos llegue la red cableada. El DLink se conecta a la red wifi del centro y con el cable de red conectamos a los puertos ethernet hasta 4 dispositivos, de tal manera que esos tienen acceso a la red del centro.

Si por ejemplo tenemos un PC de sobremesa en un area donde no llega red cableada (o llega, pero hay una avería de electrónica de red), simplemente con enchufarlo por un cable de red a un DLink configurado como contamos aqui tendrá acceso a la red del centro de forma inmediata, sin mas aspavientos y sin configurar nada en el PC.

1. Cargar OpenWRT en el DLink.

Aunque en el artículo anterior contamos como instalar OpenWRT y propusimos poner la versión 15.05, ahora he hecho pruebas con versiones posteriores y he visto que la versión 21.02.1 funciona mejor que la 15.05.

Por tanto lo cargamos la imagen como contamos en el articulo anterior, pero ahora usamos OpenWrt 21.02.1 r16325-88151b8303. En cualquier momento podremos encontrar la última imagen en la página oficial de OpenWRT dedicada a nuestro DLink.

Una vez instalado el OpenWRT hay dos alternativas para configurar la interconexión entre la wifi y los puertos ethernet del DLink:
  • Usando IP Masquerading y haciendo NAT.
  • Usando relayd, que crea un "pseudobridge" por software que interconecta el tráfico entre ambas redes.
Veremos cada uno de los casos y sus ventajas e inconvenientes.

2. Usando IP masquerading.

El esquema sería este:


La conexión wifi recibe una IP de nuestra red 172.X.Y.Z y su interfaz ethernet tiene la IP 192.168.1.1. Sobre esa interfaz corre un servidor DHCP que da direcciones a los clientes dentro de ese rango. Ambas redes están interconectadas mediante IP masquerading como se viene haciendo de toda la vida para cualquier subred privada.

Los PC u otros dispositivos conectados a los puertos ethernet, con direccionamiento 192.168.1.X, son enrutados a través de la conexión wifi hacia la red del centro.

Para lograr esto hay que realizar la siguiente configuración en los ficheros de OpenWRT:

Primero la configuración de red:
# cat /etc/config/network
config interface 'loopback'
    option device 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'
    option packet_steering '1'
    option ula_prefix 'fdd3:89a2:bcfc::/48'

config device
    option name 'br-lan'
    option type 'bridge'
    list ports 'lan1'
    list ports 'lan2'
    list ports 'lan3'
    list ports 'lan4'

config device
    option name 'lan1'
    option macaddr '90:8d:78:59:c9:5c'

config device
    option name 'lan2'
    option macaddr '90:8d:78:59:c9:5c'

config device
    option name 'lan3'
    option macaddr '90:8d:78:59:c9:5c'

config device
    option name 'lan4'
    option macaddr '90:8d:78:59:c9:5c'

config interface 'lan'
    option device 'br-lan'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option force_link '1'
    option ip6assign '60'

config device
    option name 'wan'
    option macaddr '90:8d:78:59:c9:5f'

config interface 'wan'
    option device 'wan'
    option proto 'dhcp'

config interface 'wan6'
    option device 'wan'
    option proto 'dhcpv6'

config interface 'wwan'
    option proto 'dhcp'
Como vemos hay 3 interfaces
  • lan: correspondiente al bridge que une los 4 puertos LAN ethernet del router, con IP 192.168.1.1
  • wan: correspondiente al puerto wan del router (el amarillo), que no usamos para nada.
  • wwan: correspondiente a la conexión wifi, que se configura por dhcp.
Ahora la configuración de la wifi:
# cat /etc/config/wireless

config wifi-device 'radio0' #Esde dispostivo es de la red de 5Ghz, no la uso, lo dejo desactivado.
    option type 'mac80211'
    option channel '36'
    option hwmode '11a'
    option path '1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
    option htmode 'VHT80'
    option disabled '1'

config wifi-device 'radio1'
    option type 'mac80211'
    option channel '11'
    option hwmode '11g'
    option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
    option cell_density '0'

config wifi-iface 'wifinet0'
    option device 'radio1'
    option mode 'sta'
    option network 'wwan'
    option ssid 'SSID_RED_EDUCATIVA'
    option encryption 'psk2'
    option key 'PASSWD_RED_EDUCATIVA'
Conectamos el interface de red wwan/radio1 indicando la contraseña y clave de la red educativa. Esto lo adaptarás según la wifi que quieras usar de tu centro. El DLink se conecta, autentica y recibe una IP por DHCP. Para facilitar la gestión recomiendo que la tarjeta wifi tenga configurada una IP fija en el servidor DHCP del centro.

Ahora vamos a ver el servidor DHCP:
#cat /etc/config/dhcp
config dnsmasq
    option domainneeded '1'
    option boguspriv '1'
    option filterwin2k '0'
    option localise_queries '1'
    option rebind_protection '1'
    option rebind_localhost '1'
    option local '/lan/'
    option domain 'lan'
    option expandhosts '1'
    option nonegcache '0'
    option authoritative '1'
    option readethers '1'
    option leasefile '/tmp/dhcp.leases'
    option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
    option nonwildcard '1'
    option localservice '1'
    option ednspacket_max '1232'

config dhcp 'lan'
    option interface 'lan'
    option start '100'
    option limit '150'
    option leasetime '12h'
    option dhcpv4 'server'
    option dhcpv6 'server'
    option ra 'server'
    option ra_slaac '1'
    option ignore '0'
    list ra_flags 'managed-config'
    list ra_flags 'other-config'

config dhcp 'wan'
    option interface 'wan'
    option ignore '1'

config odhcpd 'odhcpd'
    option maindhcp '0'
    option leasefile '/tmp/hosts/odhcpd'
    option leasetrigger '/usr/sbin/odhcpd-update'
    option loglevel '4'
Simplemente se define un servidor dhcp sobre el interface lan (el que da conexión cableada por los 4 puertos ethernet), que repartirá direcciones en el rango 192.168.1.100 a 192.168.1.150.

Ahora vemos la configuracion del firewall:
# cat /etc/config/firewall

config defaults
    option syn_flood '1'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'REJECT'

config zone
    option name 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'REJECT'
    list network 'lan'

config zone
    option name 'wwan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    option masq '1'
    list network 'wwan'

config zone
    option name 'wan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option mtu_fix '1'
    list network 'wan'
    list network 'wan6'

config forwarding
    option src 'lan'
    option dest 'wwan'

config rule
    option name 'Allow-DHCP-Renew'
    option src 'wan'
    option proto 'udp'
    option dest_port '68'
    option target 'ACCEPT'
    option family 'ipv4'
....
.... esta parte queda sin tocar....
....

....
config include
    option path '/etc/firewall.user'
Basicamente se permite el forwarding entre lan y wwan, activando el masquerading en wwan. De esta manera el tráfico se enrutará entre ambos interfaces y redes.

3. Usando relayd.

En esta solución también la conexión wifi recibe una IP de nuestra red 172.X.Y.Z y su interfaz ethernet tiene la IP 192.168.1.1. Pero aquí acaban las similitudes con NAT. El servicio DHCP lo da el servidor del centro, por lo que las IP que reciben los clientes son de dicha red, del tipo 172.X.Y.W. Ambas redes están interconectadas mediante un demonio relayd que pasa el tráfico entre ellas por software (por eso a esta solución se le llama "pseudobridge").

Los PC u otros dispositivos conectados a los puertos ethernet tienen direccionamiento 172.X.Y.W, y gracias al relayd están lógicamente en la red del centro pudiendo ser alcanzados por ping u otro tipo de conexión. Por ejemplo, si conectamos una impresora por cable de red al DLink se podrá acceder a su IP para imprimir desde cualquier punto del centro.

Para lograr esto hay que realizar la configuración que datallaremos a continuación.

Instalar y activar el servicio relayd:
# opkg update
# opkg install relayd
# /etc/init.d/relayd enable
# /etc/init.d/relayd restart
La configuración de red:
# cat /etc/config/network

config interface 'loopback'
    option device 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'
    option packet_steering '1'
    option ula_prefix 'fdd3:89a2:bcfc::/48'

config device
    option name 'br-lan'
    option type 'bridge'
    list ports 'lan1'
    list ports 'lan2'
    list ports 'lan3'
    list ports 'lan4'

config device
    option name 'lan1'
    option macaddr '90:8d:78:59:c9:5c'

config device
    option name 'lan2'
    option macaddr '90:8d:78:59:c9:5c'

config device
    option name 'lan3'
    option macaddr '90:8d:78:59:c9:5c'

config device
    option name 'lan4'
    option macaddr '90:8d:78:59:c9:5c'

config interface 'lan'
    option device 'br-lan'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option force_link '1'
    option ip6assign '60'

config device
    option name 'wan'
    option macaddr '90:8d:78:59:c9:5f'

config interface 'wan'
    option device 'wan'
    option proto 'dhcp'

config interface 'wan6'
    option device 'wan'
    option proto 'dhcpv6'

config interface 'wwan'
    option proto 'dhcp'

config 'interface' 'stabridge'
    option 'proto'      'relay'
    option 'network'    'lan wwan'
En este sistema hay también 3 interfaces:
  • lan: correspondiente al bridge que une los 4 puertos LAN ethernet del router, con IP 192.168.1.1
  • wan: correspondiente al puerto wan del router (el amarillo), que no usamos para nada.
  • wwan: correspondiente a la conexión wifi, que se configura por dhcp.
Adicionalmente interconectamos los interfaces lan y wwan mediante el demonio relayd.

Ahora la configuración de la wifi, que es totalmente igual a la del caso anterior:
# cat /etc/config/wireless

config wifi-device 'radio0' #Esde dispostivo es de la red de 5Ghz, no la uso, lo dejo desactivado.
    option type 'mac80211'
    option channel '36'
    option hwmode '11a'
    option path '1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
    option htmode 'VHT80'
    option disabled '1'

config wifi-device 'radio1'
    option type 'mac80211'
    option channel '11'
    option hwmode '11g'
    option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
    option cell_density '0'

config wifi-iface 'wifinet0'
    option device 'radio1'
    option mode 'sta'
    option network 'wwan'
    option ssid 'SSID_RED_EDUCATIVA'
    option encryption 'psk2'
    option key 'PASSWD_RED_EDUCATIVA'
Conectamos el interface de red wwan/radio1 indicando la contraseña y clave de la red educativa. Esto lo adaptarás según la wifi que quieras usar de tu centro. El DLink se conecta, autentica y recibe una IP por DHCP. Para facilitar la gestión recomiendo que la tarjeta wifi tenga configurada una IP fija en el servidor DHCP del centro.

Ahora vamos a ver el servidor DHCP:
#cat /etc/config/dhcp
config dnsmasq
    option domainneeded '1'
    option boguspriv '1'
    option filterwin2k '0'
    option localise_queries '1'
    option rebind_protection '1'
    option rebind_localhost '1'
    option local '/lan/'
    option domain 'lan'
    option expandhosts '1'
    option nonegcache '0'
    option authoritative '1'
    option readethers '1'
    option leasefile '/tmp/dhcp.leases'
    option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
    option nonwildcard '1'
    option localservice '1'
    option ednspacket_max '1232'

config dhcp 'lan'
    option interface 'lan'
    option start '100'
    option limit '150'
    option leasetime '12h'
    option dhcpv4 'server'
    option dhcpv6 'server'
    option ra 'server'
    option ra_slaac '1'
    option ignore '1'
    list ra_flags 'managed-config'
    list ra_flags 'other-config'

config dhcp 'wan'
    option interface 'wan'
    option ignore '1'

config odhcpd 'odhcpd'
    option maindhcp '0'
    option leasefile '/tmp/hosts/odhcpd'
    option leasetrigger '/usr/sbin/odhcpd-update'
    option loglevel '4'
El servidor DHCP local está desactivado tanto en el interface wan como en el lan. Las direcciones IP para los puestos que se conecten por la red cableada llegarán desde el servidor DHCP del centro.

Ahora vemos la configuracion del firewall:
# cat /etc/config/firewall
config defaults
	option syn_flood '1'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'REJECT'

config zone
    option name 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    list network 'lan'
    list network 'wwan'
....
.... esta parte queda sin tocar....
....
config include
    option path '/etc/firewall.user'
Simplemente permitimos todo tráfico (INPUT/OUTPUT/FORWARD) entre lan y wwan. El resto permanece igual.

4. Consideraciones finales.

Varias cosas importantes a tener en cuenta:
  • Usando NAT/Masquerading: hay que recordar que los equipos conectados por cable al DLink están en una red privada, con direccionamiento 192.168.1.X, por lo que aunque ellos tendrán acceso hacia todo el mundo, desde la red del centro no se podrá acceder a ellos.
  • Relayd: en este caso los equipos si están en la red del centro, con IP 172.X.Y.Z y se puede interactuar (ping, ssh, imprimir, etc) con ellos. Pero hemos tenido un problema grave al empezar a trabajar: en nuestro DLink, usando relayd, las respuestas DHCP no llegan. El puesto conectado al interface lan pide una IP, la petición llega al servidor DHCP del centro, se manda un paquete con la IP y al llegar al demonio relayd se pierde. Es un problema documentado en algunos router con OpenWRT y no está solucionado. En el siguiente punto vemos como hacer que funcione todo a pesar de este problema.
  • Relayd: como acabamos de decir, en nuestro DLink los paquetes DHCP llegados de fuera se pierden. Por ello, para que los equipos conectados al DLink mediante red cableada tengan red debemos configurarles la IP, puerta de enlace y DNS de forma estática a mano. Con este trámite todo funciona perfectamente.
  • Velocidad: no olvidemos que todo está conectado a través de un enlace wifi "G" que sería el cuello de botella. En las pruebas realizadas la descarga está entre 5-10MB/s. Esto hace que trabajar con un home montado mediante NFS sea muy lento, por lo que se aconseja (como ya hacemos con los portátiles de nuestros centros) trabajar con usuarios con home local.
  • Si probamos ambos métodos, NAT y relayd, se aconseja resetear la configuración del OpenWRT para empezar desde un sistema limpio cada prueba. Esto se hace con:
    # firstboot
    # reboot -f
    
Y con esto acabamos este nuevo montaje OpenWRT. Conforme vaya probando otras soluciones las iré poniendo aquí, tengo pensado probar a montar algo como un servidor NAS aprovechando el puerto USB 3, por ejemplo.

Out!