Ahora mismo estoy en Londres (UK). Cada año un sitio distinto, aunque este año casi no he salido casi de España (a diferencia de anteriores con más países y más semanas fuera). Así que en lugar de hacer uso del socorrido roaming de BlackBerry (esa famosa tarifa de datos BlackBerry ilimitada en todo el mundo por 30€ al mes que hace que no suelte ni BlackBerry ni Movistar), he decidido atreverme y probar suerte con un operador local.

La elección en este caso no es difícil (o por lo menos, no lo parecía al principio). En este caso, three.co.uk: estoy en Londres así que la cobertura 3G es muy buena, tienen tarifas muy flexibles y variadas, y además están orientados al uso intensivo de datos. Three también está en otros países (Irlanda, Italia, Austria, Dinamarca, HK, Australia, Suecia y más) y siempre con la misma filosofía orientada a datos (aunque adaptada un poco a las 'costumbres' de cada país, claro).

Three tiene únicamente 3G, lo cual puede ser bueno o malo. Por ejemplo, la vez que estuve por Irlanda y atravesando el país usé METEOR que tenía EDGE en lugar de Three, porque fuera de núcleos de población de cierto tamaño Three funcionaba pésimamente (eso es comprobable usando roaming — en parte porque en medios rurales el 3G rinde peor). METEOR tenía cobertura EDGE muy buena y 3G en algunas ciudades, así como una tarifa 'aceptable' de datos (creo que 1€ o menos por 50MB). Por aquellos tiempos tenía iPhone y además WiFi en el apartamento así que parecía bastante sensato gastarme 10€ en una SIM (gratis) y saldo para gastar en datos en el iPhone y poder twittear y leer el correo en todas partes (sí, vicio, llevo ya 5 años sin soltar internet más de una semana, creo).

En Canadá y Noruega hice uso del roaming BlackBerry porque salía bastante más rentable. En Canadá estuve bastante tiempo y consideré lo de mirar operadores pero ROGERS, Bell y Telus se parecían bastante en algo que era negarse a dejarme usar internet en un iPhone sin regalarles un riñón. En Noruega no llegué a mirar porque ya vivía por una parte con el roaming de BlackBerry que tenía activado para los dos meses de verano y porque en cada sitio que iba había WiFi.

Para este año decidí ir directamente a por three. Además traigo un arsenal ampliado: a parte del (nuevo, por cierto) MacBook Pro y la Blackberry, un iPad WiFi y un iPod Touch que también 'chupan' del bote (y pensar que hace unos años me sobraba con 50MB al día…). También tengo un MiFi (de three.co.uk, curiosamente) y teniendo en cuenta que se puede usar la BlackBerry (servicio completo, BIS) a través de WiFi parecía una idea genial comprar una SIM de three con datos, meterla en el MiFi y quemarlo de usarlo (dos blackberrys, un iPod, un iPad en las esperas en aeropuertos…). Como soy un genio, además, compré la tarjeta directamente por eBay por unos pocos euros y así ir directamente a UK con la SIM en las manos (así sólo tenía que llegar a cualquier tienda en el mismo aeropuerto y comprar un voucher para recargar, aplicar el add-on que quería y tener datos a tutiplén).

Todo salió bien, por lo menos el primer día. Pero el segundo en cuando estaba llegando a Londres dejó de funcionar y en un momento (pero nunca más) se cargo en el iPod una página de Three diciendo que no estaba cumpliendo las condiciones (vaya, hombre). Resulta que el add-on prepago (PAYG) de £15 no se puede usar en el MiFi (se entiende) y que o pagaba la cuota MiFi (de £70 por 3GB) o usaba mi tarifa sólo en un móvil.

Sé que los operadores pueden saber qué terminal usas, por una parte saben el IMEI (que es un número sin más para ellos) pero algo más debe de haber, porque METEOR.ie en su zona cliente mostraba qué móvil tenía y con su correspondiente fotografía (y clavaba perfectamente tanto el iPhone 3G como el menos común Nokia Navigator del que ni siquiera me acuerdo del modelo, iba alternando móviles para probar configuraciones). Por otra parte el hecho de que el MiFi fuese un ex-three liberado no debió ayudar mucho (y me inclino a que es eso, es normal que lleven registros de sus IMEI).

