instalacion-y-administracion-de-tomcat-v1-2008-07

Instalación y Administración de Apache Tomcat 6

Iván Párraga García – [email protected]

Instalación y Administración de Apache Tomcat

Módulo 1

Introducción

Nº 2

Objetivos


 Introducción al proyecto Apache & Jakarta  Entender la tecnología J2EE

Nº 3


El proyecto Apache  Rob McCool en el NCSA de la Universidad de Illinois, creó uno de los primeros servidores web (conocido como NCSA)  El autor dejó el NCSA y un grupo de desarrolladores lanzaron una nueva versión corregida conocida como Apache Server (A PAtCHy Web Server)  Apache fue ganando popularidad al mismo ritmo que NCSA la perdía (dejó de soportarse en 1999)  Hoy día está disponible en cualquier plataforma y se considera un plataforma de producción de alta calidad y que tiene una cuota de mercado del 60%

Nº 4


 Organización sin ánimo de lucro fundada en 1999 cuyo objetivo es facilitar el desarrollo de proyecto s de software libre  Tomcat se ha desarrollado en el marco de la ASF  Proyectos de la ASF:  Servidor Web Apache  Xerces: parser XML Java/C++  Ant: el sistema de construcción estándar de facto en Java  Jakarta Nº 5


Jakarta y Tomcat  Tomcat era un subproyecto bajo el proyecto Apache Jakarta  Apache Jakarta aglutina diversos proyectos Java  JMeter  Log4j  Struts

 Hoy día Tomcat es un proyecto de alto nivel

Nº 6

La licencia Apache


 Tomcat es código libre, gratis y que puede distribuirse libremente. Se rige bajo la licencia de Apache cuyos puntos:  La Apache License debe incluirse con cualquier redistribución  Cualquier documentación incluida con la redistribución debe ser validad por la ASF  Los términos “Tomcat”, “Projecto Jakarta”, “Apache” o “ASF” no pueden utilizarse sin permiso de la ASF  Tomcat no aporta garantías de ningún tipo  Tomcat puede ser utilizado por cualquier tipo de entidad  Si se modifica el código, no es obligatorio entregar el código fuente de las modificaciones con la redistribución  Las modificaciones no tienen que ser donadas a la ASF

Nº 7


Las diferentes tecnologías Java

Java para dispositivos móviles Java para aplicaciones de escritorio

JME JSE JEE

Nº 8

Java Enterprise Edition (JEE)  Es un conjunto de especificaciones que definen unas APIs para la creación de aplicaciones empresariales Instalación y Administración de Apache Tomcat

 Se construye encima de la JSE  NO ES UN SOFTWARE. Las especificaciones son implementadas por diferentes proveedores (el propio SUN, IBM, Oracle, etc.)  SUN controla estas (y otras) especificaciones a través del Java Community Process, que es un proceso formalizado el cual permite a las partes interesadas involucrarse en la definición de futuras versiones de características de la plataforma Java

Nº 9

Arquitectura multicapa (I)  Sistemas especializados por tareas en los servidores


 Los usuarios acceden mediante un navegador web estándar

Presentación

Persistencia

Nº 10

Lógica de Negocio

Arquitectura multicapa (II)  Ventajas


 Mantenible  Sistemas separados por responsabilidades  Fácil añadir / modificar funcionalidades

 Escalable: los diferentes subsistemas pueden dimensionarse independientemente  Mayor reusabilidad  Fácil gestión de las máquinas clientes de los usuarios

Nº 11


Arquitectura multicapa de la JEE

Cliente / Usuario

HTTP

Presentación Lógica de Negocio

Contenedor Web

RMI

Contenedor EJB

Límites de la tecnología Java Nº 12

Persistencia

SQL

SGBD

Los contenedores JEE (I)


 Un contenedor es un componente software que implementa parte de las especificaciones JEE  Proporciona servicios al programador que son comunes y habituales a todas las aplicaciones liberándole de tener que codificarlos cada vez y permitiéndole centrarse en la lógica de negocio olvidándose de tareas tediosas y repetitivas

Nº 13

Los contenedores JEE (II)  Las especificaciones definen dos contenedores


 Contenedor web: especializado en gestionar la capa de presentación con tecnologías web (JSPs, servlets, etc.)  Contenedor de Enterprise Java Beans (EJBs): especializado en gestionar la capa de lógica de negocio e interactuar con el sistema de persistencia (el SGBD)

Nº 14

Ventajas del uso de contendores Construyendo desde cero

Tareas del desarrollador  Lógica de Negocio  Persistencia  Gestión de transacciones


 Multi-threading  Seguridad  Red  Publicación de servicios

Utilizando contenedores

Tareas del desarrollador  Lógica de Negocio

Proporcionado por el contenedor  Persistencia  Gestión de transacciones  Multi-threading  Seguridad  Red  Publicación de servicios

Nº 15

Servidores de aplicaciones (I)


 Es un software que implementa las especificaciones y contenedores JEE  Sun proporciona el sello “JEE compliant server” sólo si superan unos estrictos juegos de pruebas que garantizan que se satisface la especificación  Diferentes proveedores ofrecen diferentes productos, pero está garantizada la compatibilidad entre todos ellos, así pues una aplicación desarrollada en JEE podrá desplegarse en cualquier servidor de aplicaciones

Nº 16


Servidores de aplicaciones (II)

Nº 17

¿Y Tomcat?


 Tomcat es un producto muy popular, pero no es un servidor de aplicaciones porque sólo (entre otras cosas) implementa el contenedor web  Es adecuado para aplicaciones web con arquitectura de dos capas, donde el propio contenedor web incluye la lógica de negocio sin requerir el contenedor de EJB  Tomcat es más fácil de administrar y requiere menos recursos para funcionar que servidores de aplicaciones completos

Nº 18


¿Qué hemos visto?  El servidor web Apache está en el origen de la ASF  La ASF es una organización que promociona el desarrollo de software libre  Tomcat es un proyecto auspiciado por la ASF  La tecnología Java J2EE se basa en la arquitectura en tres capas  La capa de presentación web se implementa con un contenedor web  Tomcat es un servidor y un contenedor web y es adecuado para algunas tipologías de aplicaciones por su facilidad de uso y su ligereza en cuanto a recursos

Nº 19


Módulo 2

Instalación de Tomcat

Nº 20

Objetivos  Instalar la Java Virtual Machine (JVM)


 Instalar Tomcat  Comprender la estructura de directorios de Tomcat  Resolver problemas típicos  Instalar Ant Nº 21


Instalar la JVM  Tomcat es una aplicación Java y por tanto requiere la JVM  Tomcat 6 requiere la versión Java SE 5.0 o superior  Desde la versión 6 de Tomcat no se necesita el JDK (es suficiente con el JRE)

Nº 22

Instalación de la JVM en Windows (I)


 Descargarla de http://java.sun.com  Establecer la variable de entorno JAVA_HOME en la ruta a la raíz de la JRE  Añadir a la variable de entorno PATH la ruta a la subcarpeta bin de la JRE

Nº 23


Instalación de la JVM en Windows (II)

Nº 24

Descargar Tomcat


 Conectarse a http://tomcat.apache.org  Ir a la zona de descargas y elegir la versión correspondiente:  Core: versión base disponible en diferentes formatos (nos descargaremos el instalador)  Deployer: herramientas de despliegue  Admin Webapp (no disponible todavía para la versión 6)  Embedded: para embeber el servidor en otras aplicaciones

Nº 25

Instalar mediante el asistente Instalar servicio de Windows Instalar librerías nativas APR


Puerto en el que aceptará peticiones

Instalar ejemplos de servlets y JSPs Usuario y password de las herramientas administrativas

Nº 26

Establecer las variables de entorno


 Añadir la variable de entorno CATALINA_HOME que apunte a la raíz de la instalación

Nº 27

Probar la instalación  Iniciar el servidor manualmente  \bin\tomcat6.exe Instalación y Administración de Apache Tomcat

 Iniciar el servidor como un servicio

Nº 28


Comprobar la instalación

Nº 29


La jerarquía de directorios de Tomcat  bin: scripts y ficheros de arranque  conf: ficheros de configuración del servidor y de usuarios entre otras cosas  logs: contiene los ficheros de log  lib: incluye todos los jars que el servidor requiera  webapps: contiene todas las aplicaciones web  work: archivos temporales requeridos por Tomcat

Nº 30


Problemas típicos (I)  Problema: error de versión de clase  Descripción: aparece la siguiente excepción: java.lang.UnsupportedClassVersionError  Solución: instalar una JRE 1.5 o superior y asegurar que JAVA_HOME le apunta  Problema: puerto en uso  Descripción: aparece la excepción: java.net.BindException: Address already in use  Solución: asegurarse que no hay otro servicio en ese puerto (otro servidor web por ejemplo). Se puede monitorizar el puerto mediante el comando netstat -ao

Nº 31


Problemas típicos (II)  Problema: ejecutar varias instancias  Solución: asegurarse que al intentar arrancar Tomcat no hay otra en ejecución (comprobar que no esté activo el servicio de Tomcat)  Problema: un proxy bloquea el acceso  Descripción: se tiene un proxy establecido para todos los servicios HTTP  Solución: deshabilitar el proxy para las conexiones locales. En la configuración del proxy del navegador web permitir la IP 127.0.0.1

Nº 32


¿ Por qué Ant?  Ant es una herramienta de construcción de software que permite automatizar tareas repetitivas en el proceso de compilación, enlazado, despliegue, etc  Se ha convertido en la herramienta de este tipo estándar de facto para este tipo de tareas  Tomcat define una serie de librerías que le permiten automatizar tareas como el despligue y repligue de apliaciones web Nº 33


Instalar Ant y las bibliotecas de Tomcat  Descargar Ant desde http://ant.apache.org  Descomprimir el fichero  Configurar las variables de entorno ANT_HOME para que apunte a la raíz de la distribución  Configurar la variable PATH para añadir la ruta hasta el directorio /bin  Copiar el fichero /lib/catalinaant.jar en /lib

Nº 34


¿Qué hemos visto?  Tomcat es una aplicación Java que requiere la JRE versión 1.5 o superior  Hay diferentes versiones de Tomcat. En general trabajaremos con la versión Core  La instalación bajo Windows se hace de forma sencilla bajo un asistente y la configuración de la variable de entorno CATALINA_HOME  Se han listado los errores y soluciones típicos en la instalación de Tomcat  Tomcat permite automatizar tareas mediante Ant y por eso lo instalamos Nº 35


Módulo 3

Aplicaciones web con Java

Nº 36

Objetivos


 Entender la tecnología de servlets  Entender las JSP  El framework Jakarta Struts

Nº 37

Web sites y aplicaciones web


 Un web site es una colecciones de recursos estáticos como páginas HTML, imágenes  Una aplicación web es un web site con recursos dinámicos  Una aplicación web ejecuta programas en el lado del servidor y para ello tiene diferentes tecnologías disponibles

Nº 38

Ejecución de CGI’s


Servidor Petición

Shell CGI

Petición

Shell CGI

Petición

Shell CGI

Servidor web

Nº 39

Programa CGI

Ejecución de servlets

Servidor Instalación y Administración de Apache Tomcat

Petición

Thread

Petición

Thread

Petición

Thread Servidor web

Nº 40

Servlet

Contenedor web

Ventajas de modelo de servlets


 Utilizan threads en vez de procesos que requieren menos recursos de CPU y memoria (es escalable)  Las tecnologías Java permiten separar la capa de lógica de negocio de la de presentación  Java es un lenguaje robusto y OO  Java es independiente de la plataforma

Nº 41

Fundamentos de los Servlets


 Es un tecnología de componentes que se ejecuta en el lado del servidor  Se encarga de lo siguiente:  Procesa peticiones HTTP  Genera respuestas HTTP dinámicas

 Un contenedor web es una Máquina Virtual Java (JVM) que gestiona los servlets y un pool de threads

Nº 42


Fundamentos de las JavaServer Pages  Las JSP se traducen en clases de tipo servlet que se compilan y ejecutan por el contenedor web  El objetivo principal de las JSP es centrarse en la lógica de presentación y no en la lógica de diseño  Se puede embeber código Java dentro de una JSP  Usando la tecnología Java, las JSP se suelen usar en conjunción con los servlets para implementar el patrón M-V-C Nº 43

Ventajas de la tecnología JSP


 Proporcionan alto rendimiento y escalabilidad porque usan threads para responder a las peticiones  Son tecnología Java y por tanto independiente de la plataforma  Pueden utilizar todas las características de la orientación a objetos y las API Java

Nº 44

Inconvenientes de la tecnología JSP


 Usadas de manera aislada, incluyendo la lógica de negocio, pueden ser crípticas y además son más difíciles de debuggar  Hay que tener en cuenta temas de concurrencia (hay que comprender el proceso mediante el que se convierten en servlets para evitar problemas potenciales)

Nº 45


El patrón MVC (modelo-vista-controlador)

Nº 46

Struts


 Implementa un patrón de diseño de contrastada utilidad en la gestión de interfaces MVC (modelo-vista-controlador)  El framework proporciona  Un componente que actúa de controlador  Clases de conveniencia  Archivos de configuración

Nº 47

¿Por qué vale la pena usar Struts?


 Proporciona una infraestructura flexible y extensible para implementar MVC  Permite al desarrollador centrarse en lo que aporta valor añadido a la aplicación:  Controladores  Componentes que constituyen el modelo  Vistas

 Facilita  Definir el flujo de navegación  Verificar y procesar la entrada de datos del usuario  La gestión de errores

Nº 48

Estructura de una aplicación web (I)


 La estructura de una aplicación web (jerarquía de directorios y ficheros) está definida en la API  Cualquier contenedor web es capaz de trabajar con dicha estructura  Los diferentes contenedores suelen tener un directorio de despliegue donde se instalan las aplicaciones web Ejercicio M3E1 Nº 49

Estructura de una aplicación web (II) Recursos estáticos y JSPs

Descriptor de contexto (context.xml)


Descriptor de despliegue (web.xml)

Servlets y clases compiladas

Nº 50

jars necesarios por la aplicación web


¿Qué hemos visto?  Los servlets son una tecnología más eficiente que otras soluciones para dar dinamismo a las aplicaciones web  Los JSP se centran en la presentación  La tecnología Java hace uso del patrón M-V-C y de la arquitectura en 3 capas  Struts implementa M-V-C  Las aplicaciones web tienen un estructura definida por la API que cualquier contenedor web entiende Nº 51


Módulo 4

Configurar Tomcat

Nº 52

Objetivos


 Entender la arquitectura de Tomcat  Entender la configuración básica de Tomcat  Entender los principales ficheros de configuración  Gestionar el control de acceso

Nº 53

Arquitectura de Tomcat (I)


 Tomcat se constituye como una jerarquía anidada de componentes  Un mismo tipo de componente puede aparecer en diversos puntos de la jerarquía  Es importante entender esta jerarquía a la hora de configurar y administrar el servidor  En la siguiente transparencia se muestra una configuración típica

Nº 54

Arquitectura de Tomcat (II) Servidor Servicio


Conector

Motor

Host

Logger

Válvula

Realm

Logger

Válvula

Realm

Contexto Válvula Realm

Nº 55

Encapsulador

Componentes de Tomcat (I)


 Servidor: el contenedor de más alto nivel ofrece un puerto que permite para el servidor. Sólo uno por JVM  Servicio: contenedor de alto nivel que engloba un motor y un conjunto de conectores  Motor: componente que procesa peticiones, examinándolas para redirigirlas al host o context correspondiente. Motor por defecto: Catalina Nº 56

Componentes de Tomcat (II)


 Realm: gestiona la autenticación y autorización de usuario  Válvula: son filtros transparentes a las aplicaciones que permiten interceptar las peticiones y preprocesarlas  Conector: ofrecen los puertos por los cuales los clientes se conectan a las aplicaciones

Nº 57


Componentes de Tomcat (III)  Logger: informan sobre el estado interno de un componente y permiten registrar esa información  Host: nos permite tener variaso servidores virtuales en la misma máquina y diferenciarlos por dirección IP o por nombre  Contexto: representa la aplicación web (son términos sinónimos) y se considera a la vez un contenedor de componentes servlet y JSP (entre otros)

Nº 58

Configuración por arquitectura


 Comprendiendo las relaciones padre-hijo de los componentes, la administración de Tomcat es sencilla  El fichero de configuración más importante es /conf/server.xml que representa dichas relaciones mediante anidamiento de etiquetas XML  Los scripts de arranque leen este fichero para crear y configurar los componentes Nº 59

El server.xml por defecto


Nº 60

Ficheros de configuración básicos (I)


 Residen en /conf  server.xml: fichero de configuración principal, que se lee al arrancar el servidor. Afecta a la instancia completa de Tomcat. No debería contener configuración de contexto (aplicación)  tomcat-users.xml: contiene autenticación de usuario e información de roles. Las aplicaciones de gestión utilizan esta información Nº 61


Ficheros de configuración básicos (II)  context.xml: configuración de contexto por defecto de las aplicaciones web (configura componentes como gestores de persistencia de sesión, realms, conexiones JDBC, etc)  web.xml: constituye el descriptor de despliegue por defecto de las aplicaciones web  catalina.policy: fichero de configuración del modelo de seguridad de Java SE Nº 62

Ficheros de configuración básicos (III)


 catalina.properties: propiedades que aportan accesos a paquetes internos y control de contenidos sobre los cargadores de clases  logging.properties: Tomcat utiliza por defecto la API de Java SE para escribir los ficheros de log (no log4J) y este es el archivo de configuración

Nº 63


server.xml: Componente Server

Ejercicio M4E1

Nº 64


server.xml: Subelementos de Server

Nº 65


server.xml: Componente Service

Nº 66

Los modos de operaciones de Tomcat


 Servidor de aplicaciones  Tomcat requiere un servidor web que actúe de frontend (Apache, IIS u otro)  El contenido estático es servido por el frontend  Las peticiones a servlets y JSPs son redirigidas a Tomcat por el servidor web  Recibe peticiones en protocolos específicos como AJP que son enviados por el frontend

 Standalone  No hay un servidor web que actúe de frontend  Todos los contenidos son servidos por Tomcat  Recibe peticiones HTTP

Nº 67

server.xml: Connector


 Veremos los conectores y los posibles modos de operación de Tomcat en más detalle en capítulos subsiguientes

Nº 68


server.xml: Componente Engine

Nº 69

Componente Realm


 Implementan la seguridad declarativa  Establecen un mapeo entre usuarios, contraseñas y roles de teareas que pueden llevar a cabo  Lo veremos en más detalles en un módulo posterior

Nº 70


Componente Host  Es un contenedor que representa un host virtual  Un solo servidor Tomcat 6 puede contener muchos hosts virtuales Servidor

Motor

Host Virtual 1

Host Virtual 2

Host Virtual 2

(www.host1.com)

(www.host2.org)

(host1.es)

Web App 1

Nº 71

Servicio

Web App 2

Web App 1

Web App 2

Web App 1

Web App 2


server.xml: Componente Host

Ejercicio M4E2 Nº 72

context.xml


 Ya hemos visto que los contextos establecen una serie de configuraciones para cada aplicación web (los veremos en más detalle)  Se alojan en

/conf//

 Las aplicaciones web pueden definir su propio context.xml en su carpeta META-INF  Si no se define ningún context.xml se aplica por defecto /conf/context.xml

Nº 73

Descriptor de despliegue: web.xml


 Toda aplicación web, por especificación, está obligada a aportar un descriptor de despliegue en WEBINF/web.xml  El descriptor /conf/web.xml es un descriptor por defecto que se procesa siempre antes que el descriptor propio de cada aplicación web  Sólo debería contener información general y no específica de aplicación  Permite activar/desactivar/configurar numerosas opciones como el compilador de JSPs, CGI, SSI, mapeos MIME… Ejercicio M4E3 Nº 74

¿Qué hemos visto?


 La arquitectura de Tomcat se basa en componentes organizados jerárquicamente en relaciones padre-hijo  El fichero de configuración principal es server.xml que mapea esta jerarquía  Hay otros ficheros de configuración que aplican valores por defecto sobre las aplicaciones desplegadas Nº 75


Módulo 5

Gestionar aplicaciones web

Nº 76

Objetivos


 Gestión mediante el Tomcat Manager  Integración de gestión mediante Ant  Gestión mediante peticiones HTTP

Nº 77

Desplegar una aplicación manualmente


 Añadir una entrada en el server.xml, lo que permite colocar la aplicación web en una localización diferente a /webapps

 Copiar el directorio de aplicación completo en el directorio /webapps  Copiar el fichero WAR en /webapps

Nº 78

Tomcat Manager


 Herramienta web que permite llevar a cabo tareas de administración:  Desplegar aplicación web  Listar aplicaciones desplegadas y sesiones activas  Listar recursos JNDI  Elaborar roles de seguridad  Iniciar una aplicación detenida  Detener una aplicación  Replegar una aplicación  Mostrar estadísticas de sesión Nº 79


Permitir el acceso al manager  Por defecto y por motivos de seguridad está desactivado  Hay que configurar un Realm que permita el acceso  Por defecto se controla mediante un Realm que lee los contenidos del fichero /conf/tomcat-users-xml

 Hay que activar un usuario con su password correspodiente y el rol manager Ejercicio M5E1 Nº 80


La pantalla principal del manager

Nº 81

Ajustar la configuración del Manager


 Se trata de una aplicación web como cualquier otra y por tanto tiene un descriptor de despliegue propio  En su web.xml se pueden modificar los criterios de seguridad  Operaciones permitidas y roles administrativos  Tipo de autenticación (veremos los diferentes tipos en un módulo posterior)

Nº 82


Manager: mostrar el estado del servidor

Nº 83


Manager: gestionar aplicaciones (I)

Nº 84


Manager: gestionar aplicaciones (II) Trayectoria: ruta de la aplicación web Nombre a mostrar: el del DD Ejecutándose: true o false según sea Sesiones: número de sesiones activas. Haciendo click sobre el número se obtiene más información estadística  Comandos: arrancar, parar, recargar, replegar    

Nº 85


Manager: desplegar aplicaciones


Controlar aplicaciones mediante Ant


 Instalar Ant y las librerías de Tomcat (ver módulo 2)  Añadir al script build.xml los elementos para llamar a los comandos  Añadir, si no existiera, un usuario con el rol manager

Nº 87

Importar los tasks mediante taskdef


 Los tasks de Tomcat no son estándar de Ant y por tanto hay que importarlos en el fichero build.xml que los utilice build.xml ../.. ../..

Nº 88

Importar los tasks mediante un properties


tomcat-tasks.properties deploy=org.apache.catalina.ant.DeployTask list=org.apache.catalina.ant.ListTask status=org.apache.catalina.ant.JKStatusUpdateTask reload=org.apache.catalina.ant.ReloadTask remove=org.apache.catalina.ant.RemoveTask resources=org.apache.catalina.ant.ResourcesTask start=org.apache.catalina.ant.StartTask stop=org.apache.catalina.ant.StopTask undeploy=org.apache.catalina.ant.UndeployTask ../..

build.xml ../.. ../.. Nº 89

Importar los tasks desde el script predefinido


 Desde la versión de Tomcat 5.5 existe un script que hace todo lo necesario build.xml ../.. ../..

Nº 90


Usar los tasks (I)  Una vez hemos importado los tasks ya los podemos utilizar en nuestros targets para llevar a cabo las diferentes tareas administrativas  Para ver el detalle de uso de cada task, consultar la documentación on-line para el paquete org.apache.catalina.ant

Nº 91

Usar los tasks (II)



Gestión mediante peticiones HTTP (I)


 Los comandos se lanzan con peticiones HTTP desde un navegador  El formato general de la petición es: http//

{nombre_host}:{puerto}/manager/{comando}?{params}  comando: list, sessions, start, stop, install, remove, deploy, undeploy, reload, serverinfo, roles, resources, status, jxmget, jxmset y jxmproxy  params: depende del tipo de comando

 Las respuestas son en texto plano (no HTML)

Nº 93

Gestión mediante peticiones HTTP (II)


 Un navegador web sólo puede enviar peticiones GET  Algunas operaciones requieren peticiones POST o PUT y por tanto requerirán de un cliente más sofisticado que un navegador  Para ver un listado de las diferentes operaciones y sus parámetros ver el capítulo 8 del libro Nº 94


Petición HTTP: listar aplicaciones desplegadas

Nº 95

¿Qué hemos visto?


 Hay diferentes manera de gestionar las aplicaciones web  Mediante el Tomcat Manager que es una aplicación web que requiere activación previa  Mediante tareas Ant que permite automatizar los procesos  Mediante peticiones HTTP

Nº 96


Módulo 6

Características avanzadas

Nº 97

Objetivos


 Entender las sesiones persistentes  Configurar recursos JNDI  Configurar una sesión JavaMail

Nº 98

¿Por qué sesiones persistentes?


 Por defecto, las sesiones de Tomcat están configuradas para sobrevivir a reinicios del servidor, pero si queremos más control deberemos configurarlo  Sesiones inactivas (pero no caducadas) se pueden configurar para que se copien a disco liberando los recursos de memoria asociados  Al parar Tomcat todas las sesiones se vuelcan a disco por lo que al arrancarlo de nuevo se podrán restaurar  Las sesiones que tengan un tiempo de vida que supere cierto límite se copian a disco automáticamente evitando posibles death-locks

Nº 99

Configurar las sesiones persistentes


 Se gestiona mediante el elemento como un subelemento de  Podemos definirlo de manera global si lo situamos en el /conf/context.xml  Podemos definirlo de manera local a una aplicación web si lo ponemos en su fichero META-INF/context.xml

Nº 100


El elemento Manager

Nº 101

Ejemplo de configuración


Ejercicio M6E1

Nº 102


¿Qué es JNDI?  JNDI = Java Naming and Directory Interface  Es una API Java que da una abstracción para acceder de igual forma a diferentes servicios de directorio (LDAP, MS ADS, otros) Aplicación Java

Aplicación Java

Aplicación Java

Aplicación Java

JNDI

Driver LDAP

Nº 103

Driver ADS

Otros drivers


¿Qué recursos se ofrece JNDI?  Autenticación (nombre de usuario y contraseña)  Políticas de control de acceso  Directorios de la organización  Servidores  Impresoras  Otros objetos o recursos

Nº 104


Tomcat y JNDI (I)  Los recursos se preconfiguran global o localmente (server.xml o context.xml) en el servidor  Las aplicaciones web acceden a estos recursos preconfigurados

Nº 105

Tomcat y JNDI (II) Búsqueda JNDI

Aplicación Web


Recurso devuelto

Recurso JNDI preconfigurado en server.xml

Leer y emular funcionalidad JNDI

Servidor Tomcat

Aplicación Web

Aplicación Web

Nº 106

Ámbito de config. de recursos JNDI


 A nivel global de servidor, disponible para todos los servicios y motores. En el elemento del server.xml  A nivel de host virtual. En el elemento del server.xml  A nivel de , asociado a una aplicación web (seguramente en el META-INF/ context.xml) Nº 107

Subelementos JNDI soportados


 Son elementos hijos de o

Nº 108


Atributos del elemento Environment

Ejercicio M6E2

Nº 109

JavaMail y JNDI


 JavaMail es una API utilizada para crear y enviar correo electrónico  Tomcat soporta la configuración JNDI de una sesión JavaMail

Nº 110

Instalar JavaMail  Descargar mail.jar de


http://java.sun.com/products/javamail/downloads/index.html

 Descargar activation.jar de

http://java.sun.com/products/javabeans/jaf/index.jsp

 Copiar los jars a /lib/

Nº 111

Configurar JNDI para JavaMail


 Al igual que los elementos Environment, podemos definirlo en los diferentes ámbitos mail.smtp.host localhost mail.smtp.port 25 Ejercicio M6E3 Nº 112

