Ser Libre

En Estados Unidos la Election Night que terminó con Barack Obama como nuevo presidente significó mucho trabajo para quienes se encargan de las plataformas de los sitios web de noticias. Según las estadísticas de Akamai (que es la mayor de red de entrega de contenidos – CDN) anoche, cuando se anunció el triunfo de Obama, se superó el record de visitas por minuto para los sitios de noticias : 8 millones y medio. Y aunque no todos los almacenan sus contenidos en Akamai se puede deducir que la mayoría de sitios web de noticias alcanzaron su pico más alto de tráfico. De hecho Yahoo ya había estimado el doble o hasta el triple del páginas vistas que en las elecciones del 2004.

Data Center Knowledge tiene un buen resumen de algunas estrategias previstas para la gran noche: más hardware, más caché y mayor ancho de banda. Twitter salió bastante bien parado con su Election 2008 salvo algunos hipos que tuvo durante la noche. Pero la cobertura de la twittosfera en tiempo real convirtieron al sitio en una de las fuentes preferidas para noticias de las elecciones. En el Twitter Blog han mostrado algunas estadísticas bastante generales pero que dan una idea de lo que se vivió internamente. Es bueno saber que ya corrigieron muchos de los problemas que tenían. Por lo que ve, en algunos momentos aplicaron su conocida estrategia de deshabilitar características para aliviar la carga. A mi me parece una idea muy buena pero que debe planificarse antes para no alterar el normal comportamiento del sitio.

Por lo demás el resto de sitios de noticias: NY Times, CNN, Google News se comportaron a la altura lo cual habrá de un gran trabajo de la gente que estuvo detrás. Seguro que después de un merecido descanso saldrán a contar su experiencia.

Ah, y el dato open source del día: BarackObama.com, la web del ganador, funciona en una plataforma LAMP. ¡Excelente!

Firefox 3 utiliza una base de datos de Top Level Domains para, entre otras cosas, denegar el uso de cookies HTTP entre dominios distintos. Los navegadores antiguos usaban un algoritmo más permisivo. Ésto puede ocasionar problemas si el dominio en el cual se trabajan las cookies no está autorizado por la Public Suffix List . La lista se hizo necesaria porque hay distintas políticas en cada país para asignar Top Level Domains.

Por ejemplo en Perú, se usa el .com.pe, el .org.pe, etc. Pero hasta hace poco no se permitía registrar dominios .pe . Por lo tanto en la lista sólo aparece: *.pe (lo cual incluye a todos menos a los .pe). Sin embargo, desde hace unos meses nic.pe PERMITE el registro de dominios .pe

Resultado: cuando uno navegaba con Firefox 3 por dominios .pe las cookies no pasaban. Si usabas algún tipo de autenticación basada en cookies HTTP la cosa fallaba. El problema fue reportado a Mozilla y se corregirá la lista eliminando el *.pe y agregando pe, com.pe, org.pe, etc. tal como se lee en el desarrollo del “bug” reportado. Hay algunas dudas sobre los TLD’s a agregar, nic.pe tiene la palabra.

ACTUALIZADO
Ayer 25 de setiembre salió la versión 3.0.2 de Firefox con la nueva lista y los dominios agregados. El Software Libre es lo máximo.

Hace unos meses me uní al equipo de desarrollo web de el Grupo El Comercio. Junto a César , nos dedicamos, entre otros proyectos, al nuevo sitio web del diario Perú 21 . No sólo un cambio en diseño (del cual ya han hablado muchos) sino también de plataforma. Y me alegra decir que a pesar de todas las cejas levantadas que hemos visto en el camino, el software libre está presente y muy bien posicionado.

La elección del servidor web ha sido interesante Apache y Lighttpd cumple cada uno su tarea y Nginx está a la espera listo para funcionar en caso de que se le necesite. Drupal es la herramienta que usamos para publicación pero con muchas modificaciones de parte. Yo sigo teniendo mis dudas con Drupal pero me ha gustado mucho su modularidad, que lo convierte en una herramienta muy flexible para este tipo de desarrollos tan personalizados. Y sí es Drupal, inmediatamente hablamos de PHP y MySQL, de los cuales no hace falta decir más.

Se me hace difícil mencionar la cantidad de herramientas open source que están siendo usadas para hacer grandes o pequeñas tareas. Es seguro que más adelante les dedicaré algunas líneas. Por ejemplo Ganglia y Nagios me ayudan muchísimo en estos momentos que el nuevo sitio está en línea para poder tener una idea de cómo van los servidores. Por ahora nuestra herramienta de control de versiones es Subversion, que ha funcionado bastante bien aunque tiene algunas cositas que no me terminan de gustar.

