A Django site.
Agosto 13, 2011
» Actualización de Android en Motorola XOOM

Hace un tiempo me compré una Motorola XOOM con la promoción de Personal. Mi mayor curiosidad era saber para qué me podía servir a mi un dispositivo como este. Dí muchas vueltas para comprarla porque la veía poco útil.

Elegí esta tableta en particular porque traía Android, el sistema operativo más libre (y popular) que conozco para dispositivos móviles… sí, ya sé que está algo lejos de ser bastante libre, pero bueh…

Al tiempo de usarla empezó a tener problemas de software, el cliente de correo que trae crasheaba demasiado seguido y no era la única aplicación que explotaba. Revisando por internet encontré que había dos releases más modernos publicados por Google y mi tableta no los tenía. Lo primero que pensé es que Personal no los había liberado aún, esto fue más bien por desconocimiento del funcionamiento de las actualizaciones en el ambiente Android (sigo sin saber muy bien cómo es, si es que Google libera en su repositorio y todos los dispositivos se actualizan o si esto puede ser manipulado por la compañía de teléfonos o distribuidor del aparato). En fin… la realidad es que estaba clavado en Android 3.0 y ya estaba dando vueltas Android 3.1 e incluso 3.2.

Dado que la tableta es un dispositivo no esencial para mi vida me decidí a actualizarla a manopla.

Como estuve una buena cantidad de horas con esto pensé en escribir un artículo técnico para que otro pudiera hacerlo más velozmente.

Todas estas explicaciones técnicas son para hacer desde un Linux, los usuarios de otros sistemas operativos les puede servir la explicación de cómo funcionan estas cosas.

La tableta parece tener –como las computadoras comunes– dos instancias de booteo, primero ejecutan un software que vendría a ser un “BIOS” y luego cargan el sistema operativo. El “BIOS” de la Xoom está en una región de memoria no escribible fácilmente (por lo menos no encontré cómo, pero eso es bueno, porque de sobrescribir mal esta sección brickeas la tableta y fuiste), este software tiene unas pocas opciones que te permiten:

  • Acceder a la imagen de recuperación (esto es un software que se puede modificar)
  • Ponerla en modo de Fastboot Protocol (esto sirve para cambiar el sistema operativo que bootea la tableta)
  • Y hay un modo RSD que no sé qué es, ni para qué sirve.

 

El cómo…

Lo primero que hay que hacer es tener un cable USB para la tableta que funcione bien (si no tenes uno podes usar el de los teléfonos BlackBerry o Nexus1), también preparar el Linux para que detecte la tableta al conectarla por el cable USB.

 

Preparación de Linux

La preparación del Linux es simple:

sudo touch /etc/udev/rules.d/51-android.rules
echo "SUBSYSTEM==\"usb\", SYSFS{idVendor}==\"22b8\", MODE=\"0666\"" |sudo tee -a /etc/udev/rules.d/51-android.rules
sudo /etc/init.d/udev restart

Con esto Linux ya debería ver la tableta al enchufar el USB, más información y con más detalle sobre esto acá.

Herramienta para cargar ROMs

Luego hay que bajar el software de fastboot para Linux. Hay otro que se llama ‘adb‘ que es muy útil, pero está pensado para hacer bastantes más cosas y para quienes desarrollan aplicaciones para Android.

Como solo se necesita fastboot, lo podes descargar de esta página (que te lo dan todo compiladito). Alternativamente podes bajar tooooodo el SDK de Android para Linux (con sus prerequisitos) y luego compilar los fuentes de fastboot.

 

Bajar ROMs

Motorola publica las diferentes versiones que tiene de Android para tabletas Xoom aća. Yo probé casi todas las ROMs que publican y todas funcionaron en mi Motorola Xoom de Personal (que viene con 3G y wifi), menos la de Verizon. Lo que no sé es si todas las Xoom son iguales a nivel hardware y es el software quien activa el 3G o el wifi. Incluso te da las instrucciones para cambiar las ROM en esa página.

