Desde que las conocí, las instancias spot de Amazon EC2 siempre me habían llamado la atención desde la perspectiva económica. Aunque me parecía una forma interesante de sacar provecho económico a un exceso de capacidad de la plataforma EC2 en horas valle, que de otra forma sería desperdiciada, no acababa de entender sus ventajas frente a consolidar los servidores virtuales en un menor número de hosts y apagar los ociosos para ahorrar en consumo eléctrico. Siempre había supuesto, como gran parte de la industria, que el consumo eléctrico era el principal gasto en un datacenter.

No lo entendía hasta que hace unos días tuve la oportunidad de ver la presentación “Datacenter Infrastructure Innovation” (trasparencias) que James Hamilton dió durante el Velocity 2010. En su presentación realiza un estudio de los costes mensuales de un datacenter, mensualizando el coste de los servidores y de las infraestructuras de distribución y refrigeración a lo largo de sus periodos de amortización (3 y 10 años, respectivamente). De esta manera, puede comparar esos gastos con el consumo eléctrico. Y resulta que el que yo suponía era el principal gasto realmente es el tercero, siendo los dos primeros el hardware de los servidores y las infraestructuras, en ese orden.

Como bien explica James, consolidando y apagando hosts se ahorraría en consumo eléctrico pero, al no estar sacando ningún provecho económico al servidor físico ni a la parte proporcional de las infraestructuras de distribución y refrigeración, realmente se está perdiendo dinero. Al contrario de lo que ocurre con el consumo eléctrico, la amortización de las infraestructuras no es algo que puedas ahorrarte.

Pero si tienes exceso de capacidad y apagar los servidores supone realmente un gasto, ¿qué se puede hacer? Ahí es donde encajan las instancias spot. Permiten sacarle provecho al exceso de capacidad que se produce en las horas valle, a un precio que resulta atractivo a los clientes. Mientras escribo este artículo, el precio de las instancias spot es un ~60% más barato que las on-demand. Eso sí, las aplicaciones que corran en este tipo de instancias deben estar preparadas para los apagados abruptos que se producen en cuanto la demanda de instancias “normales” aumenta.

Instancias spot, ahorro económico para los clientes y una forma de aprovechar la capacidad sobrante para Amazon.

Tras nueve meses de sequía bloguera, vuelvo con un post bastante parecido al de “Exponenciación modular” (uno de los que más visitas tiene) que toca uno de los temas que me apasionan: el rendimiento de los algoritmos. Hace bastantes meses leí, via meneame, un post con 140 preguntas que (supuestamente) Google puede hacerte en una entrevista de trabajo. Una de esas preguntas me llamó la atención, tanto que unos cuantos compañeros del trabajo la estuvimos comentando. Te pedían que escribieras un algoritmo muy simple:

Dado un array A[N] de N números. Tienes que generar un array Ouput[N] de manera que Output[i] sea la multiplicación de todos los elementos de A[N] excepto A[i]. Por ejemplo Output[0] será la multiplicación desde A[1] hasta A[N-1] y Output[1] sera la multiplicación de A[0] y desde A[2] hasta A[N-1]…

En ruby es tan sencillo como:

n = A.length
Ouput = Array.new(n) do |i|
  result = 1
  n.times { |j| result *= A[j] unless j == i }
  result
end

El problema es que la pregunta continuaba con:

… hazlo en O(n) …

Ups, hay que repensarlo ya que el algoritmo anterior tiene dos bucles sobre N anidados por lo que es O(n²). Se me ocurrió hacerlo precalculando el producto de todos los elementos de A[N] y hacer que Output[i] = Total / A[i]. Así queda O(n).

product = A.inject(1) { |total, n| total * n }
Output = A.collect { |n| product / n }

Pero faltaba un último detalle de la pregunta:

… sin el operador de división.

Uff, ahora se pone interesante. Tras pensarlo un poco y escribir Ouput como una matriz de los elementos a multiplicar, ví un patrón que me podía servir. La matriz está formada por dos “triángulos” (perdón si el termino no es correcto. Hay algún matemático entre la audiencia?) que llamaremos L, resaltado en azul, y R, en rojo.

Output[0]   = [   1, A[1], A[2], ..., A[N-1]]
Output[1]   = [A[0],    1, A[2], ..., A[N-1]]
Output[2]   = [A[0], A[1],    1, ..., A[N-1]]
...
Output[N-1] = [A[0], A[1], A[2], ...,      1]

Se me ocurrió que esos dos “triángulos” o productos parciales se podían calcular a la vez en un único bucle para usarlos posteriormente para calcular Ouput[i] = L[i] * R[i] ya que:

• L[i] = L[i-1] * A[i-1] para i > 0 (L[0] = 1)
• R[i] = R[i+1] * A[i+1] para i < N-1 (R[N-1] = 1)

