== migrazione db o errori sui db ==

A riprova dell'inaffidabilita` dei manutentori di LDAP, ci sono
parecchi problemi aggiornando openldap.

=== config files ===

Nell'ultima versione (la 2.4) hanno cambiato i files di configurazione
e ovviemente invece di mantenere la compatibilita` con il vecchio
formato (il file di testo slapd.conf sotto /etc/ldap) ed abilitare
tramite switch la nuova configurazione, hanno fatto il contrario.

Manco a dirlo, trovare l'opzione che permette di mantenere il vecchio
file di configurazione e` stata un'impresa, alla fine si tratta di
definire in /etc/default/slapd la variabile SLAPD_CONF.

=== versione berkley db ===

LDAP si basa sui db di berkley, che cambiano formato abbastanza spesso.

Anche in questo caso non esiste la compatibilita` all'indietro.
D'accordo che non e` un problema specifico dei maintainer di LDAP, ma
quantomeno questi, passando ad una versione successiva dei db, dovrebbero
documentare la procedura per il porting.

La cosa piu` sicura da fare e` sicuramente quella di eseguire un dump
completo in formato ldif del database PRIMA di procedere ad un aggiornamento
di LDAP e/o DB, per poi ricaricare da zero su un db vuoto.

Quando questa strada non e` praticabile, usare questa procedura (fa
riferimento alla versione 4.7 di berkley db, per altre versioni non
e` detto che funzioni esattamente allo stesso modo):

 * installare db4.7-util
 * fermare slapd (se e` in funzione, cosa difficile dato gli errori)
 * spostarsi nella directory dove risiedono i db
 * eseguire il comando di recovery:
 {{{
db4.7_recover -h . -v
 }}}
 * eliminare i checkpoint dal logfile (da qualche parte si legge che
 basta eliminare il file log.0000001 prima del recover, ma non e` vero),
 per ogni file con estensione .bdb lanciare:
 {{{
db4.7_load -r lfn nomefile
 }}}
 * far ripartire slapd, controllando nel syslog se parte davvero e/o se
 ci sono errori

Il tracing di questo tipo di errore e` complicato dal fatto che la diagnostica,
come da prassi per tutto quello che riguarda LDAP, e` caotica e incongruente.

I tipi di errore che possono farvi capire che si e` di fronte ad un problema
di versione sbagliata dei db sono questi:

 *
 {{{
bdb(dc=example): Program version 4.7 doesn't match environment version 0.33
hdb_db_open: database "dc=example" cannot be opened, err -30971. Restore from backup!
 }}}
 nel syslog, nel caso di versione db incompatibile, quando si lancia slapd

 notare che la versione 0.33 dell'esempio
 non c'entra niente con quella reale (era una 4.2), c'e` una certa confusione
 probabilmente nell'uso del numero di release ufficiale e quello della versione
 interna con cui vengono marcati i db; questa confusione salta fuori anche in altri
 contesti, ad esempio puo` essere che un errore dica che il logfile e` alla versione
 12 e cose del genere

 inutile dire che il consiglio di recupera da un backup e` completamente inutile,
 perche` non risolverebbe il problema

 *
 {{{
bdb(dc=example): DB_ENV->log_flush: LSN of 1/362664 past current end-of-log of 1/3026
 }}}
 nel syslog, sempre facendo parire slapd o cercando di modificare il contenuto
 del db, in caso di recovery parziale (non sono stati rimossi i LSN)

 *
 {{{
 Other (e.g., implementation specific) error (80)
 }}}
 errore emesso da ldapadd o ldapmodify, capita se l'operazione di recovery non e` stata eseguita su TUTTI
 i files con estensione .bdb (ad esempio, slapd parte ugualmente se il file id2entry.bdb e`
 a posto, ma gli altri no)
