MarioDebian, mi devlog

Desde hace unos días se ha abierto el plazo para presentación de ponencias y comunicaciones para las II Jornadas de Software Libre y Comunicaciones de Fuerteventura que tendrán lugar el 13 y 14 de abril en esa paradisiaca isla de las Canarias.



Aún recuerdo las I Jornadas [1] [2] [3] a las que tuve el honor de ser invitado y en donde conocí mucha gente que han pasado a ser muy buenos amigos.

Corren rumores, y no debería decir mucho más, que este año el cartel de las ponencias superará las de las anteriores y que los que asistan sin duda no se arrepentirán.

Voy preparando mi pequeño resumen para ver si este año volvemos por allí... ¿de que voy a hablar? pues yo creo que está claro, ¿o no?

Llegaron hoy:



Para el que no sea lector habitual de este blog, estos son dos ordenadores, más concretamente dos terminales ligeros cuyo gasto (tanto lo que valen como lo que gastan de electricidad) es infinitamente menor al de un PC convencional, lo que sale a la derecha es una pila común del tipo AA (las más usadas) para comparar el tamaño...

A la izquierda tenemos un VIA 800 Mhz con 256 de RAM y a la derecha un SIS 200Mhz con 128 de RAM.

Más fotos de los thin client

Debido a que quiero que TCOS entre como paquete oficial en los repositorio de Debian tengo que adaptarme a sus políticas correctamente.

En los paquetes de TCOS han cambiado muchas cosas:

1.- Ya no existen paquetes tcos-discover2, tcos-opengl-libs, etc... porque violan la política de licencias de debian.

2.- Ya no existen paquetes para soporte PXES o LTSP, si alguien lo necesita, que pregunte como volver a generarlos.

3.- Discover pasa a ser dependencia fuerte por lo que se desinstalará discover1. En Debian no debería haber problemas y en Ubuntu tampoco, aún así, si desinstala algo importante (ubuntu-desktop, xserver-xorg, etc...) dad el aviso para informar del bug a quien corresponda.

4.- Cambian las rutas de casi todo....

En debian no puede haber paquetes que tengan archivos en /tftpboot ni en /opt/ por lo que he movido todas esas cosas a /var/lib/tcos

Durante la actualización se os informará que borréis esos directorios viejos /tftpboot/tcos y /opt/tcos.

Podéis hacer una copia de seguridad si queréis y después de borrarles reconfigurar el paquete gentcos:

dpkg-reconfigure gentcos

La salida correcta debería ser algo como esto:
================================
Found TFTPBOOT dir at /tftpboot
INFO: /tftpboot/tcos is a symbolic link, all OK.
================================

La variable TFTPBOOT es leída de la configuración del servidor ATFTPD si lo tenéis configurado de otra manera la raíz del tftp será la que hayáis indicado.

Importante, si no borráis esos directorios TCOS seguirá funcionando pero con las imágenes de arranque viejas, las nuevas no estarán disponibles.

Para los que tenéis terminales con menos de 32 Mb debéis configurar el servidor NFS, archivo /etc/exports:

ANTES:
/opt/tcos 192.168.0.0/255.255.255.0(ro,no_root_squash,sync,no_subtree_check)

AHORA:
/var/lib/tcos 192.168.0.0/255.255.255.0(ro,no_root_squash,sync,no_subtree_check)

Acordaros de reiniciar el servicio después:

/etc/init.d/nfs-kernel-server restart
o
exportfs -ra

He subido los nuevos paquetes al repositorio a la sección experimental, si usas TCOS y quieres colaborar probando la actualización tienes que añadir un repositorio en tu sources.list:

# repositorio para debian
deb http://cls-tcos.forja.rediris.es/repos unstable main

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

NOTA: Hay que dejar los dos (en experimental no están todos los paquetes), para Ubuntu, lo mismo pero añadiendo experimental.

Hay más información (en inglés) en el documento UPGRADE.debian.

