Actualizar Debian entre versiones estables usualmente es un paseo, excepto cuando no lo es. Leer los Release Notes completamente y con intención, ahorra tiempo -- después de todo, fueron escritas por personas que saben mucho más que uno, y que de verdad hicieron el trabajo.

El directorio LDAP suele ser el sustrato de muchas instalaciones de servicios AAA y correo electrónico. Si esa actualización falla, el servicio también. Este es uno de los pocos servicios que no son triviales de actualizar de manera automática.

LDAP es tan rápido como su backend

La base de datos que almacena el directorio LDAP es fundamentalmente clave-valor. A lo largo de los años, ha evolucionado para maximizar la velocidad de lectura, sin preocuparse por la velocidad de escritura -- es la decisión correcta dado su patrón de uso.

El venerable Berkeley DB cayó en desuso hace más o menos una década. Fue reemplazado por HDB, una variante de BDB que facilita la construcción jerárquica. Tanto BDB como HDB dependen del kernel buffer cache para ser eficientes, siempre y cuando se ajusten cuidadosamente varios parámetros de operación. Aún así, siguen teniendo el problema de doble-copia (de disco a caché, de caché a proceso).

Una manera de evitar la doble-copia es establecer una biyección entre el archivo en disco y direcciones de memoria en el espacio del proceso. Esa técnica es provista por el kernel Linux hace más de una década, y se denomina «memory mapping».

Hasta Debian 11, las instalaciones LDAP se configuraban de manera automática para usar BDB/HDB, y las actualizaciones en sitio no suponían mayor dificultad. Los administradores podían agregar sus ajustes de desempeño, índices, y reglas de control de acceso, sabiendo que hay una traducción 1 a 1 para poder avanzar desde BDB hasta HDB.

Debian 11 introdujo la posibilidad de utilizar MDB. Sin embargo, no se proveyó mecanismo para configurarla de manera semi-automática con debconf. Tampoco se proveyó un mecanismo para transformar una instalación BDB/HDB hacia MDB, porque no es trivial. Eso hizo que la mayoría de los administradores se quedaran con BDB/HDB.

A partir de Debian 12, sólo está disponible MDB. Ya no hay soporte para BDB/HDB. En otras palabras, el servidor slapd de Debian 12, no va a levantar, si encuentra los datos en un backend BDB/HDB. Así de simple. Los Release Notes lo dicen claramente.

Deja para hoy lo que no quieres hacer apurado mañana

