MarioDebian, mi devlog

Acabo de subir al repositorio y anunciar en la lista que ya se puede usar (faltan aun varias cosas por programar) la primera versión del panel de control web de terminales ligeros para redes TCOS.

Es decir, viene a ser el TcosMonitor del que tanto he hablado por aquí pero accesible desde un navegador web ya sea dentro del aula como desde cualquier parte de internet. LTSP chúpate esa!!!

Instrucciones para instalarlo:

1.- Añadir el repositorio expermiental:

deb http://cls-tcos.forja.rediris.es/repos experimental main

(hay muy pocos paquetes en experimental por lo que no se os actualizará nada)

2.- Instalarlo:

# apt-get update
# apt-get install tcosphpmonitor

(por dependencias instalará un servidor web apache2/apache y php4 junto a smarty)

3.- Reiniciar apache si ya lo tenías instalado de antes:

# /etc/init.d/apache* restart

4.- Abre el navegador y entra en http://localhost/tcosphpmonitor
(se puede entrar desde otros equipos sin problemas)

5.- Datos importantes:

usuario: admin
contraseña: admin

Nada más entrar vete a la pestaña preferencias y configuras todos los datos, ese usuario y contraseña que te vuelve a pedir es el que se usa en tcosmonitor y que suele ser root:root.

Estos datos se pueden cambiar en /etc/tcosphpmonitor/tcosphpmonitor.conf

6.- La interfaz está disponible es Español (es_ES) y en inglés. Si no la ves en español y quieres verla, añade el idioma es-es a tu navegador. Hablando de navegadores, en internet explorer no funciona (para variar).

7.- Sino tienes un aula de terminales ligeros con TCOS puedes probar la demo que tengo en mi servidor de pruebas:

http://idefix.eup.uva.es/tcosphpmonitor

Por favor, no abuséis de la confianza o tendré que cambiar las contraseñas.

Estos días sin duda están siendo bastante productivos, ya he conseguido que la versión web de TcosMonitor, bautizada de momento como TcosPHPMonitor, haga capturas de pantalla al equipo seleccionado, y para prueba un pequeño video grabado con byzanz:



Lo que he tenido que programar es lo siguiente:

• He añadido soporte gettext tanto a PHP (muy sencillo, como a smarty (basándome en un array de traducción PHP, como en Javascript, también basado en PHP) esto ha sido una idea feliz que hace que el archivo de traducción *.po contenga todas las cadenas traducibles de la web.
  
• Una clase Javascript (dyntable.js) que dibuja una tabla con todos los datos de los equipos (estos datos se obtienen de una petición Ajax).
• Otra clase Javascript (dynmenu.js) que genera un menú de acciones por equipo.
• Clase PHP (localdata.class.php) que recoge los parámetros locales de todos los terminales ligeros (bastante mejorable).
• Un wrapper para que las llamadas a AJAX devuelvan lo que deben.
• Un pequeño wrapper para acceder a las capturas de pantalla (img.php). Los mini servidores web (busybox httpd) de donde tomo las capturas que se ejecutan en cada terminal sólo son accesibles desde el servidor por eso he tenido que programar este wrapper para que el servidor lea la captura y pueda recogerla desde la web.
  

Cosas por hacer:

• Implementar autenticación mediante usuario y contraseña y posiblemente varios niveles de entrada: administrador, profesor, invitado.
• Mejorar el systema de sockets de PHP y añadir tiempos máximos de espera (apache y iceweasel se tuestan si se desconecta un equipo a lo bestia)
  
• Implementar la pestaña preferencias y guardar los datos en una cookie o en un archivo de texto en el servidor (prefiero no añadir la dependencia de base de datos de momento).
• Programar el resto de las acciones del menu y añadir las que faltan.
• Añadir el menú de opciones las acciones para todos los equipos.
  
• Programar un pequeño wrapper dbus para los mensajes, ejecutar aplicaciones y ver procesos por cada usuario.

Estoy abusando en exceso de AJAX, ya que la web sólo se carga al principio (~140Kb), y todo lo demás son llamadas asíncronas. Quizás no sea buena idea pero también me está sirviendo para adentarme un poco en las tripas de Javascript avanzado. Pensaba que todo me iba a resultar más complicado pero visto lo visto, las cosas no son dificiles sino que llevan más o menos tiempo.

De nada sirve que desarrolles o colabores con el mejor proyecto de software libre del mundo si luego tus políticos no son capaces de darse cuenta que estan vendiendo lo único que tiene un pueblo que son sus ciudadanos a una empresa.

Por esto y por dar más bombo a este importante asunto desde este blog muestro todo mi apoyo a la nueva junta de Hispalinux.

Y es que el martes que viene se aprueba la LAECAP. Básicamente (no me lo he leido entero) se trata de que todos los ciudadanos y empresas podamos acceder en igualdad de condiciones a la información generada por la administración y que el software que se desarrolla en la adminstración se pueda auditar para así no desarrollar el mismo programa 17 veces, 52 o en el peor de los casos otra más por cada ministerio. También se pide que la documentación generada se archive en estándares abiertos que no impidan acceder a ellos sin tener que comprar licencias de software privativo.

Más información:

Nota de Hispalinux

Blog de Juantomás

Blog de Ramón Ramón

Blog de Fernando Acero (donde he tomado prestado el banner)

Nota en Barrapunto

Levo un par de días bastante cabezón con una idea que surgió en la lista de TCOS.

Resultaría genial si se puediese ejecutar TcosMonitor pero sin depender de tener python, GTK u otras mil cosas por lo que he pensado convertirlo en aplicación web.

Ya tengo algo a medio masticar (hace algunas cosas como ver clientes conectados), se puede ver un screencast pulsando en esta imagen:



Dura apenas 10 segundos, pero el bucle es infinito...

La idea es que tenga el máximo de funciones compatibles con la herramienta gráfica TcosMonitor aunque algunas como las relaccionadas a DBUS resultarán un poco más complicadas.

De momento estoy usando y abusando de todo lo referente al famoso Ajax, es decir, llamadas asíncronas con javascript para recargar datos, y JSON para enviarlos desde el servidor al javascript. Estoy aprendiendo a hacer clases y prototipos en javascript y aunque no es muy complicado en algunos momentos tiene su miga. Por parte del servidor uso PHP, llamadas al terminal mediante las funciones XMLRPC, y llamadas al sistema.

El código fuente está en el SVN pero aún no es usable por lo que no habrá paquetes hasta que sea más útil.

¿Alguien se apunta a programar en PHP y Javascript?

Y es que esta frase tan rara es del todo cierta.

He programado yo sólo en TCOS durante un montón de tiempo y los fallos los iba descubriendo mientras lo probaba en multitud de equipos así como las mejoras que eran formuladas por medio de algún compañero de la universidad en los ratos libres...

Desde hace unas semanas el tráfico en la lista de TCOS ha crecido muchísimo y es ahora cuando el proyecto empieza a avanzar a pasos agingantados (más si cabe) y a generar una verdadera comunidad detrás que, colaboran, informan de problemas o símplemente piden ayuda, esto me ha hecho reestructurar partes del código, facilitar otras o simplemente añadir algo que parece una tontería pero que ayuda mucho.

Animo, desde aquí, a todos los usuarios de TCOS que se subscriban a la lista para así recibir aún más "feedback".

De paso quería comentar el tremendo cartel que se está preparando para las II Jornadas de Software Libre y Comunicaciones de Fuerteventura entre los que destacan:

* Ramón Ramón: Vicepresidente de Hispalinux
* Juan Jesús Ojeda (AKA Juanje): Desarrollador de Guadalinex (Emergia) y principal promotor de lo que en su día fue metadistros hoy llamado Unidistro.
* Agustín Benito Bethancurt: Grupo CPD de las Palmas, Ejercicios Resueltos.
* Juan José Cabrera: TELEMAX
* Rodrígo Salvador de la Concha: Responsable de comunicación CGA de la Junata de Andalucía
* Jesús Espino: Vocal de Hispalinux, y desarrollador de varios sistemas como gendist.
* Alberto Morales, Luis Cabrera: GULIC
* Rubén Díaz: Adminsitrador de Linux 120%
* Antonio Ismael Olea: Consultor y miembro de Hispalinux (y que está en varios planet que suelo leer), Almeria
* David Gascón: Desarrollo LIBELIUM, Zaragoza
y el que escribe: Mario Izquierdo.

La verdad que me muero de ganas por conocer a todos y en particular a Juanje y Ramón, ya que debido a una serie de causas que no vienen al caso nunca hemos acabado de coincidir... y hemos intercambiado muchos de correos y conversaciones.

Quizás me haya adelantado poniendo nombres que aún no vienen en la web oficial por lo que se supone que los que he añadido yo, aún no están 100% confirmados. Luis no me mates !!!!

Nos vemos en la isla.

Llevo unos días recordando experiencias pasadas con gentoo, ahora que empieza el calor me he metido a compilarme una gentoo en una máquina virtual vmware.

Ya tengo Xorg, gdm, xfce4 y cuando me disponía a emerger mozilla-firefox me he encontrado con esto:

* checking ebuild checksums ;-) ... [ ok ]
* checking auxfile checksums ;-) ... [ ok ]
* checking miscfile checksums ;-) ... [ ok ]
* checking firefox-2.0.0.2-source.tar.bz2 ;-) ... [ ok ]
* checking mozilla-firefox-2.0.0.2-patches-0.5.tar.bz2 ;-) ... [ ok ]
* checking mozilla-firefox-2.0.0.2-es-ES.xpi ;-) ... [ ok ]
* You are enabling official branding. You may not redistribute this build
* to any users on your network or the internet. Doing so puts yourself into
* a legal problem with mozilla foundation