Cada ROM viene con 4 archivos dentro (recovery.img, system.img, userdata.img y boot.img).

Para cargar la ROM lo que hay que hacer es reiniciar la tableta y cuando está prendiendo apretar el botón de “bajar volúmen” (el que está sobre el contorno izquierdo del dispositivo). Cuando aparece la leyenda “Starting Fastboot protocol support.” ya se pueden empezar a ejecutar estos comando:

El clásico WARNING: Aća es donde borras todo y perdes la garantía que tenes del aparato, sabelo porque es exactamente lo que estás por hacer. Además… a no venir con reclamos, si no funciona es tu culpa por hacer cosas que no debes (como no hacerle caso al fabricante ;-) ) y no es mi culpa. A quién se le ocurre??? andar hackeando cosas… no hacer lo que le dicen que hay que hacer y caminar por otra senda que la indicada.

Entonces, primero descomprimis el archivo que contiene la ROM (el que trae los cuatro archivos .img) y luego en modo fastboot protocol ejecutas:

fastboot oem unlock

(y seguís las instrucciones de la pantalla de la xoom, luego se reiniciará nuevamente, de nuevo tenes que apretar el botón para bajar el volúmen y cuando esté de nuevo en modo fastboot protocol ejecutas: )

fastboot flash boot boot.img
fastboot flash system system.img
fastboot flash recovery recovery.img
fastboot flash userdata userdata.img
fastboot erase cache
fastboot erase userdata
#fastboot oem lock (esto no es obligatorio)
fastboot reboot

Al reiniciar va a ejecutar el nuevo sistema operativo y te va a pedir todos los datos que te pidió cuando la compraste y prendiste por primera vez.

Hasta ahora NADA nuevo, porque estas ROMs son las que vienen con la XOOM de fabrica. Si queres la ROM que te permite actualizar (por vía normal, o sea, desde Google) a Android 3.2 tenes que bajarte la ROM del Build HWI69 de esta página. Esta ROM viene con Android 3.0, pero al registrar tu Xoom con tu cuenta de Google empieza a bajarte las actualizaciones (a 3.1 primero y luego a 3.2), pero esta ROM solo es para wifi.

Con esa ROM vas a tener Android 3.2 pero solamente con wifi.

La alternativa a esto es utilizar la ROM de la gente de Tiamat. Usando esta ROM vas a tener Android 3.2 y además ya está rooteada, por lo que no será necesario poner otros boot.img para permitir ejecutar comandos como root.

Para trabajar con esta ROM hay que hacer algo previo que es cambiar la imagen de recovery (recovery.img). La imagen de recovery no es un backup de tu imagen en uso (que te permite restaurar lo que tenías de fábrica), sino que es un “sistema operativo” que te permite instalar otras ROMs, formatear todo, borrar todos los datos de usuario, básicamente te permite tratar de recuperar el sistema.

Hay un “sistema operativo” de recovery que se llama ClockWorkMod que extiende las posibilidades y te permite hacer cosas como instalar una ROM leyendo la microSD (un disco flash que podes poner y sacar de la tableta y no tener que usar el cable USB), algo indispensable para instalar la ROM de la gente de Tiamat utilizando el archivo .ZIP y no el .IMG (que se usa si lo haces en modo fastboot con la herramienta).

Seguí las instrucciones de esta página y vas a poder cambiar el “sistema operativo” de recovery. Una vez hecho booteas en modo recovery (apretas el botón para bajar el volumen 3 segundos después de que aparece el primer logo al iniciar) y desde este nuevo recovery instalas la ROM de Tiamat.

