Una pregunta que me estuve haciendo durante algún tiempo después de instalarme el servidor de listas Mailman fue cómo demonios hacer un backup de la lista de suscriptores. Se pueden encontrar muchos scripts en la red que permiten llevar a cabo esta tarea con más o menos dificultad porque dependen de otras herramientas que podrían no estar instaladas en nuestra distribución linux, o simplemente porque nuestros conocimientos de linux y sus entresijos son limitados. Estos scripts están bien, no tengo nada contra ellos excepto lo dicho: ponerlos en marcha puede resultar complicado debido a las dependencias y a veces lo que buscamos es una solución más sencilla.

Así que hoy se me ocurrió una pregunta sencilla: ¿Qué comandos se pueden ejecutar sobre las listas vía email? (aparte de los comandos de suscripción y desuscripción). En http://www.gnu.org/software/mailman/mailman-member/node41.html encontré la respuesta, y al llegar al final del documento la esperanza inundó mi corazón:

who [PASSWORD]
See everyone who is on this mailing list.

¿Así de fácil?. Bueno, me faltaba saber a qué dirección debía mandar ese mail. Después de dar algnas vueltas por aquí y por allí (leer la documentación de mailman es una pesadilla) encontré la información que me faltaba. El email debía mandarse a la dirección

[nombre_de_la_lista]-request@[dominio_de_la_lista]

Ni corto ni perezoso mandé un mail a una de mis listas utilizando la dirección sugerida y puse en el cuerpo del mensaje «who» seguido de la contraseña de acceso a dicha lista.

La respuesta fue inmediata, aunque no recibí lo que esperaba sino el siguiente mensaje:

Los resultados del comando que ha enviado por correo electrónico más
abajo. También se ha incluido su mensaje original.
– Resultados:
Ignorando partes MIME que no son text/plain
– Proceso terminado.

Así que deduje que a mailman no le gustan los correos en formato html (la configuración por defecto de mi cliente de correo). Creé otro correo exactamente igual, pero esta vez formateado como texto plano, lo mandé y esperé unos segundos. Lo que me llegó a continuación fue exactamente lo que el manual prometía: un listado de todos los suscriptores a mi lista. Una estupenda noticia, ya podía hacer un backup de una manera rápida y sencilla sin complicarme la vida con scripts de servidor.

Nota final para usuarios exigentes: Sí, si tienes cientos de listas con miles de suscriptores en cada una de ellas y lo que quieres es un backup semanal o diario de todos esos datos, lo que necesitas es un script de servidor sin duda. Hay varios escritos en python. Este me parece bastante bueno respecto a otros que he probado: http://paulschreiber.com/blog/2006/08/30/mailman-mailing-list-backup-script/.

Hace poco estuve trabajando en la web afterguantanamo.com y uno de los requisitos que queríamos cubrir era la posibilidad de tener la web en varios idiomas y que en función del país desde el que se visitase (después de todo se trata de un tema internacional), la web se mostrase en un idioma o en otro de manera automática. Para conseguirlo era necesario utilizar algún sistema de geoposicionamiento, por lo que me puse a investigar las opciones disponibles.

Después de mirar por aquí y por allá, encontré que el servicio de wipmania.com era una solución rápida bastante fácil de implementar que no exigía prácticamente ningún esfuerzo. Además, el servicio es gratuito, lo que lo hizo una elección muy sencilla respecto a otras soluciones de pago. Para utilizar este servicio no hay más que pasar a su servidor la consulta con la IP de la que queremos averiguar el país, y este nos devuelve un código de 2 caracteres que representa de forma unívoca a cada país. En principio, la consulta sólo se puede realizar a través de un método GET con el formato

http://api.wipmania.com/[DIRECCION_IP]?[URL]

donde [DIRECCION_IP] es la IP de la que queremos obtener el país y [URL] es la dirección de nuestra página web.

La única pega que tiene este magnífico servicio es que limitan el número de consultas que se pueden realizar por dominio y día a 10.000 (para eso hace falta el parámetro URL). Si prevemos que nuestro website puede generar más de 10.000 consultas diarias, entonces esta solución no es válida, o habría que combinarla con algún tipo de limitación interna que previera un comportamiento por defecto una vez rebasado el límite diario.

Investigando más a fondo descubrí que el API de wipmania.com también contaba con una interfaz de consulta javascript-json y -mira qué bien- si la consulta se hacía a través de este API en vez de a través del método GET anteriormente descrito, la limitación de consultas por día desaparecía, por lo tanto esta fue la solución inicial para afterguantanamo.com: al cargar la página principal se ejecutaba un script que realizaba la consulta por ajax (con jQuery para facilitar las cosas) hacia wipmania.com y realizaba una redirección una vez averiguado el código de la ciudad. El script era algo así:

$(document).ready(function(){
  var castellano = "AR,BO,CL,..."; //países de habla castellana
  var frances = "FR,CD,..."; //países de habla francesa
  var italiano = "IT,VA,..."; //países de habla italiana
  $.getJSON("http://api.wipmania.com/jsonp?callback=?", function(data) {
    if(castellano.indexOf(data.address.country_code)>-1)
      location.href="castellano/";
    else if(frances.indexOf(data.address.country_code)>-1)
      location.href="francais/";
    else if(italiano.indexOf(data.address.country_code)>-1)
      location.href="italiano/";
    else location.href="english/";
  });
})

Para completar la información he de decir que el API javascript-json devuelve muchos más datos aparte del código del país: latitude, longitude, zoom, address.city, address.country, address.country_code y address.region. Se puede encontrar una explicación más detallada de lo que significa cada uno de estos resultados aquí : http://www.wipmania.com/en/blog/geolocation-api-json-jsonp/, y por cierto también se puede descargar un listado de todos los códigos de todos los países aquí : http://static.wipmania.com/static/countries.txt.

Esta solución funciona perfectamente excepto por un pequeño detalle : la latencia o retardo que sufre la página como consecuencia de la consulta hacia un servicio externo, que en caso de wipmania.com es muy bajo, pero aun así, son 2 ó 3 segundos que se añaden a la carga inicial de la página, y yo quería que esta fuera lo más rápida posible.

GeoIP de MaxMind al rescate

A pesar de que la página funcionaba correctamente y que después de varias semanas de prueba no nos había dado ningún problema, yo no estaba contento con esos segundos de más que se añadían siempre a la carga inicial de la página. La solución para ello era conseguir de alguna forma consultar algún tipo de base de datos local que a ser posible devolviera lo mismo que Wipmania: un código de 2 letras que me permitiese identificar los países fácilmente, y obviamente yo no estaba por la labor de crear semejante tipo de base de datos.