Joer, mucha gente ha criticado a Debian por cambiar el logo y el nombre a firefox iceweasel (a todo esto el logo de Debian es mucho más guapo, sobre todo la versión azul), ¿nadie se ha dado cuenta que gentoo no permite (y/o aconseja) distribuir los binarios?

Allá cada uno con su conciencia.

Aprovecho para agradecer todos los comentarios sobre los paquetes de TCOS en Debian, la mini-encuesta me ha servido para afianzar más aún mi idea de paquete independiente. Intentaré entrar a Debian por otras puertas (o quizás pruebe en Ubuntu).

Esta tarde he estado terminando de limpiar el paquete principal de TCOS (initramfs-tools-tcos) para que sea aceptado en Debian. Yo pensaba que esto sería la parte más complicada de todo, pero no, ahora viene convencer a la cominidad que lo admitan como paquete nuevo.

Lo he subido a mentors.debian.net y he mandado un ITP, bug#414412 y para mi sorpresa ha aparecido uno de los grandes en Debian y Ubuntu: Matt Zimmerman...

Como era de esperar (Matt ha sido y no se si sigue siendo colaborador del proyecto LTSP) me ha propuesto que intente crear un parche para LTSP ya que desde el proyecto se vería con mejores (o al menos distintos) ojos, que LTSP por fin no dependa de un servidor NFS.

Esto mismo me pasó hace unos días en la lista de correo de debian-live, ya que alguien andaba buscando una solución como PXES pero sin ser PXES y fue entonces cuando lance una minipresentación del proyecto... uno de los consejos que me dieron era que intentase hacer un parche sobre el paquete casper.

Y pienso yo, ¿tan dificil es aceptar un nuevo paquete cuando la funcionalidad es buena y añadirlo a uno existente complica las cosas para los desarrolladores de ambos proyectos?

Supongamos que me pongo a parchear LTSP, y consigo un parche que haga que la construcción de las imágenes de arranque (ltsp-build-client) acepte un parámetro (llamémosle --tcos) que en vez de hacer un debootstrap e instalar una debian/ubuntu mínima con X, instale todas mis cosas. ¿Qué honesto desarrollador de LTSP aceptaría tal engrendro? LTSP lleva desarrollando una tecnología de terminales ligeros un montón de años y ahora no puede llegar un chavalillo que sabe programar lo justito y enseñarles a hacer las cosas de otra manera.

¿Cómo convencer al groso de los que toman decisiones de aceptar algo nuevo en Debian que, es mejor (creo yo), que de momento LTSP y TCOS sean dos proyectos distintos?

No me niego (todavía) a intentar hacer el parche, pero dudo que si lo consigo TCOS sea aceptado como parche de LTSP, más cuando nació de cero para mejorar las muchas carencias que tienen LTSP o el ya obsoleto PXES.

TCOS ha empezado a tener varios (muchos??) usuarios y es ahora cuando realmente tengo que mejorarlo para que sea una decisión dificil elegir entre LTSP, PXES, ThinStation o mi proyecto. De hecho estoy haciendo una web con los "Casos de Éxito".