La ROM de Tiamat no reemplaza toooodo, sino que cambia el kernel y algunas cosas más. Si vas a instalar la ROM de Tiamat hacelo teniendo instalado la ROM de fábrica. A mi me pasó que instalando la ROM de Tiamat no tenía forma de conectarme al 3G de Personal. Esto era porque instalé la ROM modificando una base de ROM de Motorola solo para wifi (que no tiene la posibilidad de configurar 3G). Volví todo atrás, puse la versión de Motorola que tiene 3G y wifi para LATAM y al modificar esa base con la ROM de Tiamat pude usar 3G sin problemas.

Todo muy lindo… pero luego de todo esto, todo este tiempo probando cosas y aprendiendo cómo funcionan y bootean estos dispositivos y teniendo Android 3.2 con todos los chiches… el cliente de correo sigue explotando :-D . Pero ya no me importa tanto.

Suerrrrrte! Espero que te sea útil.

 

Páginas útiles:

http://yosoyandroid.com/?p=6957

http://forum.xda-developers.com/archive/index.php/t-1049485.html

Mayo 31, 2009
» Nuevo juguete: HTC Dream G1

Hacía mucho que no me compraba algún chichecito para jugar y usar, dado que ya pasé un buen tiempo usando un NOKIA 5200 (sin romperlo) decidí que podía pasar a otro nivel, salir de la adolescencia torpe de no poder mantener intacto un aparatito; madurar para asumir la responsabilidad de tener algo caro, pequeño de tamaño sin que se me caiga, deje de funcionar en menos de 6 meses de uso (algo que no pude hacer con mis ex-celulares —Motorola U6 y Motorola V3—).

Para el que no está acostumbrado a tener un smart phone, la primer experiencia de uso es molesta, uno lo ve como un teléfono, pero en realidad lo tiene que ver como una computadora o PDA, porque sino las ganas de tirarlo por la ventana son bastante fuertes.

—Pero si yo antes, para hacer una simple llamada, apretaba el botón verde, buscaba en contacto usando los números (único teclado de cualquier telefono) y listo!

Ahora, queridísimo y flamante usuario de smartphone, no es tan sencillo. Por lo menos con el HTC G1 tenes que:

  1. Apretar el botoncito verde
  2. Elegir la solapa correspondiente (tenes cuatro: Dialer -para usar los números presionandolos desde la pantalla-, Call log -que te dice las llamadas entrantes/salientes/perdidas, Contacts -listado de contactos- y Favorites -que se va llenando sola con los números más utilizados-)
  3. Al elegir Contacts te aparecen todos los contactos, podes: a) abrir el teclado y tipear el nombre -hace búsqueda incremental- o b) mover la lista de contactos con el dedo para elegir a quien llamar.
  4. Luego de elegir podes apretar el botón verde nuevamente y llama al primer número de ese contacto o elegir otro de los números de ese contacto y así llamar a su “Work” por ejemplo.

No es tan fácil como antes, claro que ahora tengo la dirección de mail de los contactos (no solamente como dato ya que puedo usarla para enviarle un correo), multiples datos asignables al contacto como cualquier agenda y la foto de cada contacto descargada directamente de facobook, porque hay una aplicacioncita para android que se conecta a tu FB, se fija si hay contactos con datos similares (nombre, email) y descarga la foto que tiene de su perfil ese contacto y la ubica en tu agenda telefónica.

Pros y contras, como siempre. Igualmente el teléfono inteligente está mejor que mi teléfono para llamar únicamente que tenía antes. Usa Android -que es software libre- y a pesar de sus DRMs muy a la vista, hay muchas aplicaciones (libres) portadas a Android, como un cliente de OpenSSH, cliente de correo a elección y además muchas aplicancioncitas que te hacen la vida más fácil.

Desgraciadamente solo funciona en modo EDGE y no 3G (me cansé de buscar por qué ya que tiene el mismo hardware de conectividad que el HTC TyTN y sí funciona en 3G de Movistar), por lo que la conectividad a inet es lenta.

