MarioDebian, mi devlog

Bitácora de un desarrollador newbie.

Nuevo modelo Multiseat 8840

Hace unas semanas hemos comprado directamente el fabricante (Asia) un nuevo modelo de ZeroClient o también conocido como MultiPoint/MultiSeat: MWS8840

Afortunadamente el chipset es el mismo que el anterior MWS300 y funciona correctamente. Es más, con gran sorpresa veo que los vídeos de Youtube funcionan a pantalla completa Tongue out.

El dispositivo tiene una entrada USB (que se conecta al servidor de terminales)  una entrada de alimentación (5V - 3A), entrada de micro, salida de audio y 4 puertos frontales USB 2.0 (en dos de ellos se conecta el teclado y el ratón). Además este modelo trae una peana para colgarlo en la parte trasera de un monitor TFT o ponerlo en vertical.

Aquí podeis ver unas cuantas fotos. El tamaño de la caja es de aproximadamente 10cm x 10cm

        

En breve lanzaremos desde Thinetic una completa y económica solución comercial con estos aparatos tan prometedores, y todo ello con Software Libre.





Gestión de dispositivos extraíbles en MultiSeat
Hacía tiempo que programar me aburre (según que cosas claro) pero el fin de semana pasado me lo he vuelto a pasar como un niño escribiendo código.
 
Problema:
 
En la Consejería de Educación de la Comunidad de Madrid han empezado a usar un nuevo invento llamado Multiseat (Microsoft lo llama Multipoint) que consiste en unos pequeños aparatos que de una forma lógica vienen a ser un HUB USB que contiene una tarjeta de vídeo, una tarjeta de sonido, y 4 puertos USB, si conectamos varios (pongamos seis) en un equipo automáticamente multiplicamos los puestos disponibles en ese equipo (por USB conectamos un teclado y un ratón a cada Multiseat) (puedes ver algún detalle más en la web de Thinetic Systems)
 
El cómo hicimos andar todo este montaje es otra historia que algún día contaré, pero lo que hoy nos centra es un pequeño problema, y es la gestión de los dispositivos de almacenamiento que se conectan a los puertos USB del Multiseat, para que todos lo entendamos, cuando conectamos una memoria USB se conecta físicamente al servidor (con un HUB USB por el medio) y teníamos que inventar una manera de que sólo pudiera verlo/usarlo el usuario sentado directamente en ese puesto. Ya os adelanto que en Microsoft aún no lo han conseguido (que yo sepa).
 
Solución:
 
En los sistemas basados en Linux durante los últimos años se han venido usando distintas soluciones para el automontaje de discos extraibles (usbmount, HAL, DeviceKit), ahora estamos en la era de UDisk. Es un software que se conecta al gestor de dispositivos del kernel (udev) mediante unas reglas (/lib/udev/rules.d/80-udisks.rules) y crea un bus de sistema (en dbus) donde expone todo lo que encuentra, así las aplicaciones que quieran gestionar un dispositivo sólo tienen que escuchar esos eventos.
 
UDisks permite inhibir el montaje (sigue reconociendo lo que enchufamos pero advierte en dbus que está inhibido y no realiza ninguna acción) por lo que no se montan los dispositivos automáticamente, a este inhibidor se le puede pasar un comando que cuando termine deje de inhibir... un ejemplo de uso práctico es el asistente de instalación gráfico que usa Ubuntu (ubiquity) y que inhibe el montaje de dispositivos (por razones obvias) durante la modificación de particiones y la instalación.
 
Nuestra primera aplicación a desarrollar es un demonio que se conecte al bus del sistema, escuche los dispositivos que se conectan y desconectan, leemos sus propiedades y a partir de ellas adivinamos (por el DEVPATH) en que puesto Multiseat se ha conectado para entonces montarlo con privilegios exclusivos para ese usuario y crearle un icono en el escritorio para que pueda desmontarlo. Este demonio decidí programarlo en python y lo bauticé como multiseat-udisks.py se ejecuta cuando (al arranque) encuentra los puestos MultiSeat (subcarpetas en /dev/usbseat)
 
