manual configuracion apache tomcat

ConectoresTOMCAT

Introducción

• Tomcat hace uso de conectores para proveer sus distintos servicios.

• Tomcat 5.5.x incluye conectores :• HTTP• AJP (Apache JServ Protocol)

Conector HTTP

• En la version 5.5.X Tomcat incluye el conector Coyote HTTP/1.1, que permite a Tomcat funcionar como un servidor web autónomo.

• Coyote provee soporte SSL y no SSL.

Configuración del Conector HTTP

• La configuración se realiza en el archivo server.xml

• Parámetros:port: puerto TCP en el cual se creara un

nuevo socket y se esperaran conexiones.maxHttpHeaderSize: tamaño máximo del

encabezado HTTP, en bytes.(por defecto 4096)


maxThreads : numero máximo de hilos que se pueden crear para responder peticiones, determina el máximo de peticiones simultaneas que se pueden manejar.(200).

minSpareThreads: número de hilos que se crean al iniciar el conector.(4)

maxSpareThreads:numero máximo de hilos sin uso que puede haber.(50)


EnableLookups: si se realiza request.getRemoteHost():

“true” activa la búsqueda de DNS para determinar el nombre del cliente remoto.

“false” las desactivaPor defecto “true”.Para evitar demoras debido a DNS se

recomienda “false”


redirectPort: puerto hacia el cual redireccionar las peticiones SSL recibidas en este conector.

acceptCount: numero máximo de conexiones en espera, cuando están todos los hilos en uso.(10)


connectionTimeout: número de milisegundos que esperara por una petición URI, después de establecer la conexión(60000).

disableUploadTimeout: activa (true) o desactiva(false) el uso de un tiempo mas largo cuando se envían datos, o se ejecuta un servlet, permitiendo que el servlet complete su ejecución.(false)


• Ejemplo:<Connector port="8080"

maxHttpHeaderSize="8192"

maxThreads="150" minSpareThreads="25"

maxSpareThreads="75" enableLookups="false"

redirectPort="8443" acceptCount="100"

connectionTimeout="20000"

disableUploadTimeout="true" />

Configuración del Conector HTTP SSL

Para crear un conector con soporte SSL se debe:

• Configurar un conector en server.xml con soporte SSL

• Tener el archivo con el Certificado(JKS or PKCS12):

Desde un Certificate Authorityusando keytool


keytool es una utilidad de java que permite generar un certificado JKS para poder utilizarlo en tomcat.

Comando:• Windows : %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg

RSA• Linux:$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg

RSA


• El certificado generado queda en el directorio “home” del usuario que lo ejecuta

• Para cambiar el directorio se usa el parámetro -keystore [PATH]

• La password por defecto es “changeit”, se puede cambiar, pero hay que incluirla en server.xml, la “key” password debe ser la misma.


Parámetros necesarios para SSL:scheme: nombre del protocolo a retornar

al realizar request.getScheme(). Se debe usar “https” para un conector SSL.

por defecto http.secure: setea el valor a retornar al realizar

request.isSecure(). Se debe usar “true”para crear un conector SSL.

Por defecto “false”.


clientAuth: “true” tomcat pide certificado de cliente para usar este socket, si no lo recibe rechaza la conexión.

“want” tomcat pide el certificado, si no lo recibe no rechaza la conexión.

“false” desactiva la petición, a menos que le cliente intente acceder a un recurso protegido.

Por defecto “false”.


sslProtocol: version del protocolo SSL a usar. “TLS” o “SSL”.

Por defecto “TLS”keystorePass: en caso de usar no usar la

clave por defecto”changeit”, se debe indicar aquí la clave personalizada.

keystoreFile: se especifica el archivo del certificado, si no se encuentra en la ruta por defecto( en el home del usuario).


• Ejemplo:<Connector port="8443"

maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" />

Configurar Tomcat para Cooperar con Apache Web

Server

Los pro y contra de la integración

Algunas ventajas de Tomcat

• Es fácil de configurar.• No hay conector server del cual

preocuparse.• Tomcat configurado como standalone es

potencialmente más seguro.• La migración a otro computador Sistema

Operativo o arquitectura es fácil.• Actualizar Tomcat es más fácil.

