tecnoquia

Inicializando un directorio OpenLDAP 2.4

Uno de los cambios que trae FedoraCore 12 es OpenLDAP 2.4. Esta versión trae entre otros cambios, la obligatoriedad de usar el backend de configuración dinámica. Los que estábamos acostumbrados a usar toda la configuración de nuestros servidores OpenLDAP en /etc/openldap/slapd.conf, este cambio nos pilla un poco desprevenidos. Por suerte la gente de OpenLDAP había contemplado esto y nos facilita la migración.
Si queremos migrar una configuración de OpenLDAP anterior a 2.4, a esta nueva versión, podemos seguir la siguiente secuencia de pasos:

Hacer un backup de la configuración por defecto que trae el nuevo servicio 2.4
```
mv /etc/openldap /etc/openldap_original_2.4
```
Copiar la configuración del OpenLDAP anterior a /etc/openldap.
Migrar la configuración del antiguo servicio a la versión 2.4, en un directorio temporal:
```
mkdir /tmp/export
slaptest -f /etc/openldap/slapd.conf -F /tmp/export/
```

Instalar la nueva configuración

mkdir -m 700 /etc/openldap/slapd.d
cp -R /tmp/export/* /etc/openldap/slapd.d/

Editar el fichero cn=config para editar /etc/openldap/slapd.d
Fijar el login y contraseña del usuario que podrá modificar dinámicamente la configuración. Para ello, editar el fichero /etc/openldap/slapd.d/cn\=config/olcDatabase\=\{0\}config.ldif para añadir las siguientes líneas:
```
olcRootDN: cn=admin,cn=config
olcRootPW: {SSHA}pT8zKlqhV8dieALrkzwAiK8KdoxNV5m
```
La contraseña encriptada la podemos obtener ejecutando el comando slappasswd.

Copiar la configuración del monitor de OpenLDAP, de la configuración original que habíamos movido.

export FILE=/etc/openldap_original_2.4/slapd.d

cp $FILE/cn=config/olcDatabase\=\{2\}monitor.ldif \
/etc/openldap/slapd.d/cn=config/

Hacer copia de seguridad del directorio de la base de datos del directorio y preparar el directorio para inicializar el nuevo directorio:
```
mv /var/lib/ldap /var/lib/ldap_original
mkdir -m 700 /var/lib/ldap
cp /var/lib/ldap_original/DB_CONFIG  /var/lib/ldap/
```
A partir de un backup del antiguo servidor (hecha con slapcat por ejemplo), preparar un fichero ldif básico con donde se cree la raíz del directorio, y las ramas princiaples. Lo añadiremos con el comando slapadd:
```
slapadd -l /tmp/estructura_inicial.ldif 
```
Cambiar los permisos de la base de datos del LDAP, y del directorio de configuración e iniciar el demonio de LDAP, mediante los siguientes comandos:
```
chown -R ldap.ldap /var/lib/ldap /etc/openldap
/etc/init.d/slapd start
```

Restaurar la copia de seguridad en el directorio que acabamos de crear...

ldapadd -x -D "cn=admin,ou=XXX,o=carm,c=es" -w CLAVE \
     -f copia_seguridad.ldif

Recuperar la base de datos del directorio y reparar

/etc/init.d/slapd stop

slapindex
slapd_db_recover -h /var/lib/ldap
slapindex

chown ldap.ldap -R /var/lib/ldap
/etc/init.d/slapd start

Y ya tendremos nuestro directorio funcionado. :)

La imagen la he sacado del album de JPhilipson en flickr

OCS Inventory NG

Open Computer and Software Inventory Next Generation (OCS) es un programa de software libre que permite a los usuarios administrar el inventario de sus activos de TI. OCS-NG recopila información sobre el hardware y software de equipos que hay en la red que ejecutan el programa cliente de OCS (agente OCS).
OCS proporciona una interfaz web para poder visualizar el inventario, y realizar consultas sobre este inventario. Además incluye otras opciones extra como poder descubrir nuevos elementos en la red e inventariar, aunque no dispongan de agente e instalar aplicaciones remotamente a los equipos que ejecutan el agente de OCS.
Así los elementos que componen un despliegue de OCS Inventory serían los siguientes:

Servidor de base de datos MySQL, que será el servidor donde se almacenen todos los datos que se recopilen del inventario
Servidor de comunicación de OCS que es el servidor con el que conectan los agentes de OCS (equipos clientes a inventariar de nuestra red), para enviar el inventario: este servidor recoge estos datos y los lleva a la base de datos. Esta comunicación se realiza en XML por el protocolo HTTP, por lo que el servidor de comunicación no es otra cosa que un servidor Web (Apache) con una serie de scripts escritas en PERL que implementan unos métodos para posibilitar una comunicación XML y escribir en MySQL.
Clientes de OCS o agentes, son los programas instalados en los equipos que queremos mantener inventariados que periódicamente conectan con el servidor de comunicación y envían en XML el inventario del máquina donde están instalados. Existe clientes para multitud de sistemas operativos: Windows, Linux, Mac OsX, Sun Solaris, IBM AIX
Consola de administración de OCS, es una aplicación Web desde donde el administrador podrá consultar el inventario, lanzar búsquedas, borrar equipos, ver los dispositivos descubiertos, etc. Normalmente la consola de administración se suele instalar junto con un servidor de comunicación, y son un conjunto de scripts en PHP que conec- tan a MySQL y muestran la información almacenada en la base de datos MySQL.
El servidor de distribución es una pequeña aplicación web desde la cual podremos distribuir paquetes, y software a los equipos que tengan instala- do el cliente de OCS, vía HTTPS. Para ello, se necesita que los clientes reconozcan el certificado del servidor de distribución.

En algunos despliegues se suele hablar del servidor de administración de OCS: Este servidor es un tipo de despliegue especial que incluye en el mismo servidor el servidor de base de datos, el servidor de comunicación, el servidor de distribución y la consola de administración.

El descubrimiento de la red lo realizan los propios clientes OCS en función de la actividad del agente y su disponibilidad: Esta decisión la toma el propio servidor de comunicación, quien de forma periódica ordena descubrimientos de red a un conjunto de agentes. Los equipos resultantes de este descubrimiento quedan almacenados de forma especial en el inventario, a la espera de que un administrador los identifique apropiadamente y los asigne.

En la siguiente figura se presenta un esquema completo de la arquitectura de un despliegue de OCS, que en redes modestas y homogéneas no suelen separarse los elementos de la arquitectura y podemos encontrar todos los elementos en un único servidor llamado servidor de administración de OCS.

Crear paquetes .DEB con Alien

¿Cómo podemos crear un paquete .DEB para Debian en 3 minutos?: Respuesta con el paquete alien.

Primero instalamos alien:
```
apt-get install alien
```

Luego nos creamos un directorio temporal, y en el reproducimos la estructura de directorios con los archivos que queremos instalar:

mkdir /tmp/MINI_DIRECTORIO_RAIZ

mkdir -p /tmp/MINI_DIRECTORIO_RAIZ/etc/logrotate.d \
     /tmp/MINI_DIRECTORIO_RAIZ/usr/local/bin \
     /tmp/MINI_DIRECTORIO_RAIZ/usr/lib \
     /tmp/MINI_DIRECTORIO_RAIZ/var/log/mis_logs \

Después copiamos en la estructura de directorios que hemos creado, los ficheros que queremos se instalen tal cual quedarán en el sistema una vez instalados (permisos, propietario, etc)

Creamos el paquete .deb

cd /tmp/MINI_DIRECTORIO_RAIZ

alien mipaquete-0.1.tar.gz

No es que el método sea muy elegante (no creamos usuarios, no hay comprobaciones previas, dependencias, etc), pero sí que es rápido si queremos instalar limpiamente nuestros archivos, y después poder eliminarlos tranquilamente con dpkg, que siempre será mejor que hacerlo un tar o una copia manual.

La foto la he sacado del album de jurvetson en flickr.

Squid como proxy transparente

Algunas veces necesitamos configurar un servidor proxy en modo transparente para monitorizar a qué URLs acceden los usuarios de nuestra red. Con Squid, el proxy por excelencia en el mundo del software libre es muy fácil: Sólo tenemos que aplicar las siguientes reglas en nuestro router.



# Redirigir el tráfico hacia SQUID
iptables -t nat -A PREROUTING  -i INTERFAZ_CLIENTES \
        -p tcp --dport 80 -j REDIRECT --to-port 3128

# Deshacer el NAT
iptables -t nat -A POSTROUTING -o INTERFAZ_SALIDA  \
        -s RED_ORIGEN -j MASQUERADE

La foto la he sacado del album de xtopher42 en flickr.

OpenVPN en Debian

OpenVPN es una aplicación de software libre que nos permite crear VPNs (Virtual Private Networks) para poder conectarnos remotamente a otra red local de una manera segura utilizando túneles SSL/TLS. Para usar el cliente en Debian deberemos seguir los siguientes pasos:

Conectar a nuestro servidor OpenVPN y generar el certificado para el cliente VPN
```
cd /etc/openvpn/easy-rsa
. ./vars
./build-key mi_cliente_IP
```
donde mi_cliente_IP es el hostname del cliente que generaré y su IP. Esto lo hago para que luego me sea fácil recordar a quien asigné los certificados.
El script nos mostrará un asistente donde nos hará una serie de preguntas. Debemos responder a todas con Enter (opción que propone por defecto) excepto en la pregunta "Common Name", que responderemos con el nombre del cliente (valor de hostname). Cuando pregunte si queremos emitir el certificado, responder con y (yes). Con esto ya habremos generado el certificado de usuario para nuestro cliente Debian.Una vez generados, nos tendremos que llevar los ficheros /etc/openvpn/keys/mi_cliente_IP.crt y /etc/openvpn/keys/mi_cliente_IP.key al directorio /etc/openvpn/keys/ de nuestro cliente Debian como cliente.crt y cliente.key respectivamente, el fichero /etc/openvpn/keys/ca.crt que hay en nuestro servidor OpenVPN.
Ahora tendremos que generar el fichero con la dirección IP (10.8.XX.YY/30) del túnel que se le dará al cliente cuando conecte (usaremos tun0). Estas Ips deben ser únicas, y se calculan por subneting de 4 Ips: Una de red, otra de broadcast, otra para el cliente y la otra para el extremo del túnel (el servidor OpenVPN). Para ello deberíamos ver cuál ha sido la última subred dada (ordenar por fechas) en el directorio /etc/openvpn/ccd/. Luego crear el fichero /etc/openvpn/ccd/mi_cliente (cambiando el nombre del fichero, por el hostname del equipo, lo mismo que pusimos en Common Name, al emitir el certificado) y escribir el contenido similar al siguiente, donde cambiaremos las direcciones IP, en función de la última que se configuró:
```
# Redes VPN:
#   10.8.0.36 -> IP RED
#   10.8.0.37 -> IP Equipo Cliente
#   10.8.0.38 -> IP Tunel
#   10.8.0.39 -> IP BROADCAST
# http://openvpn.net/index.php/documentation/howto.html#policy
ifconfig-push 10.8.0.37 10.8.0.38
```
Ahora conectarnos a nuestro cliente Debian y ejecutar:
```
apt-get -y install openvpn liblzo2-2 lzop openssl
```
Configurar en el cliente el tunel:
```
modprobe tun
echo tun >> /etc/modules
```

Crear el fichero /etc/openvpn/client.conf con el siguiente contenido:

dev tun
proto tcp-client
remote IP_SERVIDOR_OPENVPN  PUERTO
resolv-retry infinite
nobind
pull
persist-key
persist-tun
ca   /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/cliente.crt
key  /etc/openvpn/keys/cliente.key
comp-lzo
verb 3

Crear el directorio /etc/openvpn/keys/
```
mkdir -m 755 /etc/openvpn/keys
```
Copiar en el directorio /etc/openvpn/keys/ los ficheros de claves que generamos del servidor OpenVPN.
Reiniciar el servicio OpenVPN
```
/etc/init.d/openvpn restart
```

La foto la he sacado del album de la nave de los locos en flickr.

NSIS: Instalador de aplicaciones en Windows

Hace unas semanas necesité desplegar un programa entre las estaciones de trabajo Windows de una red, en un entorno hostil: Sin dominio y en consecuencia sin políticas, sin script de logon en las estaciones, sin saber el nivel de conocimientos del usuario, sin saber si el usuario sería administrador local con permisos para poder instalar ... sin nada: Mis probabilidades de éxito eran muuuy escasas. A pesar de ello, me las apañé para solucionar el inconveniente de no tener un punto de entrada común y centralizado, con ayuda de Squid en modo transparente, bloqueando el acceso a Internet a aquellas estaciones que no hubieran ejecutado el programa que me interesaba tuvieran instalado. Así, el problema se reducía a tener en éxito en la instalación de ese programa.

Este programa debía modificar claves del registro de Windows en HKLM, instalar a su vez otro programa con ciertos argumentos y copiar algunos archivos a determinados directorios. Necesitaba tener permisos como Administrador, para poder hacerlo.

En otro tiempo y etapa de mi vida administré servidores Windows. Recuerdo que por aquel entonces usábamos editores de ficheros .MSI para distribuir aplicaciones y configuraciones. Aquello siempre fue un infierno: sólo funcionaban bien los .MSI de Microsoft, y si se quería hacer algo que medio funcionara lo mejor era ver en los foros de Windows, cómo la gente distribuía y empaquetaba la aplicación que estaba intentando preparar. Tengo un recuerdo malo de mi experiencia con .MSI, y quizás no hubiera podido hacer lo que yo necesitaba hacer en esta ocasión. También recuerdo que usaba una herramienta llamada InstallRite, que era capaz de realizar SnapShots antes y después de una instalación, y generar un ejecutable .EXE con los cambios. Aquella herramienta funcionaba muy bien con Windows 9X, pero con XP se colgaba muy a menudo, y había que dedicar mucho tiempo a la edición de los cambios, para evitar distribuir la renovación de IP en el DHCP y, otras cosas que ocurrían en el sistema mientras se instalaba la aplicación, y que por supuesto las diferencias entre los Snapshots capturaban. También llegué a usar las herramientas de distribución de software que traen los IDEs de desarrollo como Delphi o VisualBasic, pero al final requerían tener determinadas DLLs instaladas en el sistema, y aquello terminaba convirtiéndose en el pez que se muerde la cola :(.

Para este proyecto volví a repasar las soluciones que tenía disponibles y encontré NSIS: NSIS viene de Nullsoft Scriptable Install System (¿recordais la instalación de WinAmp?) y es una herramienta OpenSource para crear instaladores de aplicaciones mediante scripts, con un lenguaje de programación propio. Es lo que necesitaba, y con ella tuve éxito en mi labor. Destacaría de ella:

Usa un script para describir la secuencia de pasos que debe seguir el proceso de instalación, con un lenguaje propio a caballo entre un Basic primitivo, las macros del preprocesador de C, y ensamblador. Esto es una ventaja, porque podemos reutilizar nuestra experiencia y los scripts de instalación, además de que podemos establecer una lógica en el proceso de instalación: Si el tiene tal cosa en el registro haz tal otra, si no es administrador haz tal cosa, etc
Existe una comunidad muy amplia de usuarios, que suben sus scripts y te pueden inspirar en tu labor. Hay muchas referencias en Google, y casi seguro encontrarás ayuda para lo que quieras hacer.
Permite la inclusión plugins para ampliar funcionalidades, una de ellas es la RunAS (como el sudo de Linux, pero para Windows).
Permite personalizar completamente toda la interfaz de usuario durante el proceso de instalación.

Es una gran y robusta herramienta a tener en cuenta: Yo tardé dos tardes escasas de no tener nada y conocer la herramienta, a tener mi problema resuelto con su correspondiente instalador.

Si quereis empezar con ella, echarle un vistazo a estos dos tutoriales: Adictos al trabajo: Realizar Instaladores de forma sencilla con NSIS 2.0 y Crear instalaciones con NSIS

Leer ficheros en Bash

A menudo necesitamos leer ficheros en medio de nuestros scripts Bash, para procesar su contenido. Muchas veces nos basta con usar las comillas francesas y el comando cat dentro de un bucle, algo similar a:

for VBLE in `cat FICHERO`
do
# Hacer algo con $VBLE
done

El problema aparece cuando el fichero es muy grande, y el contenido supera el buffer que Bash destina a la línea de argumentos de los comandos (espacio reservado para el argv de la función Main en C, por simplificar mucho). Otras veces tropezamos con esta limitación al usar comodines en los comandos como ls, chmod, rm, etc, dentro de directorios que tienen muuchos archivos, a lo que el intérprete de comandos nos responde con un mensaje que nos viene a decir que la línea de argumentos es demasiado larga :P. En estos casos podemos salir con el uso del comando find y el argumento -exec, pero cuando trabajamos con el contenido de ficheros, esta solución no nos sirve :(.
Por suerte el intérprete Bash contempla esta posibilidad y nos proporciona de comandos específicos para poder procesar archivos de forma secuencial, como siempre hemos hecho. El esquema es el siguiente:

# Abrir el fichero para lectura
# El 8 representa el numero de descriptor asociado al fichero
exec 8< FICHERO

# Bucle para leer todo el contenido
# Cada iteración lee una línea del fichero y la deja en VBLE
while read -u 8 VBLE
do
# Hacer algo con $VBLE
done

# Cerrar el fichero
exec 8<&-

Resulta muy útil.

La foto la he sacado del album de jazzmasterson en flickr.