n = A.length
left,right = Array.new(n, 1), Array.new(n, 1)
1.upto(n-1) do |i|
  left[i]        =  left[i-1] * A[i-1]
  right[n-(i+1)] = right[n-i] * A[n-i]
end
Output = Array.new(n) { |i| left[i] * right[i] }

Bien, creo que al final lo hemos conseguido. Un algoritmo O(n) que no usa la división y que calcula los resultados según la formula indicada. Además, el algoritmo que usa la división tiene un problema: necesita que los elementos de A[N] sean números naturales (es decir, que no puedan ser 0) mientras que los otros dos algoritmos no tienen esta restricción.

Si os estáis preguntando si realmente hay diferencia de rendimiento entre los tres algoritmos (principalmente el primero versus los otros dos), aquí tenéis un gráfico que lo demuestra.

Como se puede ver, a medida que el tamaño del array A[N] crece los tiempos del primer algoritmo (double loop) crecen exponencialmente mientras que los otros dos (division y triangles) tienen un comportamiento lineal. Por tanto, si que hay diferencia, y mucha.

Los datos de benchmarking para generar el gráfico con el OpenOffice.org Calc los he obtenido he usado el siguiente script que genera CSV.

#! /usr/bin/env ruby
require 'benchmark'
 
def double_loop(input)
  n = input.length
  Array.new(n) do |i|
    result = 1
    n.times { |j| result *= input[j] unless j == i }
    result
  end
end
 
def division(input)
  product = input.inject(1) { |total, n| total * n }
  input.collect { |n| product / n }
end
 
def triangles(input)
  n = input.length
  left,right = Array.new(n, 1), Array.new(n, 1)
  1.upto(n-1) do |i|
     left[i]       =  left[i-1] * input[i-1]
    right[n-(i+1)] = right[n-i] * input[n-i]
  end
  Array.new(n) { |i| left[i] * right[i] }
end
 
t = 1_000
max_size  = 250
step_size = 10
 
step_size.step(max_size, step_size) do |n|
  input = Array.new(n) { rand(100) + 1 }
  t1 = Benchmark.realtime { t.times { double_loop(input) } }
  t2 = Benchmark.realtime { t.times { division(input) } }
  t3 = Benchmark.realtime { t.times { triangles(input) } }
  puts "#{input.length};#{t1};#{t2};#{t3}"
end

Por cierto, si a alguién se le ocurre otro algoritmo que lo ponga en los comentarios.

Las versiones recientes de WordPress te permiten actualizar los plugins instalados con un simple click. Aunque interesante, nunca había usado esa funcionalidad porque requería tener instalado y configurado un servidor FTP o FTPS. Y, la verdad, me daba mucha pereza tener que mantener un servicio sólo para esto.

Pero hoy, tras actualizar a la versión 2.8.1, por casualidad he lanzado un grep en un directorio que no tocaba y he descubierto el fichero wp-admin/includes/class-wp-filesystem-ssh2.php. Resulta que WordPress también puede usar SSH para realizar esas actualizaciones. Normalmente esa opción no aparece por que no disponemos de todo el software necesario para que funcione, pero es bastante sencillo conseguirlo. Veamos como hacerlo en una Debian:

$ sudo aptitude install libssh2-1 libssh2-1-dev php5-dev
$ sudo pecl install -f ssh2
$ sudo vi /etc/php5/conf.d/ssh2.ini
    extension=ssh2.so
$ sudo /etc/init.d/apache2 restart

Una vez tenemos instalada la extensión ssh2.so de PHP, podemos desinstalar los paquetes de desarrollo que instalamos en el primer paso.

$ sudo aptitude remove libssh2-1 libssh2-1-dev php5-dev

Listo, ya podemos actualizar los plugins desde la comodidad de nuestro navegador sin necesidad de tener un servidor FTP o FTPS. Seguramente también se puede usar para actualizar el propio WordPress, aunque no lo puedo confirmar ya que yo lo actualizo usando subversión.

Como se puede ver es bastante sencillo. De todas formas, os dejo un screencast que he hecho sobre la instalación (inaugurando mi cuenta de YouTube).

Hace bastantes meses escribí un artículo sobre como configurar el SpamAssassin para que verifique las firmas DKIM para luchar contra el Spam y me quedó pendiente explicar como firmar nuestros própios correos. Por aquel entonces era más o menos complicado pero desde la release de Debian Lenny, que incluye el paquete amavisd-new 2.6.1, la tarea se ha simplificado.

Voy a dar por sentado que tenemos un Postfix instalado y configurado para que use el Amavis para las funciones de anti-virus y anti-spam. Si no es así, te recomiendo que leas el excelente artículo de Jaume Sabater.

