Las difamaciones de Ramón Muñoz

Esta mañana y con prisas, dado el revuelo que estaba causando, escribí “El CDN de Telefónica, neutralidad y sensacionalismo“. Ambos artículos mencionados eran erróneos, y muy sensacionalistas. De hecho, si buscáis las frase que copié y pegué de ambos periódicos ya no están en los originales, los corrigieron.

Durante unas horas hubo una discusión si eso afectaba o no la neutralidad de la red. Así como está planteado la CDN de Telefónica no tiene por qué afectar. Se dijo que dependía de la definición de “neutralidad”, y creo que la definición es clara. Para no repetir copiaré el texto en español e inglés de la Wikipedia (me parecen concisos y correctos):

Otro intento, esta vez periodístico

Hace unos días comenté en Twitter lo que estoy intentando poner en marcha, un proyecto “periodístico” (entre comillas, por las dudas) pero con un twist: no se trata de “crear la noticia”, sino de analizar lo más objetivamente posible una noticia que está dando que hablar -por ser relevante, sensacionalista, o controvertida-. Varios me pidieron detalles, como comparto que las ideas por sí mismas no valen nada (lo que cuesta es la ejecución), mejor compartirla que tenerla en secreto. Si alguien está interesado o lo hace mejor, bienvenido sea.

De peritos informáticos y ad hominems en los juicios

Hace unos días comenté el cable de Wikileaks que revelaba que Guisasola, Presidente de Promusicae, había solicitado al gobierno norteamericano que incluyese a España en la lista prioritaria de observación de la 301. Poco después me entero que en el juicio contra Pablo Soto (defendido por David Bravo y Javier de la Cueva), el mismo Guisasola declaraba “casi llorando” que EEUU nos había incluido en la 301. Hace unos minutos me entero que además aprovechó para llamar macarra a Javier de la Cueva.

Eso me hizo recordar el nivelazo (sarcasmo) de lógica y respeto que hay en los juzgados. Recordé un juicio de 2006 donde participé como perito de la acusación contra el Govern Balear (en la época de Jaume Matas, del PP). Ya hice un resumen muy breve hace tiempo, pero ahora contaré con un poco más de detalles.

La crisis con Amazon AWS

El viernes 5 de agosto  me voy con toda la familia a un pueblo de Extremadura cerca de la frontera con Portugal (Valencia de Alcántara) a visitar a unos amigos. Regresábamos el martes 9 a la tarde, ¿qué podía pasar en Menéame que no se pudiese solucionar con una navegador y la consola web de AWS si nunca habíamos tenido problemas graves? Si necesitaba algo más, podía instalar las herramientas de AWS en otro ordenador y solucionarlo en pocos minutos. Así que por primera vez viajo sin mi portátil, sólo mi tablet Android con conexión 3G Vodafone (además de mi teléfono también con 3G).

Pues ocurrió el desastre en Amazon, les falló todo lo que podía fallar, todos nuestros planes de contingencia no podía aplicarse (salvo el “rehacer desde cero” con los bakups) y yo sin mi portátil y con el 3G completamente inestable, prácticamente como si no tuviese conexión. Si no hubiese sido así Menéame no habría estado “off line” tanto tiempo, quizás sólo unas pocas horas. Fue una pesadilla.

Amazon tuvo varios fallos: primero el corte completo de la conectividad a todas las instancias, luego la desincronización del API de gestión, luego los EBS que quedaron totalmente inaccesibles y bloqueando la gestión de las instancias que los usaban, y para rematar un fallo en el software de creación de los “snapshots” (backups por bloques en S3) que borraba datos de algunos bloques (lo descubrieron durante la crisis, y nos afectó a nosotros).

Nota: es un relato rápido, ya corregiré erratas, ahora me voy a duchar, que la última vez fue en Valencia de Alcántara

Desinflado

Desde que comenzó el tema de la Ley Sinde todo fue acelerándose e in crescendo, incluso mi cabreo e indignación. Los últimos tres meses fueron de locura, toda una campaña electoral pero sin escaños -ni poder- que puedan compensar y recomponer las quemaduras. Así fue, las ampollas empezaron a doler (y a cabrear más), las horas de sueño a reducirse al mínimo, y los escaños -y el poder- irán gente que ni se entera todavía de qué va el tema (o sea, casi todos los elegidos).

