Tag: debian

Como implementar Basic Auth en Tomcat7

Hasta ahora no me habia surgido la necesidad de tener una ruta en tomcat que necesitase un acceso con una validacion por parte del servidor de aplicaciones. Normalmente esta validacion se hace desde apache con el modulo auth_basic que permite pedir un usuario y una contraseña para acceder a una ruta concreta o incluso a un fichero concreto.

Si tienes el modulo JK para conectar apache y tomcat, este problema lo tienes resuelto. porque puedes seguir haciendo la autenticacion a traves de Apache. Pero que pasa si no quieres/no te apetece, o simplemente no sabes implementar mod_jk o no quieres cargar al servidor con un apache para servidor tus aplicaciones java por el puerto 80/443?

Pues puedes hacerlo de la siguiente manera:

1º Busca el fichero tomcat-users.xml que habitualmente esta en la ruta /var/lib/tomcat7/conf/ en una instalacion estandard por paqueteria de Debian.

vi  /var/lib/tomcat7/conf/tomcat-users.xml

2º Descomenta la seccion inferior dentro de la etiqueta
Edita el rol, y en el rolename pon el nombre que se te ocurra. Por ejemplo en mi caso

<tomcat-users>
<role rolename="application"/>
<user username="nombre_de_usuario" password="clave_de_usuario" roles="application"/>
</tomcat-users>

Evidentemente los datos vana a gusto del consumidor (nombre_de_usuario, clave_de_usuario, application)

