El problema con Twitter es Ruby On Rails

Aunque mucha gente lo sospecha, creo que nadie se atreve a decirlo publicamente por temor a la ola de críticas, pero a la luz de las evidencias, al parecer los problemas de escalabilidad de Twitter estan directamente relacionados con el framework que se utilizó para su desarrollo Ruby On Rails, que ha tenido tanto momentum actualmente.

Por qué digo ésto, pues por el post que he leído el día de hoy en el blog "Datawocky" de Anand Rajaraman, el artículo en cuestión tiene un título bastante descriptivo "SMS Gupshup de la India tiene tiene tres veces más usuarios que Twitter y sin caídas". Rajaraman, tiene ciertamente una visión muy próxima a dicha empresa de la India, pues está en contacto con los fundadores de la misma, y como dice en su post, las estadísticas muestran de que hay algo malo con Twitter, aquí las comparaciones:

  Twitter SMS Gupshup
Número de Ususarios: más de 1 millón 7 millones
Mensajes enviados diariamente: 3 millones más de 10 millones

Lo más sorprendente es que tanto SMS Gupshup y Twitter usan servidores con aquitecturas x86, corriendo Linux y usando MySQL como el motor de base de datos. Pero a diferencia de Twitter, SMS Gupshup usa una arquitectura de tres capas con un servidor de applicaciones JBoss entre el servidor de base de datos y el servidor web.

Para aquellos que no lo sepan JBoss corre sobre Java, no precisamente uno de los lenguajes más veloces para desarrollar aplicaciones, otros Start-up usan también Linux/MySQL y han podido escalar bien sin problemas, es más AdSense corre sobre servidores x86 y usa MySQL como DB, y sirve literalmente miles de millones de páginas diariamente. La pregunta es entonces qué es lo diferente en Twitter, la respuesta es simple y evidente Ruby On Rails (RoR).

Buscando en Google sobre malas experiencias con Ruby On Rails, encontré un artículo de Derek Sivers, titulado "7 razones por las que volví a PHP luego de 2 años con Ruby". Es un largo y detallado artículo publicado en Septiembre del año pasado en O’Reilly, básicamente explica que uno de los problemas con RoR es que requiere mucho más hardware para servir el mismo tipo de tráfico que un servidor LAMP corriendo una aplicación equivalente.

Es más encontré también un post en el popular blog de tecnología TechCrunch, titulado "Twitter dijo estar abandonando Ruby On Rails", en dicho post escrito por el mismo Michael Arrington, se puede leer lo siguiente: "Hemos escuchado de múltiples fuentes que: después de más de dos años de un muy notorio problema de escalabilidad, Twitter esta planeando abandonar Ruby on Rails como su framework web e iniciaría un desarrollo desde cero con PHP o Java (otra alternativa sería permanecer con el lenguaje de programación Ruby y abandonar el framework Rails)".

En el mismo artículo de Arrintong, se menciona que otros websites que usan RoR son Scribd, Hulu y  la popular aplicación Facebook Friends For Sale. Ciertamente RoR es un framework controversial, muchos desarrolladores dicen que tiene fallas estructurales de diseño que lo hacen imposible de escalar, e incluso el mismo desarrollador de Mongrel, el webserver de Ruby On Rails, Zed Shaw publicó un post en su blog titulado "Rails es un Gueto", luego de abandonar la comunidad de RoR.

Al parecer todo apunta a RoR como una de las razones de los problemas que afronta Twitter, claro cuando el website no es muy visitado, y se tiene suficiente dinero para comprar abundantes servidores, RoR puede seguir operando, pero para aplicaciones web muy populares al parecer RoR es una mala elección. Espero que los que esten haciendo uso del framework actualmente no se sientan ofendidos, pero he tratado de ser lo más imparcial posible.

Hacking en masa a WordPress, ¿Está tu blog en peligro?

En un post aparecido en TechCrunch, escrito por Nik Cubrilovic, se comenta sobre las últimas vulnerabilidades de WordPress, y cómo la popularidad de éste software le ha valido el acedio de cientos de crackers que buscan tomar el control de los blogs que usan WordPress, para lanzar ataques sobre otros o simplemente ser usados como plataforma para lanzar camapañas de spam o phising. Es más ahora se habla de campañas de hacking en masa a blogs que tienen a WordPress como su gestor de contenidos.