El primer problema lo tenemos si el mismo servidor está actuando como MX y como servidor SMTP para nuestros usuarios: Amavis firmaría tanto los correos de nuestros usuarios como los que le llegan en su función de MX, y no es lo que queremos. Por tanto, lo primero es separar esas dos funciones (MX y submission) en el Postfix añadiendo las siguientes líneas en /etc/postfix/master.cf (seguramente ya haya algo parecido pero comentado)

1
2
3
4
5

submission inet n       -       n       -       -       smtpd
-o smtpd_enforce_tls=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o content_filter=smtp-amavis:[127.0.0.1]:10026

Con estas líneas estamos indicándole al Postfix que también escuche por el puerto de submission (587/tcp), que por ese puerto sólo acepte correo de conexiones autentificadas y cifradas por TLS, y que debe enviar los correos recibidos al Amavis usando el puerto 10026 (mientras que el resto se seguirá enviando por el puerto 10024). Con esto conseguiremos que Amavis distinga y trate de forma diferente los correos de los usuarios.

Lo siguiente es hacer que Amavis también escuche por el puerto 10026 y hacer que firme los correos que le lleguen por ese puerto. Lo haremos añadiendo al fichero /etc/amavis/conf.d/50-user:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

$inet_socket_port = [10024, 10026];
 
$interface_policy{'10026'} = 'AUTH';
 
$policy_bank{'AUTH'}   = {           # Authenticated clients
os_fingerprint_method   => undef, # don't fingerprint authenticated clients
bypass_spam_checks_maps => [1],   # don't spam check authenticated clients
originating => 1,
#
# force MTA to convert mail to 7-bit before DKIM signing
# to avoid later conversions which could destroy signature:
smtpd_discard_ehlo_keywords => ['8BITMIME'],
};
 
$enable_dkim_signing = 1;
dkim_key('llull.net', 'personal', '/etc/dkim/llull.net.key.pem');

En la última línea le indicamos que para el dominio ‘llull.net‘ y el selector ‘personal‘ debe firmar los correos con la clave privada contenida en el fichero /etc/dkim/llull.net.key.pem. Para generar ese fichero ejecutaremos como root el comando

server:~# amavisd-new genrsa /etc/dkim/llull.net.key.pem
Private RSA key successfully written to file "/etc/dkim/llull.net.key.pem" (1024 bits, PEM format)

Ya sólo falta obtener y configurar en nuestro servidor DNS la clave pública y para ello disponemos de otro comando:

server:~# amavisd-new showkeys
personal._domainkey.llull.net.  3600 TXT (
"v=DKIM1; p="
"MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDoTaWXxsXpNi100Flp7fIKJSlZ"
"ptMP4aCCZjUFgT7TsWokWQJhnGUNnxexEqqPtCDbCUAvEg3iieMRrKwZoHAUDqCf"
"fvW9dcYR7+NdnaxAXCBpOh8Wg5GFJeIid9Gsx3ByBObBQnRGSMOxdBRBO4VXwGb2"
"hKAIOiBMPxaFghdDZQIDAQAB")

Y ya sólo falta añadir la salida del anterior comando a la zona de nuestro dominio en el servidor DNS. La salida está en formato Bind por lo que si usamos ese servidor DNS no tendremos más que añadir  ese texto en el fichero correspondiente.

Acordaos de reiniciar el Postfix, Amavis y Bind para que apliquen las nuevas configuraciones. Para comprobar que todo está funcionando correctamente, podemos enviar un correo a uno de los reflectores existentes.

Ahora ya no tenéis escusa para que vuestro servidor de correo no firme los correos salientes. Si os surge alguna duda, usad los comentarios. Aunque creo que me he acordado de todo, han pasado algunos meses desde que lo configuré y es posible que haya pasado algo por alto.

Artículo basado en la documentación oficial de Amavis.

Desde que Xisco me pidió consejo tras probar varias de sus páginas con YSlow tenía pendiente escribir este post. YSlow es un plugin para Firefox que analiza distintos aspectos que pueden afectar al rendimiento de páginas webs y realiza recomendaciones. Todos los aspectos que se tienen en cuenta giran alrededor del tiempo de carga de la web. No entran en temas como optimización de base de datos y otros aspectos internos del servidor.

De todas las reglas, las más sencillas de corregir son:

• Add Expires headers
• Compress components with gzip
• Configure entity tags (ETags)

Otras reglas pueden suponer reescribir parte de la aplicación pero para solventar estas tres basta con añadir algunas líneas al final del .htaccess del directorio raíz de nuestra web. Hay que tener en cuenta que los modulos necesarios deben estar instalados y la configuración del servidor nos debe permitir establecer esta configuración (directiva AllowOverride)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# Add Expires Header
<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType image/gif "access plus 1 week"
ExpiresByType image/jpeg "access plus 1 week"
ExpiresByType image/png "access plus 1 week"
ExpiresByType text/css "access plus 1 week"
ExpiresByType application/javascript "access plus 1 week"
</IfModule>
 
