Laboratorio

Modulo 9 - Amministrazione, gestione e autenticazione in rete

Esperienza su OpenLDAP

Per la realizzazione di questo modulo useremo Netkit4TIC con la connettività con la rete reale (leggere il file README).

Nella mappa (pdf, xml) della rete proposta ci sono tre host collegati allo stesso dominio di collisione (192.168.50.0/29). Nell'host server (192.168.50.1) sono configurati i servizi LDAP e DNS. Il servizio DNS è autoritativo per il dominio istituto.it assegnato a questo segmento di rete. Nell'host rserver (192.168.50.2) è configurato il servizio replica LDAP mentre nell'host client (192.168.50.3) sono configurati i programmi per testare il lato client.

Questa sperimentazione si divide nelle seguenti sezioni:

Configurazione del browser LDAP gq
Installazione e configurazione di una coppia master/replica di server LDAP
Configurazione delle Access Control Lists
Configurazione e migrazione della autenticazione
Configurazione Name Service Switch
Configurazione della comunicazione con TLS
Configurazione Pluggable Authentication Module
Esempio di utilizzo in mozilla-thunderbird
Esempio OpenPEC

Scarica il tarball (40KB) contenente il tutto, e come al solito si parte scompattandolo in una sottodirectory della HOME dell'utente. Il nodo rserver è connesso alla rete reale ed è quindi gateway per tutte le macchine della rete virtuale.

Dopo aver settato correttamente l'ambiente Netkit lancia lo script:

realhost$ ./lab start

Configurazione del browser LDAP gq

Per prendere dimestichezza con LDAP consigliamo l'uso di un browser grafico per alberi LDAP come ad esempio gq (screenshot). Per mandarlo in esecuzione da riga di comando basta digitare gq.

Per impostare un nuovo server, ad esempio 192.168.50.1, si utilizza il menu: seleziona "Files->Preferences" poi seleziona il tab "Servers" e poi schiaccia il bottone "New". I campi che vanno compilati sono:

"Name": nick name identificativo della entry
"LDAP host/URI": mettere ldap://192.168.50.1
"Base DN": mettere dc=istituto,dc=it

Dopo aver fatto questa operazione sia per il server che per la replica possiamo ottenere la lista degli elementi memorizzati nei server LDAP.
Per l'accesso anche in scrittura occorre specificare il "bind DN" come cn=admin,ou=DSA,dc=istituto,dc=it e ricordarsi che la password vale Wserver.

Le impostazioni del programma gq sono memorizzate nel file ~/.gq (in formato xml) e quindi invece di impostare i parametri da interfaccia grafica è possibile editarlo a mano oppure scaricarne uno già impostato per l'occorrenza e copiarlo nella propria HOME (screenshot).

Per sperimentare il browsing di server in Internet possiamo usare quelli della distribuzione Debian. Occorre impostare come LDAP URI ldap://db.debian.org e come Base DN "dc=debian,dc=org". Ecco una lista di alcuni server LDAP pubblici disponibili per la consultazione.

Installazione e configurazione di una coppia master/replica di server LDAP

Per nostra comodità ogni macchina virtuale è fornita con tutto il corredo software di cui hanno bisogno le esperienze Netkit4TIC realizzate. Nel caso si operasse su una macchina reale occorrerebbe dare il comando apt-get install ldap-utils (la parte client di LDAP) su tutte le macchine mentre sulle macchine server e/o replica occorrerebbe dare il comando apt-get install slapd (la parte server di LDAP).

Il caricamento del database LDAP sui due server è stato pensato diviso in una prima parte, uguale per entrambe i nodi, che carica la struttura base minimale e sui cui poggiano le autorizzazioni per l'accesso (futuro) del sistema. La seconda parte, eseguita solo sul master e riportata dai meccanismi stessi del sistema di replica sulla replica, consiste nel caricamento di informazioni aggiuntive quali ad esempio le informazioni legate a due utenti di prova.

Per testare se quanto installato funziona occorre configurare il client e quindi impostare il file /etc/ldap/ldap.conf come segue:

# /etc/ldap/ldap.conf
BASE    dc=istituto,dc=it
# Server LDAP replica
URI     ldap://192.168.50.2 ldap://192.168.50.1