En un alarde de inteligencia se me ocurrió soltar 10$ por internet para liberar mi BlackBerry 8900 y usarla, bien que sin BIS pero con la mayoría de aplicaciones vitales 'más o menos funcionales'. Vamos, mejor eso que pagar los 8€ diarios de movistar por roaming BlackBerry. Microsegundos después de darle al botón de pagar caí en la cuenta de que mi BB es sólo GPRS y EDGE. Vaya. Por lo menos ahora tengo un móvil libre, aunque para lo que le queda de vida…

Pero bueno. No todo es tan malo. Tuve la idea de traerme un móvil 3G, que era un K610i liberado de mi época en Yoigo. Se me ocurrió que quizás podía conectar ese móvil que tenía internet al iPod que tenía Bluetooth. Y cuando ya estaba terminando de hacer jailbreak al iPod (después de pelearme con actualizaciones, bajar dos firmwares distintos para engañar a redns0w y caerme de sueño encima del teclado) descubrí que… bueno, resulta que no hace falta hacer jailbreak.

El Sony Ericsson K610i, como bastantes otros móviles (por ejemplo, el iPhone) dispone de Bluetooth PAN, de tal forma que después de hacer el pairing necesario (asociación de dispositivos) puedes conectar un dispositivo a otro y que el otro acceda a una especie de 'red' creada por el host. Algo así como convertir al móvil 3G en un router sólo que por Bluetooth. Generalmente el 'compartir internet' se suele hacer (o solía, en móviles antiguos) por Bluetooth DUN, que es emplear un modem de marcación por Bluetooth. Así la única forma sería haciendo jailbreak y usar aplicaciones como iBluever y su correspondiente factura en aspirinas.

La alternativa algo más desarrollada es la mencionada, Bluetooth PAN que crea una especie de red local (con enrutado) accesible por Bluetooth y que es fácil de conectar desde cualquier ordenador o dispositivo Bluetooth y con la enorme ventaja de que no hace falta trastear con drivers ni configuraciones (marcación, APN…) puesto que todo eso se queda en el lado del móvil y ya emplea los perfiles de acceso que hay en el móvil.

En ese momento intenté hacer pairing entre el SE y el iPod… Y… ¡Sorpresa! Después de hacer la asociación, sin nada más que hacer, el iPod se conecta a internet a través del móvil:

La batería dura marginalmente más que la del MiFi (hoy he estado unas 7 horas fuera y antes se ha acabado la batería del iPod, a diez metros de casa, que la del móvil), en parte porque hay menos dispositivos, no hay HSPA y Bluetooth consume menos. Eso sí, el móvil es sólo UMTS, pero para usarlo en el iPod no es ninguna molestia (aunque se nota algo más lento). Y si pego los dos con celo, nada que envidiar a un iPhone, eh.

La moraleja de este ladrillo es… que bueno, con un poco de suerte y un buen arsenal se terminan arreglando marrones así. Espero que ahora a Three no le de por volverme a cortar porque ya estoy empezando a disfrutar lo de tener un iPhone-sin-ser-iPhone (pero tranquilos, sigo siendo más de BB, lo siento!). Realmente creo que lo ideal sería tener un iPhone o Android libre como teléfono principal e ir metiendo ahí las SIMs de operadores locales (y si eso, llevar otro teléfono pequeño para recibir llamadas con el operador de origen), pero los usuarios de BB lo tenemos un poco complicado.

Hace unos días estuve moviendo todo de soluciones cloud a un solo servidor con bastante RAM e IPs (downside: tengo que ocuparme de los backup, upside: me ahorro un dineral al mes y mantengo los mismos recursos disponibles). Con un pequeño problema (inesperado, casi) y es que las IPs adicionales venían, por narices, atadas a eth0 (eth0:x) y no había posibilidad de hacer bridging directo al switch más cercano puesto que tan sólo permitía una dirección MAC (fijada previamente) por puerto físico. Esto pasa en OVH cuando el servidor está en el DC de P19 en Paris dix-neuvième puesto aquellos que están en RBX (uno, dos, tres) pueden usar MACs virtuales.

