tecnoquia

Virtualización con RedHat: RHEV

En los últimos tiempos son cada vez más las soluciones de virtualización que se nos ofrecen. Con las últimas adquisiciones de RedHat, esta intenta posicionarse de forma privilegiada entre las soluciones OpenSource. El pasado Agosto presentó la revisión 2.2 de su plataforma RHEV que contiene las siguientes elementos:

RHEV-M for Server (o Management Interface for Server). Es la interfaz Web que usamos para administrar nuestra infraestructura. Es el mismo concepto que VirtualCenter en VMware y se instala sobre Windows 2003/2008 con Active Directory.
RHEV-M for Desktop (o Management Interface for Desktop). Es similar RHEV-M (interfaz web sobre Windows 2k3/2k8 con Active Directory), pero además incluye añadidos para controlar nuestra infraestructura VDI y el Broker basado en SPLICE.
RHEV-H (RHEV Hypervisor Baremetal). Es el hypervisor basado en RHEL 5.4 pero solo con el software de Virtualización (sin Apache, Samba, etc , etc). Es el mismo concepto que ESX en VMware.

Swish-e: GSA en casa

Shish-e (Simple Web Indexing System for Humans) es una pequeña herramienta OpenSource escrita en C que provee una Api en PERL para indexar nuestros documentos y después permitir cualquier búsqueda sobre ellos. Básicamente esta herramienta construye un árbol de índices sobre las palabras de nuestros documentos, y genera un par de ficheros con ellos. Para lograrlo debemos convertir los documentos a texto plano, de forma que el motor de indexación sea capaz de identificar las palabras y construir los índices sobre ellos. Esto en Linux es una tarea sencilla puesto que podemos ayudarnos de catdoc (para convertir .DOC a .TXT), pdf2text, unoconv (documentos OpenOffice a .TXT) y otros muchos, basta con realizar pequeñas búsquedas en Google y tener un poco de suerte. El motor permite dos modos de trabajo: Un modo araña en el que le pasamos una URL y él es capaz de escudriñar toda la Web siguiendo los enlaces, un modo local, donde nosotros nosotros indicamos un directorio y las extensiones de los documentos que queremos indexar, y un modo mixto, donde a swish-e le pasaremos el programa que usará para obtener las palabras de los documentos: así, swish-e sólo se encargará de construir los índices.
Luego, a través de una API en Perl podremos lanzar búsqueadas en nuestros ficheros. Para afinar nuestras búsquedas permite usar operadores lógicos que le dirán al motor de búsqueda cómo relacionar las distintas palabras de nuestra búsqueda:

and. Si buscamos [dolor and cabeza] le estaremos pidiendo al motor que nos busque documentos que contengan las palabras dolor y cabeza. Este es el comportamiento habitual y no hace falta escribir contínuamente el and: Si ponemos varias palabras [dolor cabeza], el resultado será el mismo que [dolor and cabeza].
or. Si buscamos [dolor or cabeza] le estaremos pidiendo al motor que nos busque documentos que contengan la palabra dolor o cabeza o ambas.
not. Si buscamos [not dolor] le estaremos pidiendo al motor que nos busque documentos que no contengan la palabra dolor.
near. Si buscamos [dolor near cabeza] le estaremos pidiendo al motor que busque documentos que contengan la palabra dolor y cerca de ella, aparezca la palabra cabeza. Esta es una opción similar a and pero permite acotar la proximidad de las palabras para afinar nuestra búsqueda. Podemos limitar la proximidad de estas palabras, añadiendo un número a near: Con [dolor near2 cabeza] le pedimos al motor que busque documentos que contengan la palabra dolor y cabeza separada hasta por dos palabras.

Para especificar varios operadores lógicos podemos usar paréntesis como si se tratase de una expresión matemática, evaluándose de dentro hacia fuera. Así [dolor and (not cabeza) ] buscará documentos que contengan la palabra dolor pero que no contengan la palabra cabeza.
Para afinar aún más nuestras búsquedas podemos usar comodines en las palabras de búsqueda.

