You are on page 1of 7

ADMINISTRACIÓN • Cluster

Cómo configurar Tomcat en cluster

REPLICACIÓN DE SESIONES
En los entornos empresariales suele ser un requisito tener en funcionamiento aplicaciones críticas ejecutándose en alta disponibilidad y balanceo de carga entre varios servidores. Veamos cómo se configura Apache Tomcat para estos menesteres. POR CAYETANO DELGADO ROLDÁN
pache Tomcat es un contenedor de servlets desarrollado en Java por la Apache Software Foundation que implementa las especificaciones de JSP (Java Server Pages) y Servlets de Sun Microsystems. A partir de la versión 5.0, Tomcat incluye la posibilidad de configurar varias instancias en cluster. ¿Por qué íbamos a querer configurar Tomcat en cluster? Pues porque los beneficios que se obtienen son múltiples: vamos a tener alta disponibilidad y alto rendimiento, ya que el tráfico y ejecución se distribuirán entre varias máquinas, y por otro lado, se obtiene tolerancia a fallos, ya que la caída de una de las máquinas no va a afectar al funcionamiento de las aplicaciones, quedando un resultado transparente para el usuario. Existen varios modelos distintos a la hora de configurar un sistema que ofrezca posibilidades de alta disponibilidad, tolerancia a fallos y escalabilidad. Por ejemplo, la arquitectura mostrada en la Figura 1, donde cada servicio (Apache, Tomcat y BD) estará ubicado separadamente en máquinas distintas. Esta solución está claro que es la que mayor coste supone (por la cantidad de “hierro”

A

implicado), pero también hay que tener en cuenta que los servidores pueden ser compartidos entre varias aplicaciones que funcionen en entornos similares. Puede verse un listado de direcciones IP de ejemplo en la Tabla 1. La definición de clustering en Tomcat tiene mucho que ver con el replicado de sesiones, que no es más que distribuir una sesión HTTP entre los distintos nodos de los que se compone el cluster, sesión cuyo estado se mantiene en una cookie dentro del navegador. Existen tres formas de habilitar el replicado de sesiones: • Usando persistencia de sesiones y guardándolas en un sistema de ficheros compartido • Usando persistencia de sesiones y guardándolas en una base de datos compartida • Usando replicación en memoria mediante SimpleTcpCluster incluido en las últimas versiones de Tomcat 5 Junto a la réplica de sesiones, un concepto bastante popular en la implementación de clusters es el despliegue en granja, que permite desplegar una aplicación en un nodo del cluster y que dicho despliegue se replique en

todos los servidores del cluster. Para el replicado de sesiones y despliegue en granja se utilizan peticiones (pings) multicast, que no es más que enviar la información en una red a múltiples destinos simultáneamente, enviándose una sola vez y copiándose a nivel de enlace a todos los rincones de la red. Evidentemente, esto genera demasiado tráfico, por lo que hay que tener cuidado con él y filtrar los pings multicasts en switchs gestionados.

Figura 1: Arquitectura modelo de los distintos sistemas en cluster.

60

Número 19

WWW.LINUX-MAGAZINE.ES

Cluster • ADMINISTRACIÓN

Instalación en nodos
Al estar desarrollado en Java, Tomcat va a funcionar en cualquier sistema operativo y plataforma para la que exista una máquina virtual, así que la instalación y configuración definida a continuación debería ser similar en cualquier entorno. Nosotros vamos a usar Linux, como no iba a ser de otro modo, concretamente la distribución CentOS, aunque también habrá algunas referencias a Debian. La instalación y configuración inicial de Tomcat se detallará para uno de los nodos del cluster (nodo1) y luego se especificarán los cambios necesarios para replicar la instalación en el segundo nodo (nodo2). Antes de instalar Tomcat, hay que tener instalada y configurada una máquina virtual de Java (JVM), de Sun o IBM, versión