La solución era efectivamente atar las IPs adicionales a la interfaz principal, crear las máquinas virtuales usando un dispositivo de red ficticio y comunicar esas máquinas virtuales con una IP privada con el host, y mediante iptables redirigir tráfico a estas IPs privadas (in/out).

Primero hay que editar /etc/sysctl.conf, añadir la línea para IP forwarding (net.ipv4.ip_forward = 1) pero antes comprobando que no existe ya (y si tiene valor 0 o 1). Luego se añade al vuelo para aplicar el cambio en la sesión actual sin reinciar (echo 1 > /proc/sys/net/ipv4/ip_forward).

A partir de aquí empieza el misterio: hay que editar el script de NAT (/etc/xen/scripts/network-nat) con un editor cualquiera (nano, por ejemplo) y buscar las líneas de iptables que usen masquerade (^W + masquerade + enter, por ejemplo) y comentarlas una a una.

Luego (lógicamente) hay que modificar los archivos de config de Xen para que use el script de network-nat, editando /etc/xen/xend-config.sxp, descomentando las líneas que contemplen (network-script network-nat) y (vif-script vif-nat) y obviamente comentando el resto de network-scripts y vif-scripts. Para que aplique todo esto hay que reiniciar xend, pero puesto que también hemos tocado la configuración de red lo mejor es -quizás- reiniciar el host y ver si se han aplicado bien los cambios.

También toca mencionar que al crear las VMs con IPs en el rango de 10.0.0.0/24 (10.0.0.10, en este ejemplo), ya sea desde el propio command line al crearla o modificando su cfg (vif = ['ip=10.0.0.19']). Dentro de las propias VMs la configuración suele estar algo patas arriba, por una parte el loopback suele estar desconfigurado (no aparece en ifconfig, en ocasiones ifup lo arregla el problema, pero no siempre es el caso). Si no, /etc/networking/interfaces tiene que parecerse a esto (cambiando la IP de la vm):

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
 address 10.0.0.10
 gateway 10.0.0.1
 netmask 255.255.255.0

Finalmente, basta con añadir una serie de reglas a iptables para enrutar a la máquina virtual desde el alias físico de dom0, en el host, lógicamente (iptables de dom0):

iptables -A PREROUTING -t nat -d 80.80.80.80 -j DNAT --to 10.0.0.10
iptables -A POSTROUTING -t nat -s 10.0.0.10 -j SNAT --to 80.80.80.80

Obviamente cambiando las IPs correspondientes (10.0.0.10 por la dada al domU y 80.80.80.80 por aquella correpondiente al alias de eth0 que tiene dom0). Lo más aconsejable es añadirlo en el initd en un script de firewall junto con reglas para filtrar el resto de tráfico que entra en dom0 (que siempre debe tener su IP dedicada, nunca una enrutada a un domU o nos quedamos sin acceder al host).