3º Ahora nos queda el ultimo paso, que es editar el WEB-INF/web.xml dentro de la aplicacion a proteger y añadir al final, antes de la etiqueta

        <security-constraint>
                <web-resource-collection>
                        <web-resource-name>Wildcard means whole app requires authentication</web-resource-name>
                        <url-pattern>/*</url-pattern>
                        <http-method>GET</http-method>
                        <http-method>POST</http-method>
                </web-resource-collection>
                <auth-constraint>
                        <role-name>application</role-name>
                </auth-constraint>

                <user-data-constraint>
                        <!-- transport-guarantee can be CONFIDENTIAL, INTEGRAL, or NONE -->
                        <transport-guarantee>NONE</transport-guarantee>
                </user-data-constraint>
        </security-constraint>

        <login-config>
                <auth-method>BASIC</auth-method>
        </login-config>

En nuestro ejemplo se protege todo el context de la aplicacion, con lo que para acceder a ella habra que introducir las credenciales que aparecen en el tomcat-users.xml

Por ultimo solo nos queda rebotar el servidor de aplicaciones tomcat

/etc/init.d/tomcat7 restart
Via: AVAJAVA

Instalación de Cluster de Tomcat7 con multiples instancias y FarmDeployer.

La instalación de una instancia de Tomcat sobre Debian en cualquier version es casi lo mas sencillo del mundo. Simplemente apt-get install tomcat7 (con la instalación previa del JDK correspondiente) y el sistema lo hace todo solo. Incluso lo arranca. Listo para colgar tus aplicaciones java, en la carpeta webapps por defecto.

Si quieres una cosa mas compleja pero que te da mas control sobre la instalación, nos pasamos a una instalación desde los binarios que provee desde la web oficial, la Fundación Apache.

El siguiente grado de complejidad seria montar distintas instancias de tomcat. Esta parte es interesante si tienes mas de una aplicación corriendo en el servidor debido a que te permitira varias cosas. Hacer deploy y undeploy de aplicaciones en cómodos compartimentos y sin afectar al servicio que dan el resto de aplicaciones. En caso de un rebote, el tiempo de parada sera unicamente el de la instancia que estes rebotando. Si una aplicación da una excepción y se para, o bien se queda sin memoria no afectara al funcionamiento del resto. Ademas se puede configurar el uso de memoria de cada instancia haciendo un estudio de carga de cada aplicación por separado en cada instancia. Con una sola instancia es mucho mas complicado optimizar el uso de memoria, ya que cada una de las aplicaciones hace uso de los recursos del servidor según la programación de dicha aplicación o los conocimientos del desarrollador.

La penultima vuelta de tuerca esta en construir un cluster. Un cluster permite tener N maquinas dando servicio al mismo tiempo, y con sesiones replicadas. Así en caso de que una maquina se caiga, la otra maquina que forma parte del cluster mantiene el servicio funcionando.

En nuestro ejemplo de configuración, debido a que tenemos 4 instancias, debemos de poner en funcionamiento 4 clusters. Cada cluster une una instancia en cada uno de los servidores. Asi, configuraremos nosotros vamos a configurar 4 instancias en 2 servidores físicos. En caso de añadir mas servidores cada cluster tendría tantos nodos como servidores físicos tengamos. Y por otra parte tendremos tantos clusters como instancias queramos desplegar. El ejemplo de arquitectura se visualiza mejor en la siguiente imagen.

Arquitectura de cluster

Arquitectura de cluster

El ultimo paso que queremos dar sirve para solucionar el problema del despliegue automatico. Cuando tenemos un servidor y una instancia, desplegar una aplicación es sencillo, casi trivial. Consiste en tener un fichero war, colocarlo en la carpeta webapps, verificar que el autodeploy en la configuración de tomcat esta en true, y dejar que el servidor haga su trabajo. En una configuración mas compleja con 4 instancias en 2 servidores implicaria desplegar 8 ficheros war, lo cual ya es una tarea mas compleja. El final, el despliegue de aplicaciones obliga a “subir” tantos ficheros war como el numero de instancias multiplicado por el numero de servidores del cluster. Por ello existe una característica dentro de la configuración del cluster de tomcat que se llama FarmDeployer. Esta característica permite desplegar un war en TODOS los servidores que forman parte de un cluster. Esto automatiza y simplifica mucho las tareas de despliegue de nuevas aplicaciones, ya que el FarmDeployer detecta el hash del fichero war subido a la carpeta definida en el modulo y en caso de detectar un war distinto lo despliega en todos los nodos.

A partir de aqui comenzamos con la configuración. El punto de partida es un servidor Debian con las siguientes características:
Dell R310 1 CPU Intel Xeon X3430 64 Bits, 32 GB de RAM, 2x300GB HD SAS 15K en RAID1
Debian 7.5 Wheezy
Securización a gusto de cada uno, pero en mi caso 5 cosas básicas:
Cambio de puerto ssh por defecto.
Acceso a root directo anulado.
Acceso interactivo con contraseña anulado.
Acceso obligatorio con par de claves RSA. Si alguien tiene una version de ssh 6.4 podrá usar la autenticación de certificado y verificación en 2 pasos con authenticator que multiplica la seguridad exponencialmente.
Ademas del correspondiente filtrado de ssh con el firewall perimetral y bloqueo por ip origen.

La siguiente configuración se realiza en los 2 servidores de manera identica.

Creamos un usuario para la instalación de tomcat

groupadd tomcat7
useradd -s /sbin/nologin -g tomcat7 -d /usr/local/tomcat7 tomcat7
passwd tomcat7

Ponemos la clave que queramos (no tiene influencia en el resultado)

Procedemos a instalar previamente la maquina virtual de java.

Con permisos de root

su -
echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu precise main" | tee /etc/apt/sources.list.d/webupd8team-java.list
echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu precise main" | tee -a /etc/apt/sources.list.d/webupd8team-java.list
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys EEA14886
apt-get update
apt-get install oracle-java7-installer

Esto instala la version:

java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)

Procedemos a descargar la ultima version de tomcat7 (7.0.56):

wget http://ftp.cixug.es/apache/tomcat/tomcat-7/v7.0.56/bin/apache-tomcat-7.0.56.tar.gz

descomprimimos en la carpeta que nos parezca oportuno (nuestra home esta correcto):

tar -xvzf apache-tomcat-7.0.56.tar.gz

Para proceder a montar las instancias de tomcat hay que tener en cuenta que ha de hacerse la instalación de cada instancia en 2 partes: una parte común a cada instancia que va en una ruta igual para todas las instancias, y una segunda parte que se monta en una ruta diferenciada para cada instancia.

En nuestro caso:

mv /home/usuario/apache-tomcat-7.0.56 /usr/local/
ln -s /usr/local/apache-tomcat-7.0.56 /usr/local/tomcat7

Ajustamos los permisos:

chown -R tomcat7:tomcat7 /usr/local/tomcat7

Ficheros comunes: CATALINA_HOME

/usr/local/tomcat7/bin
/usr/local/tomcat7/lib
/usr/local/tomcat7/endorsed

Ficheros por cada instancia: CATALINA_BASE:

/var/www/instancia-xx/conf
/var/www/instancia-xx/logs
/var/www/instancia-xx/temp
/var/www/instancia-xx/watch
/var/www/instancia-xx/webapps
/var/www/instancia-xx/work

Donde instancia-xx es la ruta que debes de cambiar para cada instancia. Para hacerlo rapido copiamos del CATALINA_HOME las rutas que deben estar diferenciadas:

Creamos las carpetas de cada instancia:

mkdir -p /var/www/instancia-01
mkdir -p /var/www/instancia-02
mkdir -p /var/www/instancia-03
mkdir -p /var/www/instancia-04

Asignamos permisos:

chown -R tomcat7:tomcat7 /var/www/instancia-0*
chmod -R 755 /var/www/instancia-0*/webapps/

