== slapd.conf ==

Il file /etc/ldap/slapd.conf e` stato modificato il meno possibile,
attivando queste opzioni:

 * backend hdb
 * ldap v.3
 * amministratore = cn=admim (+base)

Le modifiche pesanti, come aggiunta di schemi e acl, sono state
implementate aggiungendo nei punti opportuni l'include di questi
files:

 * /etc/ldap/ku-schema.conf
 * /etc/ldap/ku-access.conf
 * /etc/ldap/ku-indexing.conf

== improvements ==

Vedere lo schema utilizzato da Mandriva, che sembra molto piu` esteso
(prevede gia` supporto samba, gosa, ecc) e inolte implementa dei
meccanismi di acl abbastanza interessanti, basati su regular expression
match.


== schemas: samba ==

Il file samba.conf e` preso dagli esempi del package samba 
versione 3.0.28a-1ubuntu4.7 presenti nella directory
/usr/share/doc/samba-doc/examples/LDAP.

== schemas: gosa ==

I files sono presi dal package '''gosa''' versione 2.5.13-1ubuntu1, presenti sotto la
directory /usr/share/doc/gosa/contrib/openldap.

Solo una parte degli schemi e` utilizzata, i files non usati sono sotto la directory
gosa.notused di questo modulo.

<!> domanda per Pietro: la sequenza di dichiarazione degli schemi conta?

<!> lo schema samba.schema che viene da samba presenta dei duplicati rispetto
al samba3.schema preso da gosa, per Pietro, come hai risolto la cosa? io ho
usato samba.schema preso da gosa e sembra funzionare -- lc01

== DEBUG ==

Slapd fa dannare, e se abortisce non dice nulla del motivo (della
serie: quando un software e` fatto bene).
Controllare come suggerito il file /var/log/syslog di solito non produce
risultati.

Sempre come suggerito, lanciare a mano il daemon, aggiungendo in coda
il parametro '-d 16383' che abilita, se ho capito bene, il debug su
tutto l'universo e qualche altra dimensione parallela, esempio:
{{{
slapd -g openldap -u openldap -f /etc/ldap/slapd.conf -d 16383
}}}

== conversione db ==

Lo dico e lo ripeto: gli sviluppatori di LDAP lavorano bene con quelli
del berkley db perche` ne condividono la demenza. Chiunque gestisca un
package sa che se cambia il formato dei dati utilizzati, deve fornire
uno strumento di conversione da una release all'altra.

Questi qui fanno il contrario: berkley db memorizza nel suo "environment"
(un setup interno che non ho nessuna voglia di indagare su come viene
gestito) il numero di release, se non corrisponde con quello delle librerie
qualsiasi tentativo di accedere ai database fallisce.

Ne consegue che per convertire il db occorre usare le utilities della '''STESSA VERSIONE'''
dei db, non quelle nuove.

Con queste utils si rimuovono le informazioni di enviroment (???), e quindi
dopo con le NUOVE util si possono ricreare, ovviamente in questo modo il nuovo
environment sara` ricreato nella versione aggiornata.

In pratica, presumendo come esempio di avere un db 4.7 e di avere il software
aggiornato alla 5.1, questa e` la sequenza:

 * installare le utils vecchie
 {{{
apt-get install db4.7-utils
 }}}

 * azzerare il log delle transazioni e rimuovere l'environemnt
 {{{
cd <path-del-database>
db4.7_checkpoint -1
db4.7_recover
 }}}

 * ricreare l'environment nuova versione:
 {{{
db5.1_recover -e
 }}}

<!> nel tentativo di stare dietro a questa demenza, e nell'attesa di
trovare un modo per automatizzare la cosa, installo assieme al server
ldap anche le utils precedenti, almeno a partire dalla 9.04; se non
corrispondono, vanno installate a mano