Algunas desventajas de Tomcat

• Tomcat tiene menos software de soporte que el httpd de Apache.

• Pocos personas saben del web server de Tomcat comparado al número de la gente que sabe del httpd de Apache.

• El web server de Tomcat tiene pocas características de web server comparado con el httpd de Apache.

• Tomcat es rápido pero no tan rápido como httpd de apache.

• Tomcat no es tan configurable como Apache. • Tomcat no es tan robusto como Apache.

Tomcat funcionando con el httpd de Apache.

Operación del Servidor Web • Un servidor web está esperando

peticiones de un cliente HTTP. Cuando estas peticiones llegan el servidor hace lo que sea necesario para servir las peticiones proporcionando el contenido necesario. Añadirle un contenedor de servlets podría cambiar de alguna forma este comportamiento.

Configuración• Para realizar esta presentacion se utilizo Apache 2.0.55 y

Tomcat 5.5.15 para windows y linux, para otras versiones de Apache(por ejemplo la 2.2) y Tomcat (anteriores a la 5.5) la configuracion para la integracion es distinta.

• Apache esta escuchando todas las peticiones en el puerto por defecto 80.

• Cuando una petición llega apuntando a la Java servet Engine, es pasada a Tomcat para ser procesada. De esta forma Tomcat esta oculto tras de Apache server que es mas eficiente con el procesamiento de paginas estáticas, y Tomcat solo procesa los requerimientos relacionados con java.

Modo de funcionamiento

• La instalación de Apache en windows es simple.

• Idealmente tomcat esta instalado en un directorio fuera de archivos de programa para facilitar su manejo.

• Por lo mismo Apache se instalará en ese directorio, en nuestro caso C:\servers.

Instalación de Apache 2.0en Windows

Instalación de Apache 2.0

Sub directorio Apache2

Instalación de Apache 2.0• En el momento en que finaliza la

instalación el monitor de servicios de Apache se abre automáticamente.

• Es importante recordar permitir el acceso al puerto 80 si nuestro servidor esta detras de un firewall( sea el de windows u otro), para que el servidor sea accesible desde fuera de la red.

Instalación de Apache 2.0

Instalación de Apache 2.0 en Linux (adicional)

• Para instalar en linux hay distintas alternativas, en muchas distribuciones viene incluido alguna version de Apache por defecto (depende de nosotros haberlo o no instalado al instalar el sistema).

• Tambien se puede bajar el paquete propio de nuestra distribucion (rpm, deb, etc.).

• Ademas se puede bajar el codigo fuente y compilarlo e instalarlo (en nuestro caso esta fue la solucion).

Instalación de Tomcat 5.5• La instalación de Tomcat es la vista en la

presentación anterior.

• Para comprobar la funcionalidad Apache-Tomcat, necesitamos tener contenido jsp y/o servlet, como no tenemos contenido propio, utilizaremos los ejemplos que trae tomcat.

• Se deben seleccionar la opción examples y Webapp al instalar Tomcat.

Instalación de Tomcat

Instalación

Instalación• Para windows y linux la configuracion de Apache y

Tomcat es la misma.• Ahora se debe bajar el archivo mod_jk.so para

Apache 2.0.x, se puede bajar desde el siguiente Link(existen mas mirrors en la página de tomcat): http://apache.cs.utah.edu/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.15

• Existen binarios para linux en la pagina, pero en caso de que no correspondan a nuestra version, se puede compilar con el codigo fuente en la página, es necesario tener instalado apache para la compilación.

• Al tener el archivo mod_jk.so al directorio modules de apache (Apache2\modules). Este modulo le permite a Tomcat y Apache cooperar para manejar requerimientos http y java desde el mismo puerto 80.

http://apache.cs.utah.edu/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.15/

http://apache.cs.utah.edu/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.15/

Configuración• Se debe agregar al final del archivo httpd.conf de

Apache las siguientes líneas:

LoadModule jk_module modules/mod_jk.so JkWorkersFile conf/workers.propertiesJkLogFile logs/mod_jk.logJkLogLevel infoJkLogStampFormat "[%a %b %d %H:%M:%S %Y] "JkMount /jsp-examples/* ajp13JkMount /servlets-examples/* ajp13.

• Se agregan para que la configuración de Apache permita que los requerimientos de páginas con JSP sean enviados a Tomcat (*.jsp invoca a Tomcat en todos los archivos señalados con extensión “.jsp”):

Configuración (adicional)• Debemos configurar Apache a traves del archivo

httpd.conf (en Apache2/conf), esto significa agregar varias lineas de configuración que se indican a continuación.

• Indicarle a Apache que cargue el modulo:LoadModule jk_module modules/mod_jk.so

• Indicar donde se encuentra la configuracion de los “workers”:

JkWorkersFile conf/workers.properties• Indicar donde guardar el registro de operación

de mod_jk:JkLogFile logs/mod_jk.log

• Indicar el nivel de debug del registro:JkLogLevel info

Configuración (adicional)• Con JkMount se indican a Apache que

direcciones, para el ejemplo, queremos que si se abre http://localhost/jsp-examples/ tomcat sea el que responda.

JkMount /jsp-examples/* ajp13JkMount /servlets-examples/* ajp13.

• Con esta linea se le indica a apache que todas las peticiones as peticiones a /jsp-examples/ sean enviadas al worker “ajp13”(podria tener otro nombre), se indica el mismo proceder para las direcciones /servlets-examples/.

• Si quisieramos que solo se enviaran las peticiones de jsp a tomcat, y no todo el contenido, se usa:

JkMount /jsp-examples/*.jsp ajp13

• De esta forma Tomcat solo se encarga de gestionar el contenido dinámico.

http://localhost/jsp-examples/

Configuración

• Luego se debe copiar archivo workers.properties (sacado del código fuente de los conectores de Tomcat) a Apache2\conf de Apache server.

• workers.properties se puede obtener desde el codigo fuente del conector mod_jk, tambien se puede crear manualmente, pero es mas facil de esta forma.

Configuración (adicional)• Una configuracion minima necesaria(la incluida

en el codigo fuente es mas extensa) es la sgte:# Define 1 real worker using ajp13worker.list=worker1# Set properties for worker1 (ajp13)worker.worker1.type=ajp13worker.worker1.host=localhostworker.worker1.port=8009worker.worker1.lbfactor=1

Configuración (adicional)• Las propiedades se definen de forma generica:

worker.<worker name>.<directive>=<value>• En este caso el “worker name” es worker1, en la

configuracion vista previamente se llamaba ajp13 (el nombre por defecto).

• En “directive” se indican las distintas propiedades de cada worker, a continuacion se indican algunas, las mas importantes.

list, para indicar la lista de workers que se inciializarantype, para indicar el protocolo a usar, ajp13, ya que ajp12 no se usa.Host, el nombre o la ip del host donde se encuentra tomcat.Port, puerto en el que tomcat escucha, 8009 por defecto lbfactor, factor de balanceamiento de carga.

Prueba de la integración

• Si la integración esta correctamente hecha entonces al intentar abrir, con Apache, los ejemplos *.jsp que vienen incluidos en Tomcat, Apache debería pasar la petición a Tomcat que se encarga de abrirlos.

Prueba de funcionamiento

Funcionamiento de Tomcat cooperando con Apache httpd server.

SecurityManager

Introducción

• Tomcat puede hacer uso del JAVA Security Manager, al ser invocado con la opcion -security.

• De esta forma se implementan las politicas de seguridad definidas en en catalina.policy

Security Manager

• catalina.policy es un archivo de texto que contiene entradas del siguiente tipo:

grant [signedBy <signer>,] [codeBase <code source>] {

permission <class> [<name> [, <action list>]];};

Security Manager• <code source>, code source tiene la forma de una

url, y se pueden usar las propiedades ${java.home} y ${catalina.home}, que representan el path de java y el path de la instalación de tomcat, respectivamente.

• <class> indica el nombre de la clase que define los tipos de permisos a aplicables

• <name> indica a quien se le aplicara este permiso• <action> que acciones se permiten

Security Manager• Clases:• java.util.PropertyPermission - controla acceso de

lectura/escritura a propiedades de la JVM.• java.lang.RuntimePermission – controla el uso de

funciones de ejecucion o de sistema, como exit() o exec().

• java.io.FilePermission – controla los modos de accesos a archivos y directorios.

• java.net.SocketPermission – controla el uso de sockets de red

Security Manager

• Clases:• java.net.NetPermission – controla el uso de

conexiones de redes multicast.• java.security.SecurityPermission – controla el

acceso a metodos de seguridad.• java.security.AllPermission – permite el acceso a

todos los permisos, igual que sin usar el Security Manager.

Security Manager• Ejemplo:• Permisos del código de inicio del servidorgrant codeBase

"file:${catalina.home}/bin/bootstrap.jar" {permission java.security.AllPermission;

};

Security Manager• Permisos del driver de JDBCgrant codeBase

"jar:file:${catalina.home}/webapps/examples/WEB-INF/lib/driver.jar!/-" {permission java.net.SocketPermission

"dbhost.mycompany.com:5432", "connect";};

Clustering con Tomcat

Introducción

• Debido al incremento de las aplicaciones Web, la escalabilidad y la disponibilidad de recursos se hace critica para este fin.

La implementación de clustering para los servidores de aplicaciones Web es una solucion simple y rentable.

Clustering con Tomcat• Provee:

• Escalabilidad.

• Alta disponibilidad.

• Carga balanceada.

Escalabilidad

• El problema es , si toma un tiempo T satisfacer un requerimiento, cuanto tiempo tomaría satisfacer n requerimientos concurrentes?, El ideal en esto es cumplir con todos los requerimientos concurrentes pero manteniendo el tiempo para esto lo mas cercano posible a T.

• Idealmente la solución permitiría escalamiento vertical (aumentando recursos que computan en el servidor ) y horizontal (incrementando el numero de servidores) y el escalamiento seria lineal.

Alta disponibilidad• Se debe proveer failover.

• En el motor del servidor existen dos tipos de failover típicamente provistas por clustering:

1. Request-level failover2. Session –level Failover

Alta disponibilidadRequest –level Failover• Si un servidor del cluster se cae, los

siguientes requerimientos deben ser redireccionados a otros servidores que estén activos.

• Usa típicamente un mecanismo para detectar si algún servidor falló.

Alta disponibilidad

Session- level Failover:• Si un servidor se cae, uno de los otros

servidores del cluster debería proporcionar la sesión a los clientes con mínimas perdidas de continuidad.

• Esto típicamente implica replicar la sesión en el cluster (en otra maquina en el cluster en el menor tiempo posible).

Balanceamiento de carga

• La idea es repartir la carga entre los servidores del cluster de modo de proveer el tiempo de respuesta mas rápido posible al usuario final.

• Usando un algoritmo de distribución de carga.

Clustering

• Las soluciones de Clustering típicas utilizan un paradigma del servidor de cliente para poner un sistema en ejecución distribuido como solución, pero han limitado la escalabilidad.

Esquema de Jakarta Tomcat server engine works

Architecture of a Stand-alone Tomcat Servlet Engine

Architecture of the Clustered Tomcat Servlet Engine

Esquema• El conector del servidor de cluster recibe

la petición desde los clientes, y el procesador del servidor de cluster encapsula las peticiones en los objetos RequstEntry y los escribe en JavaSpace. El Conector del Worker del cluster luego toma esas peticiones desde Java Space y el procesador del worker del cluster satisface las peticiones.

Configuracion Rapida• Se deben seguir los siguientes pasaos:• Todas los atributos de sesion deben implementar

java.io.Serializable• Descomentar el elemento Cluster en server.xml• Descomentar Valve(ReplicationValve) en

server.xml• Si las multiples instancias de tomcat estan en la

misma maquina tcpListenPort tiene que ser unico para cada instancia.

Configuracion Rapida• Asegurarse de que web.xml tiene el elemento

<distributable/> , o definirlo <Context distributable="true" />

• El atributo jvmRoute tiene que estar definido en el “Engine” <Engine name="Catalina" jvmRoute="node01" >

• Asegurarse que todos los nodos tienen la misma hora, sincronizarlos con un servicio NTP.

• Configurar el loadbalancer en el modo ”sticky session”Para mayor informacion:http://tomcat.apache.org/tomcat-5.5-doc/cluster-

howto.html

manual configuracion apache tomcat

Documents