En mi opinión, es preferible migrar manualmente desde BDB/HDB hacia MDB en Debian 11, para que la actualización a Debian 12 no tenga que hacer nada, sino reiniciar el proceso slapd. La migración es relativamente sencilla, ejecutando los siguientes pasos como root (o con sudo):

  1. Detenga el servicio LDAP. Usando scripts SYSV o SystemD, detenga el servicio slapd. Esto hace que cualquier transacción pendiente sea escrita, y la base de datos quede consistente.

  2. Respalde los datos del directorio a un archivo LDIF. Los datos del directorio están bajo /var/lib/ldap. Con el servicio slapd detenido, basta hacer

        slapcat -l data-backup.ldif

  3. Respalde la configuración del servicio a un archivo LDIF. Las instalaciones modernas de LDAP se configuran con una jerarquía de archivos LDIF inmutables, ubicados bajo /etc/ldap/slapd.d. Si su sistema sólo tiene un archivo /etc/ldap/slapd.conf, estas instrucciones no aplican. Con el servicio slapd detenido, basta hacer

        slapcat -n 0 -F /etc/ldap/slapd.d -l config-backup.ldif

  4. Vacíe el directorio de configuración y el directorio de datos. Efectivamente, hay que reconstruir todo desde cero. Para los extra-paranoicos, puede copiar ambos directorios para tener una «recuperación de emergencia».

        rm /var/lib/ldap/*
    rm -rf /etc/ldap/slapd.d/*

  5. Usando su editor preferido, ajuste los contenidos de config-backup.ldif para reflejar el cambio de backend hacia MDB. Cuáles y cuántas cosas tendrá que cambiar depende de su instalación particular, y es una de las razones por las cuales no puede haber un «actualizador mágico» que haga el trabajo. Para el caso trivial en el cual hay solamente un backend gestionando una sola base de datos BDB/HDB, tiene que buscar y ajustar lo siguiente:

    • Ubique la entrada con dn: cn=module{N},cn=config (donde N suele ser 0) y ajuste olcModuleLoad para usar back_mdb. Esta entrada indica cuál librería usar para las bases de datos, así que en lugar de BDB/HDB necesita MDB.

    • Ubique la entrada con dn cn=olcBackend{N}hdb,cn=config (donde N suele ser 0). Ajuste el dn y el cn para tener mdb. Esta entrada declara que existe una base de datos en disco que requiere el backend MDB.

    • Ubique la entrada con dn olcDatabase={N}hdb,cn=config (donde N suele ser 1). Además de ajustar el dn y el olcDatabase para tener mdb, también tendrá que ajustar el objectClass para reflejar que se trata de un olcMdbConfig Notará muchos atributos relacionados con la raíz de búsqueda, credenciales del administrador, y posiblemente índices para mejorar la eficiencia de búsqueda. Puede dejarlos tal cual.

      Al cambiar el objectClass, es necesario que elimine cualquier directiva de configuración específica para BDB/HDB. No puedo decirle cuáles son porque eso depende de su instalación. En mi caso, tuve que eliminar todos los olcDbConfig.

      Así mismo, tiene que agregar la única directiva necesaria para MDB: un número, en bytes, que será el límite de tamaño de la base de datos. Recordando que se trata de un límite superior para hacer memory-mapping, simplemente escoja un número mucho más grande de lo que Ud. estima su base de datos LDAP va a crecer en el tiempo. En mi caso, 1Gb es suficiente así que puse olcDbMaxSize: 1073741824. No está dicho explícitamente en ninguna parte, pero es conveniente que el número sea un múltiplo de 4096.

  6. Genere la configuración bajo /etc/ldap/slapd.d usando el archivo modificado en el punto (5).

        slapadd -n 0 -F /etc/ldap/slapd.d -l config-backup.ldif
    chown -R openldap:openldap /etc/ldap/slapd.d

    Si cometió errores en el archivo LDIF, le serán reportados durante el proceso de carga. Elimine los contenidos del directorio /etc/ldap/slapd.d, y repita hasta que logre cargar la configuración sin recibir errores ni advertencias.

  7. Restaure los datos bajo /var/lib/ldap

        slapadd -l data-backup.ldif
    chown -R openldap:openldap /var/lib/ldap

    Si los datos cargan limpiamente, el directorio /var/lib/ldap contendrá exactamente dos archivos: data.mdb y lock.mdb.

    Si los datos no cargan limpiamente, seguramente es porque su instalación tiene configuraciones adicionales que deben ajustarse. En ese caso, interprete los mensajes de error recibidos, y regrese al punto (5) hasta que logre cargar configuración y datos sin problemas.

  8. Inicie el servicio LDAP. Usando scripts SYSV o SystemD, inice el servicio slapd. Si el servicio inicia sin reportar errores, conduzca las pruebas necesarias para su plataforma, confirmando que el directorio opera correctamente.

Colofón

Mis instalaciones LDAP suelen tener montones de configuraciones adicionales (índices, ACLs, múltiples credenciales administrativas, esquemas adicionales estándar o de mi propia cosecha). Agregar esas configuraciones adicionales a una instalación «nueva» es engorroso, y susceptible a errores u omisiones. Por eso prefiero hacer la media docena de ajustes descritos más arriba.

Para aquellos que tienen una configuración LDAP mínima de cajita "con el plastiquiiiito", puede resultar más práctico:

  1. Estando en Debian 11, respaldar sólo los datos a LDIF. Asegurarse que se pueden restaurar en otro LDAP nuevo en un Debian 12.

  2. Actualizar a Debian 12. slapd no va a subir.

  3. Destruir la configuración y los datos LDAP en Debian 12. Usar dpkg-reconfigure para generar una nueva base de datos usando MDB desde cero.

  4. Restaurar los datos.

  5. Revisar que todo funcione.

Entre los pasos (2) y (3) no hay servicio LDAP. Entre (3) y (4) pueden «pasar cosas» si los servicios tratan de usar LDAP y la base de datos no está completa.

Como siempre, es increíble lo que se puede aprender leyendo la documentación con intención, en lugar de simplemente seguir recetas escritas o en video...