¿Qué hemos visto?


 Para gestionar sesiones persistentes tenemos el elemento Manager que se configura a nivel de contexto (global o local a una webapp  JNDI es una API que nos permite acceder a diferentes servicios de directorio de manera independiente  JNDI nos permite configurar en el servidor recursos (como JavaMail) que luego podrán ser accedidos desde las aplicaciones Nº 113


Módulo 7

Conexión con bases de datos

Nº 114

Objetivos


 Entender JDBC  Configurar una DataSource a través de JNDI  Interactuar con MySQL

Nº 115

¿Qué es JDBC?


 La mayoría de bases de datos comerciales de hoy día son bases de datos relacionales  JDBC es una API Java que se abstrae del proveedor de bases de datos relacional haciendo transparentes las diferencias entre ambas  JDBC proporciona una interfaz SQL y de conexión contra los diferentes SGBDs Nº 116

Diagrama básico de JDBC Aplicación Java


Llamadas JDBC

Librería JDBC

Independiente del SGBD

Dependiente del SGBD Peticiones SQL nativas

SGBD

Driver JDBC Respuestas SQL nativas

Nº 117

Misión de las operaciones JDBC


 Recibir las llamadas de la API JDBC y transformarlas en una consulta SQL  Enviar esa consulta al SGBD  Recuperar el conjuntos de resultados y transformarlo en una estructura de datos Java

Nº 118

Etapas en la programación JDBC


 Obtener una conexión a un servidor de bases de datos remoto  Generar y preparar una sentencia SQL  Ejecutar la sentencia SQL  Obtener el conjunto resultado y trabajar con él  Desconectarse de la base de datos remota Nº 119

Pool de conexiones


 Los procesos de conexión y desconexión de una base de datos son costosos en recursos y tiempo  Un pool es un componente que almacena conexiones físicas pre-establecidas contra el SGBD y que las proporciona a los componentes que las requieran bajo demanda  Cuando un componente ha terminado de utilizar una conexión al cerrarla, en realidad la está devolviendo al pool pero la conexión física permanece abierta y disponible para un nuevo “usuario”

Nº 120


Funcionamiento de un pool

1.- Solicita conexión

Aplicación Web

2.- Recibir conexión lógica

SGBD 3.- Cerrar conexión lógica

Nº 121

4.- Conexión física devuelta al pool

Emulación JNDI y los pool en Tomcat 6


 Tomcat ofrece  Acceder a las fuentes de datos JDBC mediante una búsqueda JNDI  Utilizar el pool propio de Tomcat (DBCP JakartaComons)

Nº 122


Configurar una conexión JNDI  Añadir una etiqueta en el elemento (META-INF/context.xml) o en el elemento (en server.xml)  Confirmar que se ha definido un elemento en el DD que se corresponderá con el elemento del paso anterior  Utilizar llamadas JNDI en el código de la aplicación para buscar la fuente de datos JDBC

Nº 123


La etiqueta Resource


¿Qué hemos visto?


 Java ofrece la API JDBC para conectarnos de manera independiente a diferentes SGBDs  Un pool es un componente que permite gestionar las conexiones obteniendo un mayor rendimiento  Tomcat permite acceder a fuentes de datos mediante JNDI y tiene un pool integrado

Nº 125


Módulo 8

Conectores

Nº 126

Objetivos


 Entender los diferentes conectores HTTP  Entender la configuración con un servidor web actuando de front-end  Configurar Apache y Tomcat para que se comuniquen

Nº 127

Los modos de operaciones de Tomcat


 Servidor de aplicaciones  Tomcat requiere un servidor web que actúe de frontend (Apache, IIS u otro)  El contenido estático es servido por el frontend  Las peticiones a servlets y JSPs son redirigidas a Tomcat por el servidor web  Recibe peticiones en protocolos específicos como AJP que son enviados por el frontend

 Standalone  No hay un servidor web que actúe de frontend  Todos los contenidos son servidos por Tomcat  Recibe peticiones HTTP

Nº 128

¿Qué son los conectores?


 Son los componentes que proporcionan la interfaz externa al servidor  Existen conectores para diferentes protocolos (HTTP, AJP…)  El conector HTTP/1.1 basado en Coyote es el conector por defecto

Nº 129

Conectores HTTP disponibles


 Conector HTTP/1.1 basado en Java (Coyote)  Conector HTTP de alta eficiencia NIO basado en Java  Conector HTTP APR optimizado con código nativo

Nº 130

Conector HTTP/1.1


 Como hemos visto, los conectores se definen en el /conf/server.xml  El único atributo obligatorio es el port

Nº 131


Atributos del conector HTTP/1.1 (I)

Nº 132


Atributos del conector HTTP/1.1 (II)

Nº 133


Conector HTTP/1.1 con SSL  Utiliza los mismos atributos que el conector HTTP/1.1 (adicionalmente veremos otros más)  Debería tener el atributo secure a true y el scheme a https

Nº 134


Atributos HTTP/1.1 relacionados con SSL

Nº 135


El conector NIO  Es un conector escrito en Java que utiliza las nuevas librerías NIO de Java 5  Proporcionar operaciones sin bloqueo  Soporta Comet (técnica de programación similar a Ajax que permite enviar información al cliente sin que la haya solicitado)

Nº 136


¿Qué es APR?  APR (Apache Portable Runtime) es una librería de código nativo escrita en C/C++ dependiente de la plataforma  Existen versiones para Windows, Linux y Unix  No es estrictamente un conector, pero cuando se activa el conector estándar delega la mayoría de sus operaciones en él  Al utilizar código nativo incrementa la eficiencia y escalabilidad

Nº 137


¿Por qué es más eficiente y escalable?  Utiliza una llamada sendFile() en modo núcleo para enviar grandes ficheros estáticos directamente desde el sistema de ficheros nativo  Usa un solo consultor de persistencia de código nativo para implementar conexiones persistentes para un gran número de conexiones  Utiliza código nativo de OpenSSL, el cual tiene capacidad de acelerar la implementación del controlador SSL (mediante hardware)

Nº 138

Activar APR (I)  Instalar las librerías nativas


 Descargar la librería  En los sistemas Unix / Linux suele estar incluida de serie  Para Windows puede descargarse de: http://tomcat.heanet.ie/native

 Configurar la librería  En Unix / Linux incluirla en LD_LIBRARY_PATH  En Windows incluirla en el PATH

Nº 139

Activar APR (II)


 Modifica el conector para que use APR

Ejercicio M8E1

Nº 140


¿Standalone o sevidor de front-end?  La eficiencia del código nativo APR y las JVM modernas hace que la elección no sea trivial considerando sólo la eficiencia  Una configuración clúster con balanceo de carga obliga a tener un front-end  El soporte de seguridad de Apache e IIS es significativamente mejor que el de Tomcat  Si la estrategia web incluye otros mecanismos dinámicos (PHP, Perl, Python, ASP…) requeriremos un servidor de front-end especializado Nº 141


Configuración front-end con Apache  Para implementar la comunicación se requieren módulos especializados en ambos extremos  Estos módulos se comunican con el protocolo AJP  En el lado de Apache son módulos escritos en C/C++  En el lado Tomcat son conectores AJP escritos en Java

Nº 142

Arquitectura de la integración


Petición de recursos estáticos

Protocolo HTTP

Protocolo AJP

Módulo Petición de recursos dinámicos: servlets,JSPs

Nº 143

Tomcat

Apache

Conector AJP

Características de AJP1.3


 Eficiencia optimizada en redes rápidas (como ethernet gigabit)  Compresión para optimizar el ancho de banda  Soporte para SSL, cifrado y certificados de cliente  Soporte de clústeres

Nº 144

Módulos disponibles para Apache (I)


 Dos opciones  mod_jk: el módulo “tradicional”  mod_proxy: módulo estándar de Apache que en sus últimas versiones soporta AJP

 ¿Cuál es la mejor opción? mod_proxy  El esfuerzo de desarrollo se ha centrado en este módulo  Es estándar de Apache (lo tendremos disponibles sin tener que construirlo)  Es más fácil (estándar) de configurar

Nº 145

Módulos disponibles para Apache (II)


Versión de Apache 1.3.x

2.0.x

2.2.x

mod_jk

Sí

Sí

Sí

mod_proxy

No

Sí (necesita código de la 2.2)

Sí

Nº 146

mod_jk: Concepto de worker


 Representa una instancia de Tomcat en ejecución  Cuando tenemos un cluster tenemos más de un worker  Cada worker se identifica por un nombre de host (máquina donde está la instancia Tomcat) único o una combinación de dirección IP y número de puerto (puerto donde escucha el protocolo AJP) Nº 147

mod_jk: El fichero workers.properties (I)  Es un fichero que se situa en


/conf

 Es leído por el módulo de Apache que se encargará de enviar las peticiones AJP contra las diferentes instancias de Tomcat  Contiene  Descripción de la lista de workers  Descripción de cada instancia de worker de la lista anterior

Nº 148

mod_jk:El fichero workers.properties (II)


workers.properties worker.list = testworker1, tesworker2 worker.testworker1.type = ajp13 worker.testworker1.host = 192.168.1.128 worker.testworker1.port = 9009 worker.testworker1.connection_pool_size = 5 worker.testworker1.connection_pool_timeout = 300 worker.testworker2.type = … …

Nº 149


mod_jk: Propiedades de los workers

Nº 150


mod_jk: Tipos de worker  ajp13: representa una instancia en ejecución de Tomcat  lb: se emplea para equilibrio de cargas. Este worker no procesa peticiones sino que las redirige a otros worker de tipo ajp13 en función de su carga  status: se utiliza para mostrar información útil de carga  jni: es un protocolo que permite enviar peticiones entre Apache y Tomcat a través de memoria porque comparten el mismo proceso Nº 151

mod_jk: Configuración de Apache  Construir el módulo mod_jk y copiarlo en


/modules

 Añadir la directiva correspondiente en httpd.conf LoadModule jk_module modules/mod_jk.so

 Configurar el wokers.properties

Nº 152

mod_proxy: Configuración de Apache


 Añadir la directiva correspondiente en httpd.conf LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_ajp_module modules/mod_proxy_ajp.so LoadModule proxy_balancer_module modules/mod_proxy_balancer.so

 Editar la configuración de proxy en http.conf, p.e.: ProxyRequests Off ProxyPreserveHost On Order deny,allow Allow from all ProxyPass /examples/jsp ajp://localhost:8009/examples/jsp ProxyPassReverse /examples/jsp ajp://localhost:8009/examples/jsp Order allow,deny Allow from all Nº 153

Tomcat: config. del conector AJP


 En el lado de Tomcat, las peticiones AJP se reciben en un conector AJP independiente del módulo que esté usando Apache

Ejercicio M8E2

Nº 154

¿Qué hemos visto?


 Tomcat proporciona conectores HTTP eficientes que lo convierten en una opción válida para una configuración standalone  La configuración con un servidor web actuando de front-end puede seguir teniendo sentido (para montar un cluster, por ejemplo)  La comunicación entre un servidor web y Tomcat se hace mediante un protocolo eficiente llamado AJP que implica la inclusión de módulos en el servidor web y la activación de un conector AJP en Tomcat

Nº 155


Módulo 9

Seguridad

Nº 156

Objetivos


 Asegurar la instalación de Tomcat  Entender el soporte de autenticación para las aplicaciones Web  Configurar el soporte para cifrado SSL

Nº 157

Verificar la integridad de la descarga


 Es importante asegurarnos que el código que nos descargamos no ha sido modificado por una fuente maliciosa  Para verificarlo disponemos de dos opciones  Funciones de hash MD5  claves PGP

 En Windows hay diferentes herramientas que calculan las funciones de hash

Nº 158

Eliminar las aplicaciones por defecto  ROOT, tomcat-docs y examples


 No aportan funcionalidad en producción  Riesgo mínimo pero potencialmente podría haber un exploit

 manager y host-manager  Por su funcionalidad (tareas administrativas) presentan el mayor riesgo  Deberían ser eliminadas por completo  Si fueran necesarias:  Cambiar el mecanismo de autenticación de BASIC a un tipo más seguro  Permitir sólo el acceso de direcciones específicas  Elegir un usuario y password difícil de adivinar

Nº 159

Cambiar el comando de SHUTDOWN


 Ya hemos visto que el componente Server permite configurar un puerto y un comando de apagado del servidor  Se debería cambiar el puerto y la palabra clave por defecto

 También es una buena idea bloquear el acceso al puerto mediante un firewall

Nº 160


Ejecutar Tomcat con una cuenta restringida  Si un atacante se hace con el control de Tomcat es importante que el usuario que lo ejecuta no tenga privilegios para dañar el sistema  El Unix / Linux crear un usuario cuyos únicos privilegios sea ejecutar Tomcat  En Windows crear un usuario no administrativos y utilizar la utlidad Servicios de las carpeta Herramientas administrativas para establecer el usuario

Nº 161


Gestor de servicios

Nº 162

Asegurar el sistema de ficheros (I)


 En Windows  sólo podremos restringir acceso a ficheros si con NTFS (con FAT32 no hay nada que hacer)  NTFS se basa en listas de control de acceso: se puede establecer qué usuarios acceden a un recurso  Deberíamos denegar el acceso a todos los ficheros de todas las particiones

 En Unix / Linux los permisos se establecen explícitamente mediante usuarios y grupos

Nº 163

Asegurar el sistema de ficheros (II)


 Conceder permisos de lectura y ejecución sobre los ficheros de la JRE  Conceder permisos de lectura sobre  /bin  /lib  /webapps (aunque esto inhabilita el uso del manager como herramienta para desplegar nuevas webapps)

 Conceder permisos de lectura y escritura sobre /conf

Nº 164


Utilizar el gestor de seguridad de Java  La arquitectura de seguridad de Java está basada en permisos  Una vez activado (no lo está por defecto), las aplicaciones deberán tener permiso explícito para realizar ciertas tareas  Los permisos se conceden mediante ficheros de políticas  El fichero de políticas de Tomcat es /conf/cataina.policy

 Para activar el gestor:

/bin/catalina start -security

Nº 165

Proteger aplicaciones web


 Hasta ahora hemos visto como proteger Tomcat y la plataforma  Las seguridad a nivel de aplicación puede categorizarse en;  Autenticación y Realm  Cifrado  Restricción de Host

Nº 166

Autenticación y Realm


 Autenticar es el proceso de determinar y validar la identidad de un cliente  J2EE proporciona la API JAAS (Java Autentication and Authorization Service) como mecanismo estándar de autenticación  El uso de JAAS garantiza la portabilidad del mecanismo de autenticación entre diferentes servidores  El mecanismo de Realm de Tomcat es una implementación de JAAS

Nº 167

Mecanismos de autenticación


 BASIC  DIGEST  Formularios  Certificado de cliente HTTP

Nº 168

Mecanismo BASIC


 Es una aproximación simplista  El navegador envía credenciales (user y password) cifradas en base64 al servidor que descifrará y utilizará para autentificar  Problemas  base64 no es un mecanismo de cifrado seguro  Los navegadores guardan en caché las credenciales

Nº 169

Mecanismo DIGEST


 Es similar a BASIC con la diferencia que la contraseña se transmite de forma segura  El cliente aplica una función de hash sobre la contraseña y transmite el resultado al servidor. Éste realiza la misma operación sobre el password que tiene almacenado y compara los resultados

 Problemas  La contraseña original debe almacenarse en algún lugar (habrá que proteger adecuadamente este recurso)  El navegador guarda en caché las credenciales

 Java soporta los hash MD5 y SHA

Nº 170

Mecanismo de formularios


 El navegador no coopera y es la aplicación web la que tiene que crear un formulario que permita enviar las credenciales  La transmisión de los datos se puede hacer sobre HTTPS garantizando el cifrado de datos  Problema  Sigue habiendo dependencia de usuarios y credenciales que pueden obtenerse por fuerza bruta o ingeniería social Nº 171

Mecanismo de certificados digitales


 Se utilizan certificados digitales de manera simétrica  El cliente puede estar seguro que se conecta al servidor que pretendía (como certifica una entidad externa como VeriSign) mediante la clave pública  El servidor recibe un certificado del cliente que le permite autenticarlo

 Es un sistema muy seguro aunque generalmente se usan mecanismos más sencillos como la autenticación a través de formularios sobre HTTPS

Nº 172

Configurar la aplicación web


web.xml … todo TodaLaAplicacion /* administrador BASIC MiRealm administrador …. Nº 173

Configurar los Realm en Tomcat


 El modelo se construye sobre los conceptos de usuarios y roles  La aplicación declara en su descriptor qué roles pueden acceder a qué recursos y los usuarios que dispongan de ese rol tendrán acceso  Los Realm, se configuran en Tomcat (no en la aplicación) y así se pueden añadir y borrar usuarios dinámicamente  Existen diferentes implementaciones: JDBCRealm, DataSourceRealm, JNDIRealm, MemoryRealm, JAASRealm

Nº 174

MemoryRealm


 Los usuarios y roles se almacenan en un fichero de texto editable (p.e. XML) que se carga en memoria mis-usuarios.xml

context.xml Ejercicio M9E1 Nº 175

JDBCRealm  Almacena las credenciales en una base de datos


users PK

login

user_roles PK,FK1 PK

login role

password


Cifrado SSL


 Protocolo que permite una conexión segura entre clientes y servidores en una red  Tiene protocolos de clave pública/privada y de clave simétrica  HTTPS utiliza HTTP sobre SSL para ofrecer encriptación y autenticación fiable

Nº 177

Añadir soporte SSL a Tomcat


 Descargar e instalar una implementación SSL (podemos usar la librería JSSE estándar de Java o la implementación nativa APR)  Crear un almacén de claves de certificado al que añadiremos un certificado que firmaremos nosotros  Obtener un certificado de una agencia de certificación externa como VeriSign para que los usuarios puedan confiar en nuestro certificado (en desarrollo podemos obviar este paso)  Configurar Tomcat para SSL

Nº 178

Preparar el almacén de claves  Lo hacemos mediante la herramienta


/bin/keytool

Nº 179

Configuración de Tomcat


 Situamos el almacén de claves y configuramos el conector Conector Java

Conector Nativo APR

Nº 180

Configurar la webapp para que use SSL


 Hay que editar el descriptor de despliegue para añadir una user-data-constraint especificando protocolo CONFIDENTIAL web.xml todo TodaLaAplicacion /* administrador CONFIDENTIAL Ejercicio M9E3 Nº 181

¿Qué hemos visto?


 Hay que personalizar la configuración por defecto de Tomcat cuando esté en entorno de producción para garantizar la seguridad  J2EE define un estándar de autentificación para la aplicaciones web que se basa en Realms que Tomcat implementa  Tomcat tiene conectores que proporcionan SSL Nº 182


Módulo 10

Alojamiento Compartido

Nº 183

Objetivos


 Entender las nociones de alojamiento compartido

Nº 184

¿Qué es el alojamiento compartido?


 Pequeñas organizaciones es posible que no puedan permitirse tener su propio Tomcat (máquinas, ingenieros, etc.)  Se puede subcontratar el servidor a un proveedor de servicios  Estos proveedores suelen proporcionar soluciones en las que se comparten recursos: bases de datos, servidores de correo, firewall, servidores web y servidores de aplicaciones Nº 185

Alojamiento virtual


 El alojamiento virtual se refiere a que una misma máquina física proporciona más de un servidor web (o de aplicaciones)  Tipos  Basado en IP: cada dominio web necesita tener una dirección IP diferente que es lo que usa el servidor para diferenciar peticiones  Basado en nombres: los dominios pueden compartir IP y las peticiones se diferencian por nombre

Nº 186

Alojamiento virtual basado en IP


 Necesitamos que la máquina tenga más de una IP válida  Funciona con todos los clientes HTTP (aunque usen la versión 1.0)  El número de hosts virtuales máximo está limitado y la administración asociada a la gestión de muchas IPs puede ser tediosa

Nº 187

Alojamiento virtual basado en nombres


 La máquina no necesita más de una dirección IP  Para poder funcionar se basa en la cabecera Host que es una característica de HTTP 1.1 por lo que es posible que no todos los clientes puedan conectarse  La administración es más sencilla

Nº 188

Configurar Tomcat para alojamiento virtual basado en nombres


 Está disponible desde las primeras versiones  Consiste en añadir nuevas entradas Host a nivel de Engine server.xml …

Nº 189

Configurar Tomcat para alojamiento virtual basado en IP


 Es una característica nueva desde la 5.5  La configuración es prácticamente la misma excepto en que activamos un atributo a nivel de conector que fuerza a ignorar la cabecera Host de HTTP/1.1 con lo que sólo se usará la IP server.xml … … Nº 190

Configuración con front-end y alojamiento virtual


 Apache también se puede configurar para trabajar con los dos modos de alojamiento virtual  Tomcat también soporta el modo de alojamiento virtual teniendo un front-end Apache

Nº 191

Arquitectura en modo front-end


Apache Cliente Web

Tomcat

Gestor de peticiones

Host Virtual 1

Host Virtual 2 …

Módulo de Host Virtual

Host Virtual N

mod_jk

Nº 192

Conector AJP

¿Qué hemos visto?


 El alojamiento virtual tiene sentido cuando se quiere compartir el mismo servidor entre diferentes usuarios  Existe alojamiento virtual por IP o por nombre  Tomcat 6 en modo standalone soporta ambos  También se puede configurar con un front-end

Nº 193

instalacion-y-administracion-de-tomcat-v1-2008-07

Recommend Documents