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 ).

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.