Desde CATALINA_HOME copiamos las carpetas correspondientes a cada CATALINA_BASE, en la ruta de cada instancia.

cp -p -r /usr/local/tomcat7/conf/ /var/www/instancia-01/
cp -p -r /usr/local/tomcat7/logs/ /var/www/instancia-01/
cp -p -r /usr/local/tomcat7/temp/ /var/www/instancia-01/
cp -p -r /usr/local/tomcat7/watch/ /var/www/instancia-01/
cp -p -r /usr/local/tomcat7/webapps/ /var/www/instancia-01/
cp -p -r /usr/local/tomcat7/work/ /var/www/instancia-01/

cp -p -r /usr/local/tomcat7/conf/ /var/www/instancia-02/
cp -p -r /usr/local/tomcat7/logs/ /var/www/instancia-02/
cp -p -r /usr/local/tomcat7/temp/ /var/www/instancia-02/
cp -p -r /usr/local/tomcat7/watch/ /var/www/instancia-02/
cp -p -r /usr/local/tomcat7/webapps/ /var/www/instancia-02/
cp -p -r /usr/local/tomcat7/work/ /var/www/instancia-02/

cp -p -r /usr/local/tomcat7/conf/ /var/www/instancia-03/
cp -p -r /usr/local/tomcat7/logs/ /var/www/instancia-03/
cp -p -r /usr/local/tomcat7/temp/ /var/www/instancia-03/
cp -p -r /usr/local/tomcat7/watch/ /var/www/instancia-03/
cp -p -r /usr/local/tomcat7/webapps/ /var/www/instancia-03/
cp -p -r /usr/local/tomcat7/work/ /var/www/instancia-03/

cp -p -r /usr/local/tomcat7/conf/ /var/www/instancia-04/
cp -p -r /usr/local/tomcat7/logs/ /var/www/instancia-04/
cp -p -r /usr/local/tomcat7/temp/ /var/www/instancia-04/
cp -p -r /usr/local/tomcat7/watch/ /var/www/instancia-04/
cp -p -r /usr/local/tomcat7/webapps/ /var/www/instancia-04/
cp -p -r /usr/local/tomcat7/work/ /var/www/instancia-04/

Para poder levantar las instancias tenemos que cambiar varios parámetros en el fichero server.xml de cada instancia.

instancia-01

<Server port="8005" shutdown="SHUTDOWN">
Connector port="8080" protocol="HTTP/1.1"
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

instancia-02

<Server port="8105" shutdown="SHUTDOWN">
Connector port="8180" protocol="HTTP/1.1"
<Connector port="8109" protocol="AJP/1.3" redirectPort="8443" />

