trabajoprotos-120625135955-phpapp01

UNIVERSIDAD DE EL SALVADOR

FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE

CCAATTEEDDRRAA::

PPRROOTTOOCCOOLLOOSS DDEE CCOOMMUUNNIICCAACCIINN

DDOOCCEENNTTEE::

IINNGG.. JJUUAANN CCAARRLLOOSS PPEEAA MMOORRAANN

AALLUUMMNNOOSS::

MMAARRRROOQQUUIINN PPAANNIIAAGGUUAA KKEENNNNYY GGUUAADDAALLUUPPEE

PPAALLAACCIIOOSS PPAACCHHEECCOO JJOOSSEE DDAAMMIIAANN

SSAALLIINNAASS RROODDRRIIGGUUEEZZ AARRTTUURROO EERRNNEESSTTOO

SSAANNTTAA AANNAA 2255 DDEE JJUUNNIIOO 22001122

UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012

PROTOCOLOS DE COMUNICACION Pgina 2

INDICE

Introduccin. 3

Diagrama..

4

Configuracion de Heartbeat para dar soporte de alta disponibilidad 5

Codificacin de aplicaciones .. 7

Instalacin y configuracin de apache2..

11

Instalacin de Servidor Tomcat6..

14

Instalacin de monitor de desempeo para Servers Apache 15



INTRODUCCION El presente documento contiene los pasos necesarios para el montaje de un escenario que

contiene 2 Servidores HTTP(Apache2, Tomcat6), 2 Servers LDAP (Mster, Respaldo) para el

almacenaje de credenciales de los usuarios (user, password), donde el Master es el server default

para loguearse desde las aplicaciones alojadas en los servers Apache2 y Tomcat6, si el Master se

ve afectado por algn circunstancia como por ejemplo se desconect el cable, se qued sin

energa elctrica, etc, el Server de Respaldo entra a funcionar de manera transparente en las

aplicacions php y java, manteniendo la misma direccin IP del Server Master, con esto se logra un

escenario con soporte de alta disponibilidad . Adems se cuenta con 1 Balanceador de carga para

peticiones HTTP de Apache2.

El tema principal de este documento radica en la implementacin de un sistema Single Sing One

(SSO) el cual consiste en que si se tienen varias aplicaciones dentro del mismo dominio (ya sea en

el mismo servidor fsico o no) el usuario que se loguea en una de las aplicaciones debe quedar

logueado para todo el dominio, es decir si se loguea en una aplicacin y luego abre una nueva

pestaa en el navegador e introduce la Url del loguin de otro sitio(perteneciente al mismo dominio

por supuesto) la aplicacin debe ser capaz de saber si el usuario ya esta logueado o no, en caso de

estar logueado el usuario ser redireccionado a la pantalla principal de la aplicacin que esta

solicitando sin introducir su usuario y contrasea nuevamente, este mecanismo se esta volviendo

una necesidad debido a que los usuarios muchas veces manejan usuarios y password diferentes en

cada aplicacin creando un gran reto para los usuarios de recordar muchos usuarios y

contraseas.

El mecanismo SSO brinda la posibilidad al usuario de manejar credenciales nicas para todas las

aplicaciones que utiliza, evitando adems la carga en los servidores HTTP y LDAP para las

peticiones de logueo, manejando nicamente las sesiones concernientes a la funcionalidad

principal de las aplicaciones.

El mecanismo en el cual se basa este documento para lograr el SSO, son las cookies, las cuales a la

hora de crearse se hacen explcitamente visibles en todo el dominio (protocolos.xxx).

El primer paso es crear las pantallas de login en las aplicaciones desplegadas en Apache2 y

Tomcat6, los cuales en su etiqueta contendrn el action que ser el encargado de

tomar los datos ingresados por el usuario(user,password) y compararlos contra sus credenciales

almacenadas en el server LDAP, si la comparacin es exitosa se crea la sesin y las cookies en las

cuales se almacenara el nickname ingresado por el usuario. Adems de esto hay que tomar en

cuenta,que a la hora de ingresar al loguin hay que verificar si existe o no la cookie que contiene el

nickname, en caso de existir dicha cookie entonces el usuario se saltar la pantalla de login

ingresando automticamente a la pantalla principal de la aplicacin, adems en todas las pantallas

pertenecientes a las aplicaciones a la hora de ser requeridas tienen que asegurarse de que la