Gracias a la gente de debian-devel-spanish por los consejos, ahora los paquetes son casi lintian limpios (me faltan 3 o 4 páginas man) en breve prepararé un ITP y un RFS. Si alguien se anima a esponsorizar la subida que contacte conmigo.

Hasta no hace mucho tanto LTSP como PXES usaban dos arquitecturas de sonido muy semejantes (ESD o NASD), el sonido viajaba entre el servidor (donde se ejecutan los programas y se generan los sonidos) hasta el terminal de una manera más o menos sin comprimir.

Esto provoca que a partir de cierto número de terminales el sonido constante (escuchar música) consuma casi todo el ancho de banda de la red.

Con los desarrollos de nuevas soluciones, en LTSP se han dado cuenta de esto y están empezando a adoptar PulseAudio como servidor de sonido, el cual además de comprimir el «stream» también permite la compatibilidad con otros protocolos.

He preparado un pequeño diagrama, sobre cómo era, y como puede llegar a ser.

La línea naranja indica el cómo era antes, las aplicaciones usaban como plugin de salida «eSound» y a través de la red sin comprimir enviaban el audio que el terminal ligero recibía mediante un servidor de sonido escuchando en el puerto 16001 (normalmente).

ESD tiene varios problemas pero sin duda el más importante es que no es compatible a la vez con OSS y ALSA, de hecho en la mayoria de las distribuciones hay un paquete para OSS y otro para ALSA (en debian/ubuntu libesd0 y libesd0-alsa)

Con la llegada de PulseAudio nacen muchas opciones nuevas, y sobre todo mejor rendimiento ya que el audio va comprimido (pudiendo escoger entre varios algoritmos).

TCOS fue el primero en usar PulseAudio en terminales ligeros (allá por verano del 2006) y ha demostrado ser una de las opciones más viables. Los problemas vienen cuando intentamos que el montaje sea estandar para todos los equipos, mezclando OSS y ALSA en la misma red.

Con ALSA y PulseAudio (zona lateral derecha del esquema) es muy sencillo, el programa reproduce a través del plugin PulseAudio, y mediante un protocolo propio se envía por red el audio, el terminal que tiene un servidor de sonido recibe el «stream» y lo manda a la tarjeta de sonido.

Con OSS la cosa se complica. PulseAudio puede autodetectar tarjetas de sonido de cualquier tipo, pero hace cosas extrañas con las tarjetas antíguas, como por ejemplo empezar a reproducir y si alguien accede al dispositivo /dev/dsp se congela y hay que reiniciarlo.

Tenemos dos opciones:

• Cargamos el módulo oss y bloqueamos todo acceso al dispositivo /dev/dsp
• Arrancamos ESD sobre /dev/dsp y cargamos el modulo de redirección esound-sink, esto lo que hace es configurar la salida de PulseAudio como la entrada de ESD.

Aunque parezca mejor solución usar sólo un servidor, la ventaja de usar dos es la estabilidad, ya que PulseAudio no se lleva demasiado bien con OSS directamente, el inconveniente es el aumento de requerimientos (no mucho)

Otra de las cosas que he descubierto con estas pruebas es que amixer, (mezclador de niveles de volumen en consola) es sólo compatible con ALSA, por lo que no disponemos de ninguna herramienta que suba el volumen de 0 para OSS, aunque creo que por defecto al cargar el módulo se ponen al 67%... Supongo que tendré que ir pensando en otro mezclador como aumix.

Todas estas pruebas de compatibilidad con OSS nacen de la necesidad de tener sonido en el ya famoso MicroClientJr que compramos hace tiempo y que en su día me dí por vencido para hacer funcionar. Ahora mismo lo tengo conectado como terminal ligero con TCOS y el audacious de mi portátil suena por sus altavoces ;)