instancia-03

<Server port="8205" shutdown="SHUTDOWN">
Connector port="8280" protocol="HTTP/1.1"
<Connector port="8209" protocol="AJP/1.3" redirectPort="8443" />

instancia-04

<Server port="8305" shutdown="SHUTDOWN">
Connector port="8380" protocol="HTTP/1.1"
<Connector port="8309" protocol="AJP/1.3" redirectPort="8443" />

Esto impide que haya conflictos a la hora de levantar las instancias.

El siguiente paso es configurar un script de arranque de las instancias.

vi /etc/init.d/tomcat7-01

#!/bin/sh
### BEGIN INIT INFO
# Provides: Tomcat
# Required-Start: $network
# Required-Stop: $network
# Default-Start: 2 3 5
# Description: Java Servlet and JSP Engine
### END INIT INFO

JAVA_HOME=/usr/lib/jvm/java-7-oracle/
JAVA_OPTS="-Xmx800m -Xms800m"
CATALINA_HOME=/usr/local/tomcat7
CATALINA_BASE=/var/www/instancia-01

case "$1" in
'start')
$CATALINA_HOME/bin/catalina.sh start
;;
'stop')
$CATALINA_HOME/bin/catalina.sh stop
;;
*)
echo "Usage: $0 { start | stop }"
;;
esac
exit 0

Creamos los otros 3 scripts de arranque y cambiamos el parámetro CATALINA_BASE para cada instancia.
En el caso del JAVA_OPTS, podemos configurar la memoria según la configuración de memoria física instalada en el servidor y los requerimientos de las aplicaciones que queramos desplegar.

Procedemos a darle permisos de ejecución a los scripts:

chmod 755 /etc/init.d/tomcat7-0*

Ya podemos arrancar con los servicios invocando el script con:

/etc/init.d/tomcat7-01 start

Añadimos el script al arranque del servidor:

chkconfig --add tomcat7
chkconfig tomcat7 on

Procedemos a la configuración del cluster. En este caso tenemos que añadir las configuraciones de cluster a cada uno de los 8 ficheros server.xml (1 por cada instancia y en 2 servidores, total 8).

Como ejemplo añado la configuración de 1 instancia en los 2 servidores y el resto de los ficheros solo es una cuestión de usar puertos distintos y cambiar las direcciones ip a las que hay que conectar cada instancia:

Instancia 01, Servidor 01

className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="8">

Instancia 01, Servidor 02

className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="8">

Para que cada instancia solo se vea con su par en la dirección del modulo Membership tiene que ser distinta en cada par de instancias que conforman el cluster.

En nuestra configuración la instancia-01 se comunica con su par por 228.0.0.4, la instancia-02 se comunica con su par por 228.0.0.5, la instancia-03 se comunica con su par por 228.0.0.6, y la instancia-04 se comunica con su par por 228.0.0.7

Esto debe de respetarse en las configuraciones de cada cluster ya que sino el funcionamiento sera erratico y fallara el FarmDeployer.

Este ultimo modulo esta definido en las ultimas 6 lineas de cada configuración del cluster, y permite que poniendo un war dentro de la carpeta definida como watchDir, el war en cuestión se despliegue en todos los servidores del cluster.

Esto solo debe de hacerse en el servidor que consideremos como master de la configuración (osea el numero 1) para tener un unico punto de publicación. Es por eso que en el servidor 2 ponemos el parametro watchEnabled=false.

El ultimo tema que debemos de tratar es el mantenimiento de sesión. En el cluster que hemos montado, el primer modulo es el que indica como se comporta el cluster en cuanto al manejo de sesión.

className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>

Los 2 nodos están configurados como DeltaManager, que es como decir que los 2 funcionan como Master en el manejo de sesiones. Los 2 servidores mantienen en memoria las sesiones de su servidor gemelo, para que en caso de que haya caída de un servidor, no se vea afectado el servicio. Esta configuración es la ideal para un balanceo de carga, ya que el balanceador reparte la carga entre todas las maquinas del cluster y si una de ellas cae, la saca del grupo y sigue repartiendo la carga al resto de servidores.