Esta tarde después de volver de la #acampadapalma caí del todo. Mi cabreo sigue igual pero el cuerpo y la mente piden un respiro. Creo que lo que pasó en Barcelona me afectó bastante, y el enterarme que un amigo (el soporte logístico y anímico de nuestro intento con #atízame) también había recibido de los mossos (afortunadamente está bien, sólo una luxación de tobillo, parece) debe haber dado la puntilla. No sólo dieron palos a “los otros”, también a amigos.

Me retiro a la retaguardia, cancelo todos mis viajes y entrevistas para las siguientes semanas… o meses (intentaré avisar uno a uno). Sólo haré ese viaje pendiente para juntarnos con algunos “compañeros de batallas” para alcoholizarnos, hacer un poco de catarsis e intentar hablar de amor y sexo más que de leyes sindes, corrupción, paro, periodistas, fanboys, politicos y la madre que los parió.

No sé si podré seguir en escribiendo como hasta ahora, espero que sí (mañana será otro día), pero intentaré no volver a hablar de estos temas durante algunas semanas. Pero no significa que me olvido del impresionante trabajo desinteresado y anónimo de mucha gente para #nolesvotes, ni disminuirá mi admiración por lo que ha hecho #democraciarealya para el #15m, ni la cátedra de ciudadanía, civismo, pacifismo y voluntad que nos están dando las #acampadas. Mi arigatô con inclinación de cabeza incluida para ellos.

Lo importante acaba de comenzar, a ver si recupero algo de las fuerzas gastadas desde que se empezó a hablar de la Ley Sinde, allí por 2009 (¡hace dos años!). Al final esa batalla se perdió -no será la última-, pero se han ganado otras mucho más importantes que pasarán a la historia (habrá que agradecer a “los sindes” por la motivación y el entrenamiento involuntario a esa multitud de cuatro gatos).

Que siga así.

Ha sido duro, pero valió la pena poner los 2 centavos. Gracias, y disculpas, a los que sabéis. Ahora toca recuperar músculos, paz, amigos “sin red” y familia.

Os seguiré leyendo.

Cosas que no entiendo

Hoy, o mejor dicho ayer domingo, presencié varias cosas a las que no encuentro sentido.

1. Que no haya pruebas siquiera para juzgar a unas personas, pero que toda una coalición de partidos que rechazan la violencia puedan ser excluidos de listas electorales por esas personas. ¿Existe una especie de limbo o “purgatorio democrático”?

2. Que esa ilegalización esté basada en una Ley de Partidos, redactada y aprobada por “incumbentes” que afirman ser casi los únicos dos que pueden segurar la paz o la democracia.

RT: cómo impresionar, versión adolescente

No sé las mujeres, supongo que también lo hacen, pero los hombres somos muy dados a hacer el ridículo para tratar de impresionar a la chica que nos gusta. El ridículo que se puede llegar a hacer es proporcional a la fealdad del hombre y a la belleza de la mujer. Yo reunía las condiciones de feo y de gustarme las chicas guapas, así que no me alcanzan todos los dedos para enumerar los grandes ridículos que hice para poder ligar.

Uno de mis mayores ridículos fue por una chica llamada Miriam P. (espero que lea esto ). Yo tenía 15 años, estábamos cuatro amigos de acampada de una semana a la orilla de un pequeño río (riacho, de unos 50 metros de ancho, máximo) afluente del río Paraguay. Era en pleno invierno, la temperatura no llegaba a 10 grados durante el día. El sábado y por esas grandes casualidades que todavía no puedo explicar, aparece Miriam con unos amigos de paseo por esa zona.

De sólo verla me quedé atontado… su pelo rubio, sus ojos castaños, guapísima, irradiaba luz propia. Se acercaron al río, querían cruzarlo, había una canoa pero del otro lado del río. Ella se lamentaba.

¿Qué hizo este adolescente atontado?

Se metió en la tienda, se puso unos pantalones cortos y se lanzó al río, nadó hasta la otra orilla, se subió a la canoa y remó para traerla de regreso. Cuando llegó con cara de triunfo se dio cuenta que estaba temblando, casi con convulsiones. Se bajó de la canoa, cayó al fangoso suelo por los fuertes temblores y sin poder respirar. Miriam estaba preocupadísima, chillaba y salió a buscar abrigos.

No pasó nada, en pocos segundos me recuperé, empanado con fango pero satisfecho por mi acción heróica para que ella pudiese ver de cerca unas vacas de mierda con caras de aburridas al otro lado de la mierda de río de aguas turbias y fría de cojones.

¿Por qué recordé una de mis escenas de seducción más embarazosas? Porque me preguntaba ¿qué lleva a la gente en Twitter a hacer retweets de frases como «Conocí/desvirtualicé a X y es una bellísima persona, encantadora, lista, genial…» cuando X es el que hace el RT?