cookie existe en caso de existir permitir el acceso, caso contrario se redireccionara a la pantalla de

logueo.



DIAGRAMA Para tener una mejor panormica proporcionamos el diagrama de conexin y disposicin del

sistema de servidores:

La imagen muestra que los Servers Apache y Tomcat usan como repositorio de datos una

direccin IP virtual la cual es soportada por el server Master(Arturo) que en caso de caerse el

server de respaldo entra a funcionar manteniendo la misma Ip del Maester, esto es gracias a

Heartbeat con lo que podemos brindar un sistema de alta disponibilidad.

Este How To est basado en pcs con S.O Linux Debian 6 (Squeeze).



CONFIGURACION DE HEARTBEAT PARA DAR SOPORTE DE ALTA

DISPONIBILIDAD A NUESTROS SERVER LDAP

Partiendo del supuesto en que ya se tiene instalado y configurado Ldap en los 2 servers con un

rbol como el siguiente:

El primer paso para la configuracin de nuestro servicio de alta disponibilidad es instalar el

paquete Heartbeat:

#apt - get install heartbeat

Una vez instalado nos cercioramos de que se cre el directorio /etc/ha.d/

Seguidamente procedemos a crear el siguiente archivo (en los servidores ldap)

/etc/ha.d/ha.cf el cual contendr lo siguiente:



bcast eth0: Interfaz de red donde se levantar heartbeat

keepalive 2: Enva pings cada 2 segundos al otro nodo

deadtime 10: Tras 10 segundos sin recibir respuesta del otro nodo, se considera como

muerto

crear el archivo /etc/ha.d/authkeys (en ambos servers) el cual contendr lo siguiente:

crear el archivo /etc/ha.d/haresources (en ambos servers) el cual contendr lo siguiente:

El cual tiene definido el nombre del server que actuara como master seguido de la ip que ser

compartida por ambos server adems de la interfaz por la se saldr al exterior con dicha ip adems

se especifica el servicio que se estar soportando en esa ip para nuestro caso es slapd.

Debe reiniciar heartbeat

#/etc/init.d/heartbeat restart

A manera de prueba , ingresar a jxplorer (cliente grafico para arboles ldap, su instalacin es muy

sencilla: $apt-get install jxplorer) y en server coloque la ip 192.168.1.25 (ip definida en los

archivos de configuracin heartbeat) ejecute ldap en modo debug ($slapd d 16383)en el server

que se defini como mster en heartbeat(Arturo) podr notar que a la hora de acceder a Jxplorer,

el log se mueve , mientras que el log del server de respaldo permanece esttico, seguido

desconecte de la red o apague el server principal y vuelva a ingresar a Jxplorer con la misma ip

(192.168.1.25) y vera que el acceso se mantiene ya que esta siendo soportado por el server de

respaldo.

Con esto ya tenemos configurado nuestro servicio de alta disponibilidad para nuestros servers

LDAP.



CODIFICACION DE APLICACIONES Ahora procedemos a la codificacin de las aplicaciones que sern objeto del SSO en nuestro

dominio, comenzaremos por la aplicacin desarrollada en Php para ser subida a nuestro server

apache2.

crear un formulario de logueo conteniendo un textbox para usuario y otro para

contrasea y un botn para el envio de datos.

Escribir nuestro archivo procesar.php en el cual se recuperaran las credenciales

proporcionadas por el usuario (user,pass) y ser este el encargado de confrontarlo con el

server LDAP(que esta escuchando en la ip 192.168.1.25 gracias a HeartBeat). Dicho

archivo tiene que lucir de la siguiente manera:



Como se puede notar en $ldap[host] definimos la ip donde esta alojado nuestro servicio LDAP,

definimos el puerto y el rbol en donde se desea hacer la bsqueda de nuestros usuarios.

Si existe el usuario y las credenciales son correctas ($ldap[bind]) entonces se proceder a la

creacin de un cookie que ser visible para todo el dominio .protocolos.xxx y redireccionar a

asegurada.php que ser una fake page para simular la principal de una aplicacin. Caso contrario

ser redirigido a la pantalla de logueo para proporcionar nuevamente las credenciales.

Ahora regresamos a la pantalla login.php y hay que agregar el siguiente cdigo para preguntar si

existe la cookie a la hora de ingresar al login, en caso de ser verdadero pues redirecciona a la