Ya tenemos solucionado que los dispositivos de almacenamiento se automonten en su sitio y con sus permisos, ahora viene cuando el usuario quiere extraerlo, GNOME crea un icono en el escritorio con nuestro pendrive, realmente no es un archivo y con el inhibidor por el medio no lo va a crear por lo que modifiqué multiseat-udisks.py para que crease un lanzador *.desktop especial con la línea mágica «X-multiseat-desktop=x» siendo x el puesto donde esta montado (subcarpeta de /dev/usbseat ).
 
Para desmontar tenemos dos problemas, primero el usuario no es root y como el dispositivo no está en fstab no le va a dejar desmontarlo, y segundo ese icono del escritorio nos permite abrir el contenido del dispositivo de memoria pero no extraerlo de manera segura (sync && umount) lo primero que se me ocurrió es hacer una extensión para Nautilus (gestor de archivos de GNOME) para que cuando se haga click derecho sobre un archivo *.desktop busque la línea mágica y, si existe, añada una entrada a ese menú derecho del tipo «Desmontar dispositivo extraíble multiseat», cuando se pulse sobre esa opción se llama al proceso de desmontar. Esta extensión (también escrita en Python) la bauticé como nautilus-umount-multiseat.py 
 
Para el problema de los privilegios tuve que programar la tercera ficha de este puzle, una pequeña aplicación en C (instalada con bit SUID) y que eleva privilegios a root para llamar al comando de desmontaje umount.multiseat.c. Muchas aplicaciones de montar y desmontar (instaladas en /sbin) van con el BIT SUID por lo que me parece una manera bastante estandar de hacerlo y más teniendo en cuenta que los usuarios que usan MultiSeat pueden estar en un LDAP.
 
Cuando la extensión de Nautilus detecta que el icono es de un dispositivo conectado a un Multiseat, llama a esta aplicación que eleva los privilegios a root (mediante setuid(0) ) y llama a multiseat-udisks.py con 2 argumentos, el primero es el dispositivo montado (ejemplo: /dev/sdc1 ) y el segundo que se genera dentro del programa C es el UID (identificador numérico del usuario que quiere desmontarlo). El script multiseat-udisks hace una serie de comprobaciones para que los parámetros sean correctos y que el usuario pueda desmontar ese dispositivo (que el punto de montaje le pertenezca) lo desmonta y limpia tanto la carpeta donde se ha montado como el icono del escritorio.
 
El sistema lo hemos probado en varias instalaciones y funciona a la perfección, más tarde convertí el código en paquete *.deb y a instalar en los centros...
 
El motivo por el que me he vuelto a divertir programando es que nadie había hecho algo del estilo y la documentación que podía buscar por internet solo se centraba en el uso de cada herramienta o API por separado por lo que el desarrollo ha sido desde cero hasta algo terminado y funcionando.
 
Siento el tostón técnico pero a algunos nos gusta contar nuestras frikadas Tongue out




Squid 3.0 con soporte a X_FORWARDED_FOR

Cuando se mezcla Dansguardian con Squid en un proxy transparente existen ciertos inconvenientes que es bueno conocer.

  1. Dansguardian escucha las peticiones de la red interna en el puerto 8080, con iptables redirigimos todo el tráfico de salida a este puerto.
  2. Dansguardian pasa su petición a Squid por localhost al puerto 3128.
  3. Squid hace la petición y dansguardian la procesa.

Esto tiene un inconveniente y es que todas reglas acl o delay_pool en squid dejan de trabajar ya que todo el tráfico usa como IP cliente 127.0.0.1.

Existe un parche relativamente antiguo llamado follow_xff (pensado para versiones 2.x) que he reescrito en parte para que Squid3 use la cabecera X_FORWARDED_FOR. El parche se guarda en debian/patches en formato dpatch. Me falta el detalle de que no muestre un mensaje de no reconocer las nuevas reglas, porque funcionar sí lo hace.

Parece que en Debian (#523943) estaba activado, pero solo era un modificador de debian/rules, no había ni rastro de código y también parece que se ha añadido a Squid a partir de la versión 3.1.0.1.

He preparado un repositorio GIT de squid para compilarlo en Debian lenny con el parche y un simple «git-buildpackage».