P. 1
Configuración Tomcat2

Configuración Tomcat2

|Views: 923|Likes:
Publicado porCarmelo

More info:

Published by: Carmelo on Apr 14, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PPTX, PDF, TXT or read online from Scribd
See more
See less

07/22/2013

pdf

text

original

Configuración Tomcat

‡ Tras instalar Tomcat y ejecutarlo, debemos vigilar cómo funciona. ‡ Podemos utilizar Tomcat:
± como una servidor Web y contenedor de servlets independiente ± contenedor de servlets que complementa a otro servidor Web
‡ se pueden dar ambas opciones.

Servidor Web independiente
‡ el servidor Web incorporado de Tomcat es un servidor HTTP1 que sirve contenido estático con bastante rapidez. ‡ Tb se añaden a Tomcat características propias de servidores Web como CGI Scripting, direcorio de usuario

Combinado
‡ Muchas empresas utilizan un servidor httpd Apache. ‡ el servidor httpd de Apache puede ser menos eficiente al servir el contenido que Tomcat por separado. ‡ el servidor Web Tomcat está optimizado, y los tiempos de ejecución Java son muy buenos en compilar Tomcat. ‡ al configurar Tomcat para que todas sus peticiones viajen primero a través del servidor httpd Apache se ralentiza el tiempo de respuesta de Tomcat. ‡ Aún así, se pueden utilizar el servidor httpd de Apache y Tomcat conjuntamente.

Realojar el directorio de las aplicaciones Web
‡ Según cómo se instala Tomcat podemos querer almacenar los ficheros de la aplicación Wen en el árbol de direcotrios de la distribución Tomcat.
± Si por ejemplo, vamos a actualizar la instalación de Tomcat periódicamente algunos ficheros pueden sobreescribirse (ej. CATALINA_HOME/conf/server.xml)

‡ Actualizar el paquete Tomcat significa sustituir los archivos de configuración por versiones de otra nueva versión del paquete que se actualiza.

‡ Otro caso en que no queremos almacenar los ficheros de la aplicación Web en el árbol de directorios de la distribución Tomcat
± si instalamos más de una copia de Tomcat y ejecutamos más de una instancia
‡ si cada instancia sirve contenido diferente en puertos TCP diferentes ‡ que cada Aplicación Web esté en su propia JVM para que puedan operar independientes

‡ Para tener instalada una distribución Tomcat y ejecutar dos o más instancias que están configuradas de forma diferente
± debemos mantener los ficheros de cada instancia JVM por separado

‡ Durante el uso normal de Tomcat, el servidor lee la configuración de los direcotrios conf y Webapps y escribe ficheros en los directorios logs, temp y work

‡ algunos ficheros jar y class pueden tener que cargarse desde los árboles de directorios shared, server y common. ‡ para que funcionen entonces varias instancias, cada instancia de Tomcat debe tener su propio conjunto de directorios.