Para que los tomcats no se hagan un lio con las sesiones, debemos de configurar en cada instancia el JVMRoute de manera diferente.

name="Catalina" defaultHost="localhost" jvmRoute="servidor01-instancia-01">

lo que hace el servidor es añadir este jvmRoute como parte del id de sesión para poder almacenarlos de manera distintiva.

Lo unico que nos queda es ver en el log que los miembros del cluster se añaden y se eliminan con normalidad:

may 24, 2014 10:25:06 AM org.apache.catalina.ha.tcp.SimpleTcpCluster memberAdded
Información: Replication member added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{192, 168, 0, 210}:4100,{192, 168, 0, 210},4100, alive=36148, securePort=-1, UDP Port=-1, id={54 -103 16 -90 92 20 67 -28 -101 -88 19 22 109 -78 44 77 }, payload={}, command={}, domain={}, ]

El cluster ya esta completamente configurado a nivel de tomcat.

El siguiente paso es configurar Los apaches para poder servidor las aplicaciones por el puerto 80 para verlas desde un navegador y con una URL facilmente recordable/escribible.

Para ello debemos de instalar en los servidores apache el paquete mod_jk

apt-get install libapache2-mod-jk

Solo tenemos que configurarlo de la siguiente manera:

 vi /etc/apache2/mods-enabled/jk.conf
# Where to find workers.properties
JkWorkersFile /etc/libapache2-mod-jk/workers.properties

# Where to put jk logs
JkLogFile /var/log/apache2/mod_jk.log

# Set the jk log level [debug/error/info]
JkLogLevel info

JkShmFile /var/log/apache2/jk-runtime-status

# Select the log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

# JkOptions indicate to send SSL KEY SIZE
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories

JkMount /contexto_de_la_aplicacion_01/ ajp13_worker_01
JkMount /contexto_de_la_aplicacion_02/ ajp13_worker_02
JkMount /contexto_de_la_aplicacion_03/ ajp13_worker_03
JkMount /contexto_de_la_aplicacion_04/ ajp13_worker_04