Así llegué a la conclusión que es como una especie de adolescencia, el Peter Pan electrónico que quiere impresionar a alguien. No está nada mal considerando que antes había que lanzarse a aguas heladas para hacer el ridículo, hoy basta con un clic desde la comodidad usable del Mac.

Epílogo

Al final terminé saliendo con Miriam, pero después de año y pico y cientos de horas de conversaciones telefónicas. Supongo que mi carencia de sex-appeal no ayudó mucho para acelerar el proceso, pero hoy pienso que quizás fue el tiempo necesario para que se haya olvidado del ridículo de este loser ese día de invierno.

Suplantándome la identidad en Facebook

Hace un momento recibí el email que transcribo abajo. Hay personas que se están haciendo pasar por mí en Facebook y me acabo de enterar.

Por supuesto no tengo relación, mi único perfil en Facebook es www.facebook.com/gallir. Agradecería a los afectados que denunciéis a Facebook y me enviéis los datos que podáis (a gallir en gmail o en el mismo Facebook) para intentar ubicar al responsable.

Gracias.

Te escribo este email a raíz de una serie de hechos acontecidos en mi perfil de Facebook y en el de unos amigos.

Te lo mando a tí porque la persona que nos ha estado fisgando, acosando y consiguiendo información nuestra de Facebook dice llamarse Ricardo Galli, osea tu nombre y apellido. Es una persona que se ha ido creando sucesivas cuentas de Facebook y agregando a personas haciéndose pasar por gente suplantando su nombre y apellido/s.

Personalmente y en principio no creo que el asunto tenga que ver contigo, pero me gustaría saber si tienes algún conocimiento de estos hechos. Sino, aprovecho la ocasión para informarte de que alguien haciéndose pasar por ti está realizando acciones cuanto menos poco éticas por el Facebook.

Te copio a continuación la conversación que tuvo la persona que dice ser tu con una amiga indicándole de la creación de un blog contra Facebook por tu parte:

“me llamo ricardo

ricardo galli

ok?

y vais a ser noticia

en el mayor blog contra facebook

estas de suerte

vas a ser famosa

hasta luego”

Espero poder sacar algo claro en este asunto puesto que esta persona está ciber-acosando a mis amistades.

Ha conseguido mi teléfono móvil y otros tantos datos personales tanto de mi como de mis amigos de los cuales se puede hacer un uso fraudulento.

Gracias por tu colaboración.

Cómo montamos Menéame en Amazon EC2

La primera vez que alquilamos servidores dedicados para Menéame fue en ThePlanet.com. Aunque funcionaba muy bien y no tuvimos problemas decidimos traerlos a España para mejorar el ping y apostar por hosting español. Así nos fuimos a Ferca, que nos atendieron muy bien y no tuvimos problemas hasta que fueron absorbidos por Acens. Allí cambió, a peor, con caidas frecuentes de la red, problemas con sus firewalls que bloqueaban conexiones, desaparición del servicio de emergencias, imposibilidad de ver nuestras estadísticas… y lo que colmó nuestra paciencia es que a pesar que nos cobraron religiosamente los meses de noviembre y diciembre no nos enviaron las facturas (aún esperamos respuesta).

El tema del hosting suele ser un dolor de cabeza, y si además necesitas una arquitectura sofisticada, o escalable debes sacar el talonario y prepararte a gastar dinero que desde mi punto de vista no tiene justificación. Como llevaba probando y “jugando” con Amazon EC2 desde hace tiempo decidí hacer pruebas. Después de horas de cálculadora y viendo que nos costaría sólo un poco más que Acens (pero menos que otras ofertas que recibimos) pero nos daría mucha más flexibilidad y fiabilidad decidimos hacer la migración.

La arquitectura básica es la que se muestra en la siguiente imagen (prohido reirse de mi dibujo a mano con la mejor voluntad y dedicación):

Actualización: Britxardo me envió un par de parches con los esquemas:

Tenemos dos servidores (instancias) permanentes, aws0 y aws1, y un número variable de instancias que sólo atienden a las peticiones web. Todos los servidores ejecutan Ubuntu Karmic, de las imágenes (AMI) oficiales de Ubuntu para EC2.