‡ El truco para hacer este trabajo es establecer la variable de entorno CATALINA_HOME donde hemos instalado la distrubicón binaria Tomcat (los ficheros vienen de http://tomcat.apache.org) y ajustar la variable de entorno CATALINA_BASE a una ruta diferente en donde se alamacenan los archivos de la instancia JVM (estos archivos vienen de nosotros)

‡ tras establecer estas dos variables de entorno, iniciamos Tomcat. ‡ se ejecuta utilizanod los ficheros de CATALINA_BASE sobre la distribución binaria Tomcat en CATALINA_HOME ‡ Así podemos separar los ficheros de Tomcat de los nuestros, permitendo modificar todo lo que necesitemos.

‡ Primero cambiamos el directorio al directorio en donde queremos colocar los ficheros de la instancia
± éste será nuestro directorio CATALINA_BASE ± lo podemos poner en cualquier parte de nuestro sistema ± creamos un directorio llamado /opt/tomcatinstance

‡ después creamos un directorio para la nueva instancia de Tomcat (se puede llamar como el sitio que vamos a almacenar)
± ejemplo.com
‡ podemos poner rutas en lugar de punto o guión bajo

‡ Ahora copiamos el direcotrio config de la distribución Tomcat a este nuevo direcotrio y creamos el resto de directorios de la instancia Tomcat
± creamos los directorios common, logs, temp, server, shared, Webapps, work

‡ Colocamos el contenido de la aplicación Web para esta instnacia en el subdirecotrio de CATALINA_BASE como haríamos en cualquier otra configuración de Tomcat ‡ Editamos el fichero conf/server.xml para que sea específico con la instancia

‡ debemos modificar sólo lo necesario para que la instancia funcione como queremos. ‡ la instancia no debe intentar abrir los mismos puertos y servidores que otra instancia. ‡ Cambiamos el puerto de cierre por un número de puerto diferente para cada instancia de Tomcat
± <Server port= 8007 shutdown= SHUTDOWN >

‡ y los puertos de cualquier conector ‡ <Connector port= 8081 . ‡ redirectPort= 8443 . />

‡ podemos buscar en el texto el atributo port= y modificar el valor del puerto de ese atributo si su elemento no está comentado. ‡ Eliminamos todos los elementos del ejemplo Contexto y cualquier cosa anidada a ellos y añadimos un contexto de nuestr propia Webapp (se verá después)

‡ Repetimos estos pasos para crear directorios de la instancia CATALINA_BASE adicionales según necesitemos. ‡ Si solo tenemos un sitio Web o queremos ejecutar solo una JVM Tomcat, solo necesitamos un arbol CATALINA_BASE

‡ para iniciar una instancia, ajustamos ATALINA_BASE a la ruta completa del directorio de la instancia ‡ ajustamos CATALINA_HOME a la ruta completa del directorio de la distribución Tomcat ‡ iniciamos Tomcat normalmente

‡ CATALINA_BASE= /opt/tomcatinstance/ejemplo.com ‡ CATALINA_HOME = /opt/tomcat ‡ export CATALINA_BASE CATALINA_HOME ‡ start

Cambiar número de puerto 8080
‡ Tomcat, en su instalación por defecto, está configurado para atender al puerto 8080 en lugar de al número de puerto de servidor Web convencional 80
± mejor pq el puerto por defecto 80 hacen falta privilegios especiales en Linux, Solaris, BSD ± Pero la mayoría de veces, es lógico ejecutar Tomcat en el puerto 80

‡ para modificar el número de puerto, creamos el elemento Connector en el archivo server.xml ‡ buscamos la etiqueta XML

‡ <Connector port= 8080

.

‡ cambiamos por 80 y reiniciamos tomcat ‡ Salvo que el número de puerto 80 esté en uso o que no tengamos privilegios Tomcat debe funcionar con el 80

Transmitir las conexiones TCP del puerto 80 al 8080
‡ es cierto que el proceso JVM debe ejecutarse como usuario root para abrir un conector enel puerto 80 en sistemas operativos distintos de Windows. ‡ pero la JVM no tendría que ejecutarse como root si algo ufera del proceso JVM pudiese transmitir todas las conexiones TCP del puerto 80 a Tocat en algun puerto superior al 1024 (por ejemplo 8080)

‡ Tomcat puede abrir un servidor Web en el puerto 8080 y otro elemento, con los permisos necesarios, puede transmitir las conexiones TCP a un puerto 8080 de Tomcat ‡ a esto se le llama port relaying o net filtering ‡ es una caracteristica muy práctica y muy común. ‡ Se puede hacer de varias maneras en cada SO

‡ en linux
± con la característica iptables

‡ en otros SO
± otras maneras de redireccionar el tráfico TCP a diferentes puertos
‡ filtro de paquetes

Envoltorio
‡ Otra forma de ejecutar Tomcat en el puerto 80 con un usuario distinto al usuario raíz es utilizar un envoltorio de servicio binario. ‡ un envoltorio es un programa escrito en C y creado para esto
± ejecutar un servidor Java limitado a un puerto privilegiado en un SO distinto a Windows como un usuario distinto al usuario raíz

Errores
‡ elegir un puerto ya en uso ‡ netstat a para ver que puertos están en uso

Configuración de la máquina virutual Java
‡ la forma en que se ejecuta Tomcat depende en parte de la configuración de la máquina virtual de Java que se ejecuta. ‡ Si no configuramos la JVM para utilizar una determinada cantidad del área de memoria dinámica, podremos no tener suficiente para la aplicación Web que estamos intentando ejecutar.
± paginas de error ± respuesta errónea las peticiones

‡ hay muchos ajustes relativos a Tomcat que pueden realizarse

‡ Cuando iniciamos JVM, asigna una cantidad fija de memoria, si se ejecutan varios JVM, esa cantidad puede ser demasiado elevada (Problemas con el servidor) o demasiado escasa (Problemas de memoria OutOfMemory ). ‡ Tomcat 6.0 tiene la posibilidad de configurar mediante parámetros la configuración de la pila dinámica de memoria.

‡ Las opciones que puede establecer son :
± Tamaño inicial de la pila de Java : Parámetros -Xms ± Tamaño máximo de la pila de Java : Parámetro Xmx ± Tamaño de la pila de proceso de Java ; Parámetro Xss ± Tamaño Máximo Memoria Permanente : Parámetro : -XX:MaxPermSize

‡ Un Ejemplo : ‡ Para establecer un tamaño inicial de 384Mb : -Xms384m ‡ Para establecer un tamaño máximo de 512Mb : -Xmx512m ‡ Para establecer Memoria Permanente 256Mb : XX:MaxPermSize=256m

‡ Buscamos el programa catalina.bat que está en la carpeta : tomcat\bin\catalina.bat ‡ colocar estas dos instrucciones sobre la línea 70 : ‡ set CATALINA_OPTS=-Xms384m -Xmx512m XX:MaxPermSize=256m ‡ set JAVA_OPTS=-Xms384m -Xmx512m XX:MaxPermSize=256m

‡ Existe otro fichero bat en la misma ruta llamado startup.bat, es aconsejable que también introduzcas dichas instrucciones sobre la línea 28 más o menos.

Reinos roles - usuarios
‡ la seguridad de las aplicaciones Web se pueden controlar a través del contenedor o a través de la propia aplicación Web. ‡ La especifiación JavaEE llama
± container-managed security ± application-managed security

‡ Tomcat ofrece diferentes formas de gestionar la seguridad a través de mecanismos incorporados, que representan la seguridad gestionada por el contenedor ‡ Si tb cuenta con servlets y páginas JSP que tienen su propio mecanismo de registro se consideraría seguridad gestionada por la aplicación

‡ en los dos tipos de seguirdad, los usuarios y las contraseñas se gestionan en grupos llamados reinos

‡ la combinación de la configuración de un reino en el fichero conf/server.xml de Tomcat y <security-constraint> en el fichero WebINF/Web.xml de una aplicación Web define cómo se almacena la info del usuario y el rol y cómo se identifica al usuario en la aplicación Web

Reinos
‡ para utilizar la seguridad gestionada por el contenedor Tomcat, debemos crear un reino. ‡ Un reino es un conjunto de usuarios, claves y roles. ‡ las aplicaciones Web pueden decidir qué recursos son accesibles para qué grupo de usuarios en su fichero descriptor de despliegue server.xml

‡ luego, un administrador de Tomcat puede configurar Tomcat para recuperar la info de usuario, clave y rol utilizando una o más implementaciones del reino.

‡ Tomcat cuenta con un marco para los reinos y viene con varias implementaciones de reino muy utiles
± UserDatabaseRealm ± JDBCRealm ± JNDIRealm ± JAASREalm

‡ los desarrolladores de Java pueden crear implementacones adicionales para conectarlas con su propio usuario y contraseña ‡ para determinar qué reinos utilizar, debemos introducir un elemento del reino en el fichero server.xml y especificar el reino que va a utilizar con el atributo className

‡ <Realm className= class impelmentada ‡ customAttribute1= algun valor ‡ customAtribute2= otro />

‡ las configuraciones de reinos pueden invalidarse con otras configuraciones. ‡ Si un reino está configurado para todos los Hosts al configurarlo en un conjunto de ficheros XML más externo que los elementos del Host, y si uno o más reinos se delcaranen el fichero server.xml en uno de los elementos del contendor Host, la configuración del segundo reino es la que se utiliza para el Host que lo contiene. ‡ Para el resto de Hosts se utilizan la configuración del primero

‡ ninguna parte del reino API de Tomcat se usa para añadir y quitar usuarios. ‡ no forma parte de la interfaz del reino ‡ para añadir y eliminar usuarios de un reino lo podemos hacer nosotros mismos.

UseDatabaseRealm
‡ este reino se carga en memoria desde un fichero estático y se conserva hasta que Tomcat se cierra. ‡ la representación de usuarios, contraseñas y roles que Tomcat usa reside solamente en memoria.
± el archivo de permisos solo se elle una vez en el arranque

‡ el archivo por defecto para asignar permisos en un reino UserDatabaseRealm es tomcatusers.xml y está en CATALINA_HOME/conf ‡ este fichero es clave para el uso de este reino ‡ contiene una lista de usuarios que tienen acceso a las aplicaciones Web ‡ es un fichero XML con elemento raíz tomcatusers
± solo permite los elementos rol y usuario

‡ cada elemento de rol tiene un solo atributo
± rolname

‡ cada elemento usuario tiene tres
± username, password, roles

‡ rol es un grupo de usuarios para los que las aplicaciones Web definen un conjunto de capacidades. ‡ un ejemplo en Tomcat es la aplicación Manager que permite activar, desactivar, y eliminar otras aplicaciones Web. ‡ para usar esta aplicación debemos crear un usuario que pertenezca al rol manager.

‡ cuando accedemos por primera vez a la aplicación Manager, el navegador nos pide nombre y clave.

‡ los reinos UserDatabaseRealm no están pensado para trabajos de producción serios pq la única forma de actualizarlos es escribir un servlet a medida que acceda al reino a través de JNDI

‡ el servlet necesitaría entonces modificar la base de datos del usuario en la memoria o modificar el fichero tomcat-users.xml

JDBCRealm
‡ este reino ofrece más flexibilidad que el reino UserDatabaseRealm ‡ tb permite un acceso dinámico a la info. ‡ es un reino respaldado con una base de datos relacional
± todo se almacena en un base de datos ± el reino JDBCRealm accede a ellos cuando necesita

‡ tenemos que especificar los parámetros de conexión JDBC como atributos para el reino en el fichero server.xml ‡ (versiones anteriores a 5.5 daba error al conectarse adecuadamente a la base d edatos. ‡ Este reino solo para versiones superiores a 5.5.9)

JNDIRealm
‡ Si necesitamos que Tomcat recupere nombres de usuario, contraseñas y roles de un directorio LDAP, usaremos este reino. ‡ JNDI es una implementación muy flexible que permite autentificar usuarios en relación al directorio LDAP

‡ este reino puede buscar de forma recursiva una jerarquia de entradas LDAP hasta encontrar la info que necesita ‡ tb podemos configurarlo para que busque la info en un lugar concreto del directorio ‡ podemos almacenar las contraseñas como texto común y utilizar el método de autentificación básico, pero tb las podemos guardar de forma cifrada y utilizar el méodo de autentificación digest

ejemplo de reino JNDIReaml
‡ configurado para usar un servidor LDAP (en fichero server.xml) ‡ <Realm className= org.apache.catalina.realm.JNDIRealm ‡ connectionURL= ldap://ldap.miejemplo.com:389 ‡ userPattern= uid{0}, ou=gente, dc=miejemplo, dc=com ‡ roleBase= ou=groups,dc=miejemplo, dc=com ‡ roleName= cn roleSearch= (uniqueMenbar={0}) />

JAASReaml
‡ reino que autentifica los usuarios a través de la Java Authentication and authorization Service (JAAS)

Seguridad gestionada por el contendor
‡ los métodos de autentificación gestionados por el contenedor controlar el modo en que se verifican los credenciales de usuario cuando se accede a un recursos protegido. ‡ Hay cuatro tipos de seguridad gestionada por el contenedor, compatibles con Tomcat

‡ Autentificación basica (basic). la contraseña del usuario se solicita mediante autentificación HTTP como texto cifrado en base 64 ‡ Autentificación Digest: la contraseña del usuario se solicita con autentificación HTTP como hashes criptográficos ‡ Autentificación Form: la constraseña se pide con formulario de una pagina Web ‡ Autentificación Client-cert: el usuario se verifica mediante un certificado digital del lado de cliente

Autentificación basic

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->