?. Usar el comodín ? le dice al motor que sustituya ese símbolo por cualquier letra. Si buscamos [cos?] el motor nos encontrará documentos que contengan palabras como cose, cost, cose, ..., en definitiva, palabras de cuatro letras que comiencen por cos.
*. Usar el comodín * le dice al motor que sustituya ese símbolo ninguna o más letras. Mientras el comodín ? se sustituye sólo por una letra, el comodín *, se sustituye por cualquier cantidad de letras. Si buscamos [libr*] el motor nos encontrará documentos que contengan palabras como libro, librero, librería, ..., en definitiva, palabras de cualquier longitud que empiecen por libr

ShadowCopy con Samba

ShadowCopy es una característica de Windows 2003 y posteriores que nos permite obtener instantáneas de nuestros volúmenes mediante Volume Snapshot Service (VSS). De esta forma podemos tener respaldos (backups) automáticos o manuales de archivos o carpetas de una unidad de disco en un momento concreto, y mediante un pequeño cliente integrado con el explorador de Windows, acceder al histórico de versiones de un documento o de una carpeta.

En Samba podemos activar esta funcionalidad mediante un VFS especial y la ayuda de Snapshots de LVM sobre volúmenes lógicos. Para ello, procederemos de la siguiente forma:

Disponer el share de Samba sobre un volumen lógico LVM. Por ejemplo, nosotros tendremos /dev/VG_Samba/lv_homes, formateado con EXT4 y lo montaremos sobre el directorio /home/usuarios.
Crear un directorio a la altura de nuestro punto de montaje, para montar los Snapshots del volúmen. En nuestro ejemplo, tendremos el punto de montaje en /home/usuarios_snapshots.. Es importante disponer de espacio libre en el mismo Grupo de Volumen para albergar los snapshots (en nuestro ejemplo, en /dev/VG_Samba)
Configurar la instancia de Samba para activar ShadowCopy. En nuestro ejemplo, añadiremos a smb.conf las cuatro últimas líneas del siguiente bloque, que activan esta configuración.
```
[prueba]
public = yes
writable = yes
comment = Prueba ShadowCopy2
path = /home/usuarios

# Config ShadowCopy
vfs objects = shadow_copy2
shadow:snapdir = /home/usuarios_snapshots
shadow:basedir = /home/usuarios   
```
Cuando lo hayamos editado tendremos que reiniciar nuestra instancia de Samba.

Desarrollar un pequeño script para realizar los snapshots del volumen /dev/VG_Samba/lv_homes y montarlos en /home/usuarios_snapshots. Es importante respetar el formato del nombre del punto de montaje (@GMT-Año.Mes.dia-hora.minuto.segundo), si no, el módulo no será capaz de reconocerlo:

#!/bin/bash

# Nombre del SnapShot
SNAPNAME=`date +%Y.%m.%d-%H.%M.%S`

# Crear el snapshot en LVM de 1G
lvcreate -L1G -s -n $SNAPNAME /dev/VG_Samba/lv_usuarios

# Crear el punto de montaje
mkdir /home/usuarios_snapshots/\@GMT-$SNAPNAME

# Montar el snapshot en sólo lectura
mount /dev/VG_Samba/$SNAPNAME /home/usuarios_snapshots/\@GMT-$SNAPNAME -o ro