Listado 1: Ejemplo de jk.conf
01 LoadModule jk_module modules/mod_jk.so 02 <IfModule mod_jk.c> 03 JKWorkersFile “conf/workers.properties” 04 JkLogFile “logs/mod_jk.log” 05 JkLogLevel error 06 JkMount /* front

1.5.0, que se puede descargar desde la página de Sun [1] y que instalaremos, por ejemplo, en /opt/jdk1.5.0_07, directorio que será el contenido de la variable de entorno $JAVA_HOME, que puede definirse en el fichero /etc/profile.d/java.sh (en CentOS) o /etc/profile (en Debian). La instalación de Tomcat es bastante sencilla, basta con descargar de la web de Tomcat [2] el paquete “Core” correspondiente a la versión 5.5.17, y descomprimir, por ejemplo, en /opt/tomcat55-nodo1. Este directorio se puede almacenar en la variable de entorno $CATALINA_HOME. Por defecto, Tomcat viene configurado con su propio servidor web autónomo configurado en el puerto 8080. El puerto 8005, además, se utiliza para enviar los comandos de gestión al servidor Catalina. Es importante tener esto en cuenta ya que es uno de los errores típicos que nos podemos encontrar si esos puertos ya estuviesen en uso por cualquier otro proceso. Como el propósito de este artículo no es una introducción a Tomcat, para aquellos que quieran conocer en profundidad cómo funciona y se configura, tendrán que pasarse por la documentación oficial disponible en [3]. De todas formas, a modo de resumen rápido, para iniciar Tomcat

bastaría con ejecutar el script $CATALINA_HOME/bin/startup.sh, o bien el script $CATALINA_HOME/bin/shutdown.sh para detener la ejecución. Respecto a la configuración, se realiza en el fichero $CATALINA_HOME/conf/server.xml, que no es más que un fichero XML con una serie de directivas: • <Server> es el elemento raíz de toda la configuración. • <Service> representa un grupo de conectores. • <Connector> representa las interfaces de clientes externos que envían peticiones a (y reciben respuestas de) un Service particular, pueden ser de tipo HTTP y AJP. • Contenedores, que son los componentes que procesan las peticiones recibidas y generan las correspondientes respuestas. Un contenedor de tipo

Tabla 1: Direcciones IP de servidores
Servidor Servidor web Tomcat nodo1 Tomcat nodo2 Servidor BD IP 192.168.10.1 192.168.10.2 192.168.10.3 192.168.10.4

WWW.LINUX-MAGAZINE.ES

Número 19

61

ADMINISTRACIÓN • Cluster

Listado 2: Ejemplo de configuración CATALINA_HOME/conf/server.xml
01 <Server port=”8005” shutdown=”SHUTDOWN”> 02 <Listener className=”org.apache.catalina. core.AprLifecycleListener” /> 03 <Listener className=”org.apache.catalina. mbeans.ServerLifecycleListener” /> 04 <Listener className=”org.apache.catalina. mbeans.GlobalResourcesLifecycle Listener” /> 05 <Listener className=”org.apache.catalina. storeconfig.StoreConfigLifecycl eListener”/> 06 07 <GlobalNamingResources> 08 <Resource name=”UserDatabase” auth=”Container” 09 type=”org.apache.catalina.UserD atabase” 10 description=”User database that can be updated and saved” 11 factory=”org.apache.catalina.us ers.MemoryUserDatabaseFactory” 12 pathname=”conf/tomcat-users.xml ” /> 13 </GlobalNamingResources> 14 15 <Service name=”Catalina”> 16 <Connector address=”192.168.10.2” port=”8009” emptySessionPath=”true” 17 enableLookups=”false” protocol=”AJP/1.3” /> 18 19 <Engine name=”Catalina” defaultHost=”localhost” jvmRoute=”nodo1”> 20 <Realm className=”org.apache.catalina. realm.UserDatabaseRealm” 21 resourceName=”UserDatabase”/> 22 <Host name=”localhost” appBase=”webapps” unpackWARs=”true” autoDeploy=”true” xmlValidation=”false” xmlNamespaceAware=”false”> 24 <Context path=”/servlets-examples” reloadable=”true” docBase=”servlets-examples” distributable=”true”/> 25 <Cluster className=”org.apache.catalina. cluster.tcp.SimpleTcpCluster” 26 managerClassName=”org.apache.ca talina.cluster.session.DeltaMan ager” 27 expireSessionsOnShutdown=”false ” 28 useDirtyFlag=”true” 29 notifyListenersOnReplication=”t rue” 30 clusterName=”TOMCAT cluster”> 31 32 <Membership 33 className=”org.apache.catalina. cluster.mcast.McastService” 34 mcastAddr=”228.0.0.4” 35 mcastPort=”45564” 36 mcastFrequency=”500” 37 mcastDropTime=”3000”/> 38 39 <Receiver 40 className=”org.apache.catalina. cluster.tcp.ReplicationListener ” 41 tcpListenAddress=”192.168.10.2” 42 tcpListenPort=”4001” 43 tcpSelectorTimeout=”100” 44 tcpThreadCount=”6”/> 45 46 <Sender 47 className=”org.apache.catalina. 23 cluster.tcp.ReplicationTransmit ter” 48 replicationMode=”pooled” 49 ackTimeout=”15000”/> 50 51 <Valve className=”org.apache.catalina. cluster.tcp.ReplicationValve”

52 filter=”.*\.gif;.*\.js;.*\.jpg; .*\.png;.*\.htm;.*\.html;.*\.cs s;.*\.txt;”/> 53 <Valve className=”org.apache.catalina. cluster.session.JvmRouteBinderV alve” 54 enabled=”true” /> 55 <ClusterListener className=”org.apache.catalina. cluster.session.JvmRouteSession IDBinderListener” /> 56 <Deployer className=”org.apache.catalina. cluster.deploy.FarmWarDeployer” 57 tempDir=”${catalina.base}/war-t emp/” 58 deployDir=”${catalina.base}/war -deploy/” 59 watchDir=”${catalina.base}/warlisten/” 60 watchEnabled=”true”/> 61 62 <ClusterListener className=”org.apache.catalina. cluster.session.ClusterSessionL istener”/> 63 </Cluster> 64 </Host> 65 </Engine> 66 </Service> 67 </Server>

62

Número 19

WWW.LINUX-MAGAZINE.ES

Cluster • ADMINISTRACIÓN

Tabla 2: Directorios de Tomcat
Directorio bin/ common/ conf/ logs/ server/ shared/ temp/ webapps/ work/ Descripción Contiene los scripts de inicio y parada Es donde se guardan los paquetes y clases comunes a todas las aplicaciones Ficheros de configuración Ficheros de trazas y depuración Clases y paquetes de Tomcat Similar al directorio common/ Ficheros temporales Directorios y paquetes de aplicaciones Directorios de trabajo en tiempo de ejecución

Listado 3: Ejemplo de workers.properties
01 # Define some properties 02 workers.apache_log=/var/log/ht tpd/ 03 ps=/ 04 # Define 3 workers the last one being a loadbalancing worker 05 worker.list=front 06 # Set properties for nodo1 (ajp13) 07 worker.nodo1.type=ajp13 08 worker.nodo1.host=192.168.10.2 09 worker.nodo1.port=8009 10 worker.nodo1.lbfactor=1 11 worker.nodo1.cachesize=10 12 worker.nodo1.cache_timeout=600 13 worker.nodo1.socket_keepalive= 1 14 worker.nodo1.socket_timeout=60 15 # Set properties for nodo2 (ajp13) 16 worker.nodo2.type=ajp13 17 worker.nodo2.host=192.168.10.3 18 worker.nodo2.port=8009 19 worker.nodo2.lbfactor=1 20 worker.nodo2.cachesize=10 21 worker.nodo2.cache_timeout=600 22 worker.nodo2.socket_keepalive= 1 23 worker.nodo2.socket_timeout=60 24 # Set properties for front (lb) which use nodo1 and nodo2 25 worker.front.type=lb 26 worker.front.balance_workers=n odo1,nodo2 27 worker.front.sticky_session=tr ue

<Engine> recibe todas las respuestas de un <Service>, un <Host> gestiona todas las peticiones de un determinado host virtual y un <Context> gestiona las peticiones de una determinada aplicación web. • Otros componentes, que pueden residir dentro de un <Container> o de un <Context>. Ahora vamos a por la configuración. La verdad es que pueden dejarse por defecto la inmensa mayoría de los parámetros, algunos de ellos se pueden quitar porque están comentados, o simplemente porque están activados a modo de ejemplo, pero no suelen ser necesarios. Respecto a los que se pueden quitar o. por el contrario son imprescindibles, nos lo irá dando la experiencia de instalación de tipo de entornos. La parte que hace referencia a la configuración del cluster viene comentada por defecto, por lo que habría que quitar los comentarios <!— —> que engloban a <Cluster> </Cluster>. Las etiquetas de Cluster se pueden poner tanto a nivel de <Engine> como a nivel de <Host>, con lo que conseguiremos, respectivamente, clusterizar Tomcat a nivel de todo el servidor, o bien por cada uno de los hosts virtuales configurados. Para configurar un cluster con los parámetros por defecto (por ejemplo para entornos de pruebas o desarrollo), bastaría con añadir la opción
<Cluster className=”org.U apache.catalina.cluster.tcp.U SimpleTcpCluster”/>

en Engine o Host. En el Listado 2 puede verse un fichero de ejemplo de configuración completa para el nodo1. Veámoslo más en detalle: • Se añade en Engine el parámetro jvmRoute=”nodo1”, que en realidad se usa en arquitecturas con más de dos nodos, para que la máquina virtual

sepa el lugar al que redireccionar las peticiones ante una caída y recuperación. • Respecto a los Connectors, se elimina el conector HTTP/S del puerto 8080, que no se va a usar, ya que sólo vamos a utilizar el conector AJP en el puerto 8009, que servirá para sincronizar con el servidor web Apache HTTPD. De todas formas, es habitual dejar el conector 8080 en los entornos de desarrollo. También puede indicarse la dirección IP donde escuchará el conector, que aunque no es obligatorio, es útil en el caso de que tengamos varias tarjetas de red con distintas IP. • Como contexto se deja el de una de las aplicaciones web que vienen como ejemplo. En este caso se trata de los ejemplos de servlets, que además nos servirá más adelante para probar el replicado de sesiones. En dicho contexto es muy importante el parámetro distributable=”true”, que indicará al servidor Tomcat que dicha aplicación tiene que mantener la sesión en todos los nodos del cluster. • La configuración del cluster establece ese nodo como máster en el despliegue (Sender) de las aplicaciones en la granja en modo “pooled”. Las otras opciones de replicación posibles son synchronous, asynchronous o fastasyncqueue. Una vez finalizada la configuración del nodo1, podemos replicar la misma instalación en el nodo2 cambiando simplemente la dirección IP en el parámetro address del conector y del cluster, así como cambiar nodo1 por nodo2 en el parámetro jvmRoute en la directiva Engine. Y ahora manos a la obra. Iniciamos el nodo1 y nos fijamos en el fichero de trazas CATALINA_HOME/logs/catalina.out con nuestro paginador favorito (a mí me gusta less y pulsar F), esperamos a que

termine de iniciar y acto seguido iniciamos el nodo2 y, si todo ha ido bien, veremos cómo se descubren entre sí ambos nodos y se replican las sesiones que haya disponibles. Un ejemplo de este funcionamiento se puede ver en la Figura 3.

Balanceando la carga
Como balanceo de carga se podrían utilizar distintas técnicas: vía DNS (con políticas de resolución de IP en bucle RoundRobin), o bien con algún servicio

WWW.LINUX-MAGAZINE.ES

Número 19

63

ADMINISTRACIÓN • Cluster

tipo Linux Virtual Server en cada uno de los nodos para que hagan el balanceo de carga a nivel de red, o incluso se podría usar la aplicación balancer que viene de ejemplo con Tomcat. Nosotros vamos a usar mejor el servidor web Apache HTTPD, configurado con el módulo mod_jk disponible dentro de Tomcat Connectors [4]. Para instalarlo se podría utilizar el paquete que exista en la distribución en cuestión (mod_jk-ap20 en CentOS o libapache2-mod-jk en Debian), pero por compatibilidad con las últimas versiones de Tomcat que estamos usando, es preferible compilarlo a partir de las fuentes. Para ello bastaría con descargar la versión 1.2.15 y tener instalado el paquete de desarrollo de Apache (como siempre, httpd-devel en CentOS y apache2-dev en Debian) que proporciona apxs (APache eXtenSion tool).
tar -xzvf jakarta-tomcat-U connectors-1.2.15-src.tar.gz cd jakarta-tomcat-connectorsU -1.2.15-src/jk/native ./configure —with-axps=/usrU /sbin/axps make

Tabla 3: Tipos de workers
Tipo ajp12 ajp13 jni lb status Descripción Worker que implementa el protocolo ajpv12. (a extinguir) Worker que implementa el protocolo ajpv13. Worker que implementa peticiones JNI. Worker para balanceo de carga. Worker de estado para gestión de balanceo de carga.

Para instalarlo, copiamos el módulo resultante en el directorio de módulos del servidor web (/usr/lib/httpd/modules/ en CentOS y /usr/lib/apache2/modules/ en Debian):
cp apache-2.0/mod_jk.so U /usr/lib/httpd/modules/

Ya sólo queda cargar y configurar el módulo en el servidor. Para ello creamos un fichero jk.conf como el del Listado 1, ubicado en el directorio de carga automática de Apache (/etc/httpd/conf.d en CentOS y /etc/apache2/conf.d en Debian). Es ahora cuando entra en juego el

significado de los llamados workers, cuyo fichero de configuración se referencia mediante el JKWorkersFile, ubicado en el directorio conf/ de Apache. ¿Qué es un worker? Pues es una instancia de Tomcat que ejecuta peticiones de servlets recibidas desde un servidor web, o lo que es lo mismo, el servidor Apache se encargará, mediante la directiva JkMount, de redirigir la url de la petición recibida hacia un worker concreto. En el fichero de ejemplo se establece que todas las peticiones recibidas (/*) se redirijan al worker “front”. Vamos ahora a por el fichero del Listado 3, workers.properties, donde se definen los distintos tipos de workers desplegados, como los indicados en la Tabla 3. En nuestro caso, se trata de un único worker, que va a trabajar como balanceador de carga. Ojo porque en la directiva workers.list sólo se incluyen los workers, separados por comas, que vayan a ser usados en el fichero jk.conf, los nodos que se conecten a los nodos de un cluster sólo se usan en la definición del worker de tipo “lb”. El fichero de configuración comienza con la definición de varias propiedades comunes, como es el directorio de logs de Apache (utilizado para que el módulo mod_jk, que también guarda trazas) y un parámetro “ps” que se utiliza para indicar el separador de rutas (/ en Linux/Unix y \ para Windows). Después de definir el número de workers existentes, se pasa a detallar el funcionamiento de cada uno. Como vemos, existe un worker por cada

Listado 4: Script de inicio /etc/init.d/tomcat
01 02 03 04 05 06 07 08 CATALINA_HOME=”/opt/tomcat55-n odo1/” 09 10 case “$1” in 11 start) 12 if [ -f $CATALINA_HOME/bin/startup.sh ]; 13 then 14 echo $”Starting Tomcat” 15 /bin/su tomcat $CATALINA_HOME/bin/startup.sh 16 fi 17 ;; 18 stop) 19 if [ -f $CATALINA_HOME/bin/shutdown.sh ]; 20 then 21 echo $”Stopping Tomcat” 22 /bin/su tomcat $CATALINA_HOME/bin/shutdown.sh 23 fi 24 ;; 25 restart) 26 /bin/su tomcat $CATALINA_HOME/bin/shutdown.sh 27 sleep 5 28 /bin/su tomcat $CATALINA_HOME/bin/startup.sh 29 ;; 30 *) 31 echo $”Usage: $0 {start|stop|restart}” 32 exit 1 33 ;; 34 esac #!/bin/bash # # tomcat # # chkconfig: 345 63 37 # description: Start up the Tomcat servlet engine.

Figura 2: Página inicial de Tomcat accediendo desde la IP del balanceador.

Figura 3: Muestra de los ficheros de logs de las dos instancias de Tomcat en el arranque.

64

Número 19

WWW.LINUX-MAGAZINE.ES

ADMINISTRACIÓN • Cluster

uno de los nodos, cuyo tipo es ajp13, donde se especifica también la dirección IP y el puerto donde están escuchando los respectivos Connectors definidos en Tomcat. También se pueden indicar aquí otros parámetros interesantes como el peso lbfactor del worker dentro del balanceo de carga, el tamaño de la caché y el tiempo de refresco. Ya por último, se define el worker “front”, que se encargará de balancear las peticiones entre los workers, separados por coma, en balance_workers. Un parámetro bastante importante a tener en cuenta es el de sticky_session o sesión persistente, que hace que las peticiones se redirijan siempre al mismo nodo en el que se haya creado la sesión inicialmente, y sólo pasaría a usarse el segundo nodo cuando el primero dejase de existir. En la documentación de los conectores de Tomcat [6] se puede ver el significado de todas las directivas disponibles tanto en lo que respecta al módulo, como a la configuración de los workers. Una vez creados los ficheros descritos, bastaría con reiniciar Apache y empezar a jugar un poco con las sesiones. En la Figura 2 podemos ver el funcionamiento de cómo acceder directamente a la IP del servidor web: http://192.168.10.1/, donde se nos mostraría la página por defecto de Tomcat, y si usamos los servlets de ejemplo que se incluyen en Tomcat (http://192.168.10.1/ servlets-examples/), podemos ir viendo cómo crear sesiones y alojar parámetros en cookies, iniciar varios navegadores y comprobar cómo se balancea la carga asignando cada petición a un nodo distinto. También podríamos simular la caída de un nodo forzando la salida de uno de ellos y seguir haciendo peticiones al servidor y comprobar cómo se redirigen las peticiones sólo al nodo que está en funcionamiento. Mola ¿no?

ción y activado en los niveles de ejecución típicos mediante chkconfig tomcat on en CentOS y en Debian update-rc.d tomcat defaults. Otra mejora posible sería optimizar Tomcat mediante la compilación nativa, ya que las últimas versiones de Tomcat 5 están integradas con la Apache Portable Runtime[ 7], que es un subproyecto de Apache para la creación de un paquete de librerías que sirvan de abstracción consistente a implementaciones específicas por plataforma. Esto rompería a priori la portabilidad de Tomcat pero por contra se obtienen múltiples beneficios como… • … funcionalidades avanzadas de Entrada/Salida • … funcionalidades a nivel de sistema operativo y de gestión de procesos nativos, que redundará en la obtención de mejores parámetros de estado y consumo de proceso y memoria • … la obtención de una superior escalabilidad y rendimiento. Para instalar APR se podrían utilizar los paquetes precompilados de cada distribución, pero mejor vamos a compilar la última versión disponible en su web [7], la 1.2.7, en la que realizaremos los pasos típicos de compilación (huelga decir que nos hará falta tener instalado el compilador gcc y make previamente):
tar xvjf apr-1.2.7.tar.bz2 cd apr-1.2.7 ./configure && make make install

incluir en nuestra instalación de la JVM. Para ello, copiamos o enlazamos en:
cd /opt/jdk1.5.0_07/jre/lib/i386/ ln -s /usr/local/apr/lib/U libtcnative-1.a libtcnative-1.a ln -s /usr/local/apr/lib/U libtcnative-1.so libtcnative-1.so ln -s /usr/local/apr/lib/U libtcnative-1.so.2 libtcn tive-1.so.2 ln -s /usr/local/apr/lib/U pkgconfig/ pkgconfig

Ahora sólo habría que reiniciar Tomcat et voilà. Por cierto, hay un pequeño problema en lo que respecta al direccionamiento IP en esta versión de Tomcat, y es que el parámetro address del Connector AJP tiene que estar en IPv6 en lugar de IPv4. Este problema estará solucionado en la próxima versión 5.5.18. Mientras tanto, habría que traducir el formato de las IP 192.168.10.2 y .3 a IPv6 en los conectores que tengan especificado el parámetro address, aunque ya vimos que no era obligatorio especificarlo.

Conclusiones
En definitiva, usando Apache Tomcat es posible desplegar una aplicación crítica funcionando con tolerancia a fallos y existen muchas arquitecturas distintas con balanceo de carga y alta disponibilidad. Ahora sólo queda que la aplicación esté preparada para funcionar en un entorno en cluster, aunque eso ya daría para otro I artículo.

Mejorando la instalación
Como mejoras principales a realizar a la configuración anteriormente detallada, podrían realizarse algunas consideraciones de seguridad, como ejecutar Tomcat con su propio usuario no privilegiado tomcat, y luego asignar permisos reducidos a los directorios propios de la instalación de Tomcat. Por ejemplo, los directorios imprescindibles serían conf, logs, work y webapps. Ya sólo faltaría crear el típico fichero script de inicio de Tomcat para que se ejecute en cada reinicio del servidor. Un ejemplo sencillo podría ser el detallado en el Listado 4, ubicado en /etc/init.d/tomcat, con permisos de ejecu-

Mediante estos pasos se nos instalarán en /usr/local/apr los componentes necesarios que implementan el acceso nativo. Ahora tocaría instalar los wrappers JNI de Tomcat para que usen APR, además nos hará falta tener instalado el paquete de desarrollo de OpenSSL (openssl-devel en CentOS, libssldev en Debian):
cd $CATALINA_HOME/bin tar xvzf tomcat-native.tar.gz cd tomcat-native-1.1.3U /jni/native ./configure —with-apr=/usrU /local/apr/bin/apr-1-config U —with-java-home=/optU /jdk1.5.0_07 make && make install

RECURSOS
[1] Página de descarga de JDK de Sun: http://java.sun.com/javase/ downloads/index.jsp [2] Página de descarga de Tomcat 5.5.x: http://tomcat.apache.org/ download-55.cgi [3] Documentación de Tomcat 5.5: http:// tomcat.apache.org/tomcat-5.5-doc/ [4] Página de descarga de Tomcat Connectors: http://tomcat.apache.org/ download-connectors.cgi [5] Documentación de Tomcat Connectors: http://tomcat.apache.org/ connectors-doc/ [6] Documentación de Apache HTTPD: http://httpd.apache.org/docs/2.0/ [7] Apache Portable Runtime: http://apr. apache.org/

Que generará una serie de librerías JNI en /usr/local/apr/lib/ que tendremos que

66

Número 19

WWW.LINUX-MAGAZINE.ES