Aunque en éste blog he escrito repetidas veces sobre como mejorar la seguridad en WordPress, al parecer post como "Asegurando tu blog" o "Nueva vulnerabilidad en WordPress 2.3.3", no sirvieron de mucho porque igual he detectado que muchos de los blogs que hosteo en mi servidor fueron hackeados, esa fue una de las razones por las que moví mi blog a un server virtual diferente y puse todos los websites que hosteo en otros dos servers virtuales uno con control panel y otro sin control panel.

El mayor de los problemas con los hacking exitosos es que no dejan una huella visible que le permita al dueño del blog darce cuenta del problema, ya que muchas veces las técnicas usadas esconden el código maligno encriptandolo, si desean saber las técnicas más comunes de esconder código en WordPress y una descripción básica de como se producen los ataques recomiendo la lectura del artículo "¿Tú WordPress esta hackeado?", lamentablemente sólo disponible en inglés actualmente, si tengo tiempo (lo cuál sería un milagro), es uno de los artículos que deseo traducir para incluirlos en mi lista de tutoriales y howtos.

El problema con WordPress parece que no sólo es su falta de un mecanismo de actualización automática, como se sugirió en alguno de los comentarios en el post de TechCrunch, porque es posible usar el sistema de distribución automática de parches para infectar como se describe en éste artículo de SuccessForce, donde se hace referencia y se comenta un paper (monografía) escrito por investigadores de las Universidad de Carnegie Mellon, Pittsburgh y UC Berkeley titulado "Posibilidad de generar exploits para sistemas parchados automáticamente: Técnicas e Imprementaciones".

Aunque hay técnicas que permiten proteger el servidor como las descritas por mí en el post "PHP Suhosin excelente patch de seguridad para servidores compartidos", me dí cuenta que cuando se lo aplicaba los servidores que hosteaba los websites que no son míos, éste afectaba el comportamiento de algunas páginas, razón por la cuál tuve que removerlo de dichos servidores y sólo dejarlo activo en el servidor que tiene mis blogs. Y aunque hay productos comerciales que ofrecen soluciones firewall para aplicaciones PHP como "firewallscript", su precio y su dudosa eficacia, al menos para mi, no aportan una solución real al problema de hostear WordPress en servidores compartidos.

A la fecha no hay mejor solución a los problemas de seguridad de WordPress, que tenerlo siempre actualizado a la última versión disponible, lo cuál no es práctico para muchas personas que por alguna razón u otra están atados a una versión particular de WordPress, o aquellos para los que conseguir hacer funcionar su WordPress, fue el equivalente a poner un hombre en la luna.

Finalmente, y no por último menos importante, es que los blogs hackeados no siempre son de personas completamente neófitas o que carecen de formación en TI porque algunos de los blogs que he visto hackeados son de presionales en TI, incluso en el artículo de Cubrilovic, el mismo describe como hackearon uno de sus blogs dos veces, a pesar de que lo había actualizado. Además cuando el hacking es exitoso y consiguen instalar el back door, los atacantes suelen esconder muy bien sus troyanos y se necesita mucho tiempo para detectarlos, eso lo puedo decir por experiencia, pues lo he vivido con un par de blogs de clientes que hostean en mi server.

Al final creo que esta es una razón más para no desalentarme y completar la migracrión de éste blog a Blogger, como lo propuse en un post anterior. Aunque tampoco descarto una solución híbrida de tener los post  y comentarios en Blogger, pero el renderizado de las páginas aún realizado por uno o varios servidor propios.

Aprendizaje 2.0

En el blog Bokardo, encontré un interesante post de Joshua Porter, sobre como la nueva web con sus redes sociales amenaza y a la vez le da una salida a la forma de aprendizaje tradicional, llamada Cartesiana, y para mi fue la primera vez que vi el término Aprendizaje 2.0 (Learning 2.0). Aunque Porter señala a su amigo Brian Christiansen como el que le índico el camino, en realidad Christensen se basa sobre un documento PDF llamado "Minds On Fire" (Mentes en llamas) de los autores John Brown y Richard Adler.