JkMount /contexto_de_la_aplicacion-01/*.do ajp13_worker_01
JkMount /contexto_de_la_aplicacion-02/*.do ajp13_worker_02
JkMount /contexto_de_la_aplicacion-03/*.do ajp13_worker_03
JkMount /contexto_de_la_aplicacion-04/*.do ajp13_worker_04

# vi /etc/libapache2-mod-jk/workers.properties

worker.list=loadbalancer,stat1,ajp13_worker_01,ajp13_worker_02,ajp13_worker_03,ajp13_worker_04

worker.ajp13_worker_01.port=8009
worker.ajp13_worker_01.host=192.168.0.209
worker.ajp13_worker_01.type=ajp13
worker.ajp13_worker_01.lbfactor=1

worker.ajp13_worker_02.port=8109
worker.ajp13_worker_02.host=192.168.0.209
worker.ajp13_worker_02.type=ajp13
worker.ajp13_worker_02.lbfactor=1

worker.ajp13_worker_03.port=8209
worker.ajp13_worker_03.host=192.168.0.209
worker.ajp13_worker_03.type=ajp13
worker.ajp13_worker_03.lbfactor=1

worker.ajp13_worker_04.port=8309
worker.ajp13_worker_04.host=192.168.0.209
worker.ajp13_worker_04.type=ajp13
worker.ajp13_worker_04.lbfactor=1

En esta configuración cada worker controla las peticiones que llegan al apache y las deriva a la instancia que corresponde.
En nuestro caso la ip 192.168.0.209 corresponde a la ip del grupo de balanceo interno sobre el que tenemos el tomcat.

Por último en la configuración de los vhost de apache tenemos que configurar el punto de montaje de mod_jk, para que envie las peticiones a cada worker según la aplicación que este montada en cada instancia. Añadimos la configuración a nuestro virtual host preconfigurado.

vi /etc/apache2/sites-enabled/vhost-balanceo-tomcat.conf

JkMount /contexto_de_la_aplicacion-01/* ajp13_worker_01

Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

JkMount /contexto_de_la_aplicacion-02/* ajp13_worker_02

Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

JkMount /contexto_de_la_aplicacion-03/* ajp13_worker_03

Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

JkMount /contexto_de_la_aplicacion-04/* ajp13_worker_04

Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
Mas Información:Instalación de la maquina virtual de Java

Ubuntu: Un cambio razonable

Hace una temporada que no hago ningun comentario tecnico, y este me parece un buen momento para desempolvar esta categoria y escribir mi parecer sobre un sistema operativo que ultimamente esta mas de moda que el resto.

Hace ya mas de un mes que uso Ubuntu en version Dapper Drake, osease 6.06. Que coño es esto? pues es un sistema operativo GNU/Linux, o distribucion de linux basada en Debian, y que tiene una version para escritorio, osea, una version para usar con aplicaciones de andar por casa, y en contraposicion a la version servidor que esta orientada a ofrecer datos a otros ordenadores conectados mediante una red.

Despues de este toston, que la mitad de los lectores habituales no entenderan, escribo esto  mas que nada para hacer unas valoraciones sobre si actualmente es posible deshacerse de M$ y su XP o estamos condenados a usarlos por los siglos de los siglos.

Hace mas o menos un mes, como decia arriba que me he cambiado a Ubuntu. En la primera semana he estado conviviendo con los dos sistemas operativos para no perder herramientas, e irme desenganchando poco a poco de las garras de XP. Una semana despues me he deshecho definitivamente de XP, para intentar volar solo.
 Y el resultado de momento es muy positivo. No podria valorarlo de 10, pero casi casi. Como resumen podria decir lo siguiente:

Hay herramientas para todo lo que uso habitualmente: p2p, ofimatica, grabadora, sonido, video…

La dificultad radica en conocer aplicaciones para Linux.

El comando apt es dios xD. Con esta aplicacion heredada de debian se pueden instalar aplicaciones asi como aplicar actualizaciones de manera sencilla y sin preocuparte por las dependencias.

La capacidad grafica de Ubuntu es muy grande, aunque los usurios de Ubuntu con escritorio KDE (KUbuntu) diran que lo suyo es mejor.

A nivel de conectividad todo funciona mucho mejor ya que es un sistema operatico orientado a redes y comunicaciones. Por contra, XP es un sistema operativo mas orientado a multimedia y completamente de escritorio.

Puedes seguir usando todos tus ficheros pdf, word, excell, access etc, ya que OpenOffice puede abrir y generar estos ficheros sin problemas.

Al ser un sistema de codigo abierto cada aplicacion es infinitamente mas potente y cada usuario con capacidad de desarrollo de aplicaciones añade sus funcionalidades y las ofrece a la comunidad, por lo que hay plugins para aplicaciones que hacen cosas realment utiles sin que muevas un dedo.

Otra ventaja es que tiende a colgarse menos que un windows y que no tienes que reiniciar la maquina cada vez que aplicas un parche de seguridad al equipo (salvo que actualices el Kernel).

Y lo mejor de todo… es que es gratuito, te puedes bajar el DVD de instalacion de la web de ubuntu, y se instala en 30 minutos sin que tengas problemas con el harware de tu equipo (cosa que en otras distribuciones anteriores era un autentico quebradero de cabeza).

Pues como fin de fiesta simplemente deciros que el cambio no es tan traumatico como parece y que os animeis a cambiaros y dejar de pagar (los que tengan licencia) a M$ una pasta gansa por por usar un sistema operativo a todas luces mejorable.


  • Social


    Follow Me on Pinterest
  • Suscribete al Blog por Email

    Escribe tu direccion de Email para suscribirte a este Blog y recibir notificaciones de los nuevos posteos por Correo Electrónico.

  • A lo largo del Tiempo

  • -->