El driver de sonido se llama sis7019, por lo visto funciona hasta el kernel 2.6.18, en el 2.6.19 habrá que volver a investigar como parchearlo. He subido las fuentes a mentors.debian.net por si algún DD quiere patrocinar la subida. El paquete deb crea un paquete nuevo llamado sis7019-sources y mediante module-assistant crea el módulo para el kernel que se necesite, lo que no acabo de entender es por qué cuando ejecuto algo como esto «m-a -t build sis7019» se compila dos veces, también me pasa con usbvision, otro paquete que tengo en mentors.debian.net (driver de mi capturadora USB de televisión).

Si alguien está interesado en esponsorizar la subida (en castellano suena bastante mal) los dos paquetes son lintian-limpios.

Si, aunque no lo parezca, hoy se cumplen dos años aproximadamente a esta hora, cuando fue el primer post. Como el año pasado ya hice un recuento de los mejores artículos (podéis verlos por número de visitas en el panel lateral) creo que no es necesario que vuelva a repetirme.

Solo quería, una vez más, agradeceros a todos los que habeis participado en este humilde blog vuestra participación ya que un blog sin alguien que lo lea, comente, enlace o discuta no es un blog....

Aprovecho para saludar a toda la gente del planeta Hispalinux, al que estoy añadido hace unos pocos días (gracias Jorge, y Jesús Climent). Siento esta nota tan escueta pero los muchos proyectos que tengo pendientes y mi nuevo trabajo no me dejan casi nada de tiempo libre, aunque estoy preparando el artículo de los artículos, del que espero que en breve pueda dar más pistas.
Lo dicho felicidades y gracias por leerme.

Hoy se ha liberado la primera beta de Protech.

Es una distribución basada en Ubuntu feisty optimizada para ser muy rápida (escritorio Fluxbox) y pensada para aquellos administradores de redes o servidores  y programadores interesados en seguridad.

Realmente no hay muchas distribuciones de este tipo y menos basadas en Ubuntu (que yo conozca) y una de las cosas que más me ha sorprendido es que tiene un montón de utilidades listas para usar. Conozco a uno de los desarrolladores (m4sterguru) mediante gtalk, hemos intercambiado opiniones, trucos y demás para hacer livecds/metadistros desde ya hace unos cuantos meses y hoy me ha avisado para probar su nuevo juguete.

No soy experto en seguridad, ni mucho menos en atacar algo que no es mío, de hecho apenas supe defenderme de un par de ataques que hemos sufrido en SOLEUP... así que con unos buenos manuales es posible aprender que la mejor defensa es atacarse a uno mismo para descubrir vulnerabilidades y corregirlas.

He visto que entre las herramientas de securidad, hay inyectores de SQL, exploits varios, herramientas de análisis forense, ataques de contraseñas, snifers, aplicaciones relaccionadas con la seguridad wireless, etc... en fin una navaja suiza perfecta para llevarla entre nuestros 10 cds más usados.

Pongo un par de capturas de pantalla porque el aspecto gráfico es una de las cosas más trabajadas en esta distro:

Menú seguridad:



Menú aplicaciones:

He comprobado que entra bastante gente a este blog buscando información sobre iTALC, y tengo que reconocer que con TcosMonitor tengo lo que necesito así que hasta hoy no había probado la nueva versión 1.0.0.0-rc2

Me he bajado el fuente, le he quitado los parches de la 0.9.6, he añadido la traducción a español y lo he compilado....

Han cambiado varias cosas, ahora ya no hay «ivs», «lockscreen», «demoviewer», «messageviewer», se han unido todos en uno nuevo «ica», por la misma regla de tres ya no hay «icv», «italc-keygen», sino sólo italc.

Al tema de las claves se añade una nueva forma de trabajar que es con roles (profesor, administrador, ayudante y otros) lo que hace su gestión y permisos mucho más sencilla (es root el que crea esas claves).

Como se puede ver en las capturas quedan muchas partes en alemán (el archivo de tradución es de inglés a otro idioma y he tomado como plantilla el que ya existe en alemán).

UPDATE 14 feb 2007: si quieres colaborar con la traducción, entra en el trac/wiki de iTALC

