1. ¿Qué es Liferay?
2. Instalación básica
3. Usando Liferay con MySQL
4. Usando Liferay con Apache
5. Usuario por defecto y un par de ajustes más

¿Qué es Liferay?

Liferay es un gestor de portales web con una gran funcionalidad integrada (gestión de comunidades y usuarios, CMS, wiki, blogs, y mucho más), y a su vez es un contenedor de portlets, lo que le permite ser extendido de manera bastante rápida y flexible (siguiendo la especificación JSR 286: Portlet Specification 2.0). Además, cuenta con una versión Community cuyo uso es gratuito y cuyo código es libre.

Instalación básica

Descargamos la última versión Community con el usuario que arrancará Liferay (en mi caso www-data) en el sitio que queramos (yo he escogido /opt/websites/liferay.deigote.com como directorio base de la instalación):

$ su - www-data
$ cd /opt/websites/
$ wget 'http://sourceforge.net/projects/lportal/files/Liferay%20Portal/liferay-portal-tomcat-6.0-5.2.3.zip'
$ unzip liferay-portal-tomcat-6.0-5.2.3.zip
$ mv liferay-portal-5.2.3/ liferay.deigote.com

Si ahora arrancamos Liferay, podremos ver cómo nos informa en los log de que se usará una base de datos para testing (Hipersonic), y si navegamos por la web, podremos ver una serie de portlets a modo de demo:

$ /opt/websites/liferay.deigote.com/tomcat-6.0.18/bin/startup.sh
$ tail -f logs/catalina.out &
$ firefox http://localhost:8080

Este entorno de demo está bien para cacharrear un poco y ver cómo la gente de Liferay quiere vendernos sus capacidades para hacer un clon de Facebook (vienen instanciados portlets de chat, de muro, de añadir usuarios como amigo, de actividad reciente…), pero los datos no persisten, por lo que no podréis pasar de ahí. Además, Liferay viene por defecto con usa serie de portlets (en forma de plugins) preparados para hacer la demostración antes mencionada. Yo normalmente borro dichos portlets antes de continuar (de hecho, en mi caso borro todos los plugins excepto el de web-form-portlet, que es el único que encuentro útil):

$ rm -rf `ls /opt/websites/liferay.deigote.com/tomcat-6.0.18/webapps | grep -v ROOT | grep -v web-form-portlet`

Para la persistencia de los datos, tenemos que conectar Liferay con un viejo conocido .

Usando Liferay con MySQL

Para conectar Liferay con MySQL existen varias formas. De momento anotaré aquí la más sencilla (aunque para mi gusto un poco “fea”), puesto que no recuerdo exactamente cómo es la otra . Liferay incluye en su core un fichero de propiedades (portal.properties) que configuran prácticamente todos los componentes del portal, base de datos incluida. Ese fichero puede ser extendido mediante el fichero portal-ext.properties, que por defecto no existe. Así que escribimos en él la configuración de la base de datos:

$ echo "# Database connection
jdbc.default.driverClassName=com.mysql.jdbc.Driver
jdbc.default.url=jdbc:mysql://localhost/liferay_database?useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false
jdbc.default.username=mysql-user
jdbc.default.password=mysql-password" > /opt/websites/liferay.deigote.com/tomcat-6.0.18/webapps/ROOT/WEB-INF/classes/portal-ext.properties

A continuación nos conectamos al servidor de mysql (en mi caso, localhost) y creamos la base de datos y un usuario con permisos para la misma:

$ mysql -h localhost -u root -p
$ create database liferay_database
$ grant all privileges on liferay_database.* to "mysql-user"@"localhost" identified by "mysql-password";

Si en este momento arrancamos Liferay de nuevo, deberíamos ver algunos mensajes haciendo mención a la base de datos utilizada (MySQL), y otros que indican que se están creando las tablas..

Usando Liferay con Apache