Questa è in effetti la configurazione predisposta nella esperienza virtuale al termine dello startup. Per sperimentarla basta lanciare sul nodo rserver un tcpdump e sul nodo client un ldapsearch (scansione dell'intero albero replica):

rserver# tcpdump -i eth1 -n -s 1500 -w /hosthome/ldap-ldapsearch.acp

client# ldapsearch -x

Utilizzando Ethereal e la traccia (File ACP) possiamo visualizzare e mettere in evidenza tutto il traffico:

realHost$ ethereal ~/ldap-ldapsearch.acp

Proviamo a colorare/filtrare i pacchetti (screenshot):

Definiamo 2 filtri di nome 4dns e 4ldap a cui associamo il rispettivo traffico dns e ldap: andiamo sul menu, selezioniamo "Analize"->Display Filters..." e schiacciamo il bottone "New" (screenshot) e (screenshot).
Ora coloriamo di rosso i pacchetti del filtro 4dns e di verde i pacchetti del filtro 4ldap: andiamo sul menu, selezioniamo "View"->Coloring Rules..." e schiacciamo il bottone "New" (screenshot) e (screenshot).

È possibile anche selezionare la visualizzazione di una certa tipologia di pacchetti impostando il campo "Filter" al valore di un filtro (screenshot) o alla combinazione logica di più filtri (screenshot)..

Se vogliamo invece interrogare il server master dobbiamo sostituire il default settato in precedenza e il comando precedente diventa:

client# ldapsearch -x -H ldap://server/

o anche:

client# ldapsearch -x -H ldap://server.istituto.it/ \
                   -b "dc=istituto,dc=it"

Per visualizzare tutte le persone che hanno come nome e cognome "Toni Ballarin" (in gergo LDAP "Common Name" o in forma abbreviata "cn"):

realHost$ ldapsearch -x -H ldap://192.168.50.1/ \
                     -b "dc=istituto,dc=it" "(cn=Toni Ballarin)"
dn: uid=toni,ou=People,dc=istituto,dc=it
uid: toni
cn: Toni Ballarin
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 12708
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1004
gidNumber: 1004
homeDirectory: /home/toni
gecos: Toni Ballarin,,,

o in forma grafica attraverso gq (screenshot). Nel caso volessimo visualizzare sono alcuni attributi, ad esempio, cn e gecos basta aggiungerli in coda al comando ldapsearch. Per esempio se vogliamo visualizzare tutti gli uid per cui il campo gecos non è vuoto (is present) e senza commenti:

realHost$ ldapsearch -LLL -x  "(&(objectClass=posixAccount)(gecos=*))" cn gecos 
dn: uid=nane,ou=People,dc=istituto,dc=it
cn: Nane Vianello
gecos: Nane Vianello,,,

dn: uid=toni,ou=People,dc=istituto,dc=it
cn: Toni Ballarin
gecos: Toni Ballarin,,,

Nel caso volessimo fare una ricerca per sottostringa potremmo chiedere quali sono gli ipHost che nel campo cn contengono la sottostringa "ser":

realHost$ ldapsearch -LLL -x  "(&(objectClass=ipHost)(cn=*ser*))" cn
dn: cn=server,ou=Hosts,dc=istituto,dc=it
cn: server

dn: cn=rserver,ou=Hosts,dc=istituto,dc=it
cn: rserver

Le direttive LDAP che definiscono la replica sono:

# Set up replication for entire database to 192.168.50.2.
# Please note that this does not use a secure connection!
replica host=rserver:389 bindmethod=simple \
        binddn="cn=replicator,ou=DSA,dc=istituto,dc=it" \
        credentials=Zserver

Configurazione delle Access Control Lists

Una corretta impostazione delle ACL deve garantire che gli utenti abbiano accesso ai dati di cui hanno bisogno e contemporaneamente deve rispettare la privacy. Abbiamo definito tre utenti nella ou=DSA,dc=istituto,dc=it:

cn=admin,ou=DSA,dc=istituto,dc=it: ha accesso ad ogni cosa (passwd: Wserver);
cn=nssuser,ou=DSA,dc=istituto,dc=it: permette il lookup dei dati NSS (passwd: Yserver);
cn=replicator,ou=DSA,dc=istituto,dc=it: permette l'accesso al server replica (passwd: Zserver).

Nel caso volessimo cambiare la password occorre usare il comando per generare il nuovo valore che poi va inserito nel campo userPassword:

server# slappasswd -h {crypt} -s not24get
{CRYPT}JNNbwWM3gur2I

Le direttive LDAP che definiscono le ACL sono:

# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
access to attrs=userPassword
        by dn="cn=admin,ou=DSA,dc=istituto,dc=it" write
        by dn="cn=nssuser,ou=DSA,dc=istituto,dc=it" read
        by anonymous auth
        by self write
        by * none

# The admin dn has full write access;
# the trusted networks (192.168.77.0/24, 192.168.50.0/24) have read access
access to *
        by dn="cn=admin,ou=DSA,dc=istituto,dc=it" write
        by peername.ip=127.0.0.1 read
        by peername.ip=192.168.77.0%255.255.255.0 read
        by peername.ip=192.168.50.0%255.255.255.0 read
        by * none

Nota sulla configurazione del client LDAP

La struttura gerarchica delle directory implica che i servizi LDAP possono essere implementati come sistemi distribuiti. Quindi l'intero Directory Information Tree (DIT) può essere partizionato in piccole aree disgiunte dove ognuna è un albero connesso.
Ogni area può essere gestita da un server separato e dove i collegamenti tra le aree possono essere memorizzati all'interno della struttura stessa. Quando un client fa una richiesta che non riguarda l'area di competenza del server, questo ha due possibilità. La prima è ricercare l'informazione dal server competente al posto del client con una tecnica chiamata chaining. L'altra possibilità è redirigere ("refer") il client al giusto server e sarà quindi compito del client contattare il nuovo server per ricercare le informazioni.

Per aumentare la tolleranza ai guasti del servizio LDAP una stessa area può essere gestita da più server. La distribuzione del carico prevede un master, eventualmente in cluster HA (High Availability), e uno o più replicazioni. Le modifiche fatte sul database master vengono diffuse nei server replica ma le modifiche fatte sui server replica non vengono eseguite e si rediziona il client verso il server master. Quindi se i client sono in grado di interpretare la redirezione sono sempre configurati a collegarsi al server replica più conveniente mentre quando mancano di questa funzionalità la configurazione dipende dal tipo di operazione che devono fare. Per la sola operazione di consultazione del database vale la configurazione precedente mentre se devono anche fare operazioni di modifica devono essere connessi direttamente al master.

Configurazione e migrazione della autenticazione

In questo esempio assumiamo di avere già un sistema di autenticazione configurato in modo tradizionale: nel file /etc/hosts ci sono i tre IP address della rete (anche se è configurato un DNS che risponde per il dominio istituto.it associato al segmento di rete) e sono configurati due utenti di nome nane e toni.
Tutti i comandi per la modifica del database LDAP vengono effettuati in modalità "in chiaro" dal momento che sono fatte da un utente locale.

Per prima cosa dobbiamo installare il pacchetto migrationtools. Poi si imposta il file /usr/share/migrationtools/migrate_common.ph come segue:

# /usr/share/migrationtools/migrate_common.ph
# Default DNS domain
$DEFAULT_MAIL_DOMAIN = "istituto.it";

# Default base
$DEFAULT_BASE = "dc=istituto,dc=it";

# turn this on to support more general object clases
# such as person.
$EXTENDED_SCHEMA = 1;

Ora ci predisponiamo l'infrastruttura di base spostandoci sulla directory /usr/share/migrationtools e lanciando il comando:

server# migrate_base.pl > base.ldif

Editiamo il file risultante per eliminare le cose superflue quali informazioni legate al NIS e le cose duplicate come People. Ora lo si carica nel server ldap (e le sue repliche) in modalità non cifrata con:

server# ldapadd -x -H ldap://server/ \
             -D"cn=admin,ou=DSA,dc=istituto,dc=it" -W -f base.ldif

Passiamo a generare a partire dal file /etc/hosts il file da importare nel server:

server# migrate_hosts.pl /etc/hosts > hosts.ldif

e poi, dopo averlo ripulito, lo carichiamo:

server# ldapadd -x -H ldap://server/ \
          -D"cn=admin,ou=DSA,dc=istituto,dc=it" -W -f hosts.ldif

e procediamo nello stesso modo per i gruppi e gli utenti:

server# migrate_group.pl /etc/group > group.ldif
server# ldapadd -x -H ldap://server/ \
          -D"cn=admin,ou=DSA,dc=istituto,dc=it" -W -f group.ldif

server# migrate_passwd.pl /etc/passwd > passwd.ldif
server# ldapadd -x -H ldap://server/ \
          -D"cn=admin,ou=DSA,dc=istituto,dc=it" -W -f passwd.ldif

Il database per il nostro esempio è ora completo, in particolare sono consultabili i singoli files: boot-base.ldif, base.ldif, hosts.ldif, group.ldif, passwd.ldif. Sono definiti solo due utenti: nane e toni con password entrambe al valore not24get; nel caso le volessimo cambiare possiamo usare slappasswd. Un tool grafico specializzato per la gestione degli utenti e dei gruppi è Directory administrator. Il suo file di inizializzazione viene momorizzato in ~/.directory_administrator/profiles e si può fare il download di quello utile per l'esperienza virtuale (screenshot).

Configurazione Name Service Switch

In questo paragrafo mostremo come configurare il servizio Name Service Switch in modo da permettere l'utilizzo di LDAP quando un comando richiede la consultazione di informazioni riguardanti sinonimi di mail, numeri ethernet, gruppi di utenti, nomi Host e IP address, protocolli di rete, password di utenti, servizi di rete, password shadow di utenti.

Per la operatività di questa funzione mediante l'uso di LDAP è necessario il pacchetto libnss-ldap ovviamente già installato nelle macchine del laboratorio virtuale.

I due file di configurazione sono:

/etc/nsswitch.conf: presente nella configurazione base di ogni macchina. Serve a indicare come le informazioni vengono recuperate dalla libreria glibc. Può essere interessante consultare il manuale della libc con il comando info libc nss.
/etc/libnss-ldap.conf: presente nel pacchetto libnss-ldap. Regola l'accesso al server LDAP

A questo punto passiamo nel laboratorio virtuale: al termine dello script lab start la macchina client è configurata per usare NSS (in chiaro). Per verificarne il corretto funzionamento usiamo il il comando getent:

client# getent shadow | grep -e "toni\|nane\|root"
nane:$1$/N8ZAlof$2hjMoJXv4rz43RHZPVZjL0:12708::99999:7:::0
toni:$1$PqF3arYG$JyIOSL40utVJa/d1cONX5.:12708::99999:7:::0
root:fdKHUdSNrBKIw:11696:0:99999:7:::
client# su - toni
client$ getent shadow | grep -e "toni\|nane"
nane:x:12708::99999:7:::0
toni:x:12708::99999:7:::0
client# getent group | grep -e "toni\|nane\|tic"
nane:x:1003:
toni:x:1004:
tic:x:1005:nane,toni
client# id toni
uid=1004(toni) gid=1004(toni) groups=1004(toni),1005(tic)

Riportiamo le catture del primo comando rispettivamente senza TLS/SSL (File ACP) e con (File ACP).

Configurazione della comunicazione con TLS

Per questa sezione ci appoggiamo all'esperienza PKI dove sono stati generati i certificati per i tre nodi della rete.

Per configurare il lato server per la comunicazione tramite TLS occorre impostare il file di configurazione /etc/ldap/slapd.conf come segue:

TLSCertificateFile        /etc/ldap/ldapreq.pem
TLSCertificateKeyFile     /etc/ldap/ldapkey.pem
TLSCipherSuite            HIGH
TLSCACertificateFile      /etc/ldap/cacert.pem

mentre nel client occorre impostare il file di configurazione /etc/ldap/ldap.conf come segue:

URI               ldaps://server.istituto.it

tls_checkpeer     yes
tls_cacertfile    /etc/ldap/cacert.pem

Occorre fare attenzione alla riga URI dove deve essere usato il nome presente nel certificato e quindi deve essere configurato correttamente un server DNS. L'ultima modifica riguarda il file che controlla le opzioni di start/stop del server master dove deve avere attivata la connessione ldaps invece che ldap. Nel caso della replica sono attive entrambe poichè l'attività di replica viene fatta in modalità in chiaro. Come spunto di approfondimento sarebbe utile imparare a configurare una connessione stunnel per proteggere quest'ultima operazione.

Ora siamo pronti per provare la configurazione con TLS. La sequenza di comandi da dare nelle console delle tre macchine virtuali sono:

server# /etc/init.d/slapd stop
server# cp -f /etc/ldap/slapd.conf-tls /etc/ldap/slapd.conf
server# cp -f /etc/default/slapd-master /etc/default/slapd
server# /etc/init.d/slapd start
server# tcpdump -i eth0 -n -s 1500 -w tls-ldapsearch.acp

rserver# /etc/init.d/slapd stop
rserver# cp -f /etc/ldap/slapd.conf-tls /etc/ldap/slapd.conf
rserver# cp -f /etc/default/slapd-replica /etc/default/slapd
rserver# /etc/init.d/slapd start

client# cp -f /etc/ldap/ldap.conf-tls /etc/ldap/ldap.conf
client# cp -f /etc/libnss-ldap.conf-tls /etc/libnss-ldap.conf
client# cp -f /etc/pam_ldap.conf-tls /etc/pam_ldap.conf
client# ldapsearch -x

e controlliamone la traccia (File ACP) con ethereal. Un ottimo e approfondito documento sulla comunicazione con TLS lo trovi in OpenLDAP_TLS_howto.

Nel caso volessimo, come nel caso delle connessioni in chiaro, accedere al server master, dobbiamo sostituire il default settato in precedenza e il comando precedente diventa:

client# ldapsearch -x -H ldaps://server.istituto.it/

Per le utility grafiche, il supporto TLS non è ancora affidabile, anche se presente, e i pochi test che abbiamo fatto non si sono risolti con successo.

Per poter visualizzare dalla macchina reale l'albero LDAP con gq occorre impostare nel file /etc/hosts la risoluzione dei nomi server.istituto.it e rserver.istituto.it. Inoltre occorre impostare il file /etc/ldap/ldap.conf e copiare il file cacert.pem.

Nota sul test delle connessioni TLS/SSL

Per il test delle connessioni utilizziamo direttamente lo stesso pacchetto openssl. Per testare la singola connettività TLS procediamo con il comando (da una qualsiasi della macchine):

openssl s_client -connect server:636 -showcerts -state \
  -CAfile /etc/ldap/cacert.pem

mentre per la connettività con autenticazione:

openssl s_client -connect server:636 -showcerts -state \
  -CAfile /etc/ldap/cacert.pem \
  -cert /etc/ldap/ldapcert.pem -key /etc/ldap/ldapkey.pem

Nota sulla rimozione dei file di backup

Nella configurazione di default del modulo backend BDB i file di log non vengono rimossi. Lo scopo di questa impostazione è quello di permettere all'amministratore di compiere un backup giornaliero dei log file e quindi di garantirsi da un eventuale guasto dell'hard disk rifacendo eseguire le operazioni registrate nei log file.

Questa configurazione può essere cambiata utilizzando il file DB_CONFIG oppure si può operare a posteriori cancellando i file di log non più necessari inserendo i seguenti comandi in un file da aggiungere ai lavori per cron:

# cd /var/lib/ldap; db4.2_archive | xargs rm -f

Il comando db4.2_archive si trova nel package db4.2-util denominato "Berkeley v4.2 Database Utilities".

Configurazione Pluggable Authentication Module

Per un panoramica sulle funzionalità dei moduli PAM può essere utile realizzare l'esperienza PAM.
Per configurare il modulo PAM per l'uso di LDAP è necessario installare il pacchetto libpam-ldap che ovviamente è già installato sulle macchine del laboratorio virtuale.

I due passi di configurazione sono legati ai seguenti file:

il file /etc/pam_ldap.conf che regola l'accesso al server LDAP
i file nella directory /etc/pam.d/ (uno per applicazione). Nella recende Debian sarge l'organizzazione di questa directory è migliorata poichè nei singoli file è stata usata la direttiva @include che permette di cambiare il funzionamento di tutti gli applicativi modificando il solo file incluso.
Per esempio, per quanto riguarda l'autorizzazione, se operiamo le seguenti modifiche:
```
# /etc/pam.d/common-auth
auth sufficient pam_ldap.so
auth required   pam_unix.so
```
otterremo che in tutte le applicazioni che usano @include common-auth si utilizzino le informazioni LDAP e solo nel caso che non vengano trovate si utilizzeranno quelle dello Unix standard (su file). Questo ultimo caso viene visualizzato al login (per esempio) con una seconda richiesta di password che indica il fallimento del primo modulo dello stack. Per evitare questo funzionamento basterebbe aggiungere use_first_pass come argomento ai moduli successivi al primo ma noi lasciamo questa configurazione a scopo di debug per evidenziare a quale livello dello stack siamo "accettati".

A questo punto passiamo nel laboratorio virtuale e settiamo la macchina client in modo che PAM usi LDAP riportando con il nome corretto i file già preparati dallo script:

client# cp /etc/pam_ldap.conf.new /etc/pam_ldap.conf
client# cp -f /etc/pam.d/common-auth.new /etc/pam.d/common-auth
client# cp -f /etc/pam.d/common-account.new /etc/pam.d/common-account
client# cp -f /etc/pam.d/common-session.new /etc/pam.d/common-session

Per sollecitare la configurazione appena impostata possiamo provare il login ssh da una macchina virtuale o dalla macchina reale (attenzione però a ricordarsi di restartare il servizio ssh!) oppure rifare il login sulla stessa macchina client:

client# /etc/init.d/ssh restart

server# ssh -l root client
ssh -l root client
The authenticity of host 'client (192.168.50.3)' can't be established.
RSA key fingerprint is c8:f2:e3:b3:02:2f:56:31:db:4b:83:1e:c7:8f:c9:9b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'client,192.168.50.3' (RSA) to the list of known hosts.
Password: root
Password: root
client# exit
server# ssh -l toni client
Password: not24get
client$ exit

Riportiamo le catture del login rispettivamente in chiaro (File ACP) e con TLS/SSL (File ACP).

Esempio di utilizzo in mozilla-thunderbird

L'utilizzo di un servizio di directory è oramai previsto in ogni programma per la spedizione della posta. Nel nostro esempio lanciamo

realHost# mozilla-thunderbird

Il programma ci chiede per prima cosa l'impostazione di un account di e-mail. Diamo dei risultati "ammissibili" in modo da proseguire oltre.
L'impostazione del servizio di directory è nella sezione riguardante l'agenda indirizzi. Attiviamo quindi la voce "Address Book". In seguito selezioniamo dal Menu la voce Edit->Preferences e di seguito la voce "Composition". Nella zona "Address Autocomposition" selezioniamo la voce "Directory Server" e successivamente la voce "Edit Directories". Siamo arrivati al termine: aggiungiamo un LDAP Directory Server (Directory Server Properties).

Ora possiamo usare il contenuto del servizio LDAP sia quando scriviamo un messaggio che per le nostre ricerche. In questo ultimo caso attiviamo la voce di menu Edit->Search Addresses. Nel riquadro "Search in" selezioniamo il nostro server e poi impostiamo una condizione di ricerca e verifichiamo il funzionamento (Advanced Address Book Search).

Configurazione OpenPEC

La Posta Elettronica Certificata (PEC) è implementabile anche con una soluzione Open Source di nome OpenPEC. Il server LDAP è richiesto perchè replica localmente il contenuto dell'indice dei gestori. Allo stato attuale per ottenere una copia locale di questo indice basta dare il comando:

$ ldapsearch -L -x -h indicepa.gov.it -b o=postacert \
    -s "sub" "(objectclass=*)" > exp_pec.ldif

Per ottenere una copia dello schema invece:

$ wget http://www.openpec.org/docs/ind_pec.schema

Purtroppo il database fornito dal cnipa non rispetta lo standard (definito da lui stesso) e dal conseguente schema definito da openpec nel campo providerCertificateSubject. In dettaglio riporto quello che è possibile leggere nella mailing list openpec-users "il campo è definito con una sintassi '1.3.6.1.4.1.1466.115.121.1.12' che come da rfc 2256 indica un distiguished name, e quindi soggetto alle regole di sintassi definite nella rfc 2253 'Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names' e invece dal database troviamo anche caratteri come lo 'slash'. Solo la vecchia release 2.0 di OpenLDAP lo digerisce poichè 'di bocca buona'".
Per prova ho cambiato a mano la valorizzazione di un record di prova e infatti viene caricato.
Se vuoi provare lancia l'esperienza:

realHost$ ./OpenPEC start

poi copia il file di inizializzazione di gq sulla tua home directory e lancia gq (screenshot) e ricorda che la password è not24get.
Se vuoi provare a vedere le difficoltà di caricamento del database, prova:

OpenPECserver# slapadd -f /etc/ldap/slapd.conf -l exp_pec.ldif

e poi:

OpenPECserver# /etc/init.d/slapd restart

e un refresh in gq.

Sandro Doro (email me)
Ultima modifica: $Date: 2008-01-03 06:50:02 $