MarioDebian, mi devlog

Llevo todo el día pensando en las formas de hacer funcionar TCOS sobre wireless y así evaluar el rendimiento.... y por fin he conseguido arrancar un terminal ligero sobre wireless...

Ingredientes:

• El ubuntu edgy de mi hermano (Pentium IV 3.2 GHz 1Gb RAM y tarjeta wireless con chip atheros ~ madwifi)
• Kernel 2.6.17-10-generic (el que viene en ubuntu) + linux-restricted-modules (por el driver madwifi que no es libre del todo)
  
• Copia del SVN de initramfs-tools-tcos (0.57-1svn200061227)
• Router de YACOM wireless (3Com OfficeConnect blanco con 2 antenas, modo protegido de wireless: WPA TKIP)
• Mi portatil con debian SID, servidores: DHCP TFTP y XMDCP activado en el GDM

Instalamos los paquetes de tcos en la ubuntu y configuramos /etc/tcos/tcos.conf cambiando estas variables:

TCOS_KERNEL="2.6.17-10-generic"
TCOS_WIRELESS_MODS="madwifi"
TCOS_WIRELESS_ENC="WPA"

El resto de la configuración se puede dejar como está. Lo que estamos haciendo es cambiar el kernel al que usa ubuntu, decirle qué drivers wireless vamos a usar (madwifi es un alias para cargar ath-pci, ath-hal y otro puñado de módulos) supongo que funcionará también con ipw2200, ipw2100 (tenemos que tener el firmware en /lib/firmware), con ndiswrapper lo voy a tener un pelin más crudo ya que el programa ndiswrapper está escrito en perl y no es mucho plan meter 20 megas de perl y sus módulos en el initramfs...

Una vez tenemos tcos configurado generamos la imagen de arranque:

# gentcos -tftp

Sino tenemos errores (si los tenemos habrá que instalar lo que nos pida) tendremos varios archivos por nuestro sistema, lo que hay que hacer ahora es generar otra entrada al final del menu.lst de grub con este aspecto:

# tcos
title TCOS, kernel 2.6.17-10-generic
root (hd0,0)
kernel /boot/vmlinuz-2.6.17-10-generic ramdisk_size=65536 root=/dev/ram0 quiet boot=tcos wifi=1 essid=MarioDebian server=192.168.0.3
initrd /tftpboot/tcos/initramfs-2.6.17-10-generic
boot


La diferencia entre una entrada de grub normal y esta es que el dispositivo root será /dev/ram0, hay que añadir un tamaño de ramdisk en Kbs (64Mb puede valer) y para que arranque por wireless añadir las siguientes variables:

wifi=1
Le dice al script que configura la red que queremos arrancar por wifi, por lo que se cargaran los módulos que hayamos indicado en TCOS_WIRELESS_MODS y se buscará un interfaz wireless en /sys/class/net/