Para usar Apache como servidor web, creamos un host virtual y lo conectamos al servidor de aplicaciones de Liferay (en mi caso Tomcat) usando un módulo de proxy. Podemos usar el módulo proxy_http, que funcionaría con cualquier servidor de aplicaciones, o el módulo proxy_ajp, específico de Apache, y que presenta algunas ventajas sobre http, aunque yo no las recuerde . Dado que Tomcat soporta AJP, será el que usemos. Dado que yo uso Debian, necesito activar el módulo de proxy_ajp y crear un host virtual que use dicho módulo:

$ su -
# a2enmod proxy_ajp
# nano /etc/apache2/sites-available/liferay.deigote.com
# a2ensite liferay.deigote.com
# /etc/init.d/apache2 restart
# exit

El contenido del fichero /etc/apache2/sites-available/liferay.deigote.com será el siguiente:

<VirtualHost *:80>
        ServerName liferay.deigote.com
        ServerAdmin webmaster@localhost
        ErrorLog /var/log/apache2/liferay.deigote.com_error.log
        LogLevel warn
        CustomLog /var/log/apache2/liferay.deigote.com_access.log combined
        # Proxy to Tomcat
        <Proxy *>
                Order deny,allow
                Allow from all
        </Proxy>
        ProxyPass / ajp://liferay.deigote.com:8009/
        ProxyPassReverse / ajp://liferay.deigote.com:8009/
</VirtualHost>

Antes de echar a andar con esta configuración, debemos añadir un par de líneas al fichero de propiedades de Liferay, ya que si no éste dará por hecho que estamos atacando al puerto 8080 (el puerto por defecto de Tomcat) y escribirá las URL’s con dicho puerto. Una vez realizado este paso, deberíamos poder acceder a Liferay a través del host virtual que hemos usado (siempre y cuando nuestro servidor DNS sepa resolver dicho host, claro):

$ /opt/websites/liferay.deigote.com/tomcat-6.0.18/bin/shutdown.sh
$ echo "
# Webserver configuration
web.server.http.port=80
web.server.https.port=443" >> /opt/websites/liferay.deigote.com/tomcat-6.0.18/webapps/ROOT/WEB-INF/classes/portal-ext.properties
$ /opt/websites/liferay.deigote.com/tomcat-6.0.18/bin/startup.sh
$ firefox http://liferay.deigote.com

Usuario por defecto y un par de ajustes más

Una vez estemos navegando por Liferay, podremos acceder usando el usuario test@liferay.com con la contraseña test, que es administrador de la comunidad por defecto (guest) Yo recomiendo un par de ajustes más:

• Cambiar la dirección de correo (y por tanto el login) y la contraseña del usuario administrador. Esto lo podéis hacer en el Panel de control, en el apartado de Usuarios.
• Modificar el host virtual de la comunidad por defecto (o la que vayáis a usar) para que coincida con el que estéis usando para acceder a través de Apache. Esto se puede hacer en el panel de control, en el apartado Communities – Guest – Manage pages – Settings – Virtual host, usando el campo Public virtual host. Esto permitirá que las URL’s del tipo http://virtual_host/web/nombre_de_la_comunidad/pagina pasen a ser http://virtual_host/pagina, lo cual es más cómodo. Por ejemplo, la URL de la página por defecto (home) en la comunidad por defecto (guest) en mi caso pasaría de http://liferay.deigote.com/web/guest/home a http://liferay.deigote.com/home

Una vez finalizados estos pasos, ya podemos empezar a trabajar con Liferay en un entorno de producción (a falta, por supuesto, de configuraciones y optimizaciones de Tomcat, Apache y MySQL que no vienen al caso ).

Lo primero que debemos hacer es asegurarnos de que tenemos el módulo adecuado. En Debian, por ejemplo, podemos buscarlo e instalarlo si es necesario usando los siguientes mandatos:

$ aptitude search apache subversion | grep svn
# aptitude install libapache2-svn

Además, deberemos asegurarnos de que Apache habilita el módulo, lo cual, nuevamente en Debian, es trivial gracias a la buena organización que tiene de la configuración de Apache:

$ a2enmod dav_svn
# /etc/init.d/apache2 restart


El siguiente paso es crear un repositorio Subversion. Lo habitual es crear uno por proyecto, aunque en mi caso no lo hago así exactamente. Por ejemplo, tengo un repositorio al que llamo personal en el que tengo mi CV, algunas prácticas y cosas pequeñas en las que es más que improbable que participe nadie más que yo. Depende del criterio de cada uno (por ejemplo, a mi siempre me resulta tentador tener un único respositorio para todo, y a la hora de hacer el checkout, hacerlo con ruta relativa al proyecto que necesito), pero recordad que los usuarios, contraseñas y permisos serán los mismos para todo un repositorio. La creación del repositorio la hacemos con los mandatos:

$ mkdir -p /opt/svn/nombre_del_repositorio/
$ svnadmin create /opt/svn/nombre_del_repositorio/repo

Podemos verificar que funciona intentando hacer un checkout:

$ svn co file:////opt/svn/nombre_del_repositorio/repo /tmp/

Por último, creamos los usuarios y passwords del repositorio:

$ mkdir -p /opt/svn/nombre_del_repositorio/passwords/
$ htpasswd -c /opt/svn/nombre_del_repositorio/passwords/.htpasswd usuario

Y procedemos a crear el fichero de configuración del virtual host de Apache. En el ejemplo, lo voy a hacer para dos repositorios, uno llamado personal y otro llamado público, suponiendo que quiera acceder a ambos a través del mismo dominio (svn.deigote.com) pero con distintas localizaciones (/personal y /publico):

<VirtualHost *:80>
   ServerName svn.deigote.com
   DocumentRoot /opt/websites/svn.deigote.com

Como véis, definimos un virtual host para el dominio elegido, y le asignamos un docroot, en el que podríamos poner una página de inicio o incluso vacía (para que si alguien entra directamente en el dominio, no vea el clásico It works! situado en /var/www )(1).

A partir de aquí, para cada localización (personal y publico) establecemos que es un WebDAV de tipo Subversion, e indicamos la ruta del repositorio y del fichero de passwords, tanto para el repositorio personal:

   <Location "/personal" >
     DAV svn
     SVNPath /opt/svn/personal/repo

     AuthType Basic
     AuthName "SVN Deigote - Personal"
     AuthUserFile /opt/svn/personal/passwords/.htpasswd
     Require valid-user

     Order deny,allow
     Deny from all
     Allow from unaipdeconfianza.com
   </Location>

como para el repositorio público:

   <Location "/publico" >
     DAV svn
     SVNPath /opt/svn/publico/repo

     AuthType Basic
     AuthName "SVN Deigote - Publico"
     AuthUserFile /opt/svn/publico/passwords/.htpasswd
     <LimitExcept GET PROPFIND OPTIONS REPORT>
       Require valid-user
     </LimitExcept>
   </Location>

Podemos ver un par de diferencias. Mientras que el repositorio personal pide un usuario válido para todos los casos (es decir, un usuario definido en el fichero de passwords), el repositorio público especifica que necesita un usuario válido excepto para algunas acciones. Básicamente, son el conjunto de acciones que permiten lectura y navegación por el repositorio. De esta manera, todo el mundo podrá ver (acciones checkout, update, etcétera) pero sólo los usuarios válidos podrán escribir (acción commit, add, etcétera) (2)

La otra diferencia es que el repositorio personal tiene una sección que especifica que el acceso es denegado para todos, y admitido para una ip o nombre de dominio. Esto te garantiza que la persona que accede a tu repositorio lo está haciendo desde una IP de tu confianza, aumentando ligeramente la paranoia seguridad.

Añadir que el directorio raiz (/) es un location válido, por lo que podemos configurar un único repositorio para el dominio, aunque sería equivalente a poner dicha configuración directamente en el contexto del virtual host en vez de en el del location.

Añadiendo la información de logs y demás, el fichero de virtual host de ejemplo (/etc/apache2/sites-available/svn.deigote.com) queda como se ve a continuación:

<VirtualHost *:80>
   ServerName svn.deigote.com
   DocumentRoot /opt/websites/svn.deigote.com
   <Location "/personal" >
     DAV svn
     SVNPath /opt/svn/personal/repo

     AuthType Basic
     AuthName "SVN Deigote - Personal"
     AuthUserFile /opt/svn/personal/passwords/.htpasswd
     Require valid-user

     Order deny,allow
     Deny from all
     Allow from unaipdeconfianza.com
   </Location>

   <Location "/publico" >
     DAV svn
     SVNPath /opt/svn/publico/repo

     AuthType Basic
     AuthName "SVN Deigote - Publico"
     AuthUserFile /opt/svn/publico/passwords/.htpasswd
     <LimitExcept GET PROPFIND OPTIONS REPORT>
       Require valid-user
     </LimitExcept>
   </Location>

   ErrorLog /var/log/apache2/error_svn.deigote.com.log
   LogLevel warn
   CustomLog /var/log/apache2/access_svn.deigote.com.log combined
</VirtualHost>

Lo añadimos a la lista de sites y reiniciamos Apache, y ya estamos listos para jugar:

$ a2ensite svn.deigote.com
$ /etc/init.d/apache restart
$ svn co http://svn.deigote.com/personal
$ svn co http://svn.deigote.com/publico


Como nota final, ojo con los passwords. Tened en cuenta que estamos configurando un acceso a través de HTTP, por lo que la información no va encriptada. Para que sí lo fuera tendríamos que configurar el virtual host para ir a través de HTTPS, pero eso lo dejamos para un próximo capítulo (más que nada porque todavía no he aprendido a hacerlo ).

(1) Tened cuidado de no crear directorios en el document root con el mismo nombre que los location. Os encontraréis con un error de este estilo al hacer el checkout:

$ ls /opt/websites/svn.deigote.com # Docroot
personal
$ svn co http://svn.deigote.com/personal/ /tmp/personal
Authentication realm: SVN Deigote - Personal
Password for 'deigote':
svn: PROPFIND request failed on '/personal'
svn: PROPFIND of '/personal': 301 Moved Permanently (http://svn.deigote.com)
$ rmdir /opt/websites/svn.deigote.com/personal
$ svn co http://svn.deigote.com/personal/ /tmp/personal
...
Checked out revision 1


(2) Se puede afinar más usando mod_authz_svn, que permite establecer qué usuarios pueden escribir y cuáles pueden leer sin complicarse mucho, pero yo de momento no lo he necesitado, así que queda para el siguiente capítulo

Como me ha resultado un pelín farragoso, he decidido publicar los pasos por si alguien se ve en una situación parecida.

1. Instalando Ruby
2. Instalando Rubygems
3. Instalando Rails
4. Instalando SQLite y MySQL
5. Instalando Passenger

Instalando ruby

Personalmente, cuando trabajo con Rails (en realidad, con Ruby en general), prefiero tener una instalación basada en Rubygems en lugar de usar el sistema de paquetes de la distribución. Aunque a priori puede parecer peor, a la larga resulta más cómodo (puedes escoger la versión que necesitas y no dependes de que la gema esté disponible como paquete para tu distro, además de que te permite escoger la versión de Ruby, mientras que las gemas precompiladas sólo suelen estar para la versión estable) y más coherente (ya que, como no todas las gemas están disponibles como paquetes, acabas instalando algunas mediante gem y otras mediante el gestor de paquetes, en mi caso aptitude, siendo más complicado identificar qué tienes instalado.).

Por lo tanto, de momento sólo instalaremos el intérprete de ruby y los paquetes de documentación y la shell interactiva, es decir:

sudo aptitude install ruby ri1.8 rdoc1.8 irb1.8

Que en Debian 5 por defecto se traduce en la instalación de la versión 1.8 del intérprete (aunque la 1.9 también está disponible). Los siguientes enlaces simbólicos nos serán útiles si el paquete no los ha creado (para verlo, dpkg -L nombre_del_paquete):

cd /usr/local/bin
sudo ln -s /usr/bin/irb1.8 irb
sudo ln -s /usr/bin/rdoc1.8 rdoc
sudo ln -s /usr/bin/ri1.8 ri


Instalando rubygems

Debido a que el paquete rubygems tiene algunas restricciones en Debian que no te permiten usar todas las opciones, y la versión no es la más moderna, optaremos por una instalación a la vieja usanza . Aunque asuste, los pasos son realmente sencillos:

mkdir tmp
cd tmp
wget http://rubyforge.org/frs/download.php/38646/rubygems-1.2.0.tgz
tar zxvf rubygems-1.2.0.tgz
cd rubygems-1.2.0
sudo ruby setup.rb
sudo ln -s /usr/bin/gem1.8 /usr/local/bin/gem
gem --version


A continuación, nos aseguramos de que tenemos la última versión de rubygems (1), instalando la gema rubygems-update, que sirve para actualizar rubygems (mola ):

gem list -r | grep update
sudo gem install rubygems-update
sudo update-rubygems
gem --version

Como habréis observado, no me he preocupado del path a la hora de lanzar el mandato update-rubygems. Rubygems hace una cosa que bajo mi punto de vista es un gran error, pero que facilita el mantenimiento del path: copia los binarios de cada gema en /usr/bin (primer error, copiarlo a /usr/bin en vez de /usr/local/bin, ya que es una instalación local, segundo error, ¿¿porqué copiar en vez de enlazar simbólicamente??, supongo que la respuesta es que Ruby es multiplataforma y por defecto no permite enlaces simbólicos, como le pasa a Java, aunque quizá sea otra cosa).

A partir de aquí, al instalar algunas gemas (en el ejemplo, sqlite3-ruby), obtendremos un error del tipo

Building native extensions. This could take a while...
ERROR: Error installing sqlite3-ruby:
ERROR: Failed to build gem native extension.
/usr/bin/ruby1.8 extconf.rb
extconf.rb:1:in `require': no such file to load -- mkmf (LoadError)
from extconf.rb:1
Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.4 for inspection.
Results logged to /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.4/ext/sqlite3_api/gem_make.out

Esto es debido a que necesitamos las librerías de desarrollo de Ruby, ya que vamos a compilar cada gema. Por tanto, las instalamos como paquete, ya que el interprete también lo hemos instalado de esa manera:

sudo aptitude install ruby-dev

Instalando Rails

El siguiente paso es instalar Rails, con un sencillo gesto de dedos :

sudo gem install rails

Podéis especificar la versión que necesitáis, pero en mi caso he decido ir a por la que se instala por defecto, una moderna Rails 2.3.2.

Instalando MySQL y SQLite

Aunque existen otras posiblidades, MySQL y SQL suelen ser los gestores de base de datos usados para la persistencia en una aplicación Rails. Normalmente, SQLite se usa en el entorno de desarrollo y MySQL en el de producción, aunque estoy convencido de que la mayoría de aplicaciones (incluyendo la mía ) se apañarían con SQLite (que no pase hambre).

La instalación de ambas gemas es sencilla, aunque requieren instalar algunos paquetes adicionales. Aquí, lo más habitual es instalar todo lo que huela al paquete a instalar (empezaremos por SQLite), pero realmente no es necesario, y yo prefiero instalar lo mínimo necesario, sobretodo en un servidor de producción. El truco, valido también para cuando estamos compilando una aplicación Linux (con el clásico configure + make + make install), es instalar los paquetes del tipo libcosadelaquedependes y libcosadelaquedependes-dev, que contienen las librerías necesarias para la ejecución y compilación de otros programas o librerías que dependan de cosadelaquedependes.

Así, para SQLite, buscamos la gema que queremos instalar:

gem list -r | grep sqlite

y nos quedamos con la que tiene el nombre más prometedor, sqlite3-ruby . Si la intentamos instalar, posiblemente obtengamos un mensaje similar a:

gem install sqlite3-ruby
Building native extensions. This could take a while...
ERROR: Error installing sqlite3-ruby:
ERROR: Failed to build gem native extension.
/usr/bin/ruby1.8 extconf.rb
checking for fdatasync() in -lrt... yes
checking for sqlite3.h... no
make
make: *** No hay ninguna regla para construir el objetivo `ruby.h', necesario para `sqlite3_api_wrap.o'. Alto.
Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.4 for inspection.
Results logged to /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.4/ext/sqlite3_api/gem_make.out

Si os fijáis, le falta el fichero sqlite3.h, es decir, un fichero de cabeceras del lenguaje C. Por lo que procedemos a realizar el truco antes mencionado, comprobando antes y después si tenemos o no el fichero sqlite3.h:

dpkg -S sqlite3.h
sudo aptitude install libsqlite3-dev
dpkg -S sqlite3.h
gem install sqlite3-ruby


Tras esto, la gema SQLite debería instalarse sin problemas. Para MySQL, la instalación es análoga:

gem list -r | grep mysql
gem install mysql
Building native extensions. This could take a while...
ERROR: Error installing mysql:
ERROR: Failed to build gem native extension.
/usr/bin/ruby1.8 extconf.rb
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lm... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lz... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lsocket... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lnsl... yes
checking for mysql_query() in -lmysqlclient... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers. Check the mkmf.log file for more
details.
Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/mysql-2.7 for inspection.
Results logged to /usr/lib/ruby/gems/1.8/gems/mysql-2.7/gem_make.out


Buscando e instalando la librería adecuada, no deberíamos tener ningún problema:

aptitude search mysql | grep lib | grep dev
aptitude install libmysql++-dev
gem install mysql


Instalando y configurando Passenger

La instalación de Passenger es trivial, aunque por defecto no se explica cómo configurarlo a la Debian, si no que se sólo se habla de Apache en general (lógico por otra parte). Necesitáis los siguientes mandatos:

sudo gem install passenger
sudo passenger-install-apache2-module

El primero de ellos instala la gema, mientras que el segundo compila el módulo para Apache. Es probable que no funcione a la primera y os pida que instaléis una serie de paquetes de Apache (algunas librerías de desarrollo y similar), pero con seguir las instrucciones no debería dar mayor problema. En mi caso fueron los siguientes paquetes:

aptitude install build-essential libopenssl-ruby apache2-prefork-dev libapr1-dev libaprutil1-dev

Una vez instalado, Passenger nos indicará cómo configurar una aplicación en un virtualhost, así como las líneas a añadir a la configuración de Apache. Sin embargo, ya que estamos, en Debian, lo mejor es hacerlo a la Debian y crearnos el fichero /etc/apache2/mods-available/passenger.load con la ruta al módulo de Apache que Passenger nos facilita al final de la instalación:

LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.4/ext/apache2/mod_passenger.so

y su correspondiente /etc/apache2/mods-available/passenger.conf con la configuración del módulo:

PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.4
PassengerRuby /usr/bin/ruby1.8

El virtual host no tiene ningún misterio, en mi caso por ejemplo edito el fichero /etc/apache2/sites-available/mybestlap.com con el siguiente contenido:

ServerName mybestlap.com
DocumentRoot /opt/websites/mybestlap/public
ErrorLog /var/log/apache2/error_mybestlapcom.log
LogLevel warn
CustomLog /var/log/apache2/access_mybestlap.com.log combined


Depués sólo queda habilitar el módulo y el site, y reiniciar Apache

sudo a2enmod passenger
sudo a2ensite mybestlap.com
sudo /etc/init.d/apache2 restart

Y ya tenemos nuestra aplicación lista para salir a producción. Ahora queda lo más diver, implementarla :D. Happy coding!

(1) También se puede instalar directamente una versión más moderna de Rubygems, pero prefería cubrir el caso descrito, que es el que yo hice y que tenía algo más de miga.

En mi caso, el plugin de caché que estoy usando es WPSuperCache, que guarda una copia estática de cada página generada por Wordpress, y la sirve directamente en próximas peticiones, siempre y cuando el usuario no esté registrado. Esto evita todas las peticiones contra la base de datos por parte de Wordpress. Además, opcionalmente, el plugin permite guardar las páginas estáticas con una estructura de directorios equivalente a la URL que las representa, y proporciona reescrituras de URL para llegar a dichas páginas directamente, evitando toda intervención por parte de Wordpress (y evitando, por lo tanto, la ejecución de código PHP en el servidor). Finalmente, además, te da la opción de guardar los archivos HTML comprimidos con GZip. Todas estas opciones aceleran notablemente la carga de la página, puesto que el único trabajo que debe realizarse es el del servidor web: encontrar la página html y servirla.

WPSuperCache, como la mayoría de plugins de caché, cuenta con un borrado automático de la caché cada cierto tiempo. Cada vez que se ejecuta esta tarea, las siguientes peticiones (si las hay ) a las distintas páginas del blog harán que se regenere la caché automáticamente.

Sin embargo, cuando tienes pocas visitas, no es buena idea hacer que la caché sea regenerada por los lectores. En ese caso, el mío , es probable que un lector obtenga una página no cacheada en vez de una que sí lo está. Una posiblidad es aumentar en gran medida el intervalo de borrado de la caché, pero en general es preferible tener una caché actualizada. La otra posiblidad es, además de borrar la caché, regenerarla automáticamente, de tal manera que todos los lectores del blog se beneficien de la caché del mismo.

En mi caso, he escrito un script que visita todos los enlaces de una página web basándose en el sitemap de la misma, siempre que este cumpla el protocolo descrito por Sitemaps.org. El código es el siguiente:

#!/bin/bash
# Visit all the links provided by a sitemap file.
# Diego Toharia - http://blog.deigote.com

# Verify parameter
if [[ $# -ne 1 ]] ; then
    echo "Error: first parameter (sitemap URL) missing"
    echo "Usage: `basename $0` "
    exit 1
fi

url=$1
links=`wget -q -O - http://blog.deigote.com/sitemap.xml | awk '{ print $1 }' | grep "^http" | awk 'BEGIN { FS=">" } { print $2 }' | awk 'BEGIN { FS="<" } { print $1 }'`

for i in $links ; do
	echo "Visiting " $i
	wget -q -O - $i > /dev/null
done

Seguro que hay formas más elegantes de hacerlo, pero awk es tan potente que es difícil resistirse a usarlo . Lo he llamado visit_site_by_sitemap, original que es uno .

Una vez tenemos el script, lo más fácil es programar una tarea del cron que cada cierto tiempo (preferiblemente, en franjas horarias con el menor tráfico posible) borre la caché y ejecute el script pasándole como parámetro la URL del sitemap. Por cierto que, en mi caso, el sitemap lo genera el plugin Google Sitemap Generator. El mandato para la regla en mi caso sería algo como:

cd path/al/blog/wp-content ; find cache -type f -name '*.html' -exec rm {} \; -o -name '*.gz' -exec rm {} \; ; ~/bin/visit_site_by_sitemap http://blog.deigote.com/sitemap.xml

La idea es borrar todos los ficheros html y gz generados por la caché y regenerar la misma visitando todos los enlaces proporcionados por el sitemap del blog.

Podemos hacer un par de pruebas que, sin ser demasiado científicas, nos dan una idea del beneficio que obtenemos. La primera sería ejecutar en local el script dos veces, previo borrado de la caché. La primera visitaría todos los enlaces sin disponer de caché, mientras que la segunda lo haría usando la caché.

$ cd path/al/blog/wp-content
$ find cache -type f -name '*.html' -exec rm {} \; -o -name '*.gz' -exec rm {} \;
$ time ~/bin/visit_site_by_sitemap http://blog.deigote.com/sitemap.xml
Visiting  http://blog.deigote.com/
...
real    4m12.102s
$ time ~/bin/visit_site_by_sitemap http://blog.deigote.com/sitemap.xml
Visiting  http://blog.deigote.com/
...
real	0m7.759s

Podemos ver que los resultados son espectaculares. De 4 minutos hemos pasado a 7 segundos. Sin embargo, estamos probando el caso óptimo, en el que la latencia es mínima y la velocidad de conexión con el servidor web es máxima, lo que hacen que la capacidad de proceso sea el único parámetro que influye en los resultados.

Si ejecutamos esta misma prueba en una máquina externa y situada en España, la misma desde la que estoy escribiendo, obtenemos unos resultados bien distintos: casi trece minutos (12m45) frente a casi 9 (8m44s).

Sin embargo, esto es culpa de la lamentable latencia y velocidad de conexión que Dreamhost tiene en España, ya que ejecutando la prueba en una máquina situada en USA (y de otro servicio de hosting distinto), se obtienen 3 minutos (3m02s) frente a 22 segundos, resultados más parecidos a la ejecución en local. Tendré que pensar seriamente en cambiar de hosting .

La otra prueba que se puede hacer es algo más realista: medir el tiempo de descarga de una única página, que es lo que hace un usuario cualquiera (no creo que tenga ningún lector tan fan como para visitarse todas las entradas del blog una detrás de otra ). En mi caso, he usado un navegador Firefox con la caché deshabilitada y con la extensión Firebug instalada, usando la pestaña Red de dicha extensión para medir el tiempo de carga del HTML de la página de inicio. He realizado varias pruebas con la caché vacía y con la caché llena y he obtenido de media unos 2.5 segundos frente a medio segundo respectivamente, lo cual no está mal. Sin embargo, el resto de elementos de la página (malditos emoticonos ) ralentiza la carga total de la misma en gran medida, aunque eso es otra historia .

Gracias a Álvaro por su inestimable ayuda a la hora de lanzar el juego de pruebas en un servidor externo a españa.

Sin embargo, es muy probable que la entrada en la que se anuncia el nuevo blog, la cual está en el nuevo blog ( ). ¿Cómo es posible que si la URL ha cambiado los enlaces para el feed sigan siendo válidos? O una de dos: o mis lectores son muy poco observadores o pasotas, o tengo muy pocos lectores (yo pienso que es una mezcla de los dos )

Volviendo a la pregunta anterior, la respuesta es haber usado un simple URL rewriting gracias al módulo mod_rewrite de Apache. Gracias a este módulo, es posible reescribir una URL cuando esta llega al servidor web, cambiando las cabeceras de la petición, y redirigiéndola a donde corresponde tras realizar el cambio.

En mi caso, he necesitado las siguientes reglas para el dominio deigote.com:

RewriteRule ^blog$ http://blog.deigote.com [L]
RewriteRule ^blog/(.*) http://blog.deigote.com/$1 [L]

La primera de ellas sirve para cuando la URL entrante es http://deigote.com/blog (sin un slash o barra del siete al final). La segunda sirve para el resto de URLs que comiencen por http://deigote.com/blog. Seguro que algún lector (la esperanza es lo último que se pierde ) está pensando que ambas reglas se podrían fusionar en una como la siguiente:

RewriteRule ^blog(.*) http://blog.deigote.com$1 [L]

Es decir, eliminando los slash en la segunda regla para que englobe también el primer caso. El problema de hacer esto es que una URL del tipo http://deigote.com/blogstats sería redirigida a http://blog.deigote.comstats. Por ello, es mejor proteger todas las URLs con un slash al final y añadir una regla para el único caso en que no hace falta poner dicha barra (aunque quizá algún lector me corrija en este punto dándome una solución para unificar ambas reglas ).

De esta manera, todos los enlaces anteriores, ya sean los del feed, entradas, comentarios, etcétera… siguen funcionando correctamente .

PD: Si, tampoco es algo tan increible como para hacer una entrada tan larga, pero bueno, a mi me ha costado lo mío .