Para aquellos que estén pensando en cambiar a un smartphone piensen si les sirve tener tanta información (agenda y datos) en un aparato móvil y que tener todo esto implicará mayor complejidad de uso.

Ah! Y otra cosa muy importante, si sos medio reacio a enviar tus datos privados a grandes empresas como Google, no te compres estas cosas porque están pensados para que todo el mundo confíe plenamente en grandes corporaciones (no es mi caso, pero soy geek y creo saber como evitar que esto ocurra).

Febrero 13, 2009
» Uno, dos, tres, cuatrocincoseis (siete-ocho-nueve) y cero!

Hoy a las 21:31:30 (hora de Buenos Aires) el reloj UNIX mostrará la secuencia de números 1234567890. ¿No es re lindo?

Lástima que no tengo este reloj, sino me sentaría a ver pasar los segundos y preparar una cámara para sacarle una fotito.

Me tendré que conformar con escribir

watch -n 1 "perl -e \"print time() . \\\"\n\\\"\""

en una laptop y mirar el monitor sin pestañar.

Salud a todos los geeks que -como yo- nos juntaremos para vernos las caras y decir “No podeeeeeessss ser tan geek” :-D

Diciembre 22, 2008
» Quiero ser como openfire ¿y vos?

Qué lindo que es cuando uno se pone viejo y hay gente que lo entiende, pero mejor aún es cuando uno se pone viejo y hay programadores que lo entienden a uno. Será porque un fue (¿?) “programador” y cree que es mejor que te entienda un/a programador/a a la gente. No sé, pero lo cierto es que hace pocas semanas probé de instalar openfire y quedé atónito, creyendome alguien totalmente comprendido, por fin una aplicación libre para servidor que se instala tan fácilmente, se configura aún más facilmente y tiene una interfaz de administración tan bien acabada.

Hace algunos años, muchos desgraciadamente, no podía irme a dormir si no había terminado de configurar ese programa, esa aplicación o esa configuración que hace aquello tan maravilloso. Recuerdo hasta momentos donde me desperté soñando la solución a un bug o una forma diferente de encarar una funcionalidad nueva. Esos tiempos han pasado y ya hace tiempo. Ahora, que estoy más viejo, quiero que las cosas funcionen de una, nada de andar configurando esto para que ande esto otro que justamente es lo que necesita el sistema que (tan solo) quiero probar.

Lógicamente apoyo esto de no tener que reinventar la rueda todo el tiempo ¿Para qué hacer una aplicación accesible vía browser y programar (primero) un servidor web? (existiendo apache) Claro que es un ejemplo burdo, pero hay muuuuchos sistemas, compañías y programadores que caen en esta trampa, generalmente porque no conocen el software libre, su software es software privativo y creen cosas de lo más estúpidas como: si no hay que pagarlo seguramente es una porquería (o algo cercano a ello), si uso un software libre mi software entonces tiene que ser libre también, etcétera, etcétera, etcétera.

Pero es tan lindo cuando uno instala un software de servidor e instantáneamente se lo puede probar. El caso de openfire es uno de ellos, instalas el paquete, levantas el servicio y guala! todo anda. Accedes desde el browser a la interfaz de administración, te bajas el cliente XMPP (Spark) o cualquier otro y lo podes probar, queres ver qué onda alguna de sus extensiones y desde la interfaz web la instalas (el sistema la baja de sitio web correspondiente), la activas y ya está. Ningún shell, ningún comando.

No hay que configurar ningún otro demonio, ninguna base de datos, crear ningún usuario (bueno, lo hace el instalador del paquete) ni preparar nada. Ah! no, miento, hay que tener un JRE disponible (porque está escrito en JAVA).

Este tipo de facilidades solo las he visto en aplicaciones (libres) para el escritorio. Firefox, Thunderbird, OpenOffice.org y muchos otros no requieren más que eso… instalarlos, para empezar a usarlos.