Instalar el cliente de ShadowCopy en el equipo cliente Windows XP (http://technet.microsoft.com/es-es/windowsserver/bb405951)y probar.

La foto la he sacado del album de Carla216 en flickr

Balanceo con Squid

Estamos acostumbrados habitualmente a usar Apache como proxy transparente en las DMZ para bajar tráfico a la zona de nuestros servidores. El módulo ProxyPass y ProxyReverse , junto a mod_jk, y mod_proxy_ajp y demás resulta ideal para esta labor, por la versatilidad de configuración que ofrece Squid, pero a veces esto no es suficiente: Cuando tenemos que Apache tiene que servir una aplicación escrita con cantidad de contenido multimedia (pdfs, flash, imágenes, etc) en los que los usuarios acceden a la vez y de forma masiva, como por ejemplo al dar un curso online, los Apaches pueden sufrir: A la carga propia de generar el contenido dinámico (ejecución del PHP, CGI, Java, etc) se suma la carga de servir el contenido multimedia.

Un Apache en un equipo normalito (dual core y 4GB de RAM) soporta muy bien entre 200 y 300 conexiones concurrentes sin penalizar el tiempo de respuesta (más de 2 segundos). Si nuestra aplicación tiene mucho contenido multimedia, cada página que pidan los clientes se convertirá en varias de estas peticiones concurrentes y por ejemplo cada página se transforma en 20 peticiones, 15 usuarios concurrentes podrían estar sobrecargando el servidor Web. En esta situación está claro que deben estudiarse varias cosas: La configuración de Apache, la carga de base de datos, la distribución del contenido estático, el número de Apaches, el tipo de balanceo que realizamos, y un largo etc, pero como primera contramedida se puede incluir un Caché inversa transparente, dedicada a servir el contenido estático de nuestras páginas y descargar de esta labor a Apache.
Para ello podemos usar Squid, que con una mínima configuración podemos realizar esta labor, y además balancear las peticiones hacia nuestros Apaches. El fichero de configuración que podríamos usar es el siguiente:


#------------------------------------------------
# ACLS BASICAS
#
acl all          src    all
acl localhost    src    127.0.0.1/32
acl to_localhost dst    127.0.0.0/8 0.0.0.0/32
# Mi DMZ está en 192.168.3.0
acl localnet     src    192.168.3.0/24
acl manager      proto  cache_object
acl purge        method PURGE
acl CONNECT      method CONNECT

#------------------------------------------------
# ACCESO PARA MANEJAR LOS FICHEROS DE CACHE
#
#  Solo la maneja localhost
http_access      allow manager localhost
http_access      deny  manager
#  Solo permitimos la purga desde localhost
http_access      allow purge localhost
http_access      deny  purge


#------------------------------------------------
# REGLAS PARA LA CACHE WEB HACIA LOS APACHES
#
#  Decir que vamos a cachear y que no
acl IMAGENES     urlpath_regex .jpg .gif .png .swf .JPG .GIF .PNG .SWF .css .CSS .pdf .PDF .bmp .css .doc .docx .exe .jpg .js .mp3 .odt .ppt .rtf .swf .txt .wrl .WRL .xls .XLS .xlsx .zip .exe .html .htm .HTML .HTM
acl QUERY        urlpath_regex cgi-bin \? .php .asp  .xml .cgi
no_cache         allow IMAGENES
no_cache         deny  QUERY
refresh_pattern  . 0 20% 0

# Habilitar HTTP 1.1
server_http11 on


# Configurar aceleracion hacia MiVirtualHost
# Mis servidores están la 192.168.2.0/24

# Como llegar al Nodo1 de Apache
cache_peer 192.168.2.211 parent 80 0 no-query http11 originserver no-digest round-robin weight=5 login=PASS name=srv01
# Como llegar al Nodo2 de Apache
cache_peer 192.168.2.212 parent 80 0 no-query http11 originserver no-digest round-robin weight=3 login=PASS name=srv02
# Como llegar al Nodo3 de Apache
cache_peer 192.168.2.213 parent 80 0 no-query http11 originserver no-digest round-robin weight=1 login=PASS name=srv02

# Esto es para procesar las respuestas 302
header_replace X-Forwarded-For
via off
reply_header_access X-Cache-Lookup deny !localnet
reply_header_access X-Squid-Error  deny !localnet
reply_header_access X-Cache        deny !localnet

http_port 3128

#debug_options ALL,1 28,9

# Definir el acceso al propio Squid
acl thishost     src    192.168.3.121/32
acl to_thishost  dst    192.168.3.121/32


#------------------------------------------------
# REGLAS PARA LOS HERMANOS WEB CACHE
#
# Configurar para que escuche multicast
mcast_groups 224.0.14.255
# Configurar para que hable multicast
cache_peer   224.0.14.225   multicast 80 3130 ttl=16
# Configurar hermanos multicast (otros squids en DMZ)
cache_peer 192.168.3.122   sibling 3128 3130 multicast-responder
cache_peer 192.168.3.133   sibling 3128 3130 multicast-responder
mcast_icp_query_timeout     2 sec


# Definir la ACL para redirigir el backup
# y que vaya solo a un nodo.
acl phpBackup urlpath_regex /backup/

# Definir los sitios de cachearemos
acl mivirtualhst  dstdomain www.MiVirtualHost.com
http_access allow mivirtualhst
cache_peer_access srv01 allow mivirtualhst !phpBackup
cache_peer_access srv02 allow mivirtualhst !phpBackup
cache_peer_access srv03 allow mivirtualhst


# Esto se hace para no cachear internet :P
cache_peer_access srv01 deny all
cache_peer_access srv02 deny all
cache_peer_access srv03 deny all
http_access deny All


#------------------------------------------------
# MONITORIZACION SNMP DEL SERVIDOR
#
snmp_port 1161
acl Snmppublic snmp_community public
acl Adminhost src 192.168.0.0/16
snmp_access allow Adminhost Snmppublic
snmp_access deny all

#------------------------------------------------
# RESERVA DE DISCO PARA LA CACHE
#
#  Regla de oro: Por cada 1MB de RAM, necesita 32MB de disco
#   * por defecto: cache_dir ufs /var/spool/squid 100 16 256
#   * sintaxis   : cache_dir diskd Directory-Name Mbytes L1 L2 [options] [Q1=n] [Q2=n]
cache_dir diskd /var/spool/squid  1600 16 256 Q1=60 Q2=50


#------------------------------------------------

Esta configuración permite que squid derive las peticiones al dominio www.MiVirtualHost.com hacia tres Apaches (192.168.2.211, 192.168.2.212, 192.168.2.213) de forma ponderada (5,3 y 1 respectivamente), cacheando todo el contenido estático (directiva acl IMAGENES). Además evita que dos de los servidores reciban peticiones cuando la URL contenga /backup/, en cuyo caso, las peticiones sólo se derivarán al tercer nodo Apache. También presupone que existirán dos cachés más en DMZ (sibling) que nos ayudarán en la labor y cuya comunicación será vía Multicast que suponemos más rápida que si lo hiciéramos punto a punto.

La foto la he sacado del album de Richard Ling en flickr

VDI con NComputing

Hace unas semanas ví en un cliente un pequeño aparato que estaban evaluando. El aparato era un L-Series de Ncomputing que permite virtualizar escritorios Windows XP de forma económica (menos de 200 Euros). Para ello el invento se configura para usar hasta ocho licencias de escritorio remoto de Windows del equipo que configuremos como servidor y ofrecer el escritorio a los clientes, de dos formas principalmente:

Vía USB, de forma que el invento se conecta a un concentrador USB que tenga conectado el servidor Windows, al que instalaremos un software especial de NComputing, y al invento conectamos el teclado, monitor y ratón del terminal
Vía Ethernet, de manera que lo configuramos para conectar a la dirección IP del servidor Windows, e igualmente conectamos el teclado, ratón y monitor del usuario al pequeño invento.

En las demos me comentaron que usaban un equipo con VMware Server 2.X de prestaciones normalitas en cuanto a CPU (dual core) y RAM (4GB), y ejecutaban ocho equipos Windows XP, que servían 8 escritorios virtuales cada uno, lo que serían 64 puestos de trabajo.
El invento resulta muy, muy interesante, la única pega es que las licencias de Windows se deben pagar aparte. Al parecer con la licencia de Windows XP habitual sólo se pueden usar sólo dos licencias de escritorio remoto, las que sobrepasen esta cantidad deben pagarse aparte.

Samba y el refresco de archivos

Cuando implantamos un servidor Samba, a veces los clientes Windows no refrescan automáticamente los cambios que hacemos en las carpetas y tenemos que pulsar contínuamente la tecla F5. Esto podemos solucionarlo añadiendo al registro de Windows de los equipos:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update\UpdateMode = 0

También será conveniente añadir a los sitios de confianza de Internet Explorer las direcciones IP de los servidores samba y de los shares, para evitar que contínuamente Windows nos avise de que existe un riesgo de seguridad.

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Ranges\Range1]
"*"=dword:00000002
":Range"="DIRECCION_IP"

