Integración de Solr y Drupal 7.x

Antes de comenzar la instalación es necesario asegurarse que se tiene instalado Java 5 o superior y como mínimo PHP 5.2.4. Para este caso se ha utilizado un servidor con las siguientes versiones:

  • Ubuntu Server 12.04
  • PHP 5.3.10
  • Apache/2.2.22
  • Java 6

En primer lugar se debe instalar el módulo de Drupal Apache Solr Search Integration (http://drupal.org/project/apachesolr). Se ha trabajado con la versión 7.x-1.2 del módulo.

Antes de activar el módulo es necesario realizar la instalación de Solr (http://lucene.apache.org/solr). A pesar de que existan paquetes para Solr en Debian y en Ubuntu, para que la integración funcione con Drupal se ha descargado la última versión de la página oficial (Solr 3.6.2 – http://www.apache.org/dyn/closer.cgi/lucene/solr/3.6.2).

Para instalar el servidor Solr se han seguido los siguientes pasos:

  1. Descomprimir apache-solr-3.6.2.zip en el directorio /opt siempre y cuando este no sea visible para el servidor web.
    cd /opt
    sudo unzip apache-solr-3.6.2.zip
  2. Los ficheros de configuración de Solr se encuentran en apache-solr-3.6.2/example/solr/conf. Se deben sustituir dichos ficheros por los que proporciona el módulo de Drupal:
    cd apache-solr-3.6.2/example/solr/conf
    sudo mv solrconfig.xml solrconfig.xml.bak
    sudo cp [DIR DRUPAL]/sites/all/modules/apachesolr/solr-conf/solr-3.x/solrconfig.xml .
    sudo mv schema.xml schema.xml.bak
    sudo cp [DIR DRUPAL]/sites/all/modules/apachesolr/solr-conf/solr-3.x/schema.xml .
    sudo mv protwords.txt protwords.txt.bak
    sudo cp [DIR DRUPAL]/sites/all/modules/apachesolr/solr-conf/solr-3.x/protwords.txt .
  3. El módulo de Drupal incluye además varios ficheros de configuración adicionales que se deben copiar dentro del directorio de configuración de Solr.
    cd apache-solr-3.6.2/example/solr/conf
    sudo cp [DIR DRUPAL]/sites/all/modules/apachesolr/solr-conf/solr-3.x/solrconf_extra.xml .
    sudo cp [DIR DRUPAL]/sites/all/modules/apachesolr/solr-conf/solr-3.x/solrcore.properties .
  4. Es recomendable incluir una lista de palabras vacías para optimizar la indexación de los contenidos. Se pueden encontrar listas de palabras vacías para una gran número de idiomas en http://code.google.com/p/stop-words/. Para este caso el contenido que se va a indexar está en español por lo que se ha descargado la lista de palabras vacías en español.
    sudo mv stopwords.txt stopwords.txt.bak
  5. Finalmente lanzamos Jetty con Solr.
    sudo java -jar /opt/apache-solr-3.6.2/example/start.jar

Para comprobar que el servidor Solr está funcionando correctamente se debe acceder a la siguiente url http://[TU DOMINIO]:8983/solr/admin. Asegúrate que el puerto 8983 es accesibles. En caso contrario puedes abrirlo o cambiar el puerto en el fichero de configuración de Jetty.

En /opt/apache-solr-3.6.2/example/etc/jetty.xml cambia el puerto por defecto 8983 por otro que no sea el 80:

<Call name="addConnector">
[...]
<Set name="port"><SystemProperty name="jetty.port" default="8983"/></Set>

Servidor Solr con autenticación HTTP

Para proteger la página de administración del servidor Solr mediante autenticación HTTP se han seguido las indicaciones que se encuentran en la siguiente página http://www.shayanderson.com/linux/how-to-password-protect-apache-solr-server-admin-pages.htm. En primer lugar, en el fichero /opt/apache-solr-6.3.2/example/etc/jetty.xml se debe descomentar el siguiente fragmento de código, asegurándose que se sustituye Test Realm por Solr Admin Auth.

[...]
<Set name="UserRealms">
<Array type="org.mortbay.jetty.security.UserRealm">
<Item>
<New>
<Set name="name">Solr Admin Auth</Set>
<Set name="config"><SystemProperty name="jetty.home" default="."/>/etc/realm.properties</Set>
<Set name="refreshInterval">0</Set>
</New>
</Item>
</Array>
</Set>
[...]

Después se edita /opt/apache-solr-6.3.2/example/etc/webdefault.xml y se añade al final del fichero el siguiente fragmento de código:

[...]
</locale-encoding-mapping-list>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>Solr Admin Auth</realm-name>
</login-config>
<security-constraint>
<web-resource-collection>
<web-resource-name>Solr Admin Auth</web-resource-name>
<url-pattern>/admin/*</url-pattern>
<url-pattern>/update/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
</web-app>

A continuación se crea el fichero realm.properties en /opt/apache-solr-6.3.2/example/etc en el que se debe indicar el nombre de usuario, la contraseña y el identificador (role-name) que en este caso es admin:

username: password, admin

Para que el módulo de Drupal funcione con autenticación HTTP se debe indicar el usuario y la contraseña en el campo de la URL del servidor Solr:

http://username:password@localhost:8983/solr

Script en init.d

Para terminar, creamos un script en init.d para iniciar y parar el servidor Solr:

#!/bin/sh -e

# Starts, stops, and restarts solr

SOLR_DIR="/opt/apache-solr-3.6.2/example"
JAVA_OPTIONS="-Xmx1024m -DSTOP.PORT=8079 -DSTOP.KEY=stopkey -jar start.jar"
LOG_FILE="/var/log/solr.log"
JAVA="/usr/bin/java"

case $1 in
start)
echo "Starting Solr"
cd $SOLR_DIR
$JAVA $JAVA_OPTIONS 2> $LOG_FILE &
;;
stop)
echo "Stopping Solr"
cd $SOLR_DIR
$JAVA $JAVA_OPTIONS --stop
;;
restart)
$0 stop
sleep 1
$0 start
;;
*)
echo "Usage: $0 {start|stop|restart}" >&2
exit 1
;;
esac

(fuente: http://lucene.472066.n3.nabble.com/solr-init-d-script-td1867519.html)

 

Conectar Drupal con Moodle y WordPress

La parte central de Grial 2.0 gira en torno a la conexión entre estos tres gestores de contenidos, Drupal, Moodle y WordPress. Desde un principio, y por diversos motivos que ahora no vienen al caso, se decidió que la conexión fuera unidireccional, manteniendo Drupal como centro de mando y conectándolo con Moodle y WordPress para realizar las tareas pertinentes.

Para lograr este objetivo se han desarrollado dos módulos de Drupal, Drupal to WordPress y Drupal to Moodle, que realizan llamadas a WordPress y Moodle a través de XML-RPC. Ha sido necesario extender las funciones que estos dos CMS proporcionaban a través de su interfaz XML-RPC. Mediante un plugin de WordPress, Drupal to WordPress XML-RPC, se han añadido algunas funciones que permiten utilizar las características Multisite que hasta el momento no eran accesibles a través de este protocolo. En Moodle, en vez de extender la interfaz XML-RPC que viene por defecto, se ha optado por implementar una interfaz nueva, sencilla y potente, que permite realizar operaciones básicas de gestión de cursos.

Se ha intentado minimizar, en la medida de lo posible, las dependiencias entre estos pequeños desarrollos, de tal forma que Drupal to WordPress necesita del plugin correspondiente de WordPress, y Drupal to Moodle necesita la extensión de Moodle, pero tanto el plugin como la extensión pueden ser utilizados de forma independiente.

Todos los módulos y plugins estarán disponibles para su descarga en el repositorio oficial correspondiente a lo largo de este mes.

Desesperación

Esa es la palabra que mejor define mis últimos meses realizando el PFC. Tengo la cabeza llena de parches que pretendían solucionar el mundo, títulos de hilos en foros que otras personas desesperadas como yo comenzaron algún día, recetas mágicas para que todo funcione… Estoy segura de que muchas otras personas han tenido mi problema entonces por qué narices no consigo encontrar una solución en toda esa maraña de información que es Internet. Ante este alto nivel de saturación crees que has llegado a tu límite pero no, todavía puedes hundirte un poco más y es en ese momento cuando, si tienes algo de suerte, empiezas a hallar la solución.

Al principio todo parece tan fácil, yo sólo quería hacer que Drupal fuera un servidor de OpenID y que WordPress y Moodle fueran clientes. El core de Drupal proporciona un cliente OpenID y el servidor se instala como un módulo aparte. Ahí comenzó el problema, el dichoso módulo no funciona y lo peor de todo no se queja de ningún tipo de error.

Aquí comienza a entrar en juego la desesperación. Después de horas sin conseguir que funcionara pasamos a un cambio radical de estrategia, que le den por saco a Drupal como OpenID provider, me monto el mío propio y que todos los servicios sean clientes. Vale, pues el cliente OpenID de Drupal tampoco quiere funcionar.

Unas horas después de otros cuantos parches, consejos, recetas, he conseguido que, utilizando Community-ID como OpenID provider, Drupal y WordPress funcionen correctamente como clientes siempre y cuando Drupal se encuentre en un servidor distinto al que esté el servidor de OpenID. Mañana será otro día, a ver si el cliente de Moodle no da problemas…

Todo gira en torno a Drupal

El centro de todo el portal 2.0 girará en torno a un CMS o gestor de contenidos que se conectará con diferentes herramientas web tales como un LMS o el gestor de blogs en el nos encuentramos ahora . Siguiendo la política de uso de software libre que se intenta promover en la Universidad de Salamanca, y manteniendo la línea que el director del grupo trazó para el portal institucional de la USAL cuando fue Vicerrector, el CMS elegido ha sido Drupal.

La elección del LMS tampoco ha supuesto ningún problema ya que, tanto desde el grupo como por mi parte, no había nada que discutir,  nuestros cursos se desarrollarán en Moodle entre otras razones porque tenemos mucha experiencia en el uso de dicha plataforma y con vistas a desarrollos futuros para la misma.

El gestor de blogs fue mi decisión, al igual que lo fue cuando se montó Diarium. En aquel momento contemplé diferentes formas de crear una estructura estable para albergar un gran número de blogs y la mejor solución fue WPMU ya que dicha herramienta surgió a partir de la experiencia que los desarrolladores de WordPress tuvieron con su propio gestor de blogs, WordPress.com, además de que existe una gran comunidad de desarrolladores que dan soporte a la misma. Por desgracia, o tal vez por suerte, desde hace unos días está disponible la versión 3.0 de WordPress, la cual ha incluido en su core aquella funcionalidad de WPMU que permitía tener múltiples blogs. De esta forma pretenden evitar que el mantenimiento de WPMU quedara desatendido, ya que ahora sólo tienen que mejorar un único producto. La elección de WordPress como gestor de blogs no ha cambiado, pero seguramente [crucemoslosdedos]migre todo este sistema a esa versión 3.0. [/crucemoslosdedos]

Pero no sólo WordPress tiene este verano una nueva versión, los desarrolladores de Drupal y Moodle también se han confabulado para que tenga que tomar la difícil decisión de migrar los sistemas a mitad de proyecto. Grial está ahora en un Drupal 6 y resulta que hace un par de semanas han puesto a disposición de los usuarios la versión 7, la cual ya maneja OO (Orientación a Objetos). Y no hablemos de Moodle, años sin soporte para servicios web y este verano…versión 2.0 orientada a servicios, toma ya. Es cierto que actualizar me permitirá disfrutar de las ventajas y las mejoras de las nuevas versiones, pero también me traerá dolores de cabeza lidiando con toda clase de bugs que suelen encontrarse cuando un producto lleva poco tiempo en explotación. [broma]Al final lanzaré una moneda y que decida la suerte.[/broma]

Al menos me queda el consuelo de que todas estas maravillosas herramientas están hechas en PHP así que me voy a sentir como pez en el agua trasteando con sus tripas.