Claro, openfire resuelve algo que está relativamente aislado en lo que se refiere a subsistemas necesarios, es un servidor XMPP. Solo es necesario implementar el protocolo, brindar una interfaz de administración y listo, pero igualmente hay otros servidores XMPP que son muy diferentes en lo que refiere administración e instalación.

Lo pudieron haber escrito en J2EE, como tantas aplicaciones libres escritas hoy (lo que hace muy incomodo de probar algún sistema) o la interfaz web la pudieron haber escrito en PHP y así requerir que apache esté configurado con su VirtualHost correspondiente, lógicamente se requiere guardar algún dato en alguna parte y qué mejor que usar una base de datos MySQL (claro que para eso hay que tener un usuario para esa base y darle los permisos necesarios).

Nada de todo esto es imposible de hacer, siempre está el archivo INSTALL que te dice como hacerlo “en dos patadas”, pero cansa. Si uno está evaluando software para ver si lo evalúa con mayor énfasis generalmente se baja todo lo que parece que hace lo que uno necesita. Si ya para instalarlo hay que dar algunas vueltas, preparar tantas cosas el listado de software posible se va reduciendo solo y las expectativas del testeador bajan.

Para mi una aplicación libre tiene muchas más posibilidades de ser popular si su método de instalación y administración está bien pensado, bien fácil, bien APB (y también tener un modo avanzado para hacer las cosas como se debe sin tantos defaults). Sino se tiene que hacer popular de la manera tradicional, mostrando lo buena que es técnicamente y que la gente (poca inicialmente) hable bien de ella. El camino largo, pero no necesariamente mejor (técnicamente hablando) que el propuesto.

Gracias a la gente de Openfire y espero que muchos programadores de software libre aprendan de esta experiencia.

Abril 3, 2008
» DKIM - DomainKeys Identified Mail

Desde hace ya un tiempo existe una RFC que se creó para crear una nueva técnica (adicional) en la lucha contra el SPAM y el phishing. Yahoo! diseño, supongo en conjunto con otros, la RFC 4871 (DomainKeys Identified Mail (DKIM) Signatures) que cuyo objetivo es el de -sin modificar la forma en que se envía y recibe mail, o sea, el protocolo SMTP- se pueda implementar un método de verificación de remitente, a nivel dominio, usando claves públicas y privadas.

El método básicamente es el agregar un encabezado SMTP cuando se envía el mail con un hash (firma) creado con la parte privada de la clave RSA. Cuando el MTA receptor recibe este correo, hace una consulta DNS, obtiene la clave pública del dominio del cual fue enviado el correo y verifica la autenticidad del hash.

En este post voy a describir cómo lo implementé en un debian etch.

Implementación

Para implementarlo finalmente elegimos usar dk-milter o dk-filter (que es lo mismo).
Debian trae un paquete en lenny, por lo que me baje los fuentes con:

apt-get -t lenny source dk-milter

y después lo compilé (con dpkg-buildpackage)

Lo primero que hay que hacer es armar los certificados. El paquete trae un comandito para hacerlo gentxt.csh, este comando se ejecuta pasandole dos argumentos, el “selector” que es un nombre (yo le mandé “calculin”) y el nombre del dominio al que pertenece el certificado, en este caso fue “cafelug.org.ar”.

Genera dos archivos:

  • calculin.public
  • calculin.private

El archivo privado es el más importante y hay que ponerlo en alguna parte que después lea el demonio, yo lo mandé en /etc/postfix/domainkeys.

Luego hay que configurar el DNS y también algunos parámetros del dk-filter.

El dk-filter se configura tocando el archivo /etc/default/dk-filter y así quedó:

