Il giorno 21 lug 2009, alle ore 09:51, Luca Scamoni ha scritto:
Raffaele Conte wrote:
Il giorno 20 lug 2009, alle ore 13:01, Luca Scamoni ha scritto:
Ciao,
Raffaele Conte wrote:
Ho scartato la soluzione di utilizzare uno di questi due DBMS come
backend per LDAP a causa delle prestazione scadenti (abbiamo
fatto un
po' di test) e quindi a questo punto la soluzione rimane quella di
utilizzare entrambi. I dubbi però sono:
prestazioni scadenti su quali fronti (lettura, scrittura, entrambe)?
Entrambe, ma quelle che "pesano" di più sono ovviamente quelle in
lettura, dove ldap dovrebbe farla da padrone.
Strano. Le prestazioni sono sicuramente inferiori a quelle di un
backend
dedicato (hdb o bdb) ma almeno in lettura non dovrebbero essere
scadenti. Questo vuol dire che il db sottostante non è correttamente
configurato (indici, cache, ecc.)
In realtà non l'ho citato ma è stato recentemente aggiunto un
backend di
openldap che sfrutta le API di mysql-cluster per gestire questo tipo
di
interazione. In pratica la parte di storage e replicazione rimane a
carico di mysql mentre la parte di frontend ldap è gestita da slapd.
Ha ancora qualche limitazione (più che altro sul tipo di search che
puoi
fare) ma sembra ben indirizzato.
Hai un link?
- se duplico come è meglio gestire la gerarchia? Domina ldap che
poi
aggiorna il db relazionale o viceversa?
dipende da chi detiene la proprietà dei dati. Se, come spesso
accade, il
db del personale è gestito attraverso frontend applicativi e
quindi la
proprietà dei dati è quasi esclusivamente dello stesso, conviene
usare
ldap solo come un frontend di pubblicazione delle informazioni e
quindi
duplicare le informazioni su di esso gestendo gli aggiornamenti in
maniera opportuna (provisioning da db a ldap)
Certamente le password è conveniente tenerle solo in ldap ma a
questo
punto se un utente si aggiorna la propria password magari potrebbe
aggiornare anche altri dati quindi converrebbe aggiornare ldap e
poi
propagare le modifiche sul DB. O no?
se ci sono altri dati che possono essere moificati dall'utente sì
Beh sì. Il numero di telefono, li numero di stanza, lingua preferita
ecc. se li può aggiornare da solo. Questi dati non sarebbe nemmeno
utile
tenerli sul DB.
Quindi dovresti ricorrere a una soluzione "mista". Una parte dei dati
viene pubblicata su ldap a partire dai dati del db (con opportune
procedure di aggiornamento). Una parte invece sta solo su ldap e
vengono
gestiti attraverso operazioni ldap. Occhio a limitare l'accesso in
scrittura solo a questi dati evitando così che l'utente possa
modificare
anche altri attributi che dovrebbero rimanere read-only.
È quello a cui pensavo, anche se poi ci sarà da gestire "attentamente"
l'aggiornamento dei dati su due sorgenti diverse.
Se la soluzione con mySQL funzionasse bene potrebbe essere quella
risolutiva anche se la replicazione di mySQL è certamente più
complessa di quella di openLDAP.
Grazie,
raf
_______________________________________________
OpenLDAP mailing list
OpenLDAP@mail.sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap
