tecnoquia: diciembre 2010

Informe Robinson

El año 2010 acaba. Muchas cosas han pasado este año, pero por una las cosas que lo recordaremos es porque ese año España ganó por fin el mundial de Fútbol. Mi cuñao me ha pasado un enlace al Informe Robinson que además fue galardonado con un premio ondas.

El enlace al primero de los vídeos en youtube: http://www.youtube.com/watch?v=ONUwNddTzLE

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.

Apache: Balanceo de Tomcats con mod_proxy_ajp

Desde Apache 2.2 disponemos de un módulo nativo (mod_proxy_ajp) para implementar proxies inversos con AJP, desarrollado por el propio Apache. Esto hasta ahora lo habíamos venido realizando con mod_jk, que se distribuía con el propio Tomcat. Os dejo un ejemplo que usé para balancear una aplicacion hacia tres tomcats.

<VirtualHost *:80>
 ServerName  archivo.prueba.es
 ServerAlias archivo


 CustomLog /var/log/httpd/archivo.log combined

 # Preservar las cabeceras anteriores, y
 # evitar que el proxy las modifique
 ProxyPreserveHost On

 # Montar URLs hacia el cluster
 ProxyPass /archivo  balancer://archidoc_cluster/archivo  tickysession=JSESSIONID nofailover=On

 # Definir el proxy hacia los Tomcats
 <Proxy balancer://archidoc_cluster>
    BalancerMember ajp://tomcat1:8509
    BalancerMember ajp://tomcat2:8509
    BalancerMember ajp://tomcat3:8509
 </Proxy>


 # Redireccion para que vaya directamente al Tomcat
 RewriteEngine on
 RewriteRule ^$      /archivo/ [R,L]
 RewriteRule ^/$     /archivo/ [R,L]

 AddDefaultCharset ISO-8859-1
</VirtualHost>

La verdad que tampoco está muy claro cuando es recomendable usar uno u otro: Yo sólo lo he usado cuando he tenido problemas con alguna aplicación y mod_jk, que siempre es mi primera elección, simplemente por madurez del proyecto.

La foto la he sacado del album de Darny en flickr

SmbWebClient

SmbWebClient es un cliente Samba implementado en un único PHP, que permite colocar nuestros Shares de Samba accedibles vía Web. Esto permite que nuestros usuarios puedan acceder a los ficheros de sus unidades de Intranet a través de Internet.

La instalación es muy sencilla, basta con descomprimir el fichero en una carpeta de nuestro servidor Web que tenga instalado PHP y el cliente de Samba. Si tiene algún incoveniente esta herramienta, es su simplicidad y que modificarla resulta tedioso porque todo lo que usa (iconos y plantillas thtml) están embebidos en BASE64 dentro del propio código. Así, cosas sencillas como cambiar el icono de las carpetas o personalizar el HTML, nos obliga a andar descodificando y codificando en Base64 todo.

Auditoría en OpenLDAP

Desde hace tiempo vengo implantando OpenLDAP para poner en marcha proyectos de gestión de la identidad en organizaciones. La principal ventaja que nos aporta el uso de software libre para estos proyectos, es la posibilidad de retocar el código fuente y desarrollar overlays que nos permitan extender las funcionalidades que traen de serie, pudiendo adaptar así la solución a las necesidades del cliente y generar una solución óptima para él a un precio adsequible.

Estos proyectos, casi siempre se centran en la provisión de cuentas de acceso centralizada y automatizada: Desde OpenLDAP hacia otros sistemas como eDirectory, Active Directory, Oracle, Linux, etc. Para ello se suelen relajar las políticas de cuenta, dado que no siempre se tienen las mismas posibilidades de configuración en los distintos sistemas ni se implementan de la misma manera. Al final, esto degenera en que las contraseñas de las cuentas de usuario no poseen ninguna complejidad y las conservan por los tiempos de los tiempos.

Esta situación se puede corregir con el uso de políticas en OpenLDAP a partir de la versión 2.3. Para acctivarlas tendremos que editar el fichero de configuración de nuestro servidor OpenLDAP y aplicar los siguientes cambios:

Incluir el esquema de definición de políticas

include       /etc/openldap/schema/ppolicy.schema

Añadir el módulo:

modulepath    /usr/lib64/openldap
moduleload    ppolicy.la

Indicar el objeto que contendrá la política de nuestro directorio, justo después de la definición del backend de la base de datos que usaremos.
```
overlay         ppolicy
ppolicy_default "cn=defaultpwpolicy,dc=DOMINIO
```

Reiniciar el servicio para aplicar los cambios. Crear un fichero LDIF con el siguiente contenido que será nuestra política de seguridad:

dn: cn=defaultpwpolicy,dc=DOMINIO
cn: defaultpwpolicy
objectClass: top
objectClass: device
objectClass: pwdPolicy
pwdAttribute: userPassword
pwdAllowUserChange: TRUE
pwdMustChange: FALSE

La añadiremos al directorio...

ldapadd -x -h localhost -D "cn=admin,dc=DOMINIO" -w CLAVE -f politica.ldif

Esta política es muy sencillita y permisiva: Solo nos sirve para mantener en el campo pwdChangedTime cuándo se cambió por última vez la contraseña (userPassword) el usuario en LDAP. Podemos encontrar todas las opciones en la página man de salpo-ppolicy, y añadir complejidad a las contraseñas, duración, bloqueo después de intentos fallidos, etc.
La foto la he sacado del album de treevis en flickr

Réplicas OpenLDAP con SyncRepl

Todos los que hemos usado OpenLDAP desde hace tiempo como software para desplegar nuestros servicios de directorio, hemos venido sufriendo el problema de las réplicas en los esclavos para mantener la alta disponibilidad. La solución con la que contábamos era el uso de SLURPD, un pequeño demonio que se ejecutaba en el servidor con el LDAP maestro. Cada operación que se realizaba en el directorio se anotaba en un fichero de texto plano junto a la hora, y el demonio iba aplicando los cambios del fichero en cada una de las réplicas. Este proceso era bastante inestable, porque asumía siempre que la replica estaba en un estado determinado, y a partir de él aplicaba cambios. Esto no siempre era así, porque podíamos haber parado la réplica o haberla recuperado de un backup, y al final teníamos que nunca estábamos completamente seguros del estado de nuestras réplicas hasta que parábamos todo el directorio, y copiábamos a mano la base de datos del maestro en cada una de las réplicas. Teníamos demasiadas paradas en un servicio siempre importante, y el proceso SLAPD solía estar siempre en la cima del top comiendo toda la CPU que podía, sin contar las veces que el demonio SLURPD moría por causas desconocidas.

Por suerte con la versión 2.3 de OpenLDAP aparece un nuevo mecanismo de sincronización del directorio basado en un overlay y llamado SyncRepl. Este mecanismo lo que hace es escribir en cada modificación un timestamp con la hora a la que se realizó y se guarda en la propia base de datos dentro de los atributos del objeto modificado, y además mantiene un timestamp global que contiene el valor para la última modificación. Las réplicas ahora, no esperan a que el maestro les envíe las modificaciones sino, que se conectan contínuamente al maestro y le preguntan por el valor globlal: Lo comparan con el que ellas tienen anotado y solicitan todos los objetos comprendidos entres estos dos timestamp para modificarlos en la base de datos local. Este mecanismo en mucho más robusto, y aporta tranquilidad a la vida de los administradores de OpenLDAP.