# Compress CSS files
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain text/html text/xml application/rss+xml application/atom_xml
AddOutputFilterByType DEFLATE text/css application/javascript
</IfModule>
 
# ETag only use file time and size, but no inode
FileETag MTime Size

En las líneas 2 a 9 configuramos que las imágenes, hojas de estilo y javascripts tengan una fecha de expiración de una semana a partir del momento en que se ha visitado la página web. Esto significa que el navegador del usuario usará la copia local (fichero cacheado) durante una semana. Este comportamiento puede suponer un problema si tenemos ficheros de estos tipos que vamos modificando sin cambiarle el nombre (p.e. un banner) ya que los navegadores de algunos de los usuarios mantendran las versiones antiguas.

Desde la 12 a la 15 configuramos la compresión de las páginas HTML, feeds (text/xml, application/rss+xml y application/atom_xml), hojas de estilo y javascripts. De esta forma conseguimos ahorrar tráfico (importante si estamos en un hosting con limitaciones de tráfico)  y que el tiempo de transmisión sea menor.

Finalmente, en la última línea configuramos los ETags generados por el propio servidor Apache para los ficheros estáticos. Por defecto, Apache tiene en cuenta tres aspector para generar el ETag: el inodo, fecha de modificación y tamaño. Pero se recomienda no usar el inodo para generarlo ya que si nuestra web empieza a ser conocida y tenemos que distribuir la carga entre varios servidores, es muy poco probable que un fichero tenga el mismo inodo en todos los servidores de la granja. Entonces, el ETag variaría en funcion del servidor que lo generara por lo que no se sacaría provecho a esta cabecera. Para resolverlo, configuramos el Apache para que genere el ETag sólo considerando la fecha de modificación y el tamaño del fichero.

Con esta simple configuración yo conseguí pasar de una puntuación de 74 a 89.

A medida que pueda escribiré algún post más sobre optimización web y como resolverlo en el caso concreto de un blog que usa WordPress.

Icono de Aleph en el iPod Touch

Desde la versión 1.1.3 del sistema operativo del iPhone, puedes añadir enlaces a tus webs favoritas a la pantalla de inicio. Por defecto, el dispositivo crea una miniatura de esa web, pero es tan pequeña que no sirve para identificarla. Por suerte, ese icono se puede personalizar como podéis ver en la captura de pantalla.

Según podemos leer en la documentación de Apple, es tan simple como crear una imagen en formato PNG de 57×57 pixeles (sí, a mi también me parece un tamaño un poco extraño) y colocarlo en la raíz de nuestra web con el nombre  apple-touch-icon.png. El dispositivo  se encargará de redondear las esquinas y darle ese efecto glossy. Pero si nuestra imagen ya tiene algún tipo de efecto de brillo (como me ocurre a mi) queda demasiado sobrecargado: demasiado brillo. Para que el iPhone no añada ese efecto glossy a la imagen manteniendo las esquinas redondeadas, basta con renombrarlo a apple-touch-icon-precomposed.png, como se indica en otra parte de la documentación.

En lugar de usar los nombres por defecto, también podemos dar una referencia a la imagen que queremos que se use como icono añadiendo en la cabecera del documento HTML uno de los siguientes tags dependiendo de si quieremos o no que se aplique el efecto glossy a la imagen:

  <link rel="aple-touch-icon" href="/customIcon.png"/>
  <link rel="apple-touch-icon-precomposed" href="/customIcon.png"/>

Lo que no acabo de entender muy bien son los motivos que puede tener Apple para no usar el favicon (eng) que los navegadores ya usan, entre otras cosas, para asignar un icono al enlace  cuando lo guardamos en nuestros bookmarks. Ya se que normalmente el favicon es de 16×16 píxeles por lo que resulta algo pequeña para la interfaz del iPhone y escalándola quedarían horribles. Pero el formato ICO soporta que en el mismo fichero puedas tener varios tamaños de la imagen. Bastaría con que el iPhone usara la más grande disponible y si ninguna tiene el tamaño mínimo requerido que hiciera lo de la miniatura de la web. Ahora mismo no se me ocurre ningún motivo técnico para tener que usar otra imagen diferente para un fin similar.

Como ya es bien conocido, Apple inició una revolución en el campo de los dispositivos móviles cuando presentó la última generación de los iPod (incluyendo su teléfono móvil, el iPhone) y dió el siguiente paso al publicar la versión 2.x del software de esos dispositivos al añadir el App Store. Gracias a lo cual la funcionalidad de estas plataformas móviles ha aumentado enormemente al permitir que terceras partes publiquen aplicaciones.

Una de estas aplicaciones, WordPress for iPhone, es la que me ha permitido publicar este post desde mi iPod Touch. Todavía le faltan algunas funcionalidades como, por ejemplo, la de un editor enriquecido que permita añadir enlaces o algo de estilo (listas, negrita, etc.) a los post, pero seguro que sólo es questión de tiempo.

Aquellos de vosotros que lleváis más tiempo visitando mi blog, os habréis dado cuenta de que he cambiado el software con el que gestiono mi galería de fotografías. Anteriormente usaba Gallery2 por su integración con WordPress mediante el plugin WPG2 (para el que desarrollé una mejora). Pero si bién era una solución válida, resultaba demasiado compleja. Era como matar moscas a cañonazos. Sólo necesitaba una mínima parte de las características de Gallery2.

Por eso, un día empecé a evaluar alternativas que se ajustaran mejor a mis necesidades. Las únicas características que me interesaban eran que pudiera organizar las fotografías en álbumes, que se pudiera mostrar los datos EXIF de las fotografías, poder etiquetarlas, valorarlas y comentarlas, que se integrara con WordPress y que fuera una herramienta libre. Finalmente encontré Zenphoto, que cumple con todas esas necesidades excepto la integración con WordPress. En su web lo definen como:

Zenphoto is an answer to lots of calls for an online gallery solution that just makes sense. After years of bloated software that does everything and your dishes, zenphoto just shows your photos, simply. It’s got all the functionality and “features” you need, and nothing you don’t. Where the old guys put in a bunch of modules and junk, we put a lot of thought. We hope you agree with our philosopy: simpler is better. Don’t get us wrong though –zenphoto really does have everything you need for your online gallery, and you’ll even stare in awe at some of the innovative innovations we innovated upon.

Con el plugin ZenphotoPress para WordPress conseguí poder añadir fotos de la galería en los posts de forma simple. Pero integrar la apariencia me lo tuve que currar yo, usando como guía este post de Steffen Rusitschka. Pero con ese método Google no indexaba las páginas de la galería, aunque se visualizaban correctamente, porque todas devolvían un status 404. Además, compartían el título (tag <title> del HTML) haciéndolo muy poco Search Engine Friendly. Para solucionarlo tuve que modificar un poco el código de Steffen. Este es el index.php de mi theme integrado con el WordPress:

<?php if (!defined('WEBPATH')) die(); normalizeColumns(3, 6); ?>
<?php require($_SERVER['DOCUMENT_ROOT'].'/wp-blog-header.php'); ?>
<?php
// set the HTTP status
status_header('200');
 
// add the zen headers to the wordpress header
function zentitle() {
  echo '&raquo; '.strip_tags(getGalleryTitle());
}
function addzen() {
  global $_zp_themeroot;
  echo '<link rel="stylesheet" type="text/css" media="screen, projection" href="'.$_zp_themeroot.'/css/master.css" />';
  zenJavascript();
  printRSSHeaderLink('Gallery','Gallery RSS');
}
add_action('wp_head', 'addzen');
add_action('wp_title', 'zentitle');
?>
<?php get_header(); ?>
 
<div class="index">
  <!-- Código original de Zenphoto -->
</div>
 
<?php get_footer(); ?>

Lo más extraño es que yo tengo las bases de datos del blog y de la galería separadas pero no he necesitado hacer lo que comenta Steffen de conectarnos a una base de datos y luego a la otra. Por eso, si comparáis mi trozo de códico con el de Steffen veréis que falta esa parte. Lo siguiente será integrar el login de las dos aplicaciones, para lo que he visto que hay plugins, pero de momento no lo he mirado.

Como las URL de los álbumes han cambiado, también he añadido reglas de redirección en el .htaccess para no perder los enlaces que pudiera haber desde otras páginas.

Al final he conseguido dejarlo bastante bien integrado y estoy muy contento, tanto del resultado como de la aplicación en sí. Tiene justo lo que necesito. Ni más, ni menos.

La aparición a mediados de 1998 de los VirtualHosts basados en nombre en la versión 1.3 del servidor web de Apache significó un cambio importante en el mundo de los servidores web ya que permitía configurar webs en diferentes dominios, todos ellos compartiendo la misma dirección IP. Tampoco hay que olvidar que esa mejora fue posible gracias a que los navegadores (por aquel entonces disponíamos de Netscape Communicator 4.5 e Internet Explorer 4.0 [1]) implementaron la versión 1.1 del protocolo HTTP, según la cual el navegador debe enviar el nombre del dominio al que se están conectando en la cabecera Host, usada por los servidores web para discriminar que a VirtualHost deben enviar la petición.

Desgraciadamente, las webs seguras nunca han podido beneficiarse de esta mejora por la forma en que funciona el protocolo HTTPS (HTTP sobre SSL). La cabecera Host que permite al servidor discernir el host virtual al que va dirigida la petición del usuario está a nivel HTTP, debajo del cual tenemos SSL y su negociación. En esa negociación es cuando el servidor envía al cliente su certificado X.509 y el navegador comprueba la validez del certificado comparando el campo CN del certificado con el nombre del dominio al que se está conectando. Por tanto, el servidor debe enviar el certificado correcto, y por tanto del host virtual correcto, al navegador antes que este le pueda indicar mediante la cabecera Host el dominio al que se quiere conectar. La única solución es usar VirtualHosts basados en dirección IP.