En un principio y como he dicho en la entrevista que me ha hecho Ramón Castro este mes en TodoLinux, fue mi venganza contra el Google Summer Of Code del año pasado, el problema es que una venganza se está convirtiendo en un gran proyecto donde a través de mi empresa (Consoltux) me puedo dedicar a instalarlo y mejorarlo en entornos reales (ya tenemos varios colegios preparados para instalarlo en aulas de primaria e infantil) y he estado jugando muuuucho con terminales ligeros de verdad (EPATEC eTC3800, eTC2300), de hecho he conseguido que el eTC3800 este 100% soportado en TCOS (incluida aceleración gráfica), ahora ando buscando otras alternativas... he visto unos monitores TFT con terminal ligero incluido que tienen incluso wireless.

En fin, que no se que hacer con TCOS, si rendirme y seguir manteniendo un repositorio externo a Debian y 100% controlable o convencer con mi pésimo inglés a la comunidad Debian que TCOS merece la pena que esté sin ser mezclado con nadie. ¿Ideas, sugerencias?

Llevaba bastante tiempo sin comentar las mejoras de TCOS y el camino para que pueda ser adoptado dentro de Debian. Poco a poco las cosas se van solucionando.

El log de cambios de la versión experimental crece a pasos agigantados:

• Se han solucionado los problemas con tarjetas de sonido con drivers raros (OSS) como el del sis7019, de momento la solución es lanzar esd sobre el dispositivo /dev/dsp y pulseaudio sobre esd.
  
  
• Se ha añadido un sistema de caché que evitará la generación de aquellos antiguos paquetes que antes usaba (tcos-discover2, tcos-opengl-libs, etc...)
  
  El cache funciona de la siguiente manera:
  1.- Se ejecuta apt-get install --reinstall --print-uris -f -y paquete y esto nos devolverá la URI (url local o remota) del paquete
  2.- Se descarga (con wget por ejemplo) y descomprime en /var/cache/tcos/packages/paquete
  3.- Si esta programado para hacerlo se buscará en esa ruta los binarios para meterlos en la imagen cuando se necesite.
  
  El comando para hacer esto sería:
  
  # gentcos -instpkg esound
  
  ¿Para qué sirve?
  Pues imaginamos que por ejemplo tenemos esound instalado, para instalar pulseaudio-esound-compat se desinstalará este primero por lo que es hipotéticamente imposible tener los dos instalado a la vez. Si los cacheamos no tendremos dependencias y podremos usar los dos a la vez dentro de TCOS.
  
  
• Se ha mejorado la autodetección de arranque desde dispositivos locales, es posible arrancar un terminal desde cualquier partición de un disco duro (ext3 o vfat) como desde una memoria USB, antes sólo desde hda1
  
  
• He puesto los permisos a tcos.conf a 600 ya que contiene la contraseña de administración de terminales, supongo que debería pedirla en vez de guardarla... ¿ideas?
  
  
• He actualizado a la versión 2.6.18-4-486 por defecto
  
  
• Se ha mejorado el control remoto de sonido, en el que ahora es compatible tanto ALSA como OSS (mezcladores: amixer, aumix)
  
  
• Ahora se usa socket.gethostbyaddr('xx.xx.xx.xx') para resolver el nombre de equipo antes de buscar en /etc/hosts o en /etc/dhcp3/dhcpd.conf
  
  
• El usplash de TCOS se compila desde fuentes y están soportados a la vez tanto el usplash de ubuntu (0.4) como el de debian (0.3)
  
  

Todas estas mejoras están en la rama experimental de TCOS, para disfrutar de ellas hay que añadir al sources.list (no borrar la otra línea de TCOS) No asuste el nombre de experimental, podría haberlo llamado de mil formas...

# tcos experimental packages
deb  http://cls-tcos.forja.rediris.es/repos  experimental  main

Como ya he comentado anteriormente la actualización de la rama estable puede ser un poco problemática así que mejor leer y seguir los pasos documentados en el UPGRADE.debian

Tengo que mejorar la detección de la ruta que se usa para el servidor TFTPD pero en la mayoría de los casos debería funcionar sin problemas. En unos días espero tener los paquetes completamente limpios y mandar la petición para que sean incluidos en Debian.

Aprovechando las mejoras he estado rediseñando SOLEUPIX-tcos, distrubución live que lleva configurado el servidor de terminales TCOS, la mejora más significativa quizás sea que lo he convertido a USB-live, es decir, en un pendrive tenemos preparado el servidor de terminales con el podemos hacer funcionar un aula completa desde el. Será presentado en las I Jornadas de Software Libre y Comunicaciones de Fuerteventura.