Shibboleth 2 (gestión de identidades federada)

La palabra Shibboleth proviene del hebreo espiga y hace alusión a la esencia misma de las personas, a su identidad, una marca con la que se puede reconocer la pertenencia a un grupo. Cuenta el Libro de los Jueces en el Antiguo Testamento, que la tribu de Efraím tras sufrir la derrota de mano de los galaaditas, estos idearon una prueba para identificar a los supervivientes de la tribu: a los sospechosos se les hacían pronunciar la palabra Shibboleth, imposible de pronunciar para los efraimitas que no tenían el fonema 'sh' en su lengua. Murieron degollados 42000 efaimitas por pronunciar sibboleth.

Alejándonos de las raíces violentas de la palabra y acercándonos a su etimología, encontramos Shibboleth como un marco de trabajo Open Source desarrollado en Internet2 que implementa un sistema de Single-Sign-On web con intercambio de atributos basados en estándares abiertos, principalmente SAML. Este sistema federado provee acceso seguro a través de diferentes dominios de seguridad, preservando la privacidad de los datos de sus usuarios, y posibilita la escalabilidad del sistema a través de relaciones de confianza.

Internet2 es una red de cómputo sustentada por tecnologías vanguardistas sobre líneas de alta velocidad, independiente de la Internet comercial actual. Su origen se debe al espíritu de colaboración entre las universidades del mundo y su objetivo principal es desarrollar la próxima generación de aplicaciones telemáticas para facilitar las misiones de investigación y educación de las universidades, además de ayudar en la formación de personal capacitado en el uso y manejo de redes avanzadas de cómputo, recuperando con ello el origen académico de los comienzos de Internet e independizándose de intereses comerciales y particulares.
Shibboleth nace con el objetivo de proveer una solución a los desafíos que actualmente encontramos en Internet (1 y 2):

Facilitar la gestión de múltiples contraseñas en múltiples aplicaciones
Simplificar la gestión de cuentas de acceso de múltiples aplicaciones
Preservar la privacidad de los usuarios
Posibilitar la interacción entre organizaciones y sus usuarios
Habilitar la posibilidad de que elijamos en la institución donde deseamos autenticarnos
Permitir que los proveedores de servicios controlen el acceso a sus recursos
Facilitar la integración rápida y efectiva de servicios de terceros dispares

En general, proveer una solución que permita la Gestión de la identidad federada con las siguientes características:

Proviene de Internet2
Provee un proveedor de identidad (IdP) en Java y un proveedor de servicio (SP) en C++, como módulo del servidor Web Apache
Está basado en OpenSAML
Dispone de dos versiones
- 1.3 que implementa SAML v1.1 en el IdP y SP
- 2.0 que implementa SAML v2.0 en el IdP y SP además de soportar SAML v1.1

Además de proveer una solución libre y robusta para implementar nuestra gestión de identidades federada, lo mejor quizás sea que GoogleApss se integra con shibboleth y nos permite configurar el Single-Sign-on de los servicios de Google con nuestro propio LDAP de una forma segura y eficiente.