La búsqueda me llevó al sistema propuesto por Maxmind que es precisamente eso: una base de datos local que te puedes descargar e instalar en tu servidor y que además tiene APIs para un montón de lenguajes (C, Perl, PHP, Java, Python, C#, Ruby, VB.NET, Pascal, etc). En este caso la solución también es gratuita si te conformas con pocas prestaciones (obtener información sólo acerca del país y basándose en una BD con actualización semi-frecuente) y de pago si se desean más prestaciones (información sobre ciudades e incluso poblaciones, o actualización de la BD permanente). Mi caso estaba claro: la base de datos gratuita me bastaba y me sobraba y con el API PHP la solución era perfecta.

La instalación pasa sólo por la descarga y guardado en cualquier carpeta accesible por nuestros scripts PHP del único fichero que compone la BD de países y en mi caso la descarga del API PHP “geoip.inc.php”. Una vez instalado, sólo me hizo falta añadir el siguiente código PHP en la página de inicio:

include("geoip.inc.php");
$gi = geoip_open("[ruta_hacia]/geoip.dat",GEOIP_STANDARD);
$codigo_pais = geoip_country_code_by_addr($gi,$_SERVER["REMOTE_ADDR"]);
echo "..." . $codigo_pais . "..." //meterlo en cualquier contenedor visible por javascript

y posteriormente sólo hace falta modificar el javascript original para que en vez de tomar el código de wipmania lo tome del contenedor en el que hemos escrito nuestro código sacado de la BD local. El código javascript modificado quedaría algo así:

$(document).ready(function(){
  var castellano = "AR,BO,CL,..."; //países de habla castellana
  var frances = "FR,CD,..."; //países de habla francesa
  var italiano = "IT,VA,..."; //países de habla italiana
  var codigo_pais = $("[acceso_al_contenedor]").val();
  if(castellano.indexOf(codigo_pais)>-1)
    location.href="castellano/";
  else if(frances.indexOf(codigo_pais)>-1) 
    location.href="francais/";
  else if(italiano.indexOf(codigo_pais)>-1)
    location.href="italiano/";
  else location.href="english/";
})

Ni qué decir que la latencia por consulta externa queda eliminada y que la velocidad de carga de la página ahora sólo depende de la velocidad y carga del propio servidor web. Misión cumplida.

Es posible que al dar de alta un banner flash en nuestro servidor de banners OpenX nos demos cuenta de que al cabo de unas horas la cuenta de clicks del mismo sigue en 0 (-) a pesar de haber realizado varios clicks de prueba sobre el mismo. La razón es sencilla: Dicho banner tenía el enlace codificado directamente dentro del mismo banner y OpenX no ha sido capaz de reescribirlo (a pesar de haber reportado que sí lo ha hecho). La razón para que esto ocurra es que para sobreescribir el código asociado a los enlaces «hard-coded», OpenX presupone que el banner flash ha sido programado siguiendo unos patrones estándar de programación, sin embargo si dicho banner se ha programado de forma poco convencional, OpenX tendrá problemas para detectar y entender de la lógica de lo que está sobreescribiendo. En palabras tomadas de openx.org :

OpenX can’t check for every type of ActionScript and your link may be using non-standard code which is not easily detectable

Otro motivo por el que OpenX puede estar fallando a la hora de entender el código/reemplazar los enlaces del banner, es que dicho banner no haya sido producido con Adobe Flash, sino por una herramienta de terceros (hay muchas). En estos casos, el código generado también puede ser poco convencional, o simplemente la compresión realizada por dicha herramienta no ser reconocibel por OpenX. También en palabras de openx.org:

Also, if your swf banner was not created with Adobe Flash itself it could be compressed in a way that is not recognized.

La solución:
En estos casos y en general, es preferible utilizar el mecanismo que Adobe Flash pone a disposición de los usuarios para estandarizar la forma de asociar links a nuestros banners. Este estándar se llama clickTAG y es una manera de decirle a flash que ese contenido es enlazable y que dicho enlace será proporcionado desde fuera. La manera de asociar un clickTAG a un banner flash es decírselo a través del ActionScript asociado al evento release del botón asociado al banner (el que permitirá hacer el click). El código ActionScript recomendado es el siguiente:

on (release) {
	if (clickTAG.substr(0,5) == "http:") {
		getURL(clickTAG,clickTARGET);
	}
}

Notas acerca de este código:

• La condición que rodea a la instrucción getURL no es necesaria pero sí muy recomendable para evitar que se inyecte código malicioso a nuestro banner por parte de terceros.
• El segundo parámetro «clickTARGET» no es imprescindible, pero sí recomendable si queremos que el enlace se abra en una ventana diferente a la actual.
• ActionScript es sensible al uso de mayúsculas/minúsculas, por lo que es importante escribir «clickTAG» y «clickTARGET» exactamente así. Por ejemplo «ClickTag» no tendría ningún significado para ActionScript.

Cualquiera que empiece a utilizar OpenX como servidor de banners por primera vez sin duda se hecho estas preguntas. La respuesta es sencilla: OpenX utiliza un sistema de caché propio para mejorar el rendimiento de la aplicación, lo que significa que los conteos no se escriben directamente a la base de datos sino que se actualizan cada X tiempo, donde X es un valor que podemos configurar; mientras tanto la información se mantiene en memoria o en un fichero de texto, dependiendo de cómo hayamos configurado el sistema.

El tiempo de caché por defecto es 20 minutos (1200 segundos), sin embargo esto puede ser un poco molesto cuando estamos haciendo pruebas para ver cómo queda un nuevo banner en nuestra página de destino, o para intentar comprobar que la contabilización se está realizando de manera correcta (lo cual puede ser necesario cuando se incluyen banners flash con enlaces ‘hard-coded’ o incrustados).

Para cambiar este tiempo por defecto lo primero que tenemos que hacer es cambiarnos al perfil de administración : Working as > Administrator Account, y posteriormente tenemos que ir al menú Configuration > Banner Delivery Settings y cambiar el valor Time Between Banner Cache Updates.

Es posible poner 1 segundo, lo que significa que la actualización será prácticamente inmediata, sin embargo es MUY IMPORTANTE acordarnos de dejar el valor por defecto o al menos un valor mayor no menor de 10 minutos cuando terminemos de realizar nuestras pruebas, sino el rendimiento de nuestra máquina puede resentirse en caso de estar sirviendo banners a algún site con muchas visitas.

El problema: Script PHP perteneciente a cualquier aplicación que debería subir imágenes al servidor vía HTTP y no lo hace. El script se ejecuta en entorno Windows + IIS6. La versión de PHP puede ser cualquiera <= 5.3.1 (podría ser también mayor, pero hablo sólo de lo que yo he probado). Varias veces me he encontrado con el mismo problema, y varias veces me ha hecho perderder el tiempo. La primera vez hasta una semana dando tumbos por la red intentando averiguar el motivo de dicho comportamiento, revisando los permisos de las carpetas de la aplicación involucradas en el proceso, revisando los scripts, revisando la configuración del php.ini, y hasta dando permisos excesivos a usuarios potencialmente peligrosos para la web. El resto de veces sólo he perdido unos minutos hasta que recordaba: ¡Ah sí, los permisos de la carpeta temporal de Windows!.

Efectivamente, el problema es que PHP sube los ficheros a una carpeta temporal antes de pasarla a su ubicación final. Esa carpeta temporal puede variar en cada instalación, pero por defecto sería «c:\windows\temp\». Es preciso verificar el valor de la variable de configuración «upload_tmp_dir» en el php.ini para asegurarse de cuál es la carpeta correcta en nuestra instalación.

Y la solución es tan simple como otorgar permiso de escritura a esta carpeta al usuario IUSR_{NOMBRE_DE_LA_MAQUINA}. Mi recomendación es configurar el php.ini para que esta carpeta no sea «c:\windows\temp\», sino una carpeta diferente como por ejemplo «c:\php\temp\upload\» por motivos de seguridad evidentes.

Cambiado esto, y supuesto que todas las demás cosas evidentes relacionadas con la subida de ficheros estén configuradas, todo irá sobre ruedas.