# Sane defaults: log to syslog
DAEMON_OPTS="-l -m smtpd,postfix"
# Sign for example.com with key in /etc/mail/domainkey.key using
# selector '2007' (e.g. 2007._domainkey.example.com)
DAEMON_OPTS="$DAEMON_OPTS -d cafelug.org.ar -s /etc/postfix/domainkeys/dk_cafelug.org.ar.pem -S calculin"
# See dk-filter(8) for a complete list of options
#
# Uncomment to specify an alternate socket
#SOCKET="/var/run/dk-filter/dk-filter.sock" # default
#SOCKET="inet:54321" # listen on all interfaces on port 54321
SOCKET="inet:1025@localhost" # listen on loopback on port 12345
#SOCKET="inet:12345@192.0.2.1" # listen on 192.0.2.1 on port 12345

Entre las opciones esta -l que es para que mande los logs a través de syslog, -m smtpd,postfix no sé si es necesario (entre las pruebas que hice quedó). Las otras son más importantes:

  • -d cafelug.org.ar (el dominio del certificado, se pueden poner más dominios)
  • -s /etc/postfix/domainkeys/dk_cafelug.org.ar.pem (el lugar donde está la clave privada)
  • -S calculin (el “selector”).

Y la parte que me volvió un poco loco fue la opción de SOCKET=, postfix corre en chroot, por lo que la opción SOCKET="/var/run/dk-filter/dk-filter.sock" me tiraba ”’file not found”’… estuve un rato para acordarme y darme cuenta que no lo encontraba porque no estaba dentro del jail. En fin, lo deje escuchando en un puerto y así no da problemas.

Configuración de DNS

La configuración de DNS es ”tricky”, la documentación que encontré no es muy específica. La forma de correcta de setearlo es poniendo ”’dos”’ entradas de tipo ”TXT” en la zona:

calculin._domainkey.cafelug.org.ar. TXT "k=rsa; t=y; p=MFwwDQYJ[...]xfS+g/UlcszvzvY3UPFNEVGEecCAwEAAQ==”

_domainkey.cafelug.org.ar. TXT "t=y; o=-"

La primera indica la clave pública (encodeada en Base64) para el selector ”calculin” (que use con el gentxt.csh) y es importante que esté con el selector adelante y seguido de un ”.” (punto). O sea ”<selector>._domainkey.<dominio>”, las demás opciones (”’k=”’ y ”’t=”’) están claramente documentadas en la RFC 4870.

La segunda entrada indica cómo deben ser tratados los mails que llegan de este dominio, ”’t=”’ indica que el dominio está en ”test-mode” (esto se saca una vez que lo pasamos a producción), luego la opción ”’o=”’ tiene varios valores, ”~” indica que los mails pueden ser firmados o no, en cambio ”-” indica que todos los mails enviados van a salir firmados.

Configuración de postfix

La configuración de postfix es simple, lo único que hay que tener en cuenta es la versión de postfix. Esto está soportado desde la versión 2.3.

smtpd_milters = inet:127.0.0.1:1025
non_smtpd_milters = inet:127.0.0.1:1025

smtpd_milters indica donde encuentra los ”milters” definidos (ojo con la sintaxis, no es la misma que usa el dk-milter, intercambia la posición del ”host” y ”puerto”, así que no hay que hacer cut&paste).

non_smtpd_milters es para los mails generados localmente.

Probando la configuración

Para probar si todo quedó bien se pueden enviar mails a una cuenta de Yahoo! que hace el chequeo (aparece una leyenda debajo del “From:” visible desde la interfaz web (sin tener que ver los encabezados completos). La otra forma es enviando un mail a una cuenta que responde automáticamente diciendo el estado del tema. Esta cuenta es autorespond e@n dk.elandsys.com

Lo que hay que tener muy en cuenta es que tanto Yahoo! como el servidor que recibe el mail de la dirección de testeo tienen que tener la zona de nuestro dominio actualizada. Generalmente van a tenerla en un cache (si es que ya mandaron algun mail al dominio en cuestión), por lo que el test puede darnos que falló, cuando en realidad solo hay que tener paciencia y esperar a que nuestra zona expire en el DNS cache que leen estos MTA.