Para configurarlo tendremos que:

Editar la configuración del maestro y añadir la configuración de SyncRepl a justo después de la definición de nuestro backend
```
overlay     syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
lastmod     on
```

Editar la configuración del esclavo y añadir la configuración de SyncRepl a justo después de la definición de nuestro backend, como hicimos para el maestro, y además añadir al final cómo conectar con el LDAP que hace de maestro:

# Configurar el proveedor... (nuestro master)
syncrepl rid=001
      provider=ldap://__IP_MAESTRO_LDAP__:389
      type=refreshAndPersist
      retry="60 +"
      searchbase="dc=DOMINIO"
      filter="(objectClass=*)"
      scope=sub
      attrs="*,+"
      schemachecking=off
      bindmethod=simple
      binddn="cn=admin,dc=DOMINIO"
      credentials=CLAVE_DEL_ADMIN

updateref ldap://__IP_MAESTRO_LDAP__:389

Añadir índices para los campos entryCSN y entryUUID, en la sección de índices del fichero de configuración de los LDAPs. Estos campos es donde SyncRepl va anotando las modificaciones.
```
index entryCSN,entryUUID        eq
```

Después de aplicar estos cambios, tendremos que reconstruir la base de datos del maestro, con el fin de que se creen todos los objetos con estos campos reservados. Luego regenerar los índices de la base de datos con slapindex, y copiarla a los nodos esclavos para que arranquen en un estado sincronizado.

La foto la he sacado del album de Michael Dawes en flickr

OSSEC

OSSEC es un detector de intrusos basado en nodo (HIDS, Host-based Intrusion Detection System) open source que lleva a cabo las siguientes funciones: análisis de registros, comprobación de integridad, detección de rootkits, alertas basadas en secuencias temporales y respuesta activa , capaz de ejecutarse en cliente/servidor y que funciona en Windows, Linux, MacOs. Es una especie de evolución de Tripwire. Otra de las ventajas que presenta OSSEC es que la base de datos de firmas MD5 no se almacena en el equipo cliente, sino que se lleva a un servidor centralizado, por lo que si un cliente queda comprometido, las firmas no quedan comprometidas.

Para configurar los equipos linux con el Agente de OSSEC se seguirán la siguiente secuencia de pasos:

Conectarse por SSH al servidor OSSEC de la sonda donde conectaremos el cliente, como root.
Desde la consola del servidor OSSEC, ejecutaremos el comando /var/ossec/bin/manage_agents, y luego nos aparecerá un menú de opciones, donde lo que tenemos que hacer es dar de alta un nuevo agente (A) y luego extraer la clave para él (E). Pasa salir(Q). Cuando nos muestre la clave la copiaremos en un fichero, para poder importarla en el cliente:
```
****************************************
* OSSEC HIDS v2.1 Agent manager.
*
* The following options are available: *
****************************************
(A)dd an agent (A).
(E)xtract key for an agent (E).
(L)ist already added agents (L).
(R)emove an agent (R).
(Q)uit.
```
De vuelta a la consola del servidor, reiniciaremos el servicio...
```
/etc/init.d/ossec restart
```

Ahora el siguiente paso será instalar el cliente OSSEC en el equipo que queremos monitorizar, e importar esta clave, para que hable con nuestro servidor Ossec.

Conectarse por SSH al cliente OSSEC como root.
Descargar e instalar el agente en nuestro sistema
Desde la consola del ejecutar el comando /var/ossec/bin/manage_agents, y luego nos aparecerá un menú de opciones, donde lo que tenemos que hacer es importar la clave(I). que habríamos copiado desde el servidor OSSEC. Para salir(Q).
De vuelta a la consola del servidor, reiniciaremos el servicio...
```
/etc/init.d/ossec restart
```

Podemos ver los logs entre el servidor y en el cliente con ejcutando el comando:

tail -f /var/ossec/logs/ossec.log

De vuelta a nuestro servidor, podemos instalar ossec-Web-UI, descargándolo de la Web y luego ejecutar los siguientes comandos para instalarlo:

cd /var/www
tar -xzvf /opt/ossec-wui-0.3.tar.gz
mv ossec-wui-0.3 ossec-wui
bash setup.sh

... cuando nos pregunte responder username=admin y contraseña=pokemon.

usermod -G ossec www-data
/etc/init.d/apache2 restart

Acceder desde el navegador a: http://NUESTRO_SERVIDOR/ossec-wui/

AutoIT

AutoIT es una pequeña utilidad que nos permite escribir scripts para Windows y automatizar ciertas tareas que con VBS o BAT nos costaría mucho trabajo. La síntaxis es similar a la de Visual Basic y lo más interesante es que se compila y genera un fichero .EXE que podemos ejecutar en cualquier equipo sin necesidad de tener AutoIT instalado.

Os dejo un script a modo de ejemplo, que desarrollé para migrar los documentos y carpetas del escritorio de un usuario a un directorio local y así evitar que el perfil móvil del usuario pese demasiado.

;
; Script AUTOIT para mover objetos del escritorio
; a "Mis documentos y crear acceso directorio en
;

; Establecer que si se producen errores fatales no salga del script
Opt("RunErrorsFatal", 0)

; Buscar los archivos del perfil...
$search = FileFindFirstFile(@DesktopDir & "\*")
; Comprobar que se encontró algo...
If $search = -1 Then
; No, no se ha encontrao nada ...:P
Exit
EndIf

; Flag para avisar que se le han movido archivos
$flag=0

