La conjura de los necios (III): no Deus, no machina.

Continuamos con lo dicho aquí y aquí.

En esta nota de prensa del pasado 3 de agosto nuestro presuntamente respetable Gobierno proclamaba:

La Consejería de Educación y Empleo sigue apostando por el software libre en la región.
....
De esta primera reunión se ha extraído, entre otras conclusiones, que la instalación de programas propietarios se hará únicamente en los centros educativos donde se detecte una necesidad real para la formación del alumnado. Igualmente, se ha definido un itinerario a seguir para fortalecer la colaboración y el diálogo con este colectivo y velar por los intereses del software libre en nuestra región, que sigue siendo la apuesta firme de la Junta de Extremadura.
En este sentido, la Consejería asegura que un máximo del 9% de dicho presupuesto, se va a destinar a adquirir el software propietario que se usará en las ramas de Formación Profesional que requieran programas específicos, como es el caso de programas de edición multimedia, contabilidad, etc.
....

Respuesta: trola del 15. Como bien dice nuestro Servicio TIC aquí en el apartado "Instrucciones para la recepción e instalación del equipamiento" el equipamiento viene con arranque dual Ubuntu-Windows y en la mayoría de los casos se deja al libre albedrío y capricho de los usuarios con que sistema arrancar. Si se aplicase la misma política en los comedores escolares mis hijos estarían encantados de poder comer salchichas con ketchup todos los días.

El que un político diga que eso de ahí es una vaca lechera y que su partido ama los productos lácteos no vale nada cuando el obrero especializado, que en este caso soy yo, tiene que arremangarse y ordeñarla y se confirma aquello de lo que venía avisando: es un toro y de leche rien de rien.

Bueno, pues dejemos a los políticos intentando salvarnos de sus miedos y ayudándonos a solucionar sus problemas, y vamos a pensar en lo que viene, que hay que generar riqueza rápidamente para pagar la deuda del Reino de España. Está claro que si no se impone el sentido común y el respeto a la palabra dada, nos van a infestar de forma gratuita (es un decir, porque las licencias las pagamos con nuestros impuestos) de Windows y otras hierbas los centros educativos y tenemos que prepararnos para ello.

1. Lo primero es tener en cuenta que el PC típico de un centro educativo no tiene un uso normal: cada día pasan por él diferentes usuarios con diferentes habilidades a la hora de usarlo. Cualquier persona con luces que haya usado un aparato de forma compartida, desde un coche a una cafetera, sabe que la degradación del mismo es mas rápida. Como dirían Sheldon Cooper: la entropía aumenta en proporción geométrica. Da igual que pongas sistemas de seguridad limitando permisos: los usuarios somos muy ingeniosos a la hora de crear caos de forma inexplicable e involuntaria.
   
2. Lo segundo es que al trabajar con grupos, muchas veces vamos a tener que realizar la misma configuración o acción sobre grupos de PC. Es frecuente pedir al administrador instalar una aplicación en un grupo de PC/usuarios, o copiar unas carpetas y crear una serie de accesos directos, por ejemplo.
   
3. Lo tercero es que los Windows tienen la mala costumbre de actualizarse en el peor momento, ralentizando la conexión y a si mismos. La repanocha llega cuando quieres apagarlo y te dice que esperes media hora: una propuesta chispeante si estás en un centro educativo y tienes que dejar el portátil en el armario de carga porque te vas de la clase.
   

Voy a intentar exponer los distintos enfoques que se me ocurren para gestionar una marabunta de Windows en territorio acostumbrado a Linux, donde ya teníamos nuestro OpenLdap, nuestro puppet, nuestros mirror y demás utilidades al coste de 0 euros:

• Hacerlo todo a mano. Administrar los PC uno a uno. Volver a los 80 pero sin Barón Rojo y sin la URSS. Estupendo para los que les guste sentirse como Chaplin apretando tuercas 12 horas al día en la línea de producción de Tiempos Modernos.
• Montarlo artesanalmente en plan hombre pobre: validar los Windows con OpenLdap a través de pGina, crear carpetas compartidas con samba, montar un PDC con samba-ldap, usar Wpkg para instalaciones automáticas..... muy económico si hay un número razonable de Windows pero sospecho que totalmente insuficiente para lo que se nos viene encima. Para mas INRI estas herramientas tapan solo algunos de los agujeros que se avecinan, no todos, sumado a que las utilidades para administrarlos son bastante rudimentarias.
• Montarlo bien y con clase, con un Windows Server y todas las herramientas adicionales. Claro, aquí hay un problema: nos hemos gastado todo el dinero en el coche y ya no hay para gasolina. Nadie entre las mentes pensantes de la Consejería se ha dado cuenta de que para mantener un tropel de Windows hace falta un entorno de servidor Windows y una máquina potente para ejecutarlo, y eso no sale gratis y habría que haberlo incluido en el presupuesto de los lotes. Pueden mirar al cielo esperando que llegue una solución Deus ex machina, pero lo cierto es que No deus, no machina. Es curioso que en los diálogos al respecto se produce un efecto eco:
  
  
  -Necesitamos un Windows Server
  -Vale, compraremos licencias de Windows Server.
  
  Todo esto sin saber que es un Windows Server, cuanto valen sus licencias, sobre que hierros se va a instalar, ni que otras herramientas hacen falta para poder poner en producción y administrar todos los clientes Windows sin morir en el intento. Dan ganas de decir:
  
  -Necesitamos un condensador de fluzo.
  
  A ver que responden. Por supuesto, de licencias de Windows Server no se ha vuelto a decir ni pío.
  
  
  
• Otra solución que planea sobre nuestros cielos es montar todos los Windows en máquinas virtuales dentro de Linux y redistribuir esas maquinas virtuales cuando haya cambios. De esta forma los usuarios pueden usar sus Windows, les haga falta o no (de igual manera que Isabel la Católica se bañaba una vez al mes, le hiciese falta o no) y si los rompen se reparía copiando la imagen del disco duro. No podrían guardar sus datos en local, pero hacer eso en un ordenador compartido en estos tiempos en que existe Dropbox, Google Drive y demás es un comportamiento un poco dejado que merece ser castigado con perdidas de datos periódicas.
  

Y este es el estado del frente a día de hoy. Seguiremos informando conforme vayamos construyendo, one more time, la solución a un problema que no hemos creado nosotros.

Salud.

Debian Jessie: debmirror da warnings del tipo NO_PUBKEY

Bueno, pues ya he migrado el servidor principal del centro a Debian Jessie y cuando lo estaba configurando para que crease y actualizase cada noche mirrors locales de los repositorios mas frecuentes mediante debmirror me he encontrado con que daba avisos del tipo NO_PUBKEY. En principio eso no impide que se cree el mirror, pero como son un poco maniático no me gusta quedarlo así. La solución, contada en el Paso 3 de esta entrada antigua pasa por añadir las claves dentro del directorio /root/.gnupg/... ya que debmirror se ejecuta desde el crontab con el usuario root.

El problema que me he encontrado es que si repetía los pasos dados en dicha entrada había varios repositorios que seguían dando warnings con debmirror. Buscando un poco he encontrado la forma de meter la clave directamente y en un único paso en /root/.gnupg sin que luego se produzcan los warnings.

Imagínemos que el aviso sea NO_PUBKEY CBF8D6FD518E17E1, pues bien, tendríamos que hacer:

# gpg --no-default-keyring --keyring ~/.gnupg/trustedkeys.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys CBF8D6FD518E17E1

De esta manera se importa la clave gpg de CBF8D6FD518E17E1 directamente a /root/.gnupg/trustedkeys.gpg. Usamos el servidor hkp://keyserver.ubuntu.com:80 para sortear el firewall de la Red Educativa, tal como contamos en su día aquí.