Sin embargo, si los diferentes dominios que tenemos en el servidor son subdominios que comparten el second-level domain, o SLD, podemos conseguir que todos ellos dispongan de web segura usando una única dirección IP. Por ejemplo www.example.com y mail.example.com tienen el SLD example.com en común.

Para conseguirlo, también es imprescindible el uso de un Wildcard SSL Certificate (he decidido no traducirlo porque ninguna de las tradicciones que se me han ocurrido me acababa de gustar), que es un certificado SSL en el que el nombre del dominio contiene un comodín. Por ejemplo: *.example.com. De esta manera, indicamos al navegador que este certificado es válido para cualquier subdominio de example.com. No voy a explicar como se generan los certificados SSL ya que buscando un poco por google se encuentran multitud de páginas al respecto. Si le vamos a dar un uso personal, podéis crear un self signed certificate. La única diferencia con los tutoriales que podáis encontrar es que como dominio introduciremos “*.<dominio>” (Por ejemplo: *.example.com).

Configuración del servidor web de Apache

Voy a suponer que en nuestro servidor tenemos configurado un servidor web Apache2 con varios host virtuales (www.example.com, mail.example.com y un servidor WebDAV para el Subversion en svn.example.com), y que el servidor sólo dispone de una dirección IP.

Lo primero que hay que hacer es poner el servidor web a escuchar en el puerto 443 (puerto estándar de HTTPS) y configurar un host virtual sobre ese puerto:

Listen 443
<VirtualHost *:443>
  ServerName *.example.com
  ErrorLog /var/log/apache2/https-error.log
 
  # Possible values include: debug, info, notice, warn, error, crit,
  # alert, emerg.
  LogLevel warn
 
  CustomLog /var/log/apache2/https-access.log combined
  ServerSignature Off
 
  SSLEngine On
  SSLCertificateFile /path/to/certs/example.com.pem
  SSLCertificateKeyFile /path/to/private-keys/example.com.key
</VirtualHost>

Con esto ya tenemos la capa SSL configurada. El certificado indicado en el parámetro SSLCertificateFile es el Widlcard SSL Certificate que hemos creado anteriormente. A partir de aquí, el “truco” está en el uso creativo del mod_proxy, que conseguiremos añadiendo la siguiente configuración dentro del hosts virtual que acabamos de crear:

  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>
 
  # Proxy requests to ourselves preserving the Host header
  ProxyPass / http://localhost/
  ProxyPassReverse / http://localhost/
  ProxyPreserveHost on

Con esta configuración estamos reenviando todas las peticiones que nos lleguen a este host virtual por HTTPS hacia el propio servidor, pero cambiando el protocolo de HTTPS a HTTP. Es importante destacar la última línea, que le indica al servidor web que debe mantener la cabecera Host al hacerse la petición a sí mismo, gracias a la cual no tendrá ningún problema a la hora de determinar que página quiere ver el usuario.

Para que las aplicaciones web puedan distinguir si la petición que les llega a entrado por HTTP o HTTPS, configuraremos el host virtual para que añada la cabecera X_FORWARDED_PROTO a las peticiones que se hace a sí mismo:

  # Add the X_FORWARDED_PROTO=https to allow applications to identify
  # proxyed https connections
  RequestHeader set X_FORWARDED_PROTO https

Ya sólo queda un detalle, necesario únicamente si vamos a usar esta configuración para proteger un WebDAV. El problema de esta configuración con WebDAV viene a la hora de intentar hacer un ‘svn mv‘, por ejemplo. Este comando indica el destino en la cabecera HTTP Destination. Como el cliente se esta conectando a https://svn.example.com/repo/etc, la cabecera tendrá ese valor. Pero el host virtual que tiene la configuración de WebDAV sólo está configurado para HTTP por lo que espera que la cabecera Destination empiece por http://svn… Para solucionar la inconsistencia entre la cabecera esperada y la recibida echaremos mano del mod_rewrite:

  # Workarrounf for WebDAV Destination header
  RewriteEngine on
  RewriteCond %{HTTP:Destination} ^https://(.*)$
  RewriteRule . - [env=DESTINATION:http://%1,PT]
  RequestHeader set Destination %{DESTINATION}e env=DESTINATION

Resumen de la configuración

Una vez explicadas las diferentes partes de la configuración, os pongo toda la configuración tal cual se debe escribir en los ficheros de configuración del servidor web para que no haya problemas de “¿y esto donde va?, ¿dentro o fuera del virtualhost?” :

Listen 443
<VirtualHost *:443>
  ServerName *.example.com
  ErrorLog /var/log/apache2/https-error.log
 
  # Possible values include: debug, info, notice, warn, error, crit,
  # alert, emerg.
  LogLevel warn
 
  CustomLog /var/log/apache2/https-access.log combined
  ServerSignature Off
 
  SSLEngine On
  SSLCertificateFile /path/to/certs/example.com.pem
  SSLCertificateKeyFile /path/to/private-keys/example.com.key
 
  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>
 
  # Workarrounf for WebDAV Destination header
  RewriteEngine on
  RewriteCond %{HTTP:Destination} ^https://(.*)$
  RewriteRule . - [env=DESTINATION:http://%1,PT]
  RequestHeader set Destination %{DESTINATION}e env=DESTINATION
 
  # Add the X_FORWARDED_PROTO=https to allow applications to identify
  # proxyed https connections
  RequestHeader set X_FORWARDED_PROTO https
 
  # Proxy requests to ourselves preserving the Host header
  ProxyPass / http://localhost/
  ProxyPassReverse / http://localhost/
  ProxyPreserveHost on
</VirtualHost>

Conclusiones

Personalmente veo está configuración como una solución válida para servidores personales en los que se suelen usar self signed certificates o de CAcert. Para pequeñas empresas (con unos pocos dominios) puede ser una solución, pero los Widlcard SSL Certificates de autoridades certificadoras comerciales (cuyos certificados raíz vienen en los navegadores) no son baratos. Dependiendo del hosting creo que saldría más barato contratar IPs adicionales para el servidor y certificados individuales que no usar el Widlcard SSL Certificate en un servidor con una sóla IP.

En empresas medianas o grandes, puede justificarse el uso de Widlcard SSL Certificates si tienen un gran número de subdominios que quieren asegurar ya que puede suponer un ahorro, pero no veo el motivo de tenerlo todo sobre una sóla dirección IP. Por tanto, no veo que la configuración aquí explicada sea aplicable en este tipo de empresas.

A mi, esta solución me está funcionando muy bien y de momento no he encontrado ningún problema.

Notas adicionales

[1] Para los nostálgicos, ¿os acordáis de la guerra de navegadores?

DomainKeys Identified Mail, o DKIM, es un sistema de autenticación que permite verificar que el correo realmente proviene de quien dice provenir. Como los spammers suelen falsificar los remitentes de los correos que mandan, también veremos como esa verificación nos puede servir como un método más para luchar contra el correo no deseado.

DKIM recuerda bastante al Sender Policy Framework, o SPF, cuya finalidad es que los servidores puedan verificar que el servidor que les está entregando un correo está autorizado a hacerlo. Es decir, si el servidor mx.example.org está intentando entregar un correo con remitente user@example.com a mi servidor, este usará SPF para verificar si mx.example.org está autorizado a gestionar el correo de ese dominio. La idea es buena pero, por la forma en que se hace, tiene problemas cuando hay redirecciones o forwards. Para más información, podéis leer la introducción a SPF del proyecto OpenSPF o el artículo de la Wikipedia [en inglés].

Quería introducir un poco SPF para poder compararlo con DKIM ya que ambos tienen finalidades similares y usan el sistema de DNS para publicar la información necesaria. Pero así como SPF publica en DNS qué servidores pueden o no enviar correo de un dominio, DKIM publica una clave pública que se usará para verificar que el correo se originó desde un servidor legítimo, evitando el problema de los forwards. Pero nos estamos avanzando un poco…

¿Cómo funciona?

Simplificando bastante: a la hora de enviar, el remitente firma el mensaje y añade esa firma al correo. Entonces, cualquiera de los servidores por los que pasa el correo, puede comprobar su autenticidad verificando la firma. Aunque cualquiera de los servidores puede, la comprobación normalmente se realiza en el servidor destinatario.

Profundizando algo más, DKIM se basa en sistemas muy usados y conocidos como son la criptografía asimétrica, las funciones de hash y, como ya habíamos anticipado, DNS. Para entender mejor su funcionamiento, vemos la infraestructura que hay que configurar para que pueda funcionar:

1. El administrador del dominio de correo debe generar un par de claves asímetricas.
2. Seguidamente, configurará la clave privada en sus servidores de correo, que la usaran para firmar los mensajes.
3. Finalmente, publica la clave pública como un registro TXT en la zona DNS de su dominio para que los servidores que quieran comprobar la autenticidad de los correos puedan obtenerla.

Ahora ya podemos ver el proceso con más detalle: el servidor remitente calcula el hash del correo teniendo en cuenta el cuerpo y algunas cabeceras, y cifra ese hash con la clave privada generando la firma que se añade al correo. Cuando un servidor quiera verificarlo, como necesitará la clave pública para hacerlo, consultará al sistema DNS para obtenerla y poder realizar la comprobación. Si el correo se originara desde un servidor ilegítimo, como no tendría la clave privada adecuada, la comprobación de la firma fallaría poniendo en evidencia al servidor como posible spammer o phisher.

Como la comprobación no se basa en quién nos está entregando el mensaje sino en quién lo originó, este esquema no sufre de los problemas de SPF con los forwards. Sin embargo, al estar basado en firma digital, tiene problemas con las modificaciones que pueda sufrir el correo durante su transmisión. Por ejemplo, si se añade un disclaimer después de que se haya firmado, la verificación fallará.

Para más información sobre DKIM os remito su web, donde encontrareis multitud de documentación, y, como nó, a la Wikipedia.

Como referencias, decir que tanto Yahoo! como Gmail son dos grandes ejemplos de ISPs que usan DKIM en sus servidores.

DKIM en SpamAssassin

Finalmente, veamos como podemos configurar SpamAssassin para sacar provecho de este sistema. Estoy dando por supuesto que usamos Debian Etch y que ya tenéis el MTA (Postfix o similar) y el SpamAssassin instalados y configurados. Sólo mostraré la configuración a realizar para que se empiecen a comprobar las firmas de DKIM. Desgraciadamente, la versión que viene con Etch no es del todo adecuada por lo que deberemos añadir el repositorio de backports a nuestro source.list. Una vez añadido, actualizaremos la lista de paquetes e instalaremos libmail-dkim-perl, con todas sus dependencias, desde backports:

  server:~# aptitude update
  server:~# aptitude -t etch-backports install libmail-dkim-perl

Ahora sólo falta habilitar el plugin Mail::SpamAssassin::Plugin::DKIM descomentando la correspondiente línea en el fichero /etc/spamassassin/v312.pre. Recordad reiniciar spamd, amavisd-new o el content-filter que uséis para que se aplique la nueva configuración.

Como ejemplo, veamos las cabeceras de un correo enviado desde gmail:

X-Spam-Status: No, score=-0.124 required=4.5 tests=[AWL=-0.185,
	BAYES_20=-0.74, DKIM_SIGNED=0.001, DKIM_VERIFIED=-0.001,
	DNS_FROM_SECURITYSAGE=0.001, HTML_MESSAGE=0.001, P0F_Unknown=0.8,
	SPF_PASS=-0.001]
...
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to
         :subject:mime-version:content-type;
        bh=JvMz4j1uNftb2YwcCYFAjZF73T5HtaC0paeyk3KqFao=;
        b=s2/id2fqmQMef9gWIvn6jhs09lz9nnyOrwepQtQQdzd6Bj8iB/7b2G3PN+bLcOW0k1
         kTs7ew+y8P1rROBlA+T8CpsYirWL0gSp6YZidyhN2SHJVg9ZXQ7oWq6czAcqs/y3871n
         l4Wnm53EqPPNn4Tqos6ruDghAfyJ/deBxFY3Q=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:mime-version:content-type;
        b=U6s9wCp2Q5U7DC0WcQGJ6S6hNwTNmPUiklMd0RtMgB+pJzvP8T/NaqT43Q4QyaukPz
         ig4b3S0/QF3B6uOctVvYQE9YAlgbilx+QxthVzhtc9xvyfePgF63RoebvK28hNlL5VUn
         +0cdEBbEOqkPzo1d1j5XaDGDUV6W/0xHRZb2o=
Received: by 10.210.65.2 with SMTP id n2mr4808273eba.65.1224441206376;
        Sun, 19 Oct 2008 11:33:26 -0700 (PDT)
Received: by 10.210.113.2 with HTTP; Sun, 19 Oct 2008 11:33:26 -0700 (PDT)
Message-ID: <57e22bd310j416695a2d215d0810191133h6297c2b8a@mail.gmail.com>
Date: Sun, 19 Oct 2008 20:33:26 +0200
From: "Gmail user" <user@gmail.com>
To: user@example.com
Subject: DKIM test
MIME-Version: 1.0
Content-Type: multipart/alternative;

Como podéis ver, con la puntuación que le dá SpamAssassin por defecto no mejoramos la discriminación de spam: +0.001 por venir firmado que se compensa con -0.001 porque la firma es correcta. En la lista de correo de spamassassin-users podemos encontrar algunas sugerencias (y sus actualizaciones).

Conclusiones

DomainKeys Identified Mail es otro sistema pensado para verificar el origen del correo que, como el resto de alternativas, tiene sus ventajas e inconvenientes. Y hemos dado unas pinceladas sobre como se puede usar para ayudar a nuestro sistema anti-spam. En un futuro post, explicaré como configurar nuestro Postfix y Bind para que nuestro correo use DKIM.

Yo, personalmente, pienso que más que intentar parchear el protocolo SMTP, debería tomarse la decisión de hacer “borron y cuenta nueva” y diseñar un nuevo protocolo de transmisión de correo teniendo en cuenta todo lo aprendido hasta ahora y especialmente pensado para no permitir el spam.