Un detalle que no me gusta un pimiento son los globos esos de KDE que ponen la CPU al 99%, menos mal que se pueden desactivar (traducirlos es otro tostón).

IMPORTANTE

Como la traducción es bastante larga y no tengo demasiado tiempo, PROPONGO desde aquí que alguien con soltura en traducir documentación técnica de inglés a español me eche un cable con esta, como agradecimeinto prepararé el paquete deb y mandaré el «debianizado» al equipo de Debian Edu que son los responsables de la anterior versión para que lo actualicen en los mirror oficiales de debian. De paso también se lo mando al autor Tobias como ya lo hice con la anterior.

Si alguien se anima que contacte conmigo por medio de correo electrónico o dejando un comentario en este hilo.

Ah !! Esas capturas son sobre un equipo con TCOS que ya soporta esta nueva versión (y que ocupa bastante más por cierto...)

No asustarse !!! no me he pasado al lado oscuro.

El título puede parecer un poco exagerado pero realmente es así.

Acabo de hacer el commit en TCOS para soporte de rdesktop (RDP). Realmente ha sido muy sencillo (hooks-addons/rdesktop).

El problema más grande ha sido instalar Windows MalaVista (AKA BadVista) en un Vmware Server, desde casa, con una imagen ISO y el instalador del MalaVista emperrado en que le diera los drivers del cdrom virtual antes de instalar.

Como de soluciones raras estan los sistemas operativos propietarios, he tenido que instalar primero Xp, actualizar (sin mantener XP) a MalaVista, crear un disco duro donde he copiado los drivers de vmware en otra máquina virtual y «enchufar» el disco para que instalase el driver de red (el del cdrom sigue sin ir...) La ventaja de usar Vmware es que el servidor de terminales si tiene suficiente RAM y CPU puede servir sesiones remotas Linux o Windows (de éste último más bien pocas porque consume bastante por usuario).

Rdesktop funciona bastante bien con conexiones lentas siempre que no se abusen de los efectos gráficos (umm wait !!!) que he tenido que desactivar ...

Bueno con este pequeño añadido creo que se puede pensar en migraciones de oficinas donde dependan de software exclusivo para Windows... (ya no hay disculpas)

Creo que redirecciona el sonido (al menos eso pone en el mezclador) lo que ya no se es como recogerlo desde el terminal. Los soportes extraibles USB, disquetes y demás no funcionan a menos de una forma tan sencilla (quizás usando SAMBA). También he leido que es posible ejecutar aplicaciones windows sueltas sin ver el escritorio completo, o al menos eso dice el man de redesktop. Tanto Windows Xp como Windows MalaVista permiten mediante lo que se conoce como compartir escritorio que se conecte un usuario simultáneamente. Para más usuarios hay que usar Windows 2000 o 2003 Server con Terminal Server.

Las pruebas las empecé ya hace un tiempo con un Windows 2003 server, pero en la universidad sólo me han facilitado las claves y los datos del contrato de campus, pero no me han dicho como activar el Terminal Server por lo que si algún alma caritativa sabe, agradecería el comentario (la web de microsoft me da un error 0x01) y desde el teléfono de activación me piden enviar por fax no se que gaitas !!! manda narices que sea más fácil piratearlo que usarlo legal, claro, así les va...


UPDATE:

Dos capturas para los incrédulos:





Para que arranque con windows hay que añadir al cmdline «startx=W rdesktop=xxx.xxx.xxx.xxx» Siendo las XXX la dirección IP ( o nombre de la máquina ) con un windows.

La ruleta de la fortuna habla sobre debian.

Ánimo a todos los DD que ya debe estar al caer....

Esta mañana según he llegado a casa tenía un sobre con matasellos de Polonia y al abrirlo ha aparecido esto:



Tres revistas Linux+ en las que sale publicado un artículo, bastante completo sobre terminales ligeros basados en TCOS.

Gracias a su redactora jefe: Paulina y gracias a Luis por el contacto !!!

Pillaos una antes de que se agote en vuestro kiosko favorito.