; Por cada fichero que se encontró hacer el bucle...
While 1
; Obtener el nombre del fichero ...
$file = FileFindNextFile($search)
; Ver si hemos terminado el bucle
If @error Then ExitLoop
   ; Obtener los atributos del archivo
   $attrs=FileGetAttrib(@DesktopDir & "\"& $file)
   ; Obtener la extension del archivo
   $ext = stringRight( StringLower($file), 4)
   ; Por extension o en caso de que sea un directorio...
   If (StringInStr($attrs, "D")) or ((NOT($ext == ".lnk")) and (NOT($ext == ".url")) ) Then
      If (StringInStr($attrs, "D")) Then
         ; Tenemos que mover el archivo
         DirMove ( @DesktopDir & "\"& $file, @MyDocumentsDir, 1 )
      Else
         ; Tenemos que mover el archivo
         FileMove ( @DesktopDir & "\"& $file, @MyDocumentsDir, 8 )
      EndIf
      ; Crear acceso directo en el escritorio...
      ShellExecute("\\SRV\NETLOGON\XXMKLINK.EXE",' "' & @DesktopDir & "\" & $file &'.lnk"  "' & @MyDocumentsDir & '\' & $file & '"', @UserProfileDir)
      $flag=1
   EndIf
EndIf
WEnd

Este script se apoya en XXMKLINK que permite crear enlaces simbólicos de Windows.

Apache: Evitar redirecciones indeseadas

A menudo tenemos configurado en nuestros servidores Web Apache, VirtualHosts que usan mod_rewrite para modificar algunas peticiones y dirigirlas a otras URLs. Esto puede ser aprovechado por un atacante para evitar el baneo de la pertenencia a listas negras. Podemos hacer una comprobación sencilla ejecutando telnet NUESTRO_SERVIDOR 80 y luego escribir:

GET http://l25.member.re3.yahoo.com/config/login?login=a-jj&passwd=Monster HTTP/1.0

Si nuestro servidor Web devuelve una respuesta 302, podríamos ser candidatos a ataques mal intencionados. Lo correcto sería que nuestro servidor respondiera con un 403. Para ello, podemos añadir a la configuración de nuestro VirtualHost:

 # Para evitar que nos usen de Salto...
RewriteCond   %{HTTP_HOST}   !^NOMBREVIRTUALHST
RewriteRule   ^(.+)          http://NOMBREVIRTUALHST/fallo [F,L]

Donde NOMBREVIRTUALHST es el nombre de nuestro VirtualHost.

La imagen la he sacado del album de rbowen en flickr

Clariion CX300 con Multipath y Ubuntu 10.04

Para preparar multipath en nuestro sistema Ubuntu, lo primero que debemos ejecutar es:

apt-get install sg3-utils sysfsutils multipath-tools

Luego añadiremos al fichero /etc/modprobe.d/scsi.conf la siguiente línea:

options scsi_mod max_luns=256

Esto permite numerar hasta 256 los dispositivos scsi, si no cuando presentemos varios discos (la segunda controladora los muestra por encima del id_scsi 64) es fácil que dejemos de ver alguno de ellos. Esto es necesario en Ubuntu y Debian.
Una vez se tiene instalado el software multipath se creará el fichero /etc/multipath.conf de configuración inicial, con el siguiente contenido:

defaults {
udev_dir                /dev
user_friendly_names     yes
}
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z][[0-9]*]"
devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]"
}
devices {
device {
   vendor               "DGC*"
   product              "*"
   path_grouping_policy group_by_prio
   getuid_callout       "/lib/udev/scsi_id -g -u -d /dev/%n"
   prio_callout         "/sbin/mpath_prio_emc /dev/%n"
   path_checker         emc_clariion
   path_selector        "round-robin 0"
   features             "1 queue_if_no_path"
   no_path_retry        300
   hardware_handler     "1 emc"
   failback             immediate
}
}
multipaths {
#   multipath {
#       wwid               360060160ffc21a0072174c3f6edede11
#       alias              pruebas
#   }
}

Esta configuración es particular para cabinas EMC Clariion CX300, está extraída de http://www.querzone.de/wiki/Wiki.jsp?page=EMCClariion. Una vez establecida la configuración inicial del servicio multipath, se debe refrescar la información de la SAN, ejecutando los siguientes comandos:

/etc/init.d/multipath-tools stop
/etc/init.d/multipath-tools start
multipath -F
multipath -v2
multipath -ll

Al tener varios dispositivos (/dev/sda, /dev/sdb) asociados al mismo disco físico (/dev/mapper/pruebas), las herramientas LVM pueden ser un cuello de botella además de mostrar los típicos mensajes de duplicidad de nombres al ejecutar pvscan. El cuello de botella se puede producir, porque cuando se reinicia el sistema el monitor de LVM ejecuta los comandos pvscan, vgscan y lvscan, para crear los dispositivos asociados a nuestros volúmenes. El problema puede darse que en este escaneo, LVM primero detecte /dev/sda o /dev/sdb, antes que /dev/mapper/pruebas, y por tanto construyan los dispositivos asociados a los volúmenes a un camino, en vez de hacerlo al dispositivo virtual que nos creó dm-mpath para abstraernos del camino activo. Entonces cuando cambie el camino activo, LVM no podrá acceder al disco y el sistema se colgará. Para evitarlo, se debe editar el fichero /etc/lvm/lvm.conf y realizar los siguientes cambios que se indican a modo de parche:

26c26,27
<
preferred_names = [ ]
---
>
# preferred_names = [ ]
>
preferred_names = [ "^/dev/mpath/", "^/dev/mapper/", "^/dev/cciss" ]
53c54,55
<
filter = [ "a/.*/" ]
---
>
#filter = [ "a/.*/" ]
>
filter = [ "a|/dev/cciss/c.*|", "a|/dev/mapper/.*$|", "r/.*/" ]
84a87
>
types = [ "device-mapper", 1 ]

Existen dos bugs reportados para Ubuntu 10.04, referidos a este tipo de configuraciones:

Bug con udev: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/578180
Bug initramfs: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/230006

Para evitarlos editaremos el fichero /lib/udev/rules.d/95-multipath.rules , como comentan en el bug y quitaremos el change de la línea ACTION:

#ACTION=="add|change", SUBSYSTEM=="block", RUN+="/sbin/multipath -v0 /dev/%k"
ACTION=="add", SUBSYSTEM=="block", RUN+="/sbin/multipath -v0 /dev/%k"

Luego instalaremos el paquete multipath-tools-boot, para incluir multi- path en el initrd, de forma que cuando se inicie el sistema ya estén disponibles los caminos.

apt-get install multipath-tools-boot

Reiniciar el sistema, para comprobarlo. Al iniciar de nuevo y ejecutar multipath -ll debemos obtener la misma salida que antes de reiniciar. Recordar que debemos regenerar el fichero initrd cada vez que modifiquemos el fichero lvm.conf o multipath.conf, mediante:

update-initramfs -c -k `uname -r`

La imagen la he sacado del album de winkydo en flickr

Gestión de LVM con discos compartidos

Para configurar un cluster Linux con almacenamiento compartido debemos plantearnos si queremos tener acceso concurrente o no a los datos. Para configurar un acceso concurrente necesitamos implantar un sixtema de archivos concurrente como OCFS2 o GFS. Si no necesitamos de acceso concurrente podemos configurar bloqueo de los volúmenes mediante LVM. Para ello, tendremos que editar el fichero /etc/lvm/lvm.conf de los sistemas involucrados y configurar la línea volume_list con el nombre de los volumenes compartidos que no queremos bloquear.

El problema nos aparecerá cuando queramos extender un volumen de los que hemos configurado como bloqueantes. Al ejecutar:

root@nodo1:~# lvcreate -L 50G -n lv_usuarios VG_Usuarios
Aborting. Failed to activate new LV to wipe the start of it.

El sistema nos impide trabajar con normalidad con este volumen. Para poder hacerlo tendremos que activarlo y marcarlo:

root@nodo1:~# lvcreate --addtag @nodo1  \
-L 50G -n lv_usuarios /dev/VG_Usuarios
Logical volume "lv_usuarios" created

Ahora ya podremos formatear nuestro nuevo volumen /dev/VG_Usuarios/lv_usuarios
La imagen la he sacado del album de jpockele en flickr

QEmu

Hace unas semanas apareció un famoso parche de 200 líneas para Linux que permite acelerar notablemente nuestras aplicaciones de escritorio. El gran Jesusda recogió en su bitácora cómo podemos aplicarlo y me animé a probarlo, con tan mala suerte que libvirt me dejó de funcionar y tuve que aprender a manejarme directamente con QEMU.

QEmu es un emulador/virtualizador OpenSource que principalmente uso para ejecutar sistemas Windows sobre Linux. QEmu se comporta como virtualizador cuando ejecutamos sistemas operativos x86 sobre hardware x86 y se comporta como emulador cuando ejecutamos sistemas operativos no x86 (ARM, PPC, etc) sobre hardware x86. Además el rendimiento mejora cuando lo usamos con KVM (Kernel-based Virtual Machine).

KVM es un módulo del kernel de Linux (kvm.ko) y el conjunto de herramientas asociadas para proveer una solución de virtualización completa con Linux sobre hardware x86, dado que aprovecha las extensiones de virtualización de la CPU (vt/svm instructions set), Intel-VT y AMD-V. Al ser un módulo del kernel el hypervisor puede usar el gestión de CPU y memoria propia del Kernel y ser más ligero y sencillo, a diferencia de XEN. KVM no soporta paravirtualización de CPU aunque sí para los drivers de dispositivos mejorando con ello el rendimiento.

Para usar QEmu lo primero que se necesita es una imagen para almacenar los datos persistentes, lo que sería nuestro disco duro :P. Esto lo hacemos con el comando qemu-img y podemos generar dos tipos de imagen:

raw Sin compresión. Puede exportarse a otros formatos.
qcow2 El mejor. Crece conforme se va llenando.

Podemos crear un nuevo fichero de imagen ejecutando:

qemu-img create -f qcow2 windows.img 10G

Para copiar el contenido de un archivo de imagen a otro:

qemu-img convert -f qcow2 original.img \
                -O qcow2 nuevo.img

Para iniciar una nueva máquina virtual montando una ISO y que arranque con 512MB RAM desde el CD-Rom podemos usar:

qemu -enable-kvm  \
    -cdrom MiSistema.iso  \
    -hda discoDuro.img  \
    -m 512 \
    -boot d

Sobre la identidad digital

La era digital en la que vivimos, está propulsada por la intrusión de las Tecnologías de la Información y la Comunicación en nuestras vidas, de forma han supuesto toda una revolución en los patrones de demanda y consumo de empresas y familias, con un impacto directo sobre nuestra economía y sociedad. Este impacto ha cambiado nuestra forma de hacer negocios y nuestra manera de relacionarnos, aunque sigue manteniéndose constante la necesidad de ser identificado, disponer de una identidad para poder hacer negocios, comprar algo o simplemente tener amigos.

En el contexto de Internet, el concepto de identidad es ligeramente distinto del que acabamos de presentar, y podemos diferenciar entre identidad digital e identidad personal, de la que hemos hablado en la sección anterior. La principal diferencia radica en la posibilidad de que un individuo pueda tener diferentes identidades ante una misma entidad, mientras que esto no sucede con la identidad personal: Tu identidad ante una misma entidad es única, aunque no tiene por qué coincidir con la de otras entidades.

Definimos la identidad digital como:

Conjunto de datos que describen de forma única a una entidad y su relación con otras entidades.

Ahora, el concepto de entidad no se limitará a personas físicas, sino podría referirse a personas jurídicas, ficticias o fallecidas, no siendo un requisito la existencia de un cuerpo físico, ni su presencia, ni la necesidad de ser observable, lo cual también es una diferencia con el concepto de identidad personal. Existe una viñeta muy ilustrativa sobre este concepto, en el que se pueden ver dos perros con un ordenador, y como uno le dice a otro: “En Internet nadie sabe que eres un perro”.

El uso de “conjunto de datos” en la definición nos invita a pensar en bases de datos que contienen registros individuales, donde los atributos de estos registros son características representativas de cada individuo. Entre estos atributos, encontraremos dos tipos de atributos:

unos que nos permitirán identificar de manera única un registro de entre todos, y que llamaremos identificadores,
y otros que no nos servirán para identificar el registro, pero sí nos servirán para verificar la identidad, y que llamaremos verificadores.

Quizás en algún momento, usted tuvo una cuenta de correo electrónico. Si reflexiona sobre ello, esta cuenta de correo representa una identidad digital asociada a su identidad personal. Su proveedor le solicitó una serie de datos personales (en los que no quizás no se le obligó a ser sincero), le pidió que introdujera una contraseña (atributo verificador), y finalmente le asignó su dirección de correo electrónico (atributo identificador). Su identidad digital queda completamente identificada mediante su dirección de correo, donde encontrará un identificador único (el nombre de usuario que eligió) y la relación con su proveedor (el @dominio_del_proveedor), que por el identificador (usuario@dominio) sabemos que se trata un proveedor de correo electrónico.

El papel de los atributos verificadores de la identidad es fundamental en la relación entre el proveedor de la identidad y el propietario de la misma, porque nos permite resolver el dilema “¿cómo podemos reconocer a una entidad?”, ¿cómo una entidad puede asegurarse de que otra es quien dice ser?. Ya en los años setenta IBM procuró dar respuesta a este dilema, ofreciendo tres posibles formas de que una entidad reconociera a otra:

Un secreto compartido, algo que se sabe o se recuerda, responder a la pregunta “qué sabes”
Algo que se posee, responder a la pregunta “qué tienes”
Alguna característica física que se tiene, responder a la pregunta “qué eres”

En cualquiera de estos casos, la entidad que debe reconocer a la otra tendrá almacenado un atributo con la respuesta a la pregunta y que actuará como verificador de identidad.

Con el paso del tiempo se ha demostrado que lo más cómodo para los administradores de sistemas es gestionar un secreto compartido (clave, pin, frase, etc) o algo poseído (smartcard, tarjeta rfid, etc), frente a características físicas basadas en tecnologías biométricas, porque ¿cómo resetea un administrador tu huella dactilar?, además de los inconvenientes que suceden con algunos de nuestros rasgos físicos tras sufrir accidentes o simplemente la edad haga mella en nosotros.
El proceso mediante el cual una entidad reconoce la identidad de otra, o dicho de otra forma, verifica su identidad digital, se conoce como autenticación. Este proceso tiene lugar cuando dos entidades tienen que comunicarse y una requiere algún servicio de la otra, de manera análoga, a lo que hacemos a diario para cualquier gestión que requiera nuestro DNI: Primero nos identificamos y luego solicitamos algún servicio a la entidad prestadora.

Gestión de la identidad digital

La proliferación del uso de las Tecnologías de la Información y Comunicación en la sociedad y nuestra economía, han generado toda una eclosión de nuevos servicios y aplicaciones, empezando por nuestro trabajo diario: en nuestras organizaciones ya no basta con disponer de acceso a la red, ahora necesitamos correo electrónico, mensajería instantánea y un sinfín de accesos a las distintas aplicaciones con las que tenemos que interactuar a diario: contabilidad, gestión de personal, documentación, gestión de incidencias, ERP, base de datos, formación continua, ... con el agravante de que para cada uno de estos servicios necesitamos una identidad digital. Cuando la cantidad de identidades digitales y servicios empiezan a tener un volumen considerable, aparece en los administradores de sistemas la necesidad de poder gestionarlos y administrarlas de forma eficiente.

La aparición de esta necesidad viene acompañada del desarrollo de políticas y procesos organizativos encargados de proveer una identidad digital con la que conseguir el acceso a los sistemas de información de nuestra organización. Este conjunto de políticas y procesos conforman lo que llamamos gestión de la identidad digital, o simplemente gestión de la identidad, dado que su mayor aplicación y evolución ha devenido con las TICs. En la mayoría de los casos consistirá en automatizar los procesos de provisión de usuarios y roles, gestión de contraseñas y control de acceso, y encontraremos elementos comunes:

Un metadirectorio que unifique las bases de datos de identidades de diversos tipos y fabricantes en un repositorio único y consolidado, en forma de servicio que acumula información de identidades desde diferentes fuentes de datos a lo largo de la organización, combinando toda o parte de esta información dentro de una visión integrada y unificada.
Single Sign On (SSO), como mecanismo de autenticación que permite a los usuarios registrarse una única vez y acceder a múltiples aplicaciones para las que dispone de autorización.

Solucionar eficientemente la Gestión de la Identidad (digital) ha desarrollado todo un sector de actividad económica dentro del mundo del software empresarial, que representa nuevas oportunidades de negocio para el sector, y engloba soluciones interrelacionadas que generalmente incluyen la gestión centralizada de cuentas de acceso (provisión/desprovisión/sincronización), autenticación (Single Sign On), derechos y restricciones.

Factores de éxito en la gestión de la identidad

El centro del escenario que se acaba de presentar, está ocupado por el servicio final que se ofrece al usuario: Lo importante es poder acceder al servicio como recurso de información, y el esfuerzo se realiza en hacer que esto sea posible en el menor tiempo posible, y de una forma homogénea. Este ha sido el enfoque, que llamamos tradicional, de la gestión de la identidad. Así, el éxito de este tipo de soluciones está condicionado por dos factores principalmente:

La complejidad del sistema en su conjunto, que estará en función de las aplicaciones que se usen para implementarla y, como los usuarios deban interactuar con ellas: Sistemas en los que se deben formar a los usuarios de manera explícita estarán abocados al fracaso. El usuario debe percibir la gestión de su identidad como una ventaja que le facilita la vida, no que se la complica.
La usabilidad de la solución final; si el diseño no tiene en cuenta que debe interactuar con usuarios con distintos grados de formación, y no se orienta a que resulte sencillo para los menos preparados, apenas se usará, y si se les obliga a ello, acabarán usando Posits bajo del teclado y en el lateral del monitor.

A pesar que lo importante sea proveer acceso a los servicios y recursos de información, las políticas y procesos que se desarrollen para la gestión de la identidad, deben ser simples y sencillos, y el software que se use para implantarlos debe ser usable por cualquiera, sin prácticamente ninguna formación previa en la herramienta.

Factores de riesgo en la gestión de la identidad

Saber que existe un sistema, que centraliza nuestros datos personales y nuestras credenciales de acceso a la información, supone en sí mismo una clara amenaza a la seguridad del mismo, y a nuestra privacidad.

La seguridad de un sistema informático consiste en asegurar que los recursos de información sean accedidos de la forma que se decidió que se accedieran, y que su modificación sea realizada por las entidades habilitadas para ello, dentro de su límite de autorización. Comprometer el sistema en el que se centralizan todas las credenciales de acceso, comprometería toda la seguridad informática de la organización, y esta encuentra sus mayores amenazas en las revisadas y actualizadas técnicas de man-in-the-middle, secuestro de sesiones y phising.

Centralizar datos confidenciales como la dirección de correo electrónico, cuentas bancarias, nuestro número de teléfono, cuentas bancarias, el currículum profesional, opciones políticas y religiosas, pone a disposición de cualquiera información que hasta ahora, en el mundo analógico, no había sucedido. La difusión de parte de estos datos, puede suponer un atentado contra nuestro derecho a la privacidad, como ya recogen las legislaciones de la mayoría de países.
El reto más importante a los que debe enfrentarse un sistema de gestión de la identidad es la preservación de la privacidad de los datos confidenciales, de acuerdo con la legislación vigente, y asegurar la seguridad en el acceso a los mismos.

Reputación e identidad digital

La proliferación de los sitios de redes sociales en Internet ha supuesto una eclosión 2.0 de nuevos servicios y aplicaciones en la red, pero en esta ocasión la repercusión ha sido sobre nuestra forma de relacionarnos y no tanto sobre nuestro trabajo diario, si obviamos el hecho de que nos hacen ser menos productivos.

Para poder conseguir acceso a estos nuevos servicios, el usuario de forma voluntaria, cede sus datos aunque no siempre sea consciente de la repercusión que este hecho pueda tener, especialmente por el uso que el proveedor del servicio pueda hacer de su información personal brindándola a terceros. Aunque no exista una retribución económica para poder usar estos servicios, el precio que el usuario debe pagar, es ceder parte de su derecho a la privacidad, lo cual potencia el factor de riesgo de la gestión de nuestra identidad. Este factor de riesgo se potencia aún más con el hecho de que al compartir información no tenemos el control ni la propiedad sobre ella, una veces conscientemente (al verter nuestra opinión en un foro), pero otras ajeno a ello (hacer click en los resultados de google, o al rellenar una encuesta).

Las múltiples identidades digitales que podemos tener en este conglomerado de nuevos servicios, el uso que hacemos de ellas, y la opinión que ello genera, han ampliado el concepto de identidad digital con lo que se conoce como reputación digital, y que se define como:

La imagen que un individuo proyecta en Internet, creada con o sin su propia participación

En este caso no nos referimos a personas humanas como individuos, sino a cualquier entidad con identidad digital, producto, lugar, documento, actividad, aplicación, etc donde ya no es requisito siquiera que exista una identidad digital asociada.
El hecho de que esta imagen sea creada sin nuestra participación, puede tener repercusiones positivas o negativas en nuestra actividad cotidiana, y puede llegar a causar un atentado ya no contra nuestra privacidad sino contra nuestra propia imagen.

Al asociar el concepto de identidad digital y de reputación digital a personas humanas, comprobaremos como el conjunto es análogo al concepto de identidad personal, con el que empezamos este capítulo: la identidad no incluye sólo rasgos físicos que nos diferencian de los demás, sino el cómo nos vemos a nosotros mismos, cómo nos ven los demás y como interactuamos con el resto de la sociedad con el paso del tiempo.

Nuestra identidad en Internet son, el conjunto de datos sobre nosotros mismos que crean y proyectan nuestra propia imagen en la red y nos caracteriza. Ello minimiza las diferencias entre el mundo real y el virtual de Internet; ambos son mundos reales pero ocupan diferentes espacios: inevitablemente se trata de nuestra propia identidad personal en otro escenario, y por ello debemos cuidarla.

La imagen la he sacado del album de César Poyatos en flickr

Qué es la identidad

El diccionario de la Real Academia Española define identidad en una de sus acepciones como:

Conjunto de rasgos propios de un individuo o de una colectividad que los caracterizan frente a los demás

De esta definición reflexionaremos un momento sobre el individuo como persona humana y cómo este se caracteriza del resto, intentando respondernos a unas preguntas simples: ¿cómo diferenciar un individuo del resto? ¿qué hace que dos individuos no sean idénticos? ¿qué me hace a mí diferente del resto?.

La primera pregunta es fácil: Los atributos físicos como el aspecto, el color, la forma, el olor, ... pero pensemos un momento en dos hermanos gemelos, construidos a partir del mismo material genético. En teoría deberían ser idénticos, pero sabemos que con el paso del tiempo no lo serán y que lo que los diferencia no es sólo físico, sino el cómo los vemos con el paso del tiempo. Ahora pensemos en nosotros mismos en la actualidad y hace diez años, obviando los cambios físicos debidos a la edad; ¿somos la misma persona?, ¿qué ha cambiado en mí?. Entre las respuestas quizás encontremos en resumen, que con el transcurrir de los años, no nos vemos de la misma forma y no nos relacionamos con el resto de la sociedad como antaño.

Así, el conjunto de rasgos propios del que habla la definición de RAE, incluirá no sólo rasgos físicos, sino el cómo nos vemos a nosotros mismos, cómo nos ven los demás y como interactuamos con el resto de la sociedad con el paso del tiempo. De todo ello hay características que podemos controlar como nuestros hobbies, preferencias musicales, el domicilio o el estilo de vestir, otras nos vienen asignadas y poco podemos hacer, como el nombre, el número de DNI, el código postal o el número de la seguridad social, y otras tantas, sobre las que no tendremos ningún control, variarán dependiendo de nuestras relaciones sociales y condicionarán cómo nos ven el resto: simpático, aplicado, moroso, cariñoso, etc. Decir que dos individuos son idénticos es un disparate y decir que alguien es idéntico consigo mismo en un momento dado, es como no decir nada, pero habitualmente, cuando hablamos de identidad para referirnos a personas (¿es esa persona que conozco?), tendemos a pensar que el paso del tiempo apenas ha causado efectos en ella: La identidad de una persona está representada por un cuerpo físico pero no está confinada a él.

A partir de estas reflexiones se nos plantea un dilema: ¿cómo podemos reconocer a una persona?, y generalizando ... ¿qué hace que una entidad reconozca a otra entidad?. Sencillamente, la identidad que tenemos retenida de ella: Una serie de atributos memorizados que los diferencian del resto.

Cuando estamos tiempo sin ver a alguien, la reconocemos por una serie de atributos que teníamos memorizados de ella, y que la hacían diferente (incluso de su hermano gemelo si lo tuviera): Aspecto físico, forma de hablar, de moverse, de sonreír, de mirar, su carácter, los recuerdos conjuntos, etc. Es obvio que con el paso del tiempo, la persona no será la misma, pero estos atributos retenidos en nuestra memoria, nos permitirán reconocerla e identificarla.

El estado español puede reconocernos gracias a nuestro Documento Nacional de Identidad (DNI), y esto no es sino una colección de atributos (nombre, dirección, fotografía, firma, padres, sexo, edad, y un número) que permite diferenciarnos a unos de otros; pensar en el DNI de dos hermanos gemelos, donde prácticamente todo es igual excepto el nombre y el número. Igual que sucede con el DNI, sucede con nuestra tarjeta sanitaria, o el carnet de conducir: Son una colección de atributos de nosotros, que las entidades emisoras tienen retenidos y que les ayudan a identificarnos.

Nuestra relación con la sociedad provoca que nos relacionemos con nuevos individuos, de los que no conocemos absolutamente nada. En primera instancia, nuestro instinto animal nos empuja a desconfiar. Está desconfianza inicial se va transformando con el paso del tiempo, conforme vamos conociendo a esa nueva persona; podríamos decir, que vamos identificando el valor de los atributos que nos interesan en nuestra relación con ella, y aprendemos a identificarla. Luego sólo tenemos que reconocerla. Pero también sucede, que esa desconfianza inicial es menor, si nos presenta alguien conocido nuestro, como si parte del proceso de identificación que nos corresponde, lo hubiera hecho ya ese conocido nuestro, e inconscientemente lo hubiéramos delegado. Esto también sucede con el DNI, por poner un ejemplo: la primera vez que nos lo hacemos tenemos que ir acompañados de alguno de nuestros padres, y presentar mucha más documentación que cuando tenemos que renovarlo. Este documento es expedido por la Dirección General de Policía, y representa nuestra identidad ante la misma, sin embargo, con el DNI podemos sacar dinero de nuestras cuentas del banco, sin presentar la documentación bancaria, de forma que el propio banco confía en la identidad que la policía tiene de nosotros.

La imagen la he sacado del album de KatB Photography en flickr

Sobre las redes sociales

Desde los comienzos casi de nuestra civilización el hombre se ha esforzado en crear redes para conectar dos o más puntos separados con algún fin concreto. El tendido eléctrico conecta nuestra casa con la central eléctrica más cercana, que a su vez está conectada con otras y todas de una manera u otra, con una central desde la que se genera la electricidad que enciende nuestras bombillas. De la misma manera, la red de saneamiento conduce las aguas fecales de nuestras casas hasta la depuradora más cercana donde el agua se tratará y limpiará para aprovecharla. La red telefónica es otro ejemplo de red. La red de ferrocarril o la de carreteras es otro ejemplo del esfuerzo del hombre por conectar lugares separados y alejados, con algún objetivo, en este caso facilitar la comunicación y el comercio. Cuando conectamos más de dos lugares con algún motivo solemos referirnos al conjunto como red y le atribuimos como adjetivo el motivo por el que los conectamos: red eléctrica, red telefónica, red comercial, etc.

De la misma manera, las personas no se conectan entre sí pero si interactúan entre sí con un motivo común: trabajo, negocios, ser compañeros de curso, amor, aficiones, gustos musicales… y cuando interactúan entre ellos hablamos de relaciones personales en vez de hablar de conexiones.

Fue Aristóteles quien dijo que “el hombre es un ser social por naturaleza, inmerso en la sociedad desde que nace hasta que muere”. Históricamente, los grupos de personas que compartían un tipo de motivo para relacionarse se agrupaban y se llamaban colectivos o comunidades: Comunidades de vecinos, colectivos sindicales, comunidad hispana, colectivo y gays y lesbianas, etc. Desde los comienzos de nuestra civilización han existido estas comunidades que periódicamente se reunían para intercambiar impresiones, opiniones, actuar, reivindicar o debatir, fomentando así esa relación que los unía. El hecho de reunirse varias personas que comparten algo con el objetivo simplemente de relacionarse siempre lo hemos llamado acto social. Cuando los motivos por los que se relacionan estos grupos de personas, tienen manifestaciones artísticas y provocan cambios de comportamiento empezamos a hablar de cultura: cultura griega, cultura gótica, cultura afroamericana, cultura geek, … y cuando este colectivo se hace muy, muy grande, surge la necesidad de regular su funcionamiento interno con normas y leyes que ayuden a integrarse en esa comunidad. Se habla entonces de sociedades.

Internet ha revolucionado la manera en la que las personas se relacionan: Antes sólo podíamos relacionarnos con la gente que vivía cerca de nosotros o que conocíamos durante nuestros viajes. Mantener la relación y el contacto obligaba a desplazarse o a esperar días o semanas hasta que las cartas llegaran a su destino. Internet es la mayor red de comunicaciones de la Tierra que permite poner en contacto a dos personas en cualquier parte de la Tierra en décimas de segundo. Esta facilidad para la comunicación ha cambiado completamente nuestra forma de comunicarnos: Ya no hay que esperar ni viajar, podemos relacionarnos con cualquier persona del planeta, como si fuera nuestro vecino de la puerta de al lado.
Esto ha permitido que los colectivos o comunidades como las conocíamos antes, aparezcan y evolucionen mucho más rápido, simplemente porque es mucho más fácil comunicarse y el número de candidatos es casi el número de habitantes del planeta. Hace unos años encontrar seguidores de música funk en tu localidad era muy difícil, y si no te gustaba el mismo tipo de música que a la mayoría de personas con las que te relacionabas podías ser motivo de exclusión y rechazo. Hoy día con Internet es mucho más fácil encontrar gente con tus mismos gustos musicales y así poder evolucionar en el plano personal porque, a fin de cuentas, las relaciones personales sólo sirven para evolucionar como personas. Pertenecer a un grupo social, un colectivo o una comunidad, permiten al anónimo popularidad, al discriminado integración, al diferente igualdad, al malhumorado educación y así muchas cosas más. La fuerza del grupo permite sobre el individuo cambios que de otra manera podrían ser difíciles y genera nuevos vínculos afectivos. Quizás ya podamos hacernos una idea un poco más concreta sobre qué es una red social: Una red social es un grupo de personas conectadas por una o más tipos de relaciones, tales como amistad, creencias, conocimientos o intereses comunes …y han existido desde mucho antes de que existiera Internet.

Internet hace posible las relaciones entre ese grupo de personas igual que las hace el tren, una carta, una revista, la televisión o un programa de radio, pero de diferente manera: La comunicación ahora es instantánea y multidireccional, no de uno a uno, o de uno a muchos.
Desde principios de la década (allá por el año 2001), han comenzado a surgir nuevas herramientas en Internet que hacen mucho más fácil la comunicación de estos colectivos, orientándose principalmente en hacer posible y fomentar las relaciones entre personas y su comunicación. De la misma forma que crecían el número de estas herramientas, surgía la especialización entre ellas, y comenzaban a distinguirse unas de otras, orientándose a un tipo de relaciones concreto: amistad, trabajo, fotografía, vídeo, etc. El conjunto de estas herramientas o aplicaciones se conocen como social media o medios sociales , y no dejan de ser las herramientas que ayudan a la comunicación de las redes sociales a través de Internet. Entre ellas encontramos:

Círculo de amigos
- Facebook (http://www.facebook.com). La más famosa y comercial
- Tuenti (http://www.tuenti.com). En español, destinada a adolescentes.
Círculo profesional
- Linkedin (http://www.linkedin.com). La más famosa y comercial
- Xing (http://www.XING.com). En español.
Encuentros y contacto
- Meetic (http://www.meetic.com). La más famosa y comercial
- Badoo (http://badoo.com). ERelaciones esporádicas.

Estas herramientas están íntegramente orientadas a fomentar este tipo de relaciones, pero se suelen apoyar en otras herramientas que nacieron al mismo tiempo, que si bien no fomentan las relaciones, sí que sirven de vehículo para la comunicación entre los miembros de las redes sociales:

Youtube (http://www.youtube.com) Permite subir nuestro vídeos
Gmail (https://mail.google.com) y Hotmail (http://hotmail.com). Permite el intercambio de correos electrónicos y la mensajería instantánea (chat)
Twitter (http://twitter.com) Permite la publicación de mensajes cortos.
Flickr (http://www.flickr.com) y Orkut (http://www.orkut.com). Permite publicar nuestras fotografías.
BlogSpot (http://www.blogspot.com) y Wordpress (http://es.wordpress.com). Permite tener blogs que son una especie de portal de noticias o editoriales

¿De qué nos sirve tener teléfono móvil si no tenemos amigos a quien llamar?. Estas herramientas de la social media (YouTube, Gmail, Twitter, etc) hacen posible la comunicación igual que la hace posible el teléfono móvil. Con las herramientas orientadas a las redes sociales (facebook, tuenti, Linkedin, etc), podemos hacer nuevos amigos con quien contactar y relacionarlos usando diferentes formas: chat, correo electrónico, blogs, etc.

La imagen la he sacado del album de 10ch en flickr

Clusters Java con Terracota

Terracotta es un software Open Source de clusterización para aplicaciones Java, compuesto de dos partes:

Un servidor responsable de la administración y de distribuir la información entre los clientes
y el propio cliente que publica y recibe información hacia/desde el servidor de terracotta

El servidor se encarga de replicar las instancias de clase entre los miembros del cluster a través del cliente. Para ello, nuestra aplicación debe estar programada a consciencia, y declarar qué clases deben propagarse en un fichero de configuración especial del cluster. La particularidad de este cluster reside en la posibilidad de replicar instancias de JVM y mantenerlas sincronizadas.
Para dotar a nuestras aplicaciones de alta disponibilidad configuraremos el servidor de terracotta en todos los nodos. Compartirán la misma configuración y sabrán cómo conectar al resto de nodos que ejecutan la aplicación Java que queremos clusterizar. Inicialmente se elegirá automáticamente cuál de los nodos se erige como maestro, mediante un algoritmo distribuido propio, dejando el resto de servidores terracotta en modo pasivo. Cuando el maestro de terracotta caiga, otro asumirá el rol de maestro. El problema viene cuando todos los nodos se inicien a la vez, dado que el algoritmo puede tardar en decidir quien se erige como maestro. Esta situación se considerará una situación de desastre y requerirá la intervención de un administrador que inicie primero una de los servidores, y cuando esté arriba, poco a poco iniciar el resto de servidores para que se unan al cluster. Echadle un ojo a este tutorial si quereis empezar a probarlo.

La imagen la he sacado del album de luispabon en flickr

El efecto 2038

Ya queda un poco lejano el efecto 2000, pero afortunadamente para nuestras espectativas de trabajo se acerca el efecto 2038. Este futuro efecto está causado por la longitud del espacio reservado para almacenar timestamps en POSIX (time_t es un entero de 32 bits con signo) que cuenta el número de segundos transcurridos desde el 1/Ene/1970 a las 00:00:00 y alcanza su valor máximo (19/Ene/2038 a las 03:14:07), comenzando de nuevo la cuenta por el 1/Ene/1970. En arquitecturas de 64bits, time_t usa un entero con signo, pero de 64bits, que aplaza el problema durante unos cuantos millones de años, y claro, si el estándar POSIX ha funcionado bien durante todos estos años, tampoco íbamos a modificarlo para corregir este inconveniente, y por supuesto, tampoco es necesario montar sistemas que sabemos en el año 2038 tendrán problemas con la hora: Es deseable que los administradores Unix comencemos a migrar nuestros sistemas de 32 a 64 bits, por el llamado efecto 2038.
Una vez se dispone de una plataforma 64bits, es deseable usar una ver- sión Java de 64bits. La versión de 32bits de Java en Linux, tiene la gran limitación de permitir asignar hasta 3GB de RAM para la máquina virtual, y de ellos, sólo podremos darle a nuestra aplicación 2GB, porque el restante lo necesita la Runtime de Java para alojar el recolector de basura, heap, PermGen, etc. Esto que parece mucho, en realidad conforme van subiendo las conexiones a nuestro servidor se convierte en un inconveniente, porque la única forma que tenemos de mejorar el tiempo de respuesta y la cantidad de threads es aumentando la asignación de memoria RAM a la máquina virtual. Las distintas librerías y frameworks que actualmente necesitan las aplicaciones Java hacen que 2GB de RAM sea poco a largo plazo, y claro, no está recomendado si vamos a poner en marcha un sistema con la previsión de que esté funcionando después del año 2038.

La imagen la he sacado del album de simpologist en flickr

MultiPath para una cabina HP MSA

Si queremos configurar una cabina SAN HP MSA con Device Mapper Multipath sobre un sistema Debian, Ubuntu o Gentoo, podremos usar el siguiente fichero de configuración /etc/multipath.conf

blacklist {
   devnode "^cciss!c[0-9]d[0-9]*(p[0-9]*)?"
}
defaults {
   user_friendly_names yes
}
devices {
   device {
      vendor  "HP*"
      product  "MSA2312fc"
      getuid_callout "/lib/udev/scsi_id -g -u  -s /block/%n"
      hardware_handler "0"
      path_selector "round-robin 0"
      prio  alua
      #path_checker alua
      #prio_callout     "/sbin/mpath_prio_alua /dev/%n"
      path_grouping_policy group_by_prio
      failback  immediate
      rr_weight  uniform
      no_path_retry 18
      rr_min_io  100
      path_checker tur
   }
}
multipaths {
   multipath {
      wwid                   3600c0ff000da437942ece24c01000000 
      alias                  LUN1_MSA
   }
   multipath {
      wwid                   3600c0ff000da44502b1aec4c01000000
      alias                  LUN2_MSA
   }
}

Apache: Reescribir todo HTTP a HTTPS

A menudo ponemos en marcha VirtualHosts en nuestro servidor Apache, que más tarde decidimos securizar con HTTPS por cualquier razón, aunque las más habituales son la recomendación de nuestro auditor de seguridad, o la configuración de servicios autenticados con Login y Password. Esto siempre sucede después de haber publicitado la URL de nuestro servicio, y ya no tenemos control de qué URLs y bookmarks apuntan a nuestro servidor. Si se decide cerrar el puerto HTTP en nuestro servidor, los usuarios que accedan al servicio se encontrarán un error 404 y pensarán que la página ya no existe. Quizás sea más práctico configurar nuestro servidor para que reescriba todas las URLs en HTTP a HTTPS con mod_rewrite mediante el siguiente bloque:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

PhPKI

Casi todas las organizaciones tienen la necesidad de gestionar sus propios certificados autofirmados para implantar servicios OpenSSL. Hasta ahora siempre había recomendado usar los servicios de Certificación de Windows, por la comodidad que ofrecían: Una pequeña aplicación Web, desde la cual cualquiera puede solicitar un certificado de servidor, de cliente, VPN, etc. Además nos mantiene una pequeña base de datos con los certificados emitidos, y desde la interfaz web podemos renovarlos, volver a descargarlos y revocarlos.

Hacer esto mismo con OpenSSL delante de una consola Linux, no resulta tan intuitivo para nada, y por eso siempre he recomendado usar Windows para esta labor. Con OpenSSL siempre terminamos buscando en Internet cómo solicitar un nuevo certificado, que nunca es la misma página que usamos para configurar nuestra primera CA, y desgraciadamente acabamos configurando una nueva CA con un nuevo certificado raíz, que tendremos que volver a distribuir entre los clientes.

No hace mucho, encontré una pequeña aplicación Web OpenSource llamada PhPKI que nos permite olvidarnos de OpenSSL en la consola Linux, y hacer lo mismo pero desde la ventana de nuestro navegador. Esta aplicación simplemente es un Wrapper sobre OpenSSL y se instala con sólo descomprimir el TGZ en el directorio de nuestro servidor Web. La infraestrucutra PKI de nuestra entidad de certificación se mantiene en un directorio separado de la Web y toda la aplicación se configura mediente un fichero config.php. El código PHP es muy sencillito y se puede retocar y acondicionar muy facilmente. Ahora recomiendo usar esta herramienta :).

La imagen la he sacado del album de thierry en flickr

Optimizar las conexiones a MySQL

Si monitorizamos nuestro servidor MySQL recién instalado, podemos comprobar con el paso de las horas cómo se van amontonando conexiones en estado "Sleep" durante horas. Si nuestro servidor de base de datos empieza a recibir muchas conexiones será cuestión de tiempo que empiece a denegarlas.
El problema de que las conexiones quedén ahí sin cerrar los encontramos en la configuración de nuestros Apaches y en el propio MySQL.

En nuestros Apaches debemos revisar /etc/php.ini para configurar las conexiones persistentes a MySQL
```
mysql.allow_persistent = Off
mysql.max_persistent = 20
```
De esta forma le decimos a Apache que no se quede ahí con conexiones persistentes: Conecte y cierre.
En MySQL editar /etc/mysql/my.cnf y en la sección de [mysqld] añadir
```
wait_timeout = 60
```
El valor por defecto es 1 dia (expresado en segundos), y es el tiempo que tarda MySQL en matar sesiones, esperando a que se cierren. Tendremos que reiniciar el servicio para que se apliquen los cambios.

Para consultar el valor de las variables de TimeOut de nuestro MySQL debemos entrar en la consola mysql y ejecutar:

show global variables like '%time%';

Para fijar un valor en caliente:

set global wait_timeout=30;

La imagen la he sacado del album de mjsonline en flickr

Mirrors de Ubuntu

Durante este año he comprobado cómo cada vez más, Ubuntu Server es un estupendo candidato para instalar en servidores. La gran ventaja que nos ofrece es poder disponer de versiones de paquetes mucho más modernas que las que encontramos en RedHat Enterprise Linux (Oracle Unbreakable Linux, CentOs) o en Debian, y disponer de actualizaciones de seguridad gratuitas. También supone una ventaja el uso de paquetes DEB fáciles de recompilar para personalizar las opciones que necesitemos.
El uso de Debian o Ubuntu en servidores, nos obliga a disponer de conexión hacia de Internet para poder acceder a los reposiotorios de paquetes DEB. Esto no siempre es posible dependiendo de la topología de la red, y quizás nos convenga disponer de nuestro propio repositorio local de paquetes si queremos evitar permitir la conexión hacia Internet.
Para configurarlo realizaremos los siguientes pasos:

Instalar el paquete debmirror y apache2:
```
apt-get install debmirror apache2 rsync
```
Crear los directorios donde dejaremos nuestra réplica
```
mkdir /var/www/mirror/ubuntu/
```

Crear nuestro propio script para realizar la sincronización en /var/www/mirror/mirror-ubuntu.sh con el siguiente contenido:

#!/bin/bash
#

if [ "$1" = "" ]
then
 echo "ERROR: Debes pasar el nombre de la distribucion (ej: karmic,lucid...)" >&2
 exit 2
fi

# Mirror de 32bits
debmirror --ignore-release-gpg  -a i386 \
 -s main,restricted,universe,multiverse \
 -h cc.archive.ubuntu.com \
 -d $1,$1-security,$1-updates,$1-proposed,$1-backports \
 -r /ubuntu --progress -e http /var/www/mirror/ubuntu

# Mirror de 64bits
debmirror --ignore-release-gpg  -a amb64 \
 -s main,restricted,universe,multiverse \
 -h cc.archive.ubuntu.com \
 -d $1,$1-security,$1-updates,$1-proposed,$1-backports \
 -r /ubuntu --progress -e http /var/www/mirror/ubuntu

El script recibirá como argumento el nombre de la distribución: lucid, karmic, etc.

Preparar nuestro anillo de claves PGP, mediante:

apt-key exportall \
| gpg --no-default-keyring --keyring trustedkeys.gpg --import

Lanzar la sincronización y descarga de paquetes a nuestro directorio local:
```
cd /var/www/mirror
nohup bash mirror-ubuntu.sh karmic &
```

Una vez se hayan descargado todos los paquetes de la distribución de la que queremos mantener la réplica, configuraremos nuestros clientes apt, editando el fichero /etc/apt/sources.list y modificando la ruta del repositorio de paquetes:

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic main restricted
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic main restricted

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic multiverse
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic multiverse

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic universe
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic universe

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-updates main restricted
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-updates main restricted

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-updates multiverse
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-updates multiverse

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-updates universe
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-updates universe

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-security main restricted
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-security main restricted

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-security multiverse
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-security multiverse

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-security universe
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-security universe

Sería conveniente que ejecutemos periódicamente el script para mantener sincronizada nuestra réplica local.

La imagen la he sacado del album de Tobyotter en flickr

tecnoquia