ServidoresdeAplicaciones

(1)

Ser vi dor es de Apl i caci ones

en Li nux

(2)

Servidores de Aplicaciones en

Linux

2010/PFT/2887

Jorge López Díaz

(3)

A María, Nuria y Jaime, que me han facilitado el trabajo y han soportado mi aislamiento durante todos estos días.

Jorge López Díaz

(4)

Índice de materias

Table of Contents

Prólogo 1

Módulo 1 – Shell. Comandos 3

Shell ... 3

Comandos ... 4

Redirecciones ... 4

Módulo 2 - Sistema de archivos. Configuración 7

El sistema de archivos ... 7

Enlaces ... 8

Los archivos de configuración ... 8

Módulo 3 - Certificados SSL 11

Estructura PKI ... 11

Gestión de certificados ... 12

Certificados y Java ... 14

Módulo 4 – Apache. Subversion 17

Apache ... 17

Subversion ... 23

¿Problemas? ... 26

Módulo 5 - Tomcat 29

Instalación ... 29

Gestión de aplicaciones ... 32

¿Problemas? ... 34

Módulo 6 - JBoss 35

Instalación ... 35

Estructura de JBoss ... 37

Configuración ... 38

¿Problemas? ... 40

Módulo 7 - Clusters 41

Tomcat ... 41

JBOSS ... 43

Módulo 8 - Auditoría y Seguridad 47

Seguridad ... 47

Registro (logs) ... 49

Auditoría ... 50

ANEXO A – Comandos habituales 53

ANEXO B – Cluster Tomcat 59

Bibliografía 63

(5)

(6)

Prólogo

PRÓLOGO

Tanto el sistema operativo Linux como los servidores de aplicaciones son dos tecnologías cada vez más usadas, pues permiten el despliegue de aplicaciones desarrolladas en Java de forma muy rápida, fiable e independiente del cliente.

Este manual hace un recorrido por los diferentes servidores de aplicaciones que se ejecutan sobre el sistema operativo Linux y de los servicios en los que se apoyan. A la vez, se hace un repaso de algunos conceptos colaterales tales como la estructura del sistema operativo, el uso de certificados digitales, la ejecución en cluster y aspectos sobre auditoría y seguridad. Todo ello desde la perspectiva de la administración de sistemas y no desde el desarrollo de aplicaciones.

En el módulo 1 nos acercaremos a los comandos habituales de Linux y el entorno en el que se ejecutan. En el módulo 2 se explicará la organización y configuración del sistema operativo.

Se dedicará el módulo 3 a la gestión de certificados digitales que se debe hacer en Linux. Apache y Subversion son dos productos que se integran y que repasaremos en el módulo 4.

Los módulos 5 y 6 se dedican a los servidores de aplicaciones más comunes: Tomcat y JBoss respectivamente. En el módulo 7 se verá el modo de clusterizar los productos anteriores y, para terminar, el módulo 8 dará algunas notas sobre seguridad y auditoría bajo Linux.

Linux y los productos de software libre se han introducido lenta e inexorablemente en las empresas e instituciones, ofreciendo soluciones de calidad. Es por ello una necesidad, cuando no una obligación, familiarizarse con ellos.

Espero que este manual pueda servir de guía en esa tarea, que resulte útil y, si es posible, ameno.

Jorge López Díaz Técnico de Gestión Informática en la Consejería de Sanidad y Consumo

(7)

(8)

Módulo 1 – Shell. Comandos

MÓDULO 1 – SHELL. COMANDOS

El sistema operativo Linux ha conseguido implantarse en el mundo de la informática profesional a lo largo de los últimos años. Sigue la filosofía de Unix por lo que numerosos comandos tienen el mismo nombre y muchas de sus opciones, aunque la coincidencia no es total.

Shell

Para poder ejecutar estos comandos es necesario un entorno que permita su introducción y nos muestre el resultado de su ejecución. Esto se consigue mediante un tipo de programas llamados shells. Como casi todo en Linux, es posible usar varias alternativas, entre las que destacan:

• C-Shell

• Bourne Shell

• Korn Shell

• Bash

El shell Bash, de los más utilizados, dispone de una serie de variables de entorno predefinidas así cono una serie de palabras reservadas que se pueden consultar en http://www.linux-es.org/node/107. Asignando valores a estas variables de entorno conseguiremos acomodar el shell para poder trabajar en él del modo más adecuado. Algunas de las más usadas son:

• _PATH: contiene las rutas en las que encontrar programas.

• _LANG: define el idioma con el que trabajaremos, de modo que los mensajes de error, la ayuda y otras informaciones se ofrecerán en el que se fije.

• _PS1: indica que caracteres se mostrarán en la línea de comandos del shell como prompt.

• _HOME: señala cual es la carpeta por defecto del usuario con el que hemos abierto sesión.

• _HOSTNAME: su valor es el nombre del servidor.



A menudo se define PS1 como el nombre del usuario seguido del directorio actual, terminando en $ (en # si es el usuario root)

El shell permite crear scripts, o programas, con gran variedad de instrucciones y posibilidades como bucles, funciones, inclusiones, parámetros, etc. Esto permite una gran potencia cuando se usan adecuadamente.

Una característica del shell es la capacidad de poder redirigir tanto la entrada como la salida de un comando. Estas redirecciones permiten, por ejemplo, registrar en un archivo los mensajes que genera la ejecución de un comando, también

(9)

que un comando tenga como entrada el contenido de un archivo y, por último, concatenar dos o más comandos de modo que la salida del primero sea la entrada del siguiente.

Comandos

En el anexo A, al final del manual, se enumeran los comandos más comunes por orden alfabético.

Otra característica muy útil del shell Bash es el auto completado. Bastará introducir los primeros caracteres de un comando y pulsar la tecla <TAB> para que se termine de escribir el comando o los nombres de ficheros y carpetas.

Casi todos los comando ofrecen la opción _-h o _–help que nos proporcionarán una descripción breve del uso del comando.

Para información más detallada existe el comando man, el cual se ejecuta seguido del comando sobre el que necesitamos ayuda:

man ls

Este comando, como el resto, nos mostrará la ayuda en el idioma definido por la variable _LANG.

Ejercicio 1: Usar el comando ls para nos liste el contenido de la carpeta /etc ordenado alfabéticamente de forma descendente.

Redirecciones

Cuando se ejecuta un comando en Linux, por defecto usará la entrada estándar (stdin, normalmente el teclado), y proporcionará unos datos por la salida estándar (stdout, normalmente la pantalla). Además también generará una salida de errores (stderr) que, por defecto, también irá a la salida estándar.

Con las redirecciones seremos capaces de cambiar este comportamiento redefiniendo la entrada, la salida o ambas.

Se añade al final del comando el signo _< para indicar que archivo será la entrada y el signo > para indicar a que archivo irá la salida. Por ejemplo:

gzip < un_archivo > un_archivo.gz ls l > listado.txt



Para redirigir la salida de errores usaremos 2> nombre_archivo

Ejercicio 2: Ejecutar el comando ls /etc y luego ls /etc > listado.txt. Observar el resultado en ambos casos.

Si en vez de usar >, usamos >>, la salida se redirige al archivo indicado pero si existe no se crea de nuevo sino que se añade la salida al final del archivo ya existente.

(10)

Ejercicio 3: Redirige la salida y la salida de errores al mismo archivo, por ejemplo ls -l no_existe > listado.txt 2> listado.txt.

Ahora ejecuta ls -l no_existe > listado2.txt 2>&1. Observa los archivos de salida. ¿Qué deduces?

Mediante el signo & podemos redirigir a la vez la salida estándar y la de errores al mismo archivo:

ls a* b* &>salida.txt



Redirigiendo la salida estándar y de errores mediante & también es posible usar

>> para añadir al fichero de salida.

Otra posibilidad de redirigir la entrada es usar el signo _<<

seguido de una cadena de caracteres. El comando aceptará como entrada todo lo introducido por el teclado hasta encontrar la cadena antes especificada:

sort k2 <<FIN

>1 manzana

>2 pera

>3 almendra

>FIN

Tubos

Sirven para encadenar un conjunto de comandos que no están programados para ello de tal forma que la salida estándar de cada comando se usa directamente como la entrada del siguiente, mediante un tubo anónimo (pipe). Se emplea el signo _| para representar el tubo.

Fig. 1.1 – Esquema de una “tubería" de comandos.

Estos entubamientos pueden ser muy simples:

(11)

ls l | less

O muy complejos:

curl "http://en.wikipedia.org/wiki/Pipeline_(Unix)" | \ sed 's/[^azAZ ]/ /g' | \

tr 'AZ ' 'az\n' | \ grep '[az]' | \ sort u | \

comm 23 /usr/share/dict/words

Ejercicio 4: Escribir una tubería de comandos que devuelva el número de archivo dentro del directorio /tmp.

Comando

xargs

Este comando usa la entrada estándar como una lista de parámetros para el comando especificado a continuación, como por ejemplo:

cat > texto1

>pera

>manzana

>naranja

xargs < texto1 echo “fruta: “

fruta: pera fruta: manzana fruta: naranja

Ejercicio 5: Usar el comando xargs para obtener en una línea todos los directorios dentro de /var/log.

(12)

Módulo 2 - Sistema de archivos. Configuración

MÓDULO 2 - SISTEMA DE ARCHIVOS.

CONFIGURACIÓN

El sistema de archivos

Sólo existe una estructura de directorios o carpetas que empieza por la carpeta raíz, que se representa mediante /, y bajo la cual cuelga toda la estructura de ficheros y carpetas.

Además, todo se trata como fichero, desde un disco duro a un ratón o una zona de memoria.

Todas las particiones con un sistema de archivos que reconozca Linux se montan a partir de un directorio, el punto de montaje. No hay, por tanto, letras de unidades.



Linux reconoce y es capaz de manejar casi todos los sistemas de archivos que hay, incluso aquellos en desuso. Destacar la capacidad de montar en modo lectura-escritura NTFS.

Colgando del directorio raíz hay una serie de directorios que tienen un cometido específico:

• _/dev: aquí se definen todos los dispositivos físicos que el sistema conoce como discos, particiones, puertos USB, el ratón, etc.

• _/etc: bajo este directorio se almacenan las configuraciones y parámetros del sistema operativo como el nombre del servidor, su dirección IP, las carpetas compartidas, los usuarios definidos, etc.

• _/home: Contiene los directorios de los usuarios.

• /media: Bajo este directorio se montan de forma automática las particiones que se detectan, usando la etiqueta del sistema de archivos para distinguirlos, o su tamaño cuando no se dispone de etiqueta.

• _/proc: Hace referencia a los parámetros del kernel almacenados en memoria pero presentados como ficheros.

• _/usr: Este directorio contiene los programas instalados en el sistema operativo como editores, utilidades, correo electrónico, etc.

• _/var: Almacena información no vital como archivos de log, cálculos parciales, los mensajes de correo-E, los trabajos de impresión o los trabajos diferidos.



Si el nombre de un archivo empieza por “.", éste quedará oculto.

Ejercicio 6: Ejecutar el comando ls para que muestre los archivos ocultos.

(13)

Enlaces

Otra particularidad interesante en Linux son los enlaces. Un enlace es un alias para el nombre de un archivo. Los hay de dos tipos: simbólicos y físicos.

Los primeros son meros punteros a una ruta, por lo que es conveniente definirlos de forma absoluta. Los segundos son nombre alternativos para un archivo que ocupan un i-nodo. La consecuencia es que si borramos el archivo original, en el primer caso sólo permanecerá el puntero, mientras que en el segundo caso el archivo permanece pero ahora con el nombre alternativo solamente.



Un i-nodo es un espacio reservado en el sistema de archivos que indica en que parte del disco se encuentra el archivo al que hace referencia.



El comando para crear enlaces es ln, con la opción -s o -h si lo queremos simbólico o físico respectivamente.

Ejercicio 7: Crea el archivo fichero1 y después un enlace simbólico enlaceS y otro físico enlaceF. Observa que sucede después de borrar el archivo fichero1.

Los archivos de configuración

Como ya se comentó, se suelen almacenar bajo el directorio /etc. A su vez, dentro de éste encontramos los directorios que configuran los programas instalados así como el propio sistema.

En la carpeta /etc/network suele almacenarse la configuración de red.

Otro par de archivos muy interesantes son /etc/passwd y /etc/group. El primero contiene la definición de los usuarios del sistema, mientras que el segundo recoge los grupos.

En el fichero _/etc/fstab se indican las particiones y sistemas de ficheros que se montarán de forma automática.

Un directorio de gran importancia es /etc/init.d pues contiene los archivos que nos permiten parar y arrancar los servicios de nuestro sistema, tanto de forma manual como automática.



Para arrancar o parar un servicio basta con lanzar el correspondiente comando con el parámetro start o stop, como por ejemplo: /etc/init.d/crond stop

Para gestionar automáticamente el modo de arranque y qué servicios se arrancan, se definen siete niveles de ejecución y otros tantos directorios del tipo _/etc/rcn.d, donde _n es el nivel.

(14)

Se suele arrancar el sistema en el nivel 3 si no queremos entorno gráfico y en el nivel 5 para disponer de él.

También es posible cambiar de un nivel a otro mediante el comando _init seguido del nivel deseado.



Sólo el usuario root podrá ejecutar el comando init.

Veamos para que se usa cada uno de estos niveles:

0. Apagado. Si cambiamos a este nivel, en realidad estamos apagando el sistema pero deteniendo primero los servicios.

1. Monousuario. Tan sólo se puede acceder como root.

2. Multiusuario sin soporte de red.

3. Multiusuario con soporte de red.

4. No se usa.

5. Multiusuario con soporte de red y gráfico.

6. Reinicio. Se reinicia el sistema de forma inmediata, parando primero los servicios.



Para determinar el nivel de del sistema en el arranque se incluye en el archivo /etc/inittab la siguiente línea:

id:5:initdefault:

En cada uno de los directorios rcn.d existirán enlaces simbólicos hacia los scripts de los servicios contenidos en init.d, creados de tal manera que los que empiezan por K se ejecutan antes de salir de ese nivel, y los que empiezan por S se ejecutan antes de entrar en ese nivel. A su vez se numeran para ordenar la ejecución de cada uno de ellos.

Por ejemplo, en _/etc/rc3.d (el nivel 3), podemos encontrar algunas entradas como éstas:

Fig 1.1 – Muestra del contenido de /etc/rc3.d

Ejercicio 8: Ejecuta el comando init 1 para entrar en modo monousuario y después ejecuta el comando init 6 para reiniciar.



Para ejecutar comandos como root hay que anteponer el comando sudo.



Para saber en nivel estamos hay que ejecutar el comando runlevel.

(15)

Para añadir o quitar servicios de un nivel de ejecución se utiliza el comando _chkconfig, dependiendo de las opciones que le pasemos.

Si usamos la opción _–list nos mostrará la configuración de inicio de todos los procesos. Podemos indicarle uno concreto, así chkconfig –list crond nos mostrará:

Para configurar un servicio, le indicaremos los niveles en los que queremos que se arranque o en los que no queremos que se arranque, por ejemplo:

chkconfig --level 35 httpd on chkconfig –-level 1 httpd off Ejercicio 9: Comprobar la configuración de arranque de crond. Ejercicio 10: Deshabilitarlo para el nivel 3 y habilitarlo para el nivel 2.

(16)

Módulo 3 - Certificados SSL

MÓDULO 3 - CERTIFICADOS SSL

Casi todas las distribuciones de Linux usan _openssl para gestionar la infraestructura de certificados, aunque hay alternativas como _gnutls. A su vez, las diferentes aplicaciones pueden usar _openssl, _gnutls u otra solución, pero también la primera es la más habitual.

Estructura PKI

Hay dos estrategias principales a seguir: usar certificados de entidades externas, como la FNMT o Verisign, o usar certificados generados por una CA propia. Dependerá de la necesidad de interactuar con equipos y organizaciones ajenas.

En el primer caso bastará con importar los certificados y claves en las carpetas adecuadas. En el segundo caso será necesario crear toda la infraestructura PKI en nuestro servidor. Existirá una carpeta para los certificados de la autoridad certificadora propia (CA), y otra para el resto.

Antes de explicar la creación de esa infraestructura, es necesario conocer los diferentes formatos disponibles para almacenar certificados:

• CER,DER,CRT: Se utilizan normalmente para el almacenamiento del certificado en formato binario (DER, Distinguish Encoding Rules).

• PEM - Certificado codificado en Base64, encerrado entre

"---BEGIN CERTIFICATE---" y "---END CERTIFICATE---". (PEM, Privacy-enhanced Electronic Mail)

• P7B, P7C: El formato PCKS#7 permite almacenar el certificado junto con los certificados de la ruta de certificación. La ruta de certificación es el conjunto de certificados que jerárquicamente firman un certificado.

• PFX, P12: Este formato permite la transferencia de los certificados junto con sus claves privadas correspondientes. PCKS#12 permite incluir todos los certificados de la ruta de certificación.

En http://es.wikipedia.org/wiki/PKI#Componentes se explica la infraestructura PKI, de lo que destacamos los tipos de certificados y ficheros:

• Clave privada: Contiene la clave privada y suele tener contraseña.

• Solicitud de certificado: Se envía la clave pública y la información de identidad en este archivo a la CA para que ésta la firme.

• Certificado: Contiene la clave pública firmada por la CA.

• Lista de revocaciones: Este archivo contiene una lista de certificados revocados por la CA.

(17)

• Certificado CA: Contiene el certificado auto firmado de la CA.



Cuando se envía la solicitud de certificado a la CA es necesario especificar el uso o los usos que podrá tener:

Identificar usuarios de correo electrónico Identificar servidores web.

Identificar desarrolladores de software

Gestión de certificados

Existen varios tipos de certificados pero el más extendido es el X.509, definido por la norma del ITU-T X.509 (versión 3) de la ISO (International Organization for Standardization) para su modelo OSI .(Open System Interconnection).

Un certificado X.509 normalmente es un fichero pequeño que contiene la siguiente información:

• Nombre Distintivo del propietario.

• Nombre Distintivo de la Autoridad Certificadora.

Identificación y firma de la Autoridad Certificadora (CA) que firmó el certificado.

• Período de vigencia. El período de tiempo de vigencia del certificado.

• Información adicional sobre la CA, como números de serie o versión.

OpenSSL

Openssl es un conjunto de herramientas que permiten una completa gestión de certificados. Para manipular certificados tenemos el comando _openssl, que admite una gran variedad de modalidades distintas, entre ellas:

• _ca: Gestión de una autoridad certificadora (CA).

• _crl: Gestión de revocación de certificados CLR (Certificate Revocation List).

• _crl2pkcs7: Conversiones de CRL a PKCS#7.

• _passwd: Generación de contraseñas.

• _pkcs12: Gestión de certificados PKCS#12.

• _pkcs7: Gestión de certificados PKCS#7.

• _req: Gestión de solicitudes de certificados X.509 (Certificate Signing Request, CSR).

• _rsa: Gestión de llaves RSA.

• x509: Gestión de certifcados de tipo X.509.

En función de la distribución, la configuración de openssl se encontrará en un directorio bajo _/etc. Dentro de la carpeta se

(18)

estilo openssl.cnf. En él se especifican los valores por defecto, las carpetas dónde se almacenan las claves y certificados, etc.

Normalmente habrá una carpeta _private que contiene la clave del servidor, otra _certs que contiene los certificados conocidos de confianza y otra newcerts que contiene una copia de cada certificado que firma la CA.

El archivo openssl.cnf se divide en secciones dentro de las cuales se especifican las opciones que se deben aplicar.

Las secciones que habría que modificar son:

[ CA_default ]

dir = /etc/pki/cursoCA # Carpeta base

certs = $dir/certs # Certificados firmados crl_dir = $dir/crl # Listas de revocacion database = $dir/index.txt # Indice base de datos new_certs_dir = $dir/newcerts # Certificados nuevos certificate = $dir/cacert.pem # Certificado de la CA serial = $dir/serial # Numero seria actual private_key = $dir/private/cakey.pem# Clave privada C A

# Politica respecto de los valores de la CA [ policy_match ]

countryName = match # debe coincidir stateOrProvinceName = supplied # debe proporcionarse organizationName = supplied

organizationalUnitName = optional # puede dejarse vacio commonName = supplied

emailAddress = optional

# Valores por defecto para solicitudes de certificados [res_distinguished_name]

countryName_default = ES

stateOrProvinceName_default = Region de Murcia 0.organizationName_default = CARM

organizationalUnitName_default = curso Serv Aplicaciones

Creación de una CA

Una Autoridad Certificadora (CA, Certificate Authority) es la autoridad encargada de firmar los certificados y posteriormente confirmar que el dueño de un certificado es realmente quien dice ser.

Para generar una CA tendremos que crearnos la carpeta dónde queramos tener la configuración de nuestra CA y, dentro de esa carpeta, los directorios private, certs y newcerts. Después debemos ejecutar ejecutar los siguientes comandos

(19)

desde el directorio creado en primer lugar:

echo -n “01" > serial touch index.txt

openssl req -new -x509 \

-keyout private/cakey.pem \ -out cacert.pem -days 3650

el primero inicializa el contador, el segundo crea el archivo índice, el siguiente genera el par de claves, mientras que el último se encarga de crear el certificado auto firmado con una validez de diez años.

Ejercicio 11: Crea una CA en tu sistema.

Creación de una solicitud de certificado

Una solicitud de certificado es, básicamente, una clave pública asociada a una clave privada que contiene una identidad. Una solicitud de certificado, una vez firmada se convierte en un certificado.

Una vez que disponemos de una CA, podemos crear certificados de usuarios o servidores. Lo primero que habrá que hacer es generar la solicitud de certificado. Ejecutaremos el comando:

openssl req -new -newkey rsa:1024 \ -keyout cert.key -out newcert.req

En el archivo _cert.key estará la clave privada, con contraseña, y en el archivo newcert.req la clave pública.

Deberemos almacenar la clave privada en un lugar seguro y con los permisos adecuados.

También indicamos que las claves serán de 1024 bits. Este valor determina la fortaleza del par de claves. Hasta hace poco 256 bits eran suficientes pero actualmente se usan las de 1024.

Ejercicio 12: Crea la solicitud de certificado para tu servidor.

Firmar una solicitud de certificado

Es necesario firma la solicitud para disponer del certificado que nos permita firmar y encriptar la información. El comando que debemos ejecutar para firmar un certificado es:

openssl ca -in newcert.req -out newcert.pem -keyfile /ruta/a/cacert.key

-days 730

Ahora podremos usar nuestro certificado.

Ejercicio 13: Firma la solicitud creada en el ejercicio anterior.

(20)

Ubicación e identificación de certificados

Para que _openssl pueda reconocer los certificados en los cuales confía, bien de otras CAs o de servidores, es necesario identificarlos de manera unívoca. A tal fin, se calcula para cada certificado un hash que es utilizado para crear un enlace simbólico en el directorio _certs configurado en las opciones de _openssl, al archivo del certificado. El comando es:

openssl x509 -noout -hash -in newcert.pem

ln -s newcert.pem /ruta/a/certs/hash_obtenido.o Ejercicio 14: Calcula el hash del certificado de servidor y crea el enlace

correspondiente.

Certificados y Java

Las aplicaciones desarrolladas en Java usan unos contenedores para la gestión de certificados. Será necesario importar dentro de estos contenedores los certificados en los que confiemos o aquellos que usemos para firmar o cifrar.

Mediante la herramienta _keytool podremos realizar todas estas operaciones, incluyendo la creación de solicitudes.

Habrá un contenedor genérico que se usará para cualquier aplicación Java y que normalmente contiene los certificados de las CAs en las que confiamos.

Para importar un certificado de una CA a este contenedor genérico en el Java de Sun, usamos el comando:

keytool -import -alias CAdeConfianza -keypass clavedelcertificado -file /ruta/a/cacert.pem

-keystore $JAVA_HOME/jre/lib/security/cacerts -storepass clavedelcontenedor

En el Java de Sun, para importar un certificado, cuya CA está incluida en el contenedor genérico, en un contenedor específico el comando a usar será:

keytool -import -alias uncertificado -keypass contraseñadelaclave -file /ruta/a/uncertificado.pem -keystore /ruta/al/contendor/keystore -storepass clavedelcontendor

-trustcacerts

Ejercicio 15: Importar nuestro certificado en un contenedor.



Para un usuario, su contenedor por defecto está en su directorio HOME con el nombre .keystore.

(21)

Ejercicio 16: Obtener e importar el certificado de la FNMT en el contenedor genérico de Java.

(22)

Módulo 4 – Apache. Subversion

MÓDULO 4 – APACHE. SUBVERSION

Subversion es un software para gestión de versiones muy usado, cuyo cometido es controlar el proceso de desarrollo y mantenimiento de aplicaciones informáticas. En este curso veremos como se integra con el servidor HTTP Apache para proporcionar acceso mediante WEBDAV.

Apache

Apache es el servidor HTTP más usado en el mundo y quizá el proyecto libre de más éxito y repercusión. Debido a este éxito son muchos los aplicativos, tanto libres como privativos, que se apoyan en él. Subversion es un claro ejemplo.

Instalación

CentOS se basa en el paquete _rpm para la gestión de paquetes de software. La instalación de puede hacer en modo gráfico o en modo texto. Para la primera lanzaremos la aplicación “Yum Extender":

Fig. 4.1 – Herramienta Yum Extender

(23)

Ahora pasamos a la “Vista de grupos". Debajo de “Web Server"

marcamos _httpd y _{mod_ssl}:

Fig. 4.2 – Selección de paquetes

A continuación pulsamos “Procesar Cola" y después “Aceptar".

Si todo ha ido bien obtendremos un mensaje indicándolo.

Pulsamos “OK" y salimos de “Yum Extender".

Ejercicio 17: Incluir httpd en los niveles de ejecución 3 y 5.

Ejercicio 18: Iniciar el servicio httpd

Para comprobar si Apache está iniciado ejecutamos el siguiente comando:

Fig. 4.3 – Ejecución de httpd

Como comprobación definitiva de si Apache está bien instalado, accederemos a http://localhost con un navegador, por ejemplo _Firefox, desde el que deberíamos ver:

(24)

Fig. 4.4 – Apache funcionando.

Configuración

Normalmente los archivos de configuración de Apache se encuentran en un directorio _/etc/httpd o /etc/apache, dependiendo de la distribución de Linux. En CentOS lo encontramos en la primera opción.

Dentro de esta carpeta tenemos estas otras carpetas:

• _conf: contiene los archivos de configuración globales.

• _conf.d: contiene los archivos de configuración específicos para SSL, subversion, etc.

• _logs: contiene los archivos de log.

• _modules: aquí están los módulos que proporcionan funcionalidades extra a Apache.

El archivo /etc/httpd/conf/httpd.conf define las directivas globales de Apache tales como el nombre del servidor, el directorio de documentos, los puertos de escucha, etc. Algunas de las más habituales son éstas:

ServerRoot "/etc/httpd"

DocumentRoot "/var/www/html"

Listen 80

LoadModule auth_basic_module modules/mod_auth_basic.so .... (varias líneas LoadModule)

Include conf.d/*.conf

DirectoryIndex index.html index.html.var

(25)

DocumentRoot específica el directorio donde se almacenan los documentos web.

Listen indica el puerto por el que atenderá peticiones Apache.

Las directivas LoadModule le dicen a Apache qué módulos cargar, es decir, de que opciones dispone.

Una directiva <Directory ruta_en_sistema_ficheros>

engloba a un grupo de directivas que se aplicarán solamente al directorio del sistema de ficheros especificado y a sus subdirectorios. Normalmente indican cómo accederemos.

La directiva _Options configura posibles opciones de comportamiento del servidor y se puede especificar por directorios incluyéndola bajo una directiva <Directory >. Algunas opciones son:

• _All todas las opciones salvo _MultiViews. Es el valor predeterminado

• _ExecCGI Se permite la ejecución de scripts CGI.

• FollowSymLinks el servidor seguirá los enlaces simbólicos. Tener esta opción activa aumenta el rendimiento ya que el servidor no comprueba si un fichero o directorio es un enlace simbólico y es má rápido, pero en algunos casos puede presentar problemas de inseguridad.

• _Includes se permiten incluir sustituciones Server-side.

• IncludesNOEXEC se permiten incluir Server-side pero se deshabilitan las órdenes _#exec y _{#exec CGI}.

• _Indexes Si una URL solicita un directorio y no existe DirectoryIndex (p.e. index.html) en ese directorio, el servidor devolverá una lista del contenido del directorio.

• _MultiViews se permiten mostrar contenido negociado en función de diversos valores.

• SymLinksIfOwnerMatch Se sigue un enlace simbólico sólo si los propietarios del enlace y del destino coinciden.

Alias ruta_URL ruta_en_sistema_ficheros, directiva que permite acceder a documentos almacenados en el sistema de ficheros local fuera de la ubicación especificada por la directiva DocumentRoot. Necesita que se defina una directiva

<Directory >.específica para poder acceder a esos documentos. Es necesario cargar el módulo mod_alias para que Apache soporte esta opción.

La directiva User indica el usuario del sistema operativo bajo el que se ejecutará Apache, mientras que la directiva _Group hace lo propio con el grupo.

(26)

Un ejemplo de archivo de configuración sería:

ServerRoot "/etc/httpd"

Port 80

<IfDefine SSL>

Listen 80 Listen 443

</IfDefine>

User www Group www

ServerAdmin [email protected] ServerName www.misitio.com

DocumentRoot "/home/httpd/misitio"

<Directory "/home/httpd/misitio">

Options Indexes FollowSymLinks AllowOverride None

Order allow,deny Allow from all

</Directory>

Ejercicio 19: Modificar el archivo /etc/httpd/conf/httpd.conf para que incluya un alias al directorio /home/administrador/www, en el que habremos creado un archivo index.html simple.



Existen dos módulos, mod_info y mod_status, que proporcionan información acerca de la configuración de Apache desde el propio servidor mediante las URLs http://localhost/server-info e http://localhost/server-status, aunque suelen estar deshabilitados por seguridad. Para habilitarlos basta con descomentar y ajustar las líneas de las dos directivas <Location> existentes en el archivo httpd.conf.

Ejercicio 20: Habilitar los módulos mod_info y mod_status editando adecuadamente el archivo /etc/httpd/conf/httd.conf para que sólo se pueda acceder desde localhost.

SSL

Primeramente vamos a crear dos carpetas _ssl.cert y ssl.key bajo /etc/httpd dónde alojaremos el certificado y la clave primaria del servidor copiándolos o moviéndolos desde su ubicación actual, probablemente bajo /etc/pki.

Para habilitar SSL será necesario abrir el archivo /etc/httpd/conf.d/ssl.conf con un editor y modificar los parámetros que se indican con los valores propuestos (adaptando las rutas a nuestra instalación):

(27)

Listen 443

AddType application/xx509cacert .crt AddType application/xx509cacert .pem SSLCertificateFile ssl.cert/server.pem SSLCertificateKeyFile ssl.key/server.key

Este archivo contiene la definición de un servidor apache virtual, es decir, que el mismo proceso httpd responde a las peticiones para diferentes servidores Apache, los cuales usan puertos diferentes, 80 por defecto y 443 para SSL.

Las directivas anteriores especifican el puerto de respuesta, añaden los tipo mime de los archivos de certificados e indican la ubicación de la clave primaria y el certificado del servidor.

Para habilitar todos estos cambios debemos reiniciar el servicio Apache con el comando:

sudo service httpd restart

Comprobamos que se nos pide la contraseña de la clave privada del servidor y que tras introducirla el servicio arranca bien:

Fig 4.5 – Inicio de Apache.



Podemos quitar la contraseña a un archivo de claves, por lo que deberemos asegurarnos que sólo su propietario puede leerlo, mediante los comandos siguientes:

sudo openssl rsa -in server.key -out server.key sudo chmod 400 server.key

Ejercicio 21: Eliminar la contraseña del archivo de la clave del servidor y darle los permisos adecuados. Reiniciar Apache para comprobar que no pide la contraseña.

(28)

Subversion

Subversion nos permitirá acceder a nuestros repositorios mediante una URL del tipo:

http://servidor/raiz_subversion/repositorio1

Al igual que Apache, la aplicación subversion está ampliamente soportada por la mayoría de distribuciones, por lo que su instalación es bastante sencilla.

Instalación

Necesitaremos instalar el paquete subversion, que contiene la aplicación propiamente dicha, y el paquete mod_dav_svn, que permitirá acceder con WEBDAV al repositorio a través del servidor Apache.

Esta vez vamos a instalar desde la línea de comandos, aunque nada impediría hacerlo con la herramienta gráfica. La herramienta de instalación de software en modo texto de CentOS es _yum.

Ejecutamos el comando:

sudo yum install subversion mod_dav_svn

A continuación nos pedirá confirmación tras lo que nos informará del resultado de la instalación:

Fig. 4.5 – Instalación de subversion.

Configuración

Una vez instalado debemos configurarlo adecuadamente. Lo primero será crear una carpeta _subversion en la que almacenar los repositorios y la configuración, dentro de la que habrá además otras tres subcarpetas:

• _repos: contiene una carpeta por cada repositorio.

• _access: contiene los archivo de usuarios y permisos.

(29)

• _styles: contiene las hojas de estilo y la página inicial.



Es posible crear una estructura completa de carpetas con un sólo comando:

sudo mkdir -p carpeta0/{subcarpeta1,subcarpeta2}

Dentro de la carpeta _styles copiamos los estilos de los que dispone subversion:

sudo cp \

/usr/share/doc/subversion-1.4.2/tools/xslt/* \ /home/subversion/styles

Los estilos CSS nos permiten modificar el aspecto de nuestra página de subversion independientemente del contenido que muestren. En un estilo se definen los parámetros de presentación que se aplicarán.

Ejercicio 22: Crear los directorios necesarios subversion, subversion/repos, subversion/access y subversion/styles bajo la carpeta /home.

El siguiente paso es crear un repositorio. Para ello deberemos usar el comando de administración de subversion indicándole la carpeta dónde queremos ubicarlo:

sudo svnadmin create /home/subversion/repos/curso Este comando genera una serie de directorios y ficheros bajo curso en los que se organiza el repositorio.

• _conf: contiene los ficheros de configuración del repositorio.

• _dav: es usado por Apache y mod_dav_svn para proporcionar el acceso webdav.

• _db: Aquí residen todos los datos versionados. Es un entorno Berkeley DB o un entorno FSFS.

• _format: Un fichero que contiene un entero que dicta el número de versión del repositorio.

• _hooks: Contiene plantillas de hook scripts y hook scripts una vez que se hayan instalado (un hook script es un programa que se lanza cuando sucede un evento en el repositorio).

• _locks: para gestionar los bloqueos a los archivos del repositorio.

• _README.txt: Este archivo advierte sobre la posible corrupción de todo el repositorio si se hacen cambios sin usar _svnadmin.

También hay que dar los permisos necesarios para que Apache pueda acceder, así que definimos como propietario y grupo los de Apache:

sudo chown -R apache:apache /home/subversion/repos

(30)

Ejercicio 23: Crear el repositorio curso y dar los permisos correctos.

Ahora debemos configurar el servidor Apache convenientemente para que se pueda acceder al repositorio.

Lo primero que necesitaremos es poder identificar a los usuarios. Aquí se puede optar por usuarios del sistema, usuarios de un directorio LDAP o por usuarios definidos dentro del propio subversion. Esto último es lo que explicaremos.

Cambiamos al directorio _access y ejecutamos el siguiente comando, que creará el archivo _svnusers y el usuario _user1, para el que se pedirá también una contraseña.

sudo htpasswd -cm svnusers user1

Para seguir añadiendo usuarios bastará repetir el comando omitiendo lo opción _-c y cambiando el nombre de usuario.

Ejercicio 24: Crea el archivo y el primer usuario. Después añade otros dos usuarios más: user2 y user3.

Con el fin de asignar derechos a los usuarios sobre el repositorio crearemos el archivo _control en la misma carpeta access. Añadiremos las líneas necesarias, sin dejar espacios en blanco, según esta estructura:

[repo1:/]

user_a=rw user_b=r

Ejercicio 25: Da permisos de lectura-escritura a user2 sobre el repositorio curso, y de sólo lectura a user1 y user3.

El próximo paso será editar el siguiente archivo:

/etc/httpd/conf.d/subversion.conf, al que añadiremos las opciones para usar SSL y configurar subversion:

# Cargamos los módulos

LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so

# Defininos el puerto Listen 447

# Creamos un servidor virtual para el puerto 447

<VirtualHost *:447>

DocumentRoot "/home/subversion/styles"

ServerName curso

# Opciones de SSL SSLEngine on

SSLCipherSuite ALL:!ADH:!EXPORTS56:RC4+RSA:+HIGH:

(31)

+MEDIUM:+LOW:+SSLv2:+EXP

SSLCertificateFile ssl.cert/newcert.pem SSLCertificateKeyFile ssl.key/cert.key

# Opciones de subversion <Location /repos>

DAV svn

SVNListParentPath on

SVNParentPath /home/subversion/repos SVNIndexXSLT "/svnindex.xsl"

AuthzSVNAccessFile /home/subversion/access/control Satisfy all

Require validuser AuthType Basic

AuthName "Authorization Realm"

AuthUserFile /home/subversion/access/svnusers </Location>

</VirtualHost>

Ejercicio 26: Crear el archivo subversion.conf y comprobar que se puede acceder al repositorio.

Lo siguiente es alimentar nuestro repositorio. Para ello ejecutaremos el comando _svn para importar el directorio sobre el que llevaremos el control de versiones, que si suponemos que es _proyecto:

svn import /ruta/al/proyecto \

http://localhost/svn_dir/repos/proyecto \ -m "Carga inicial"

Ejercicio 27: Crear la siguiente estructura de directorios: /home/proyecto-curso/

{carpeta1,carpeta2}, e importarla al repositorio curso.

A partir de ahora podremos hacer checkouts de todo o parte del proyecto, añadir archivos, borrarlos, hacer checkins y las operaciones que correspondan.

¿Problemas?

Hay ocasiones en que nuestra pareja Apache-subversion no funciona según lo esperado. Muy probablemente se deba a una configuración inapropiada, a unos permisos incorrectos o a alguna otra causa similar.

La manera que tenemos de averiguar que es lo que provoca el problema es acudiendo a nuestros amigos: los archivos de log.

Dado que la gestión la hacemos a través de Apache, son los archivos de log de éste los que deberemos consultar.

En Linux, los archivos de log suelen hallarse en _/var/log, y los de Apache están en /var/log/httpd:

(32)

• _{access_log}: registra la actividad del servidor.

• _{error_log}: anota los errores que se producen.

• ssl_access_log: actividad específica para SSL.

• ssl_error_log: errores en la actividad SSL.

• ssl_request_log: las peticiones hechas con SSL.



/etc/httpd/logs es un enlace simbólico a /var/log/httpd.

Mediante la observación de estos archivos deberíamos ser capaces de solucionar el problema, contando siempre con la ayuda de Google, claro.

Ejercicio 28: Acceder a una página inexistente en nuestro servidor y observar el archivo error_log.

(33)

(34)

Módulo 5 - Tomcat

MÓDULO 5 - TOMCAT

Tomcat es un servidor web con soporte de servlets y JSPs. No es exactamente un servidor de aplicaciones, como JBoss o JOnAS. Incluye el compilador Jasper, que compila JSPs convirtiéndolas en servlets. El motor de servlets de Tomcat a menudo se presenta en combinación con el servidor web Apache.

Dado que Tomcat fue escrito en Java, funciona en cualquier sistema operativo que disponga de la máquina virtual Java.

Instalación

Como ya hemos dicho, Tomcat corre sobre Java por lo que lo primero que habría que hacer es instalar la máquina virtual Java, si es que no lo está.



Para comprobar si tenemos instalado Java basta con ejecutar el comando java -version

Para instalar la última versión de Java debemos descargarla desde http://java.sun.com/javase/downloads/index.jsp dónde elegiremos la edición Standard JDK para Linux de 32 bits (o de 64 bits si nuestro sistema lo admite).

Ejercicio 29: Descargar la última versión del JDK para linux de 32 bits desde la web de Sun, en el directorio /opt (unos 80 MB).

Para instalar Java desde _/opt procederemos así:

sudo -i

cd /usr/share

/bin/sh /opt/jdk-6u18-linux-i586.bin

alternatives --install /usr/bin/java java \ /usr/share/jdk1.6.0_18/bin/java 20000 alternatives --install /usr/bin/javac javac \

/usr/share/jdk1.6.0_18/bin/javac 20000 cat > /etc/profile.d/java.sh <<FIN

export JAVA_HOME="/usr/share/jdk1.6.0_18"

FIN exit

Ejercicio 30: Comprobar la versión de Java en uso tras la instalación anterior.

(35)

Módulo 5 - Tomcat



La versión 5 de Tomcat sólo requiere el JRE de Java, pero instalaremos el JDK que requerirá JBoss.

Para la instalación de Tomcat ejecutaremos el siguiente comando:

sudo yum install tomcat5 tomcat5-admin-webapps tomcat5-webapps



En CentOS es necesario modificar dos archivos para que funcione Tomcat, /etc/sysconfig/tomcat5 y /etc/tomcat5/tomcat5.conf. En ambos hay que definir la variable JAVA_HOME="/usr/share/jdk1.6.0_18".

Tras un tiempo moderadamente largo (es necesario descargar e instalar alrededor de 80MB), podremos iniciar Tomcat con:

sudo service tomcat5 start

Si nos conectamos a http://localhost:8080 desde un navegador podremos comprobar si Tomcat se ha instalado correctamente:

Fig. 5.1 – Tomcat funcionando.



La variable de entorno CATALINA_HOME define la ubicación de Tomcat en el sistema. En CentOS, esta variable se define dentro del archivo /etc/sysconfig/tomcat5 como "/usr/share/tomcat5".

Ejercicio 31: Pulsar sobre las opciones 'Tomcat Administration' y 'Tomcat Manager'.

El usuario es “tomcat" y la contraseña también. ¿Qué sucede?

Podemos usar Tomcat para gestionar Tomcat mediante las dos aplicaciones mencionadas en el ejercicio, pero recién instalado no hay autorización por motivos de seguridad. Para concederla es necesario asignar al usuario “tomcat" los roles “admin" y

“manager".



Los usuarios de Tomcat se definen en un archivo de configuración llamado

$CATALINA_HOME/conf/tomcat-users.xml

(36)

Módulo 5 - Tomcat

Ejercicio 32: Asignar los roles “admin" y “manager" al usuario “tomcat".

Tomcat tiene una serie de carpetas bajo $CATALINA_HOME que vamos a enumerar a continuación:

• _bin: contiene los scripts de inicio y parada.

• _common: Es donde se guardan los paquetes y clases comunes a todas las aplicaciones

• _conf: aquí encontramos los archivos de configuración. El más importante es server.xml

• _logs: Ficheros de trazas y depuración.

• _server: Clases y paquetes de Tomcat

• _shared: Similar a common.

• _temp: Ficheros temporales

• _webapps: Directorios y paquetes de aplicaciones.

• _work: Directorios de trabajo en tiempo de ejecución Ejercicio 33: Cambiar la contraseña al usuario “tomcat".

Como se decía, _server.xml es el archivo de configuración general de Tomcat. Este archivo puede contener entradas de estas categorías:

• Elementos de alto nivel - <Server> es elemento raíz de todo el archivo, mientras que <Service> representa a un grupo de <Connector> asociados a un <Engine>

• Conectores - Representan la interfaz entre clientes externos que hacen peticiones a un <Service> particular (y del que reciben respuestas).

• Contenedores - Representan componentes cuya función es procesar las peticiones y crear las correspondientes respuestas. Un <Engine> gestiona todas las peticiones a un <Service>, un <Host> gestiona todas las peticiones a un host virtual concreto y un <Context> gestiona todas las peticiones a una aplicación web específica.

• Componentes anidados - Son elementos que pueden ser anidados dentro de un contenedor. Algunos elementos pueden incluirse en cualquier contenedor, mientras que otros sólo se pueden incluir en un <Context>.

Un ejemplo de _server.xml:

<Server port="8005" shutdown="YIKES">

<GlobalNamingResources>

<Resource name="UserDatabase" auth="Container"

type="org.apache.catalina.UserDatabase"

description="B.D. De usuarios"

factory="org.apache.catalina.users.MemoryUserData

(37)

Módulo 5 - Tomcat

baseFactory"

pathname="conf/tomcatusers.xml" />

</GlobalNamingResources>

<Service name="Catalina">

<! Define un conector noSSL HTTP/1.1 por el puerto 8088 >

<Connector port="8088" maxHttpHeaderSize="8192"

maxThreads="50" minSpareThreads="5"

maxSpareThreads="15" enableLookups="false"

redirectPort="8443" acceptCount="50"

connectionTimeout="40000"

disableUploadTimeout="false"

compression="on" compressionMinSize="2048"

noCompressionUserAgents="gozilla, traviata"

compressableMimeType="text/html,text/xml" />

<! Define un conector SSL HTTP/1.1 en puerto 8443 >

<! <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" /> >

<! Define un conector AJP 1.3 en el puerto 8009 >

<Connector port="8009" enableLookups="false"

redirectPort="8443" protocol="AJP/1.3" />

<Engine name="Catalina" defaultHost="localhost"

jvmRoute="jvm1">

<Realm

className="org.apache.catalina.realm.UserDatabaseRealm"

resourceName="UserDatabase"/>

<Host name="localhost" appBase="webapps"

unpackWARs="true" autoDeploy="true"

xmlValidation="false"

xmlNamespaceAware="false">

<Valve

className="org.apache.catalina.authenticator.S ingleSignOn" />

</Host>

</Engine>

</Service>

</Server>

En http://tomcat.apache.org/tomcat-5.5-doc/config/index.html

(38)

Módulo 5 - Tomcat

SSL

Hasta ahora hemos accedido usando HTTP, lo que quiere decir que toda la información es transmitida en claro por la red, o lo que es lo mismo, accesible a cualquiera con un sniffer.

Al igual que Apache, Tomcat soporta el uso de SSL para cifrar la información y autentificar clientes. La manera de configurar esta opción es editar el archivo de configuración _server.xml. Hay que habilitar un conector para configurar SSL, de modoe que escuche por el puerto 8443 el protocolo HTTPS. Además deberemos indicar los parámetros específicos de SSL, como el certificado, clave privada, etc.

Dado que Tomcat corre sobre Java, deberemos definir un contenedor (o keystore) en el que almacenar estos datos mediante la herramienta _keytool.

El conector será definido de este modo:

Fig. 5.2 – Conector SSL para Tomcat.

Ejercicio 34: Editar server.xml para crear el conector (ya hay uno, aunque comentado).

En la misma carpeta dónde se halla _server.xml crearemos el keystore mediante:

openssl pkcs12 -export -in \ /ruta/al/servercert.pem \ -inkey /ruta/a/la/server.key \ -out /ruta/al/keystore -name tomcat



Es necesario que el archivo de clave tenga contraseña, así que previamente crearemos otro archivo de clave privada con contraseña con el comando:

sudo openssl rsa -in /etc/httpd/ssl.key/server.key -out /etc/httpd/ssl.key/serverpass.key -des3

(39)

Módulo 5 - Tomcat

Ejercicio 35: Crear el keystore a partir de un nuevo archivo de clave privada con contraseña.

Ahora debemos reiniciar Tomcat para que tome los cambios.

Ejercicio 36: Comprobar el acceso a Tomcat por SSL.

Gestión de aplicaciones

Mediante la aplicación “Tomcat Manager" es posible gestionar parar, recargar, replegar e incluso desplegar e instalar las aplicaciones:

Fig. 5.3 – Gestor de aplicaciones de Tomcat.



El modo de publicar una aplicación es empaquetarla en un archivo .war y dejarla en CATALINA_HOME/webapps. Tomcat desplegará la aplicación automáticamente.

Ejercicio 37: Experimentar con las aplicaciones de ejemplo.

¿Problemas?

En los archivos de log encontraremos la información para investigar el origen de los problemas. Tomcat graba sus logs en el directorio /var/log/tomcat5, dentro del archivo catalina.out.

(40)

Módulo 5 - Tomcat

Fig. 5.4 – Log catalina.out de Tomcat.

(41)

(42)

Módulo 6 - JBoss

MÓDULO 6 - JBOSS

JBoss es un servidor de aplicaciones preparado para la producción empresarial y certificado J2EE 1.4, de código abierto e implementado totalmente en Java. Al estar basado en Java, JBoss puede ser utilizado en cualquier sistema operativo que lo soporte.

Un "Java Application Server" se encuentra compuesto por dos partes: un "Servlet Engine" y un "EJB Engine", dentro del

"Servlet Engine" se ejecutan exclusivamente las clásicas aplicaciones de Servidor (JSP's ("Java Server Pages") y Servlets) , mientras el "EJB Engine(Container)" es reservado para aplicaciones desarrolladas alrededor de EJB's

"Enterprise Java Bean's" .

JBoss usa como “Servlet Engine" un Tomcat adaptado, aunque es posible usar otro.

Instalación

Aunque ya va por la versión 6, nosotros vamos a ver la versión estable JBoss 4.0.5GA. Esta versión necesita el JDK 1.5 de Sun o superior. Debemos asegurarnos de que tenemos la versión adecuada instalada.

Java

En el módulo anterior nos descargamos e instalamos la versión JDK 1.6, que podemos usar.

Sin embargo, hay que asegurarse de que el entorno Java necesario está definido. Esto lo logramos creando un archivo llamado /etc/profile.d/java.sh con este contenido:

JAVA_HOME="/usr/share/jdk1.6.0_18"

PATH=$PATH:$JAVA_HOME/bin CLASSPATH=$JAVA_HOME/lib

LD_LIBRARY_PATH=$JAVA_HOME/jre/lib/i386

#JAVA_OPTS="Djava.awt.headless=true"

export JAVA_HOME PATH CLASSPATH LD_LIBRARY_PATH

#export JAVA_OPTS

JBoss

Nos podemos descargar la versión 4.0.5 de JBoss desde el enlace:

http://downloads.sourceforge.net/project/jboss/JBoss/JBoss- 4.0.5.GA/jboss-4.0.5.GA.zip?use_mirror=sunet

por ejemplo con el comando _wget:

(43)

Módulo 6 - JBoss

cd /opt sudo wget

http://downloads.sourceforge.net/project/jboss/JBoss/JBos s4.0.5.GA/jboss4.0.5.GA.zip?use_mirror=sunet

A continuación cambiamos a _/usr/share y ejecutamos el comando:

sudo unzip /opt/jboss4.0.5.GA.zip

Creamos el enlace simbólico:

sudo ln s /usr/share/jboss4.0.5.GA /usr/share/jboss

El siguiente paso que daremos será copiar el archivo con el script de inicio/parada a /etc/init.d/jboss

sudo cp jboss/bin/jboss_init_redhat.sh /etc/init.d/jboss

Lo editamos y cambiamos estas dos líneas para que reflejen nuestra configuración:

JBOSS_HOME=${JBOSS_HOME:"/usr/share/jboss"}

...

JAVAPTH=${JAVAPTH:"/usr/share/jdk1.6.0_18/bin"}

Creamos el usuario jboss y lo asignamos a la carpeta de JBoss de esta forma:

sudo adduser jboss

sudo chown R jboss:jboss /usr/share/jboss*

Ahora crearemos un archivo que nos inicialice las variables de entorno que necesita JBoss, lo cual conseguimos editando el archivo /etc/profile.d/jboss.sh con este contenido:

JBOSS_HOME=/usr/share/jboss PATH=$PATH:$JBOSS_HOME/bin export JBOSS_HOME PATH

Para iniciar JBoss hay que ejecutar:

service jboss start

Ya tenemos JBoss accesible en http://localhost:8080.



Por defecto, tanto JBoss como Tomcat usan el mismo puerto, 8080, por lo que no podremos tener ambos en ejecución si no cambiamos es puerto en uno de ellos.

Ejercicio 38: Realizar todos estos pasos y comprobar que se está ejecutando JBoss.

(44)

Módulo 6 - JBoss

Estructura de JBoss

La estructura de la carpeta bajo la que se instala JBoss la tenemos en esta figura:

Fig. 6.1 – Estructura de JBoss.

En el primer nivel nos encontramos con las carpetas:

• _bin: Este directorio contiene los ejecutables utilizados por JBoss para arrancar y parar en diferentes plataformas.

• _client: Contiene los diversos archivos _.jar que serán utilizados por los distintos clientes de los EJB's utilizados en JBoss.

• _docs: Contiene documentación acerca de JBoss.

• _lib: Este directorio contiene los archivos _.jar empleados por JBoss requeridos en cualquier modalidad.

• _server: contiene la distintas carpetas de configuración para ejecutar JBoss en diferentes modalidades. Por defecto existen estas tres:

- _all: Contiene todos los elementos que tiene JBoss.

- _default: Contiene los elementos más comunes.

- _minimal: Contiene los mínimos elementos para que arranque.



El script de inicio ($JBOSS_HOME/bin/run.sh) arranca la modalidad default.

Para que arranque otra será necesario editarlo adecuadamente.