En el documento de Brown/Adler se cita por ejemplo que luego de hacer públicos los escritos académicos producidos por los alumnos de sus cursos, observaron como cuando los alumnos se dieron cuenta de que otros leían sus post, comenzaron a mejorar la calidad y extensión de los mismos. Lo cuál lleva a la conclusión de que las personas se esfuerzan y procuran hacer un mejor trabajo si saben que su obra será mostrada en público.

Adicionalmente Brown/Adler promueven una nueva forma de ver el aprendizaje. Ellos identifican una forma tradicional de realizar la enseñanza a la cuál llaman "Cartesiana", donde el conocimiento se ve como un objeto que puede ser transmitido de profesor hacia los alumnos, y la pedagogía desde ese punto de vista no es más que una metodología que procura maximizar esa transferencia de conocimientos. Sin embargo si se tiene una visión social del conocimiento, la nueva visión propuesta por Brown/Adler, la enseñanza es vista de otra manera, ya que es la participación en un grupo la que genera conocimiento. A la idea Cartesiana de "pienso luego existo", Brown/Adler proponen una visión social del conocimiento y acuñan la frase "participamos en un grupo, luego existimos".

Como una prueba de su nueva visión social del conocimiento, alegan que por eso los grupos de estudio son más eficientes que el estudio individual, porque le da la oportunidad a los miembros del grupo de intercambiar roles y volverse maestros, recordandonos la conocida frase de "la mejor manera de aprender algo es enseñandolo", lo cuál es básicamente la escencia de casi todo blog técnico, pues lo que procuramos es poner información útil tanto para el autor, como para los que leen el blog. Si lo pensamos bien un HowTo o un FAQ no son más que una versión simplificada de lo que sería una lección en clase.

Ya que yo no podría explicar éstos conceptos mejor que los autores, les traduzco lo que ellos han propuesto sobre el Aprendizaje 2.0:

"El énfasis en el aprendizaje social está en agudo contraste con el punto de vista tradicional Cartesiano sobre los conocimientos y el aprendizaje, que ha sido la visión dominante sobre la que se ha estructurado la educación durante los últimos cien años. La perspectiva Cartesiana asume que el conocimiento es una especie de sustancia y la pedagogía se enfoca a la mejor forma de transferir esta sustancia, por parte de los profesores a los estudiantes. Por el contrario, en lugar de partir de la premisa cartesiana de ‘pienso, luego existo’ y de la hipótesis de que el conocimiento es algo que se transfiere a los estudiantes a través de diferentes estrategias pedagógicas, la opinión social de aprendizaje dice: ‘Nosotros participamos, por lo tanto existimos’.

Esta perspectiva cambia el centro de nuestra atención de el contenido a las actividades de aprendizaje y las interacciones humanas que en torno al cual se encuentra el contenido. Esta perspectiva también ayuda a explicar la eficacia de los grupos de estudio. Los estudiantes de estos grupos pueden hacer preguntas para aclarar alguno puntos que no esten claros o sean confusos, puede mejorar su comprensión del material estudiado al ver las respuestas a las preguntas de sus compañeros de estudios, y quizás la más poderosa de todas las herramientas, puede asumir el papel de maestro para ayudar a los demás miembros del grupo lo cuál beneficia su comprensión (una de las mejores maneras de aprender algo es, después de todo, enseñar a los demás)."

Las herramientas sociales del web 2.0, defitivamente están impactando la educación y cambiaran la forma de realizar el proceso de enseñanza, de alli que el Aprendizaje 2.0, no sea simplemente dictar clases por Internet, sino permitir que grupos enteros interactuen unos con otros intercambiando roles de profesor/alumno, sin la necesidad de que dichos grupos esten en geográficamente próximos.

Tal vez uno de los ejemplos más claros de como un desarrollo social de conocimiento puede redifinir las reglas de la economía y la sociedad, es el software libre (OpenSource), que ha llegado a producir no solamente conocimiento, sino también riqueza. Además nos permite multiplicar el conocimiento ya producido haciendo uso de la comunidad (red social) que los distribuye y mantiene.