essid=MarioDebian
Este es el nombre de la red wireless a la que nos conectaremos. En el servidor deberiamos tener un archivo en /etc/wpa_supplicant/*.conf con la clave de la red ya que vamos a usar una red protegida con WPA, si no encuentra ese archivo preguntará por la clave y lo generará cuando arranque.

server=192.168.0.3
Como el router wireless va a hacer de servidor DHCP tenemos que indicarle que nuestro servidor de verdad (el que tiene tftp y gdm) es otra máquina.

Con esto ya tenemos todo listo para hacer la prueba. Reiniciamos y seleccionamos la entrada de TCOS en grub. Si no hay problemas con la clave WPA en más o menos 1 minuto deberiamos estar en frente al gestor de entrada GDM.

Para dar soporte a wireless, simplemente he creado un nuevo hook-addon (extensión) llamada wireless , he tenido algun pequeño problema con las librerías a las que está enlazado wpa_supplicant pero lo he solucionado metiendolas en /lib en vez de /usr/lib (/usr se descarga más tarde y no es accesible cuando se necesita). También he tenido que modificar el script de arranque que configura la red ( 05network ) para poder configurar red por cable o wireless desde la línea de comando.

He hecho unas fotos con el móvil (no tienen mucha calidad pero se pueden leer los mensajes)






En esta se puede ver TcosMonitor funcionando con una sesión SSH al terminal donde vemos el interfaz ath0 (he emborronado la key y las MAC por si tengo algún vecino listo) de paso he probado el sonido (PulseAudio) y parece que funciona muy bien en ubuntu.



Si alguien quiere las imágenes para poder probar TCOS por wireless que me lo diga y las subo junto con un pequeño texto explicando como cambiar la clave WPA.

Quizás los números de versión de TCOS no reflejan la calidad, el trabajo o las horas que llevo metidas en este proyecto pero creo que un buen proyecto debe tener versiones inferiores a 1.0 mientras:

• lo usen cuatro gatos :(
  
• cuando cualquier día se cambian partes importantes no manteniendo compatibilidad con versiones anteriores
• hay cambios casi diarios en el SVN
• nuestro código contiene varios «#FIXME»
  

Aún así los números de versión de TcosMonitor (0.0.16), TcosConfig (0.0.8) y un poco menos tcos (0.56.18) creo que están haciendo un flaco favor al proyecto así que, que nadie se sorprenda si la próxima versión pasa a ser 0.1.1 ó 0.2.1 ...

He estado solucionando unos temas estéticos de las multicapturas (añadir una leyenda en vertical) y he añadido una nueva variable de información, el «uptime» o tiempo que lleva encendido el terminal. No es que sea de gran utilidad pero los terminales ligeros no conviene tenerlos demasiado tiempo encendido por problemas como fugas de memoria de algún programa (no suelen tener RAM de sobra) o calentones, así que mirando esta variable se puede tomar la decisión de que es hora de reiniciar el equipo desde TcosMonitor.

Este es el aspecto con el que quedan las multicapturas (a tres clientes), pronto colgaré otra con más...



El modo multicaptura tarda demasiado (24 equipos más de 1 minuto), ya que cada terminal necesita poco más de 3 segundos para «hacerse una foto», probé a realizar las capturas usando Threads que lanzaba a la vez, pero en python por muchas veces que se instancie una clase no se pueden usar variables distintas de esa clase, así que la solución será crear una nueva instancia de esa clase por Thread, o lo que es lo mismo por cada captura, lo que reduciría el tiempo a lo que tarda python en generar los hilos y esperarlos más tarde (de la misma forma que tengo la clase que hace ping a la red) calculo que de esta forma puede tardar como 10-15 segundos.

Aquí se ve la nueva variable «uptime»:




En mi lista de cosas por hacer están:

• Acabar de mejorar el instalador (permite arrancar los clientes ligeros desde disco duro y así ahorrarnos una buena pasta en tarjetas de red buenas u olvidarnos de los malditos disquetes)
  
  
• Añadir soporte wifi, un buen amigo (Lluís Gras) se le ocurrió la genial idea de arrancar TCOS mediante wireless así que en un par de cruces de emails hemos preparado un pequeño «hook-addon» o extensión para que TCOS pueda funcionar con dispositivos wireless (hay que investigar sobre WEP y WPA)
  
  
• Añadir soporte para clonado de equipos. Idea de Xabi Ezpeleta. Muchos administradores de red conocen GHOST y saben lo que se tarda en reinstalar un aula por red (muy poco), la idea es usando partimage conseguir algo parecido.
  
  
• He recibido más sugerencias, como por ejemplo hacer un paquete de TCOS para equipos instalados y que permita tomar el control de ellos de la misma forma que se hace con clientes ligeros.
  

Los paquetes con las nuevas versiones estarán hoy a última hora o mañana en el repositorio de TCOS.

Felices fiestas a todos.

Una de las últimas cosas que se ma había ocurrido para TcosMonitor es la posibilidad de ver lo que estan haciendo todos los usuarios conectados en una aula TCOS de un vistazo (ya era posible hacer capturas de uno en uno).

Así que aprovechando que el menú de acciones para todos los usuarios era un gran desconocido he puesto un botón en la barra para que aprezcan las acciones para todo el aula y la nueva acción «MetaGranHermano», Capturar todas las pantallas:



He aquí lo que aparece en el htmltextview:



El tamaño de las minicapturas se puede configurar desde las preferencias (por defecto creo que está al 15 o 25% de la pantalla de usuario) he probado a meter las capturas todas juntas (sin saltos de línea pero no hay manera de saber que captura es la de qué equipo, tendré que mirar como lo pongo "más potito", tipo <span> o algo así)

El código está en el SVN pero de momento no hay paquetes....

Si hace unos días publiqué el interés de la Comunidad de Madrid por TCOS, puedo avanzar que se avecina algo bastante más gordo (y eso que lo de la Comunidad de Madrid es muy grande...).

Dentro de poco en sus navegadores o lectores de RSS ;)

Resulta que de vez en cuando, (cuando el servidor del AulaMagna se pone a 100% de cpu) miramos por los jugones que se estan aprovechando.

Hace un tiempo teníamos uno, pero se ha ido reproduciendo como los caracoles hasta tener tres (o más).

Total que después de avisarle, cerrarle el navegador varias veces y el proceso java_vm otras tantas, seguía abriendo el puto juego.

Me he acabado cabreando y he desinstalado java (se que pagan justos por pecadores pero así es la vida)

Uno de estos chicos se ha debido mosquear y le he pillado intentándome juanquear (para hackear no tiene nivel suficiente):



Y es que con TcosMonitor ha sido muy sencillo, pillarlo, avisarlo, recriminarlo y hasta reiniciarle el equipo. Pero llega un momento que la gente se pone demasiado pesada y se deben tomar medidas más drásticas.

Se que no va a leer esto, pero por si lo lee: «Eres un puto lamer jugón de mierda»

El anterior asistente de construcción de imágenes para TCOS tenía las variables justas en el momento en el que fue desarrollado (aún recuerdo aquel fin de semana en el que metí un huevo de horas seguidas).

TCOS ha ido creciendo y han aparecido muchas nuevas variables, por lo que el interfaz había quedado un poco desfasado, el problema es que en contra de las recomendaciones de usabilidad quiero que aparezcan la mayoría de las variables necesarias para que cualquiera pueda personalizar TCOS tanto como quiera. El segundo problema es que son demasiadas variables para mostrarlas todas juntas por lo que he estado rediseñando esa parate del asistente donde salen.

Una de las ventajas de lo mal programado que está es que no hay que tocar ni una sóla línea de pyhton para añadir nuevas variables ya que cuando carga lee todos los «widgets» que empiezan por "TCOS_".

Con dos capturas de pantalla creo que se va a entender mejor:

Este es el aspecto que tenía cuando aún eran pocas variables:



Al crecer el número de variables (no entran todas a la vez en la pantalla) he tenido que ponerlo de esta otra forma:

Por defecto todos los «expansores» están cerrados:



El primero contiene variables de depuración y funcionamiento interno de TCOS.



El segundo es el que indica los servicios que queremos que tenga cada terminal (ssh, inetd) así como el soporte para discover, dispositivos USB, el nuevo instalador, o la utilidad «debootstrap» que permite instalar debian/ubuntu por red sin necesidad de disquetes ni cds.



Opciones gráficas, he añadido el soporte para todos los drivers de Xorg, así como el reciente soporte para OpenGL.



Las opciones de sonido (que aunque no son muchas) se pueden ver en este diálogo (creo que tengo que mover también el volumen por defecto que está en otro paso del asistente...




El último es para acceso remoto al terminal, en este he puesto el soporte para iTALC y VNC.



Los paquetes actualizados están donde siempre, en el repositorio de TCOS.

Hoy hemos estado buscando a algún profesor de la Politécnica para que nos ayudase (más bien midiese él) ***GRACIAS JULIÁN PÉREZ*** el consumo eléctrico de nuestro juguete.

Estos son los resultados (*):

• Proceso de arranque (uso de cpu ~100%): 10.5~11 vatios
• MicroClient en marcha pero en reposo (abriendo programas, navegando....): ~8.5 vatios
• TcosMonitor accediendo a todos los datos (cpu ~100%): 10.5 vatios

(*)
NOTA: Nos ha resultado bastante extraño que la gráfica de consumo de intensidad tenga picos de frecuencia a 100Hz (doble de la tension de red: 50Hz) y esperamos poder realizar las mediciones con otros instrumentos en breve, así como medir también la parte de contínua (que creo que va a 5V). Con esos picos la potencia máxima es de ~160 vatios, que es bastante ilógico mirando el transformador que trae.

Creo que no debería volver a repetir las bondades del software libre, pero en un aula con 25 MicroClient, la factura anual de la electricidad se puede reducir hasta 40 veces sólo por el hecho de usar terminales ligeros de este tipo.

Supongo que este y otros muchos ejemplos como este son los que usaremos para convencer al Rector de la Universidad de Valladolid en nuestra próxima entrevista. A propósito, hoy la Universidad ha firmado un acuerdo con Autodesk por el cual alumnos y profesores podremos usar sus productos de manera gratuita (tipo licencia de Campus), algo que ya hicieron en su día con Microsoft, y que hemos intentado averiguar a cuando asciende pero dentro del presupuesto es cosa de locos buscar algo tan concreto...

Gráficas y fotos de las pruebas de hoy en el artículo extendido. (Más)

Como ya viene siendo costrumbre cada vez que llega un fin de semana un poco más largo de lo normal o un puente, nuestro servidor decide que él tiene derecho a tener vacaciones, y le da un kernel panic justo en el momento que sabe que no va a venir nadie para reiniciarlo.

Total, que pido perdón por enésima vez, tanto a los que suelen visitar este blog como cualquier otra web de SOLEUP, por no haber estado accesible durante el fin de semana. El servidor debe tener tocada la placa, la memoria o ámbas y cuando se le antoja da un panic.

Aunque parte de mi trabajo puede depender si está online el servidor o no, este largo puente (no me he tomado vacaciones) lo he aprovechado para pulir algunas cosas de TCOS, y una de las que más ganas le tenía es al soporte OpenGL para TCOS.

OJO !!! esto no significa que se pueda ejecutar Beryl en los terminales pero es uno de los principios para que algún día funcione. en LTSP hace poco ví que lo habían conseguido, lo que no logro entender es para qué!!!!

Problema GLX:

Cada vez que uno de los terminales arrancaba el protector de pantalla o alguna aplicación a pantalla completa que usase algo de aceleración 3D (ejemplos gcompris, glxgears), se morían las X dando un backtrace relaccionado con glx....

Solución teórica:

Sabía que tenía que copiar algún archivo de Xorg a la imagen de arranque e investigando un poco descubrí que eran exactamente estos tres:

• libGL.so.1.2 ( /usr/lib )
  
• libGLU.so.1.* ( /usr/lib )
  
• libGLcore.so ( /usr/lib/xorg/modules/extensions )
  

Solución práctica:

El asunto podría haberse resuelto copiando directamente estos tres archivos en la imagen sin más miramientos, pero aparecen muchos problemas, el primero, en equipos muy viejos quizás esto sea antiproducente por lo que debería poder activarse/desactivarse, así que he creado una nueva variable en tcos.conf TCOS_XORG_OPENGL.

Otro gran problema es que mucha gente, sin importarle demasiado, instalan drivers propietarios (que son mu malos, malosos!!!) y que sin miramientos sobreescriben esos archivos o incluso en el mejor de los casos los mueven usando dpkg-divert. Así que una posible solución sería mirar donde guarda dpkg-divert los archivos originales......

En la ubuntu de mi hermano con drivers NVIDIA instalados a la debian (module-assistant) sólo he podido encontrar una de las tres, las otras dos tenían un enlace roto. La solución, no era buscar las librerías porque en cada equipo pueden estar en mil sitios dependiendo de la versión, así que lo que he hecho (similar a lo que hice en su día con discover2) es hacer un nuevo paquete con esos tres archivos que se toman de un sistema «limpio» (sin drivers malos, malosos) y en caso de que se detecte que hay drivers NVIDIA o ATI que pida que se desinstalen o que se instale mi paquete extra.

Ahora hay que detectar si tenemos instalado los drivers o no, otras mil formas..... La que se me ha ocurrido es buscar las cadenas en la librería de esta forma:

strings /usr/lib/libGL.so.1 |grep -c NVIDIA (para nvidia)
strings /usr/lib/libGL.so.1 |grep -c -i fgl (para fglrx)

Si esto es distinto de 0 tenemos muchas papeletas que que sea un driver malo maloso y dar el aviso.

Conclusiones:

Parece que ya funciona (más o menos) y que se puedan ejecutar aplicaciones 3D en los terminales, el siguiente paso es poder usar drivers malos malosos, aunque no estoy mucho por la labor, ya que pasamos el cuello de botella a la red... 2 o 3 personas jugando (~30fps) pueden consumir el 80% de una red de 100Mbps.

He estado actualizando los paquetes de TCOS que hay en el repositorio, ahora las distribuciones/versiones soportadas son:

• Debian testing/unstable (usan los mismos paquetes, cuando salga etch haré dos ramas)
• Ubuntu Dapper (6.06) (como es LTS supongo que tendré que darla soporte unos cuantos años, he tenido que actualizar libnotify para tener python-notify)
  
• Ubuntu Edgy (6.10)
• Ubuntu Feisty (7.06)

El repositorio ocupa ~ 63 Mb, (tengo copia en otros dos equipos y lo sincronizo con rsync).

En otro órden de cosas, sigo jugando con prototype y Ajax, mi último juguete es un editor "Inline", es decir, muestra los datos de una tabla de una base de datos y permite editar cada elemento y guardarlo/borrarlo o incluso añadir uno nuevo sin recargar la página. Cuando lo tenga un poco más pulido liberaré el js. Mientras para abrir boca, un screencast:



Es un bucle infinito, la animación dura como 15-20 segundos.

Me ha sorprendido muchísimo la potencia que tiene javascript y en especial con la librería prototype para modificar el DOM de un documento.