El kernel que se ejecuta en cada instancia debe ser compatible con el “anfitrión” de Amazon, Canonical tiene un convenio con Amazon para validar su kernel, que son mucho más modernos que otras distribuciones (estas imágenes –AMI– se encuentran en “Community AMIs” de EC2). También nos interesaba Ubuntu Karmic porque en la migración cambiaríamos el tipo de motor de la base de datos a MyISAM a InnoDB y la versión de InnoDB del MySQL 5.1 está muy mejorada con respecto a la 5.0 de la última Ubuntu LTS (08.04).

Servidor principal: aws0

Es el “servidor central”, del tamaño large (m1.large) de 64 bits, cuesta $ 0.38 por hora, con 7.5GB de RAM y además la imagen está montada y arranca de un EBS (Elastic Block Service, un “disco persistente” con mejor rendimiento). Además de las ventajas obvias de persistencia de datos permite que en cualquier momento detengamos la instancia y la volvamos a iniciar con otros parámetros, por ejemplo más CPU y memoria RAM.

Los servicios que da este servidor son:

• Servidor MySQL: Aprovechando la migración hemos pasado a usar InnoDB y usar las transacciones/commit donde más hacían falta.
• Servidor NIS y NFS: Todo el software del Menéame y las cuentas de usuario están exportadas por NFS que son usadas por aws1 y las instancias web. Para centralizar la gestión de cuentas usamos el NIS.
• Servidor principal DNS: Es el primario de la zona meneame.net y notame.net.
• Servidor memcache: Usado por todas las instancias web.
• Servidor SVN para la gestión del software.
• Servidor SSH
• Servidor SMTP: Recibe todos los correos desde las otras instancias. Debido a las restricciones de Amazon EC2 para el correo saliente, todos los correos lo enviamos vía AuthSMTP (más adelante lo explicamos)

Teníamos muchas dudas de cómo se iba a comportar con carga real a la base de datos, y estamos gratamente sorprendidos, durante el funcionamiento normal no supera el 50% de uso de la CPU como se puede ver en la imagen (los picos de madrugadas son por el cálculo del karma y otras tareas como generación de “summaries”)

Mysql

Es fundamental la configuración mínimamente correcta del servidor MySQL, en caso de InnoDB es muy crítico el tamaño del buffer, como tenemos un total de 7.5 GB le asignamos 5 GB de RAM.

[mysqld]
default-character-set=utf8
server-id=1
set-variable=max_connections=1000
set-variable=query_cache_wlock_invalidate=True
table_cache=1024

innodb_buffer_pool_size = 5G
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 0
innodb_additional_mem_pool_size = 16M
innodb_log_buffer_size = 8M
innodb_file_per_table = True

join_buffer_size = 1M
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 2M
thread_cache_size = 64
thread_concurrency = 8
query_cache_size        = 96M
query_cache_limit = 16K
query_cache_type        = 2
tmp_table_size = 64M
max_heap_table_size = 64M
wait_timeout = 60

Servidor secundario y de backups: aws1

Esta es una instancia m1.small, de 32 bits, cuesta $0.095 por hora, con 1.7 GB de RAM, un sistema raiz de 10 GB y otro adicional (en /mnt) de 150 GB (ninguno de los dos es persistente)

• Secundario DNS
• Réplica en tiempo real de la base de datos (slave)
• Sphinx para las búsquedas

Esta instancia ya la teníamos funcionando desde noviembre como secundario DNS, ahora simplemente la reaprovechamos para hacer más cosas. Las fundamental es la réplica en tiempo real de la base de datos, que nos sirve para hacer backups a discreción sin afectar al servicio web, también lo usamos para muchos scripts de control que son “pesados” en consultas (en MyISAM era imprescindible hacerlo así porque bloquea todos los updates, con el InnoDB ya no se nota, de todas formas seguimo usando el slave para estas tareas).

También estamos usando (no acabamos de configurar todo) el S3Sync para hacer backups diarios a S3. El S3Sync emula de alguna forma el tradicional rsync, pero para trabajar sobre el sistema de S3.

Réplicas con balanceo de carga y escalado automático

Decidimos poner todo el servicio web en un sistema que se autoescale automáticamente, no sólo por la cuestión de precios sino por la tranquilidad que en momentos de mucha carga no habrá problemas de saturación (como nos ocurrió durante la Eurocopa, que tuvimos que montar un servidor adicional en EC2, pero al hacer réplica en EEUU de un servidor en España no iba muy fino por las enormes latencias).

La decisión fue poner todos los servicios web en una misma imagen:

• Apache con PHP para HTTP y HTTPS (puerto 80 y 443)
• Lighttpd para los ficheros estáticos (puerto 81)

