Scrivi sempre alla lista! 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. >>> >>> - 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. >>> >>> Voi cosa ne pensate? >>> >>> Esistono in giro documenti con best practices? >> che io sappia no ma ci sono individui o società che hanno una lunga >> esperienza in merito ;-) > > Non riesco a capire a chi ti riferisci!;-) Mah! Qualcuno lo conosco... :-) Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. Gruppo Partners Associates via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scam...@sys-net.it ----------------------------------- _______________________________________________ OpenLDAP mailing list OpenLDAP@mail.sys-net.it https://www.sys-net.it/mailman/listinfo/openldap
