Trabajo protos
-
Upload
kenny-marroquin -
Category
Documents
-
view
231 -
download
1
Transcript of Trabajo protos
UNIVERSIDAD DE EL SALVADOR
FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE
CCAATTEEDDRRAA::
PPRROOTTOOCCOOLLOOSS DDEE CCOOMMUUNNIICCAACCIIÓÓNN
DDOOCCEENNTTEE::
IINNGG.. JJUUAANN CCAARRLLOOSS PPEEÑÑAA 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 Página 2
INDICE
Introducción……………………………………………………………………………………………………………………. 3
Diagrama…………………………………………………………………………………………………………………………..
4
Configuracion de Heartbeat para dar soporte de alta disponibilidad………………………………… 5
Codificación de aplicaciones …………………………………………………………………………………………….. 7
Instalación y configuración de apache2……………………………………………………………………………..
11
Instalación de Servidor Tomcat6………………………………………………………………………………………..
14
Instalación de monitor de desempeño para Servers Apache……………………………………………… 15
UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012
PROTOCOLOS DE COMUNICACION Página 3
INTRODUCCION El presente documento contiene los pasos necesarios para el montaje de un escenario que
contiene 2 Servidores HTTP(Apache2, Tomcat6), 2 Servers LDAP (Máster, 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 algún circunstancia como por ejemplo se desconectó el cable, se quedó sin
energía eléctrica, etc, el Server de Respaldo entra a funcionar de manera transparente en las
aplicacions php y java, manteniendo la misma dirección IP del Server Master, con esto se logra un
escenario con soporte de alta disponibilidad . Además se cuenta con 1 Balanceador de carga para
peticiones HTTP de Apache2.
El tema principal de este documento radica en la implementación 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 físico 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 aplicación y luego abre una nueva
pestaña en el navegador e introduce la Url del loguin de otro sitio(perteneciente al mismo dominio
por supuesto) la aplicación 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 aplicación que esta
solicitando sin introducir su usuario y contraseña nuevamente, este mecanismo se esta volviendo
una necesidad debido a que los usuarios muchas veces manejan usuarios y password diferentes en
cada aplicación creando un gran reto para los usuarios de recordar muchos usuarios y
contraseñas.
El mecanismo SSO brinda la posibilidad al usuario de manejar credenciales únicas para todas las
aplicaciones que utiliza, evitando además 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 explícitamente 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 <form></form> contendrán 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 comparación es exitosa se crea la sesión y las cookies en las
cuales se almacenara el nickname ingresado por el usuario. Además 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 automáticamente a la pantalla principal de la aplicación, además 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.
UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012
PROTOCOLOS DE COMUNICACION Página 4
DIAGRAMA Para tener una mejor panorámica proporcionamos el diagrama de conexión y disposición del
sistema de servidores:
La imagen muestra que los Servers Apache y Tomcat usan como repositorio de datos una
dirección 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).
UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012
PROTOCOLOS DE COMUNICACION Página 5
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 configuración 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:
UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012
PROTOCOLOS DE COMUNICACION Página 6
bcast eth0: Interfaz de red donde se levantará heartbeat
keepalive 2: Envía 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 además de la interfaz por la se saldrá al exterior con dicha ip además
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 instalación es muy
sencilla: $apt-get install jxplorer) y en server coloque la ip 192.168.1.25 (ip definida en los
archivos de configuración heartbeat) ejecute ldap en modo debug ($slapd –d 16383)en el server
que se definió como máster 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 estático, 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.
UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012
PROTOCOLOS DE COMUNICACION Página 7
CODIFICACION DE APLICACIONES Ahora procedemos a la codificación de las aplicaciones que serán objeto del SSO en nuestro
dominio, comenzaremos por la aplicación desarrollada en Php para ser subida a nuestro server
apache2.
crear un formulario de logueo conteniendo un textbox para usuario y otro para
contraseña y un botón 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:
UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012
PROTOCOLOS DE COMUNICACION Página 8
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 búsqueda de nuestros usuarios.
Si existe el usuario y las credenciales son correctas ($ldap[‘bind’]) entonces se procederá a la
creación 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 aplicación. 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 código 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 aplicación, caso contrario pues carga la pantalla login.
UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012
PROTOCOLOS DE COMUNICACION Página 9
Seguido nos disponemos a la codificación de nuestra aplicación Java, la cual será alojada en un
server tomcat6, para ello creamos un archivo llamado index.jsp en el cual se contendrán 2
textobos (user y pass) y un botón de acción para ejecutar la búsqueda, quedando de la siguiente
manera:
Luego codificamos en el archivo test.jsp el cual contedra las siguientes definiciones:
UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012
PROTOCOLOS DE COMUNICACION Página 10
Dicho archivo hace referencia a una clase llamada conexión en el cual será el que soportara el
logueo de la aplicación 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 contraseña creara la cookie y el usuario será redirigido a la
principal de la aplicación.
Por ultimo falta activar el sso en nuestra pantalla de login, para ello será necesario codificar lo
siguiente en dicha vista:
UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012
PROTOCOLOS DE COMUNICACION Página 11
INSTALACION Y CONFIGURACION DE APACHE2
Instalar en el server que dará soporte al balance de carga y también hay que instalarlo en los 2
equipos que serán 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
UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012
PROTOCOLOS DE COMUNICACION Página 12
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
instalación de Apache2 y luego dar de alta al sitio que será manejado por el archivo PhpApp,
además hay que dar de alta a algunos módulos 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.
UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012
PROTOCOLOS DE COMUNICACION Página 13
configuración de los servidores apache2 (192.168.1.4,192.168.1.5)
Para la configuración 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
definición de la Ip y probablemente la ubicación 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.
UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012
PROTOCOLOS DE COMUNICACION Página 14
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 están escritas en Php se nos hace
necesaria la instalación de los paquetes
#apt-get install php5 libapache-mod-php5
INSTALACION DE SERVIDOR TOMCAT6
La instalación 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:
UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012
PROTOCOLOS DE COMUNICACION Página 15
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 atendías y los últimos archivos solicitados…