Desde hace tiempo usamos mnmstatic.net como dominio para los ficheros estáticos, esto mejora la carga desde el navegador y evita que el navegador envíe los cookies de meneame.net [*] cada vez que se baja una imagen, en las pruebas que habíamos hecho se ahorra hasta 14KB de tráfico de subida en cada página.

[*] No son sólo los nuestros, que son sólo dos, sino también todos los que definen vía javascript los medidores como Google Analytics, podéis verificarlo en vuestros navegadores.

Cada instancia al arrancarse monta por NFS el directorio donde tiene acceso a todo el software y las imágenes (estáticas y dinámicas). Esto se hace el el fstab, pero hay que tener cuidado con las opciones, fundamentalmente la opción bg para que que bloqueada al arranque, y otras para aumentar la eficiencia y tolerancia a errores.

# /etc/fstab: static file system information.
proc                       /proc  proc   defaults        0       0
/dev/sda3                  None   swap   defaults        0       0
/dev/sda1                  /      ext3   defaults        0       0
/dev/sda2                  /mnt   ext3   defaults        0       0
x.x.x.amazonaws.com:/home  /home  nfs    rw,bg,noatime,soft,nolock,intr,async,nodev,nocto,ac,actimeo=15 0 0

Balanceo (Load Balancer)

Como tenemos que balancear del puerto 80 dos tráficos diferentes (al Apache y al Lighttpd) tuvimos que definir  dos baleanceadores diferentes (web-balancer y static-balancer). Cada balanceador te da una dirección IP y nombre DNS. Uno de los balanceadores –web-balancer– redirecciona a los puertos 80 y 443 y el otro –static-balancer– redirecciona del puerto 80 al 81 del lighttpd.

Para cada una de las réplicas elegimos primero el tamaño pequeño (m1.small), pero el primer día de funcionamiento (el lunes) y a pesar que durante las fiestas el tráfico es bastante menor que lo habitual vimos que el AutoScaler creaba cinco  instancias para poder atender a la demanda, y durante las horas de menor tráfico no bajaba de dos. Me soprendió bastante, no esperaba que el consumo del Apache fuese tan elevado.

Me puse a estudiar y comparar con el vmstat, ví que las estadísticas del monitor de EC2 (CloudWatch) no se correspondían con estas. Investigando más me di cuenta del problema, el vmstat –al menos con el kernel de Ubuntu– no toma en cuenta la “capacidad” real de CPU asignada sino la del procesador. La asignada es un 40%  de la total de la CPU (fácil de comprobar, se pone un proceso que consuma el 100% de cpu –por ejemplo yes > /dev/null– y se mira la columna idle del vmstat, en este caso el idle indicaba 60%).

Entonces tenía que buscar una solución más barata, y encontré una solución muy buena, bonita, potente y barata, usar una instancia orientada a CPU para el Apache. EC2 ofrece este tipo de instancias, las High-CPU Instances. Con la c1.medium y por sólo el doble de precio ($0.19/hora) podía tener una máquina con la misma memoria y algo menos de prioridad de E/S (que es muy poca, sólo los logs del Apache) pero con 5 veces la capacidad de CPU.

Así que reconfiguré el AutoScaler para que cree las instancias del tipo c1.medium y problema solucionado: desde que lo pusimos en marcha no ha creado ninguna instancia adicional, nunca superó al 80% de CPU:

AutoScaler

La configuración del escalador automático es casi lo último que se hace, necesitas tener definido los balanceadores y la imagen (AMI) que se usará para arrancar las réplicas. A diferencia de lo anterior, que se puede crear y modificar con la consola web del Amazon AWS, todavía no existe esa opción para el AutoScaler (aunque seguro que la agregan en las próximas semanas).

Por ahora toca hacer con los scripts, se necesitan definir tres cosas que están mostradas en el código de abajo:

# Crea la configuración para lanzar las instancias
as-create-launch-config web01cpu --image-id ami-ami-d3fad1a7 --instance-type m1.small --group default,www

# Define el grupo de autoscale llamado web-group
# Se "conecta" a los dos balanceadores
# Después de tomar una decisión no hace nada durante 180 segundos
as-create-auto-scaling-group web-group --launch-configuration web01cpu  --availability-zones eu-west-1a  --min-size 1 --max-size 6 --load-balancers web-balancer,static-balancer --cooldown 180

# Define los parámetros para crear o destruir
# Crea cuando consume más del 80% de cpu durante dos minutos
# Destruye cuando baja del 30%
as-create-or-update-trigger web-trigger --auto-scaling-group web-group --namespace "AWS/EC2" --measure CPUUtilization --statistic Average --dimensions "AutoScalingGroupName=web-group" --period 60 --lower-threshold 30 --upper-threshold 80 --lower-breach-increment=-1 --upper-breach-increment 1 --breach-duration 120