Botize es una herramienta muy sencilla (pero también) potente para programar bots de Twitter. Permite hacer bots muy básicos (como un bot de respuesta automática a mentions con un hashtag de #followfriday, por ejemplo) sin requerir conocimientos de programación. Y también permite hacer bots completos con su API y unas pocas líneas de PHP, Python o Ruby.

Antes de que Twitter forzase la autenticación por OAuth, era relativamente fácil hacer un bot que respondiese a hashtags o replys en unas pocas líneas de código y una línea en el crontab.

Con Botize se pueden hacer el mismo tipo de bots básicos (y está muy bien documentado), pero también bots algo más complejos (y ahorrándonos peleas con el API de Twitter). Hubo un concurso de bots hace poco (pronto anuncian los resultados) y como es lógico, yo también me he apuntado con un par de bots:

• @whenwillair: usa el API de showRSS (semi-pública y en desarrollo, habrá sorpresas!), responde diciendo cuando se emitirá un episodio para una serie (además el API usa aproximación textual para encontrar el nombre de la serie, con lo que se pueden mandar consultas como 'tbbt' o 'ncis la')
• @horabus: es una adaptación de EMT Espera a Twitter (aunque teniendo el app web no es del todo eficaz), más que nada experimental (cuando Botize sea realtime ganará en utilidad!)
• @metrocerca: esta es mi principal apuesta (y el bot, junto con whenwillair, qué más útil me parece personalmente). Aquí abajo lo explico con más detalle.

@metrocerca es un bot que devuelve paradas de metro cercanas. Funciona para Barcelona, Valencia y Madrid. Incluye paradas de metro ligero y tranvía. 

Además, hace uso de la ubicación contextual de un tweet. Se puede mandar un tweet desde Twitter for iPhone o ÜberTwitter (teniendo la funcionalidad de geolocalización activada en el programa y en la web de Twitter) del tipo @metrocerca aqui, y obtener en cuestión de segundos (o minutos) una respuesta.

Además, como foursquare y gowalla envían tweets con información geográfica al hacer check-in, se puede mencionar al usuario en el mensaje (al final, por ejemplo) y obtener por Twitter un reply con paradas cercanas al lugar al que nos encontramos (también es necesario activar la geolocalización en la web de Twitter).

Y si no, siempre queda la posibilidad de obtener paradas cercanas a una dirección postal, @metrocerca consell de cent 343.

En cuanto a Botize, el proyecto en sí es magnífico. Es de JuanSa (Dieyes), fue un proyecto ganador en la Campus Party y es tremendamente útil. Hay un par de cosas que añadiría a Botize:

• Cuentas validadas – esto podría ser comercial e idea de negocio. Estas cuentas podrían tener mayor libertad, como realizar RTs, responder también a búsquedas, hacer autofollow y enviar DMs.
• Posibilidad de enviar varios tweets con una petición y añadir lugar geográfico a la respuesta
• API (premium quizás) para enviar tweets/DMs por push (es decir, evitando pasar por OAuth, pero sin esperar a que Botize se conecte a nuestro plugin)

Suerte a todos los participantes y ánimos a cualquier persona para que le eche un vistazo.

Visto así lía un poco. Explico: la idea es tener por un lado nginx, y por otra Apache y/o lighttpd haciendo virtual massive hosting. Es decir, que un dominio cualquiera (example.com) redirija a la carpeta correspondiente (/home/domains/example.com/) sin tener que modificar la configuración de vhosts a cada nuevo dominio.

Primero, nginx como proxy. En mi caso, pongo una entrada por dominio (pero con alias para eliminar www). Como pequeño detalle, tengo tanto Apache como lighttpd en puertos distintos con la configuración de massive virtual hosting usando los mismos folders. Así puedo decidir a qué servidor van las peticiones según dominio.

server {
    listen 80;
    server_name example.com www.example.com;
    if ($host = 'www.example.com' ) {
        rewrite ^/(.*)$ http://example.com$uri permanent;
        break;
    }
    location / {
        proxy_pass http://127.0.0.1:8080/;
        proxy_buffering off;
        proxy_connect_timeout 10;
        proxy_pass_request_headers on;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

Después, la configuración de VirtualHost. Son muy sencillas. Primero con Apache:

<VirtualHost *>
    UseCanonicalName Off
    VirtualDocumentRoot /home/domains/%0
</VirtualHost>

Y con lighttpd:

server.modules += ( "mod_simple_vhost" )
simple-vhost.server-root = "/home/service/"
simple-vhost.document-root = ""
simple-vhost.default-host = "default"

En el caso de Apache, si no detecta dominio (o no se envía header Host) va al document root por defecto. Lighttpd, en su caso, interpreta el dominio 'default' si se ha especificado Host, o de lo contrario también recurre al document root (así que es conveniente unificarlo).

Como puntualización: si nginx y el httpd de nuestra elección están en la misma máquina (no es mi caso) siempre se puede retocar la configuración para hacer bypass al httpd para servir el contenido estático.

Además hay parámetros que no he especificado en el ejemplo (que pertenecen a nginx.conf), como worker_processes, worker_connections, keepalive_timeout, tcp_nopush y tcp_nodelay, que son importantes para evitar cuellos de botella cuando se usa nginx como reverse proxy únicamente, y atendiendo peticiones de forma masiva.

Llevo ya unos días intentando hacer funcionar un esquema NAT con Xen. La idea es la de tener un dom0 (host) conectado a una red LAN o directamente a internet a través de eth0 (IP estática), y luego tener una red LAN entre todas las domU (luego para mayor seguridad se aisla con firewall a nivel iptables).

De esta forma, se puede configurar un nginx bindeado a la IP pública de dom0 (la IP asignada a eth0) y desde ahí hacer proxy a las distintas domU que no disponen de IP pública. Todo muy sencillo.

Pero llevo varios días de cabeza con esto. Por un lado, porque los scripts network-nat y vif-nat no tiraban ni para atrás, y por otro porque además estos scripts montaban una interfaz intermedia por cada VM (así, el esquema es domU <-> eth0:domU <-> vifx.x:dom0 <-> eth0), así que ifconfig terminaba a reventar de interfaces que tenían cada una su IP propia en la red 10.x.x.x y por lo tanto dom0 no tenía una IP fija en la red virtual de los domU).

Una posible solución (por la que he optado al final) ha sido la de crear una interfaz red virtual (estilo loopback), meter ahí a dom0 como host y gateway y usar el script network-bridge sobre esa interfaz virtual. Para la interfaz virtual he usado el módulo de kernel dummy y he declarado una interfaz virtual dummy0.

En dom0 hacemos una serie de cambios:

Activamos el módulo dummy usando modprobe dummy, y /etc/modules debería parecerse a esto:

loop max_loop=64
dummy

Por una parte, el fichero /etc/network/interfaces queda así:

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static
   address 192.168.1.10
   netmask 255.255.255.0
   gateway 192.168.1.1

auto dummy0
iface dummy0 inet static
   address 10.0.0.1
   netmask 255.255.255.0

Después, ajustamos las tripas de /etc/xen/xend-config.sxp para configurar bridge sobre dummy0 (dejamos todos los network-script y vif-script comentados):

(network-script 'network-bridge netdev=dummy0')
(vif-script vif-bridge)

Después, esto ya en nuestro domU, en /etc/network/interfaces:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
   address 10.0.0.10
   gateway 10.0.0.1
   netmask 255.255.255.0

Es especialmente importante poner correctamente los gateway y netmask en dom0 y domU, así como no tener MAC clonadas en la misma red (en el cfg de cada domU se puede quitar la línea de IP, y especificar la MAC es innecesario).

Después de reiniciar manualmente (reboot), o al menos reiniciado el networking en nuestras dom0 y domU (conviene hacer shutdown desde cada domU, reiniciar dom0 y hacer create, puesto que si no preserva el estado de las domU al apagar dom0), veremos que podemos pinguear desde dom0 hacia domU y viceversa, y entre domU.

Ahora volvemos a dom0 para configurar el NAT (IP forwarding).

Creamos un nuevo fichero en /etc/network/if-up.d/ (puede llamarse algo así como 00-nat) y metemos el script que se ejecutará al levantar las interfaces.

#!/bin/sh

iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state NEW -i eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o dummy0 -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -i dummy0 -o eth0 -j ACCEPT

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

echo 1 > /proc/sys/net/ipv4/ip_forward

Le damos permisos de ejecución con chmod u+x 00-nat y lo ejecutamos manualmente por ser la primera vez. Ahora los domU ya deberían ser capaces de comunicarse con el exterior.

Por fin.

Ahora mismo escribo desde el móvil. Estamos al borde de un pequeño lago, en un campamento de YMCA (y esto es genial).

Desde la última vez que escribí han pasado muchas cosas (mi padre dice que esto se parece a “El día de la marmota”). Como siempre, hay un puñado de fotos en mi álbum de Flickr.

CN Tower, cataratas del Niágara (realmente impresionantes, hay que vivirlo en primera persona al menos una vez en la vida)… Y mucha vida (día a día) en downtown Toronto.

Tampoco tengo mucho que escribir ni que contar ahora mismo (en realidad sí, pero difícilmente voy a poder condensar todo de una vez). En cualquier caso tenía ganas de hacer una lista de las (muchas) cosas de este lugar que me han parecido interesantes o sorprendentes, aunqu por ahora, cae esto:

• Starbucks: Son muy comunes por aquí. Visualmente (marca) son lo mismo, aunque la calidad de lo productos es mucho más acorde al precio (que es razonable, y al cambio, hasta barato; además aquí todas las bebidas son más grandes que allí y los Frapuccino no saben a hielo picado con zumo).
• PATH: Toronto es una ciudad muy grande y activa. Hay una serie de pasillos subterráneos que une los “basemenent” de los edificios con grandes galerias comerciales. Es como un centro comercial a lo grande, muy cercano a la superficie y transitado esencialmente en invierno, cuando la gente trabaja y las temperaturas son del orden de -20'C.
• El transporte público es muy caro. El aparcamiento también. Unos 3 dólares por trayecto, 36 dólares por un abono semanal y un centenar para el mensual (unas 3 veces más caro que en Madrid). La TTC (empresa de transportes) abarca metro, tranvía y autobús. La infraestructura es muy vieja y está en proceso de renovación, aunque está muy bien conservada y mantenida. Además a menudo el metro conecta con el PATH (que a su vez se conecta directamente con los edificios de empresas) y con los tranvías, que llegan a las afueras, así que para mucha gente la rutina en invierno consiste en coger el tranvía y no pisar la (fría) calle durante la jornada.

Aún me quedan cuatro días aquí. En cuanto tenga un ordenador a mano me pondré a escribir más.

Voy recuperándome poco a poco del jet lag. Hoy hemos descubierto un poco más la residencia (antiguo hotel con 27 plantas hábiles y un montón de habitaciones enormes). El panorama de la ciudad, que además se ve desde el último piso de la residencia (hay una zona muy grande con tele, sillones y completamente acristlada por las cuatro esquinas del edificio) es sencillamente impresionante.

Por lo demás... Ha sido un día entretenido, conociendo gente y en general el mecanismo urbano (por ejemplo, que en hora punta toca esperar unos quince minutos para coger un tren de metro, aunque pasen cada dos minutos). Por ejemplo, el tranvía es a la vez precario y moderno: la comodidad y frecuencia de paso son geniales, la velocidad es muy buena y las líneas también, pero el sistema de 'tokens' se basa en echar un pedazo de papel en un cubo y para pedir parada hay que tirar de un cable en el lateral del tranvía.

Cerca de la zona en la que estamos está la zona universitaria. Hay universidades propiamente dichas (campus de temas relacionados con medicina esencialmente) y a lo largo de una avenida (University Avenue) se sitúan tanto campus como un montón de hospitales dedicados a la investigación (y a acoger enfermos, eso también). La cantidad de pancartas situadas en las fachadas incitando a la colaboración en la investigación e informando de los progresos en este sector resulta un contraste con la situación en el otro lado del atlántico.

Eso sí, la ciudad es muy cara. Quizás no he mirado en los sitios más baratos, pero para conseguir desodorante, pasta de dientes, champú y agua me he dejado 22 dólares (casi 17 euros). Al mismo tiempo, el nivel de vida es muchísimo más alto. Eaton Centre es impresionante, no hay palabras que lo describan.

Spoiler: QUIERO VIVIR AQUÍ (bueno, por lo visto las temperaturas en invierno andan por el orden de -10ºC y -30ºC, cosa entendible teniendo en cuenta que esta tarde hemos pasado frío).

Hemos despegado a las 13.30h de la península. Eurocontrol nos ha retrasado el vuelo de una hora, así que hemos pasado algo más de media hora en el tarmac y el vuelo de ida, pasando por NAT, se ha alargado de media hora más. Hemos aterrizado a las 1650LT, casi las once de la noche en GMT+1. El vuelo, con Transat, era en un A310 de nueve personas por fila en tres bloques. A diferencia de lo que me esperaba, los asientos eran muy cómodos y reclinables. Y han servido comida durante todo el vuelo de casi 9h, incluyendo dos platos de comida caliente y bebidas gratuitas. Muy bien, vaya. La ciudad es bonita, muy moderna. Todo está apretado aunque es muy agradable (grandes torres, grandes calles... y casi siempre a la sombra). Ahora estamos en un bus de colegio que parece sacado de una pelicula. Parece sacado de un DIY!