Leer éste post y ojear el documento "Minds On Fire" me ha abierto los ojos sobre el futuro de la educación y las inmensas posibilidades de nuevos emprendimientos en ésta área, al menos ahora ya se hacia donde debo de orientar mis esfuerzos en desarrollar aplicaciones GAE (Google Apps Engine). Es decir al desarrollo de herramientas (software) que las redes sociales puedan usar para crear conocimiento de forma colaborativa.

El peor error que he visto en Debian

Bueno la última semana ha estado tomando demasiada notoriedad el error en la libreria OpenSSH, que ha afectado a varios sistemas operativos, incluído Linux. La causa del problema es que hace un par de años se removió un par de líneas del código de la librería para evitar los contínuos ataques de buffer overflow a que era propenso OpenSSH, pero creo como efecto secundario, que el único número realmente aleatorio incluído en el algoritmo para generar las claves fuera el PID, que en Linux sólo toma un valor entre 1 y 32767 (aunque jamas es 1, porque ese suele ser el PID del proceso init que carga el kernel en si mismo).

Así que culaquiera podía adivinar por fuerza bruta la clave usada para encriptar la información porque sólo había que probar 32767 semillas, peor aún el proceso se hacía más rápido si se utilizaba diccionarios con los fingerprints de las claves, osea que cualquier sniffer podía capturar data para luego ser analizada y por simple fuerza bruta obtener la información encriptada en los paquetes.

Todo aquel software que usase las librerías OpenSSH estaba afectado, eso incluía obviamente el sshd (el daemon del SSH), que usamos a dirario para administrar remotamente nuestros servidores, pero también se han visto afectados los certificados SSL, que deben ser regenerados nuevamente luego de que el sistema ha sido parchado.

Aunque parchar el sistema es fácil, es tan secillo como hacer ésto como root:

# apt-get update
# apt-get dist-upgrade

El problema es que todos los certificados que hemos generado usando un Linux desde el 2006 y hasta el 13 de mayo de éste año, deben ser generados nuevamente, y ese es todo un lío, porque debemos de generar los certificados para todos aquellos servicios que confían en la encriptación como el https, ftps, imaps, pop3s, smtps, etc.

Y hacer eso me ha tenido ocupado toda la mañana de hoy. Aquellos que no esten seguros si su sistema esta dentro de los afectados, puede salir de dudas descargando y usando éste simple script de python:

http://demo21.ovh.com/82a960d7199ea9391c73c2034b6b34dfP/debian_ssh_scan_v4.tar.bz2

Espero que mientras el sistema no estuvo parchado no hayan sido hackeados con algun tipo de ataque man in the middle, sólo para estar seguros revisen si no hay nuevos usuarios creados en su sistema, o actividad sospechosa. Esperemos que ésto no se siga ramificando.

Configurando tu propio GAE server

Una de las novedades de Google que más me ha llamado la atención en los últimos meses es GAE (Google App Engine), que permite utilizar la red de Google para desplegar nuestra aplicación web y ganar de forma transparente la habilidad de soportar millones de visitas diarias a la vez de tener la data replicada, resolviendo los dos problemas serios que enfrenta todo Startup de la industria de las Tecnología de la Información, escalabilidad y disponibilidad del servicio.

El principal problema actualmente con GAE, es que esta en fase beta y sólo se puede acceder a él por invitación, afortunadamente cuento con una de esas invitaciones, pero me puse a pensar en todos aquellos que desean probar el servicio y no tienen una cuenta actualmente. Por más que quisiera ser generoso, Google no permite más de tres proyectos en GAE actualmente, y no puedo borrar proyectos, así que hasta yo debo ser cuidadoso con mis tres oportunidades.

Entonces ¿qué podemos hacer,? pues bien, Google ofrece actualmente en el SDK del GAE un webserver muy simple que nos permite probar nuestra aplicación GAE en nuestra propia máquina, el problema es que por defecto el script dev_appserver.py sólo escucha en el localhost en el puerto 8080. Se me ocurrio sencillamente jugar un poco con las opciones de configuración y consegui que trabajara usando el IP público y el puerto 80, actualmente tengo ese tipo de solución corriendo en http://gae.volkanrivera.com