En pocos días seguimos para bingo...a ver si puedo contar ya cosas de las pizarras Galneo, que de momento pintan muuuuuy bien.

debmirror deja de funcionar con wheezy-backports

En esta entrada contaba como crear unos mirrors de wheezy-backports y otros repositorios en nuestra red local para permitir una instalación y actualización más rápida de paquetes.

Hoy me he dado cuenta de que hacía al menos 15 días que no se sincronizaba el mirror de wheezy-backports y por tanto tampoco los equipos que se actualizaban desde él, provocando un fallo en pkgsync que acaba interrumpiendo todas las actualizaciones. Lanzando el comando debmirror a mano:

# debmirror -v --getcontent /var/www/mirrors/backports-wheezy/  --timeout=1200 \
--ignore-missing-release --ignore-release-gpg --passive --nosource --rsync-extra=none \
--arch=i386,amd64 --ignore=disks-i386,amd64/ --section=main,contrib,non-free --method=http \
--host=ftp.es.debian.org --dist=wheezy-backports --root=debian

se empezaba a descargar algo pero a los pocos segundos quedaba congelado sine die, sin avanzar nada. Para otros repositorios si que funcionaba debmirror, pero probando para wheezy-backports desde otras redes (para descartar si era problema de mi red) también fallaba.

Después de estar un rato dando vueltas como pollo sin cabeza mi compañero Ricardo me ha dado la solución: añadir el parámetro "--diff none", de tal forma que queda:

# debmirror -v --getcontent /var/www/mirrors/backports-wheezy/  --timeout=1200 \
--ignore-missing-release --ignore-release-gpg --passive --nosource --rsync-extra=none \
--arch=i386,amd64 --ignore=disks-i386,amd64/ --section=main,contrib,non-free --method=http \
--host=ftp.es.debian.org --dist=wheezy-backports --root=debian --diff=none

O modificando el script de creación del mirror, quedando:

#! /bin/sh

debug="$@"
arch=i386,amd64
base=/var/www/mirrors
.....
.....
destdir=$base/backports-wheezy
dist=wheezy-backports
section=main,contrib,non-free
allopt="$debug --timeout=1200 --ignore-missing-release --ignore-release-gpg --passive --nosource --rsync-extra=none --arch=$arch --ignore=disks-$arch/ --section=$section --method=http"
defopt="$allopt  --host=ftp.debian.org --dist=$dist --root=debian --diff=none"
debmirror -v --getcontent $destdir/ $defopt

La causa, según cuenta Ricardo, es que para no se tenga que descargar el Packages entero por pequeñas modificaciones hay repositorios que usan archivos diff, conteniendo sólo los últimos cambios. Este método ha dejado de funcionar bien con debmirror, pero con diff=none le dices que ignore dichos archivos diff. ¡Gracias, Ricardo!.

Lo que voy a echar de menos los mirrors cuando los Windows que nos quiere poner la Junta de Extremadura empiecen a actualizarse de forma masiva en los centros educativos. Será la fiesta del bit. Aunque siempre podemos, como sugirió algún iluminado, desactivar las actualizaciones. Entonces será la superfiesta.

Bueno, pues ahí queda eso.

Cargar firmware desde cero a LG Optimus Hub E510 brickeado.

Después de jubilar mi LG Optimus Hub se me ocurrió recuperarlo y remozarlo para usarlo como reproductor de podcasts de Colectivo Burbuja, el Vórtice y otras radios online para cuando salgo a andar. Y si además puedo reutilizar hardware en teoría obsoleto para tener un iPod Touch lonchafinista mejor que mejor.

De esta estupenda colección de ROMs para mi móvil, la que mas me gustaba era la LiteHub: una Gingerbread ligera y pequeña (aunque, como cuento en la aventura interior, no va con la SIM de Vodafone pero ya me da lo mismo). En la carga volví a liarme de mala manera y acabé con el terminal brickeado. No entraba ni en el recovery y no había tampoco fastboot mode.