principal de la aplicacin, caso contrario pues carga la pantalla login.



Seguido nos disponemos a la codificacin de nuestra aplicacin Java, la cual ser alojada en un

server tomcat6, para ello creamos un archivo llamado index.jsp en el cual se contendrn 2

textobos (user y pass) y un botn de accin para ejecutar la bsqueda, quedando de la siguiente

manera:

Luego codificamos en el archivo test.jsp el cual contedra las siguientes definiciones:



Dicho archivo hace referencia a una clase llamada conexin en el cual ser el que soportara el

logueo de la aplicacin en LDAP, dicha clase debe lucir de la siguiente manera:

La ip del server hace referencia a la ip que se ha definido en heartbeat. De igual forma que en php

si el usuario existe y coincide con su contrasea creara la cookie y el usuario ser redirigido a la

principal de la aplicacin.

Por ultimo falta activar el sso en nuestra pantalla de login, para ello ser necesario codificar lo

siguiente en dicha vista:



INSTALACION Y CONFIGURACION DE APACHE2

Instalar en el server que dar soporte al balance de carga y tambin hay que instalarlo en los 2

equipos que sern los servidores HTTP como tal, para ello instalamos los siguientes paquetes:

#apt-get install apache2 apache2-prefork-dev apache2.2-common apache2 utils

Una vez instalado procedemos a la configuracion del server de carga (192.168.1.3)

configuramos el archivo /etc/apache2/ports.conf .

Quedando de la siguiente manera, en el cual estamos especificando que se tendr un sitio alojado

en esa ip por medio del puerto 80.

crear un archivo dentro de la carpeta /etc/apache2/sites-available.

Este archivo deber contener el nombre de PhpApp:

#nano /etc/apache2/sites-avalable/PhpApp



Ahora hay que codificar de forma que luzca de la siguiente manera:

Una vez terminado el archivo PhpApp hay que desmontar el sitio default que vienen en la

instalacin de Apache2 y luego dar de alta al sitio que ser manejado por el archivo PhpApp,

adems hay que dar de alta a algunos mdulos necesarios para el balance de carga y por ultimo

reiniciar nuestro apache2:

#a2dissite deafult

#a2ensite PhpApp

#a2enmod proxy_balancer

#a2enmod proxy

#a2enmod proxy_http

#/etc/init.d/apache2 restart

Con esto tenemos listo nuestro server que ser el encargado de balancear la carga en los servers

apche2.



configuracin de los servidores apache2 (192.168.1.4,192.168.1.5)

Para la configuracin llamaremos balancer1 al sitio montado en el primer server y balancer2 al

segundo server, para ello simplemente hay que crear un archivo en /etc/apache2/sites-available

denominado balancerx (x representa el numero del server), quedando de la siguiente manera:

El contenido del archivo es el mismo para ambos servidores con la nica diferencia es en la

definicin de la Ip y probablemente la ubicacin del directorio del sitio, luego de eso nos situamos

en el archivo /etc/apache2/ports.conf (en ambos servidores) en el cual solo variamos la ip para

cada server.



Ahora solo falta reiniciar nuestro servicio apache en los 2 servers

#/etc/init.d/apache2 restart

Ya que las aplicaciones que han sido alojadas en apache2 estn escritas en Php se nos hace

necesaria la instalacin de los paquetes

#apt-get install php5 libapache-mod-php5

INSTALACION DE SERVIDOR TOMCAT6

La instalacin de este servidor es sumamente sencillo solo basta con instalarlo desde el

repositorio:

#apt-get install tomcat6 tomcat6-admin

Para comprobar que el servicio ha sido instalado vamos al navegador y digitamos la siguiente url

http://localhost:8080 y nos deber aparecer una patalla similar a la siguiente:



INSTALAR MONITOR PARA APACHE2 Existe un monitor muy bueno para el monitorear el rendimiento de nuestro servidor para ello

instalamos el siguiente paquete:

#apt-get install apachetop

Para ejecutarlo basta con escribir lo siguiente:

#apachetop f /var/log/apache2/acces.log

Y nos mostrara una ventana similar a la siguiente:

El cual es un resumen del total de peticiones atendas y los ltimos archivos solicitados

trabajoprotos-120625135955-phpapp01

Documents

Transcript of trabajoprotos-120625135955-phpapp01