Utilizo slapd para dar un servicio de directorio, la clásica agenda de contactos con email, teléfono y demás. Hace algunos años, cansado de tener que pasar de una a otra herramienta de gestión de contactos, según cambiaba de programa de correo (de mutt a pine; de pine a evolution; de evolution a thunderbird), decidí quedarme en el punto intermedio de todos ellos y, tras investigar un poco, éste resultó ser OpenLDAP.
Crear una estructura de directorio es sencillo (forat, cúrrate un howto 
) y muy útil. Como, además, el servicio lastra muy poco el equipo donde está alojado, puede funcionar en máquinas no muy potentes, como es mi caso. A cambio, dispondremos de una agenda de contactos rápida, accesible desde la mayoría de clientes de correo (incluso Outlook Express) y fácil de gestionar y mantener. En mi caso era así, hasta hoy.
Hay ciertos servicios que, una vez los pones a funcionar, dejas de pensar en ellos y únicamente los utilizas, los conviertes en rutina. Por eso, cuando fallan (porque nada es infalible), la sensación de estupor es grande y no sabes por dónde empezar la batalla.
Hace dos días, slapd decidió no arrancar más tras una actualización del equipo. El error que aparecía en syslog era bastante feo, llegando a mencionar el sacrosanto backup, toda una osadía, en mi opinión.
slapd[18614]: backend_startup_one: starting "dc=midominio,dc=net"
slapd[18614]: bdb_db_open: database "dc=midominio,dc=net": dbenv_open(/var/lib/ldap/midominio.net).
slapd[18614]: bdb(dc=midominio,dc=net): Program version 4.8 doesn't match environment version 4.7
slapd[18614]: bdb_db_open: database "dc=midominio,dc=net" cannot be opened, err -30971. Restore from backup!
Tras bucear un rato por internet (aquí y aquí) entendí que las bases de datos que utiliza slapd tenían el formato Berkeley DB version 4.7 y, desde la última actualización, debían tener el formato Berkeley DB version 4.8. Para pasar de un formato a otro hacen falta un par de paquetes, uno por cada versión de la base de datos con que vamos a trabajar. Se instalan:
$ sudo aptitude install db4.7-util db4.8-util
El directorio de las bases de datos está definido en el fichero de configuración de slapd (/etc/ldap/slapd.conf) pero, por defecto es /var/lib/ldap/midominio.net. Todas las modificaciones se harán sobre ese directorio y es conveniente, como siempre, hacer una copia de seguridad de los ficheros que vamos a tocar porque esta solución salió al tercer intento.
Lo primero es eliminar toda referencia a la versión 4.7 en los ficheros:
# db4.7_checkpoint -1 # escribe las transacciones pendienes
# db4.7_recover # deja la base de datos en un estado consistente
Y, una vez hecho esto, falta por restaurar la base de datos con la nueva versión del entorno, algo así como la nueva versión del gestor.
# db4.8_recover -e
Como los ficheros que se han tocado no pertenecen al programa que los va a usar, retoco permisos y propietario:
# chown openldap:openldap *
# chmod 600 *
Y, al reiniciar de nuevo slapd, funciona sin más problemas.
Pero al igual que pasó con Debian 4.x (Etch), te das cuenta de lo que significa el término “compromiso” y “comunidad“. Sí, desde Debian son conscientes al igual que lo soy yo en mi día a día con los servers, que muchos de ellos (por los motivos que sea) siguen sin haber sido actualizados a la versión 6 (Squeeze) y te sorprenden (una vez más) liberando la versión 5.0.10 de Lenny y con ello, (anuncio oficial con todos los cambios) solventado muchos problemas de seguridad, algunos de un impacto “alto” caso de ser explotados.