Es importante tener presente que no todas las funcionalidades de GAE estan soportadas por el dev_appserver.py la pérdida más importante es la posibilidad de logueo usando una cuenta de Google. Tenga en cuenta que éste tipo de solución que expongo aquí implica ciertos riesgos así que le recomiendo que lo haga sobre un servidor virtual que puede sencillamente apagar en caso de problemas (alguien hackeo el dev_appserver.py y lo esta usando para enviar spam).

Comencemos con la configuración, como usuario "root" instale estos paquetes:

# apt-get install g++ zip unzip less postfix proftpd pound

De ser necesario puede reconfigurar el postfix usando éste comando:

# dpkg-reconfigure postfix

Cuando sea preguntado sobre que tipo de instalación desea para el proftpd, selecciones "standalone".

Luego edite el archivo /etc/proftpd/proftpd.conf y agregue estas líneas:

TimesGMT                        off
DefaultRoot                     ~

Hagalo después de éstas línea:

# Port 21 is the standard FTP port.
Port                            21

Adicionalmente deshabilite el protocolo ipv6 en el /etc/proftpd/proftpd.conf de ésta forma:

UseIPv6                         off

Ahora edite el archivo del proxy inverso /etc/pound/pound.cfg y sólo deje estas líneas, tenga cuidado en reemplazar www.xxx.yyy.zzz por el IP público de su server:

User            "www-data"
Group           "www-data"
LogLevel        1
## check backend every X secs:
Alive           30

ListenHTTP
        Address www.xxx.yyy.zzz
        Port    80

        xHTTP           0

        Service
                BackEnd
                        Address 127.0.0.1
                        Port    8080
                End
        End
End

Luego edite el archivo /etc/default/pound y coloque el valor de la variable startup=1

Ahora instalemos el SDK, para ello debemos descargarlo e instalarlo como root de ésta forma:

# cd /usr/src
# wget http://googleappengine.googlecode.com/files/google_appengine_1.0.2.zip

# unzip google_appengine_1.0.2.zip
# mv
google_appengine /usr/local/gae

Ahora que tenemos instalado nuestro SDK debemos proceder a crear un usuario que deseamos usar para probar el GAE en nuestro caso usaremos el nombre de usuario gae, pero puede ser cualquiera.

# adduser gae

Finalmente cambiamos al usuario "gae" y continuamos el resto de la configuración como dicho usuario:

$ cd ~/
$ cp -R /usr/local/gae/demos/guestbook/ ./

Necesitamos crear dos scripts uno para arrancar el servidor GAE y otro para detenerlos aquí esta el script para arrancar el dev_appserver.py, puede llamarlo start_gae

#!/bin/bash

/usr/local/gae/dev_appserver.py
–enable_sendmail
$1
2>~/gae.log &

Aquí esta el script para detenerlo, puede llamarlo stop_gae:

#!/bin/bash

kill -9 `lsof -i :8080 | grep ^python | awk ‘{print $2}’`

Antes de arrancar el servidor GAE, necesitamos crear los siguientes archivos, lo haremos con el mismo usuario que correrá GAE usando estos comandos:

$touch /tmp/dev_appserver.datastore
$touch /tmp/dev_appserver.datastore.history

Si no tiene privilegios para crear esos archivos, pues sencillamente creelos como "root" y luego cambie el propietario con el comando chown.

Ahora ya estamos listos para iniciar el servidor GAE, que por el momento lo usaremos para correr la aplicación demo que viene dentro del SDK llamada guestbook, para ello como el usuario "gae" ejecutaremos éste comando:

$ ./start_gae guestbook/

De haber hecho todo de bien Ud. debería de obtener ésto con un netstat -tl:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 localhost:webcache      *:*                     LISTEN
tcp        0      0 *:ftp                   *:*                     LISTEN
tcp6       0      0 *:ssh                   *:*                     LISTEN
tcp6       0      0 *:smtp                  *:*                     LISTEN

Observe que "webcache" es el nombre del puerto 8080. Ahora como usuario "root" debemos de iniciar el proxy inverso, para ello usamos este comando:

# /etc/rc.d/pound start

Listo ahora podemos ver nuestro guessbook sencillamente apuntando al IP público o usando un nombre de dominio válido apuntado a dicha IP.