Carajo, había que instalar el sistema desde cero. Como muchos fabricantes (por ejemplo, Samsung con Kies/Odin o los moviles MTK con MTKDroidTools) en LG hay herramientas particulares para cargar la ROM en un móvil cascado (cosas del libre mercado perfecto: cada tornillo necesita un destornillador). Estas ROM son publicadas por LG en formato kdz y la herramienta se llama KDZ Firmware Updater. Los pasos son:

• Descargar e instalar los drivers universales LG "LGUnitedMobileDriver_S4981MAN37AP22_ML_WHQL_Ver_3.7.2".
• Descargar el KDZ_FW_UPD_EN.ZIP de cualquier sitio como éste, descomprimirlo, instalar MSXML y dejarlo listo para ejecutar el KDZ_FW_UPD.
• Descargar el fichero KDZ correspondiente a nuestro móvil y país desde este repositorio. Hay varias ROM KDZ para LG E510, pero la más adecuada es la V10B_00 de Movistar, ya que es la única que se deja rootear mas adelante. Las otras son mas modernas y están protegidas contra los métodos usuales de rooteo.
  

Para cargar la ROM entramos en KDZ_FW_UPD y configuramos:

• TYPE: 3GQCT
• PHONEMODE: DIAG
• KDZ FILE: seleccionamos archivo que KDZ que descargamos antes
• Ponemos el móvil en Emergency Mode: se apaga, se quita la batería un minuto, se pone de nuevo y se pulsa VOL+ y botón de encendido hasta que se enciende con una pantalla donde pone "Emergency Mode". Este es un modo parecido a Fastboot para cargar la ROM KDZ.

• Lo conectamos al USB del ordenador y dejamos que el Windows lo detecte correctamente.
• Pulsamos LAUNCH SOFTWARE UPDATE: empieza el baile en el que se muestran varios contadores en el log y durante el cual se puede reiniciar el móvil varias veces. Hay que esperar hasta que los contadores llegan a 0 y se muestra algo así como "Finished".

Una vez acaba, reiniciamos y nos encontramos una flamante ROM de Movistar, que no nos va a durar mucho. Recordemos que hemos elegido esta ROM entre todas las demás porque es la única que se deja rootear de una forma sencilla. Los pasos ahora son:

• Rootear con UnlockRoot23, según estas instrucciones.
• Una vez rooteada, ya podemos poner CWM Recovery, lo que permitirá cargar luego cualquier Custom ROM. Para ello descargaremos recovery-clockwork-5.0.2.7-e510.img y flash_image.zip y seguiremos el resto de instrucciones del enlace anterior.
• Una vez instalado el Recovery, descargamos la ROM LiteHub y la instalamos.

Un problema de todas las ROMs para este móvil es que tiene solo unos miserables 150-170Mb para aplicaciones de usuario, que se llenan enseguida (especialmente con los datos de las Google Apps, que bajan megas y megas no se con que finalidad). Lo que había hecho hasta ahora era instalar Link2SD para mover a mano algunas aplicaciones a la SD, pero no siempre soluciona las cosas y tarde o temprano sale el temido problema de "Memoria casi llena".

Esta vez quería probar otra cosa: instalar INT2EXT+, que usa de forma transparente la partición en formato "ext2/3/4" de la memoria SD para las aplicaciones que instalemos: con eso consigo tener una digna memoria de 900Mb para aplicaciones de una forma automática y sin más dolores de cabeza.

Al arrancar tenemos la ROM ligerita y minimalista, preparada para poder poner mis podcasts y aplicaciones de senderismo. Un par de apuntes más por si quiero explorar esos caminos en el futuro:

• Truco para meter, de forma bastante arriesgada, el Recovery CWM en un KDZ durante el flasheo.
• Truco para convertir una ROM KDZ en formato apto para flashear con el Recovery CWM.

Bueno, pues como aventuré las elecciones nos dejarían un panorama divertido. Entre eso y mis puñetas varias con Linux y sus variantes no hay manera de aburrirse.

Salud y aguas revueltas.