Y eso sin contar el tema de seguridad … pero seguiría interminablemente. Claro, en el proceso he aprendido mucho gracias a esa inmensa comunidad que hace temblar a cualquier “full support” que te ofrecen las empresas de software propietario.

No hace falta decir más, solo que el software libre sigue pateando los traseros de las nenas propietarias.

Ganglia es una herramienta originalmente dirigida al monitoreo de sistemas tipo clusters o grids recolectando información de todos los nodos y procesándola para mostrarla en gráficos consolidados. Lo he encontrado particularmente útil porque me permite obtener el dato en el mismo servidor origen (digamos número de consultas mysql) y enviarlo a otro servidor central que hace tareas de monitoreo.

Se instala de manera muy sencilla y se compone de tres partes: Gmond que es un servicio que recolecta los datos y los envía a otro servidor. Gmetad se encarga de procesar esta información y generar los archivos para el rrdtool . Y finalmente un frontend web para mostrar la información.

En el equipo o nodo que queremos monitorear instalamos ganglia y gmond. En el archivo /etc/gmond.conf cambiamos sólo el nombre del cluster al que pertenece nuestro nodo para agruparlo con otros. Gmond utiliza multicast para enviar su información pero también se puede accesar a través de un puerto TCP (por defecto el 8649).

En el servidor de monitoreo instalamos ganglia, gmetad y el frontend. Y ahí más bien solo nos interesa modificar el archivo /etc/gmetad.conf con los datos de los nodos que vamos a monitorear:

data_source “micluster” x.x.x.x:8649

Y listo, reiniciamos los servicios en cada lado y ya debería existir comunicación entre ambos. Para comprobarlo accesamos a ganglia via web y ya veremos nuestro cluster “micluster” y los nodos que hemos accesado además de una serie de información que de arranque nos ofrece ganglia (carga de CPU, memoria, etc.). Además nos ofrece un consolidado de todos los equipos en el cluster.

Claro que se puede hacer lo mismo con Cacti , pero el proceso se me hizo mucho más sencillo y te permite graficar la información que desees siempre y cuando la puedas obtener como un valor numérico. Este proceso lo veremos en otra ocasión.

Pueden darle una mirada a una demo de Ganglia para el UC Berkeley Millenium Project . Aunque ya sabía de Ganglia anteriormente no había notado su poder hasta ahora y en parte fue gracias a la presentación que hizo John Allspaw de Flickr para la conferencia Velocity, en la cual habla de Ganglia como una de las herramientas que usan en Flickr para el planeamiento de capacidad.

Hay un detalle curioso que encontré al estar revisando un script en PHP. El script se llama index.php y se encuentra dentro de un directorio mail. Entonces si se quiere llamarlo desde un formulario se podría usar:

<form action="http://dominio.com/mail" method="post">

Con mod_dir lo que debe hacer Apache es convertir mail a mail/ (haciendo un redirect 301) y llamar al index.php ya que está definido en la directiva DirectoryIndex de la configuración del Apache . El redireccionamiento también se podría hacer con mod_rewrite o un Alias. Todo funciona a la perfección excepto por el detalle que los datos no pasan al script, todo lo que se envía por POST se pierde.

Revisando los logs de apache se encuentra:

x.x.x.x – - [02/Apr/2008:15:33:10 -0500] “POST /mail HTTP/1.1” 301 320
x.x.x.x – - [02/Apr/2008:15:33:10 -0500] “GET /mail/ HTTP/1.1” 200 8176

Se ve que /mail se considera un redireccionamiento (301) y pasa a /mail/ pero el detalle está en que el POST se convierte en GET. En la documentación de los códigos de respuesta de HTTP se encuentra en una nota para el 301:

Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.

Parece que éste error no sólo se aplica a clientes HTTP/1.0. Lo he probado con Firefox y Opera como clientes y además en Apache y Lighttpd con idénticos resultados.

La solución: poner el trailing slash al final. Además por una cuestión de orden. Cuando el servidor web recibe una petición a mail lo primero que hace es buscar un archivo con ese nombre y luego recién busca el directorio y hace el redireccionamiento. Doble trabajo que no realizaría con el trailing slash colocado.

A List Apart dice El trailing slash es tu amigo y Steve Souders de Yahoo que evitemos los redirect