Con todo lo comentado anteriormente, esta es la situación habitual de funcionamiento del Menéame:

Para mostrar el funcionamiento del escalador puse la CPU de la instancia web al 100% (ejecutando dos yes > /dev/null para poner al 100% cada una de las CPU) para obligar a crear otra instancia.

Aquí se puede ver como el trigger indica HighBreaching, es decir que se superó el límite superior

$ as-describe-triggers web-group --headers
TRIGGER  TRIGGER-NAME   GROUP      STATUS         NAMESPACE  MEASURE         STATISTIC  PERIOD
TRIGGER  web-trigger    web-group  HighBreaching  AWS/EC2    CPUUtilization  Average    60

Aquí se oberva como la “capacidad deseada” es de 2 y que inició la creación y arranque de una nueva instancia:

$ as-describe-auto-scaling-groups web-group --headers
AUTO-SCALING-GROUP  GROUP-NAME  LAUNCH-CONFIG  AVAILABILITY-ZONES  LOAD-BALANCERS                MIN-SIZE  MAX-SIZE  DESIRED-CAPACITY
AUTO-SCALING-GROUP  web-group   web01cpu       eu-west-1a          static-balancer,web-balancer  1         6         2
INSTANCE  INSTANCE-ID  AUTO-SCALING-GROUP  AVAILABILITY-ZONE  STATE
INSTANCE  i-04ef2c73   web-group           eu-west-1a         InService
INSTANCE  i-4e7dbe39   web-group           eu-west-1a         Pending

Finalmente las dos instancias ya están activas y accesibles:

$ as-describe-auto-scaling-groups web-group --headers
AUTO-SCALING-GROUP  GROUP-NAME  LAUNCH-CONFIG  AVAILABILITY-ZONES  LOAD-BALANCERS                MIN-SIZE  MAX-SIZE  DESIRED-CAPACITY
AUTO-SCALING-GROUP  web-group   web01cpu       eu-west-1a          static-balancer,web-balancer  1         6         2
INSTANCE  INSTANCE-ID  AUTO-SCALING-GROUP  AVAILABILITY-ZONE  STATE
INSTANCE  i-04ef2c73   web-group           eu-west-1a         InService
INSTANCE  i-4e7dbe39   web-group           eu-west-1a         InService

Así es como se ve en la consola:

Problemas encontrados

Tuvimos dos problemas fundamentales.

HTTP SSL detrás del balanceador

El primero es que las instancias sólo “ven” la IP privada del balanceador y envía una cabecera HTTP para indicar la original, esto no ocasionó gran problema porque el software del Menéame ya estaba preparado. Pero con el SSL (o HTTPS) la cosa es muy distinta, en estos caso la conexión entre el balanceador y la instancia no es vía HTTP, sino TCP (por razones obvias, la comunicación va cifrada) por lo que no se recibe nada de información de la IP del cliente.

Esto obligó a modificaciones y agregar campos de control en los formularios de registro y login vía el servidor seguro. No fue nada importante, pero me obligó a pensar bastante en una solución razonablemente segura (digo razonable porque seguro que se le pueden encontrar problemas si se le dedica tiempo).

Envío de correo por AuthSMTP

El segundo problema fue inesperado y el que nos retrasó la migración del día sábado al domingo. El viernes recibimos un email de Amazon indicándones que estábamos enviando correo saliente (nuestras pruebas de envío de validación de cuenta y recuperación de contraseña) y que nos iban a bloquear la salida. Además vimos que agregan automáticamente nuestras IPs al Spamhause.

Aunque te envían el URL de un formulario para pedir la autorización decían que hay que esperar por lo menos dos días hábiles (hoy nos enviaron un email diciendo que ya estudiaron el caso y nos autorizan, pero las IPs siguen apareciendo en Spamhause). Fue un momento de depresión, además ví que es un problema en Amazon por las medidas que tomaron para evitar spammers en su servicio.

Pero encontré una solución buena, bonita y barata: AuthSMTP.

Por un precio muy razonable ellos se encargan de enviar el correo de tus usuarios o todo el dominio. Funciona muy bien y muy rápido, te olvidas del problema que las IPs de tus servidores de correo aparezcas en esas demoníacas bases de datos de spammers.

En nuestro caso la configuración del Postfix de aws0 fue muy sencilla, sólo tuvimos que agregar las siguientes líneas al main.cf:

relayhost = mail.authsmtp.com:2525
smtp_connection_cache_destinations = mail.authsmtp.com
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = static:USUARIO:PASSWORD
smtp_sasl_security_options = noanonymous
default_destination_concurrency_limit = 4
soft_bounce = yes

Con esto se solucionó el problema más grave que encontramos y pudimos hacer la migración.

Costes mensuales

• 1 m1.large: $ 273
• 1 m1.small: $ 64.8
• 1, 2 instancias c1.medium web de media (máxima): $ 164.16
• 2 TB transferencia de datos: $ 340
• 1 EBS de 50GB almacenamiento + aproximadamente 50 Mops= $ 11
• 3 instancias medias medidas con Cloudwatch: $32.4
• 2 Balanceadores: $40.32 + $16 de 2 TB de tráfico, $56.32

Coste total estimado: $ 941.68, al cambio actual del euro queda en 649 € mensuales

Fin

Sí, se pueden encontrar ofertas más baratas, y es un poco más de lo que pagamos a Acens (pero mucho menos que otras ofertas que recibimos), pero te olvidas de estar atado por una arquitectura, de tener que hacer engorrosas y largas negociaciones si necesitas un nuevo servidor, de abrir averías por la red (en Amazon está todo monitorizado y es público,  una caída afecta a muchos servidores, así que no tardan nada en resolver).

Y lo más importante, es el futuro, mucho más sofisticado, pero también más divertido (y creo que además más ecológico, el hardware está mucho mejor aprovechado) y como administrador de sistemas/programador/CTO tienes una libertad y flexibilidad impensable hace pocos años.

Como conclusión, por ahora muy positivo. Ya veremos como evoluciona, conociendo la historia de EC2 no dudo que agregarán cada vez más servicios y que bajarán los precios una vez al año.

PS: Son las cinco de la mañana, lo publico como está, disculpad los errores que haya, ya los corregiré luego.

Kindle, Spofity y la legitimización del DRM como “servicio”

Primero la aclaración y gran disclaimer de mis propias contradicciones: estoy en contra del DRM, sin embargo tengo un Kindle con DRM (para decirlo todo, también un teléfono Nokia, un Sony-Ericcson y un Android, todos tienen programas reproductores con DRM, además de no ser libres).

Compro muchos libros, fundamentalmente técnicos en Amazon.co.uk. Desde hace tiempo que quiero dejar de comprar libros en papel por varias razones:

1. ecológicas (papel, transporte),
2. coste (los libros en papel son más caros, y en Amazon.co.uk son más caros que en EEUU),
3. rapidez (un libro en Kindle te llega en segundos),
4. comodidad (es más cómodo y ligero que un tocho de papel).

Hasta ahora no lo había comprado porque sólo servía para leer los libros de Amazon (o sea DRM + customer lockin), pero hubo un par de cambios importantes:

1. Amazon tiene servicio de conversión por email. Tiene uno que te cobran $0.99 por megabyte (lo probé una vez, con un PDF de 3MB, pero todavía no me han cobrado), envías un documento por email a tu cuenta Kindle (usuario@kindle.com), te convierte el fichero y te lo sube al Kindle. Tiene otro gratuito (usuario@free.kindle.com) al que envías el documento, luego te responde con un enlace donde lo puedes bajar a tu ordenador y copiarlo al Kindle vía USB.
2. En la actualización de firmware de hace pocas semanas incluyeron un lector de PDF, lo que permite que puedas tener tus libros. Nota: aprendí en carne propia que el PDF es un pésimo formato para eBook [*], pero también aprendí y comprobé que el Kindle lee perfectamente el formato .mobi.
3. Conocí el programa Calibre (programado en Python, multiplataforma) que gestiona bilbioteca de eBooks, los convierte a casi cualquier formato y además detecta automáticamente el lector enchufado al USB y hace las conversiones necesarias de forma automática según los formatos que acepta el dispositivo.
4. Es un cacharro barato comparado con los demás: me costó más o menos 220 € incluido transporte y aduana, el Papyre está a 299 € (aunque se puede conseguir algo más barato en PC City, al menos hasta la semana pasada, conseguí comprarlo a 257 € por una oferta a empresas en su página web).

[*] El Kindle no recorta bien los márgenes de los PDF, por lo que achica las fuentes hasta hacerlas ilegibles, tampoco permite hacer zoom salvo que se rote le pantalla para leer en apaisado (muy incómodo). Tengo un Papyre 6.1 y en este sentido funciona mucho mejor que el Kindle.

Así que me decidí y compre un Kindle. Estoy muy contento con el “ecosistema” Kindle + Amazon + Calibre. Puedo comprar libros de Amazon rápidamente (aunque el catálogo no tiene todavía nada que ver con los de papel), el cacharro funciona muy bien, es muy ligero, y puedo leer casi cualquier libro gracias al Calibre (los originales PDF suelen dar problemas, si tenéis opción elegid un .fb2, .epub, .mobi o html, que son convertidos mucho mejor, si es que hace falta –el Papyre los lee a todos–).

Luego comenté varios de estos temas en Twitter, varios han criticado o comentado que es mala opción por su DRM. Pero me sorprendió una cosa: creo que casi todos los que criticaron son usuarios [y fans] de Spotify [*] (y algunos de iTunes). Es más, muchas de esas personas ponen de ejemplo a Spotify como el “futuro de la comercialización y distribución de música”.

[*] Suelen pasar enlaces por Twitter de lo que están escuchando, y los que no tenemos Spotify debemos conformarnos con una página de error sin indicar siquiera de qué canción se trata.

Nunca usé Spotify porque:

1. es un sistema con un protocolo cerrado,
2. sólo puedes oir la música en su propio programa (Windows, Mac o algunos móbiles para la versión Premium),
3. no hay alternativas libres,
4. no hay ninguna alternativa para GNU/Linux (salvo el de usar el Wine),
5. sólo puedes escuchar lo que tienen en su biblioteca,
6. no puedes almacenarlas localmente para escucharlo cuando quieras (salvo la versión de pago, pero sólo con el programa de Spotify), hacer copias, ediciones etc.,
7. pueden eliminar las obras que les apetezca, sin previo aviso y sin derecho a reclamación.

En resumen, que me parece el peor de los DRM, sólo que cambia el método de cobro:

1. Una cuota mensual de “all you can eat” para no tener publicidad, poder escuchar en los móbiles y en “off line” (mientras vas de viaje, por ejemplo)
2. Gratuito si admites publicidad (que es una forma de pagar con “atención” en vez de con dinero) y sólo para escuchar en el ordenador en streaming (i.e. “on line”).

Es decir, para muchos de lo que están en contra del DRM basta con cambiar el método de cobro, o que sea “gratuito” para que el peor de los DRM ya no sea tal. No entiendo esta lógica, me parece profundamente incoherente, o como mínimo que no se haya entendido el problema de fondo del DRM.

La justificación de que es “gratuito” no es lógica, porque el DRM no se trata sólo de dinero, y porque pagas indirectamente con publicidad.

La justificación de que puedes “compartir” con otros tampoco tiene sentido, porque sólo pueden hacerlo aquellos que instalen sus programas, tengan Windows o Mac, acepten las condiciones restrictivas y que además coincida con la zona/país, porque en otros países puede no estar en la biblioteca, o incluso hay países (creo que la mayoría) donde Spotify no ofrecen servicios.

¿Qué pasaría si Amazon no cambia nada de su DRM pero cambia el método de cobro? Por ejemplo pagar 12 euros al mes para leer los libros que quieras. O meterte publicidad entre el texto de los libros. Con la misma lógica el Kindle ya no tendría DRM, a pesar que no hayan cambiado una coma del código ni un transistor del hardware.

No se sostiene. Tampoco pretendo justificar a Amazon ni a mi contradicción: sigue teniendo DRM, sigue siendo una contradicción (al menos por ahora).

En realidad la diferencia fundamental es la “actitud”, aquellos que usan Spotify ya lo hacen a sabiendas de que no quieren “poseer las canciones”, sólo escucharlas. Mientras que para los libros no pretenden sólo leerlos, sino también poseerlos. Pero no deja de ser un cambio de actitud consumidora, más que en la [no] existencia real del DRM.

¿Pasará también lo mismo con los libros digitales? ¿dejaremos de querer “poseerlos”?

Si es así, como parece indicar la lógica, la comercialización como servicio de las obras artísticas habrá convertido al DRM es una condición necesaria pero aceptada, a tal punto que el concepto de DRM –y lo malo que es/era– habrá quedado en el olvido.

No sé si será bueno, malo, peor o mejor, pero claramente es un dilema cada vez más difuminado, incomprendido… o del que es mejor no hablar. Pero seguramente este año, con la popularización de los lectores eBook  se convertirá en tema de debate y acusaciones entre “autores” y “lectores” por la “piratería de libros”, como pasa con la música.