2011/3/30 Luigi Augello <lauge...@unipa.it> > Caro Marco > > Esatto anche questo. > Vedo che anche nell'esempio che citi sotto non indichi mai la direttiva > "database meta". > Il meta, nonostante sia "virtuale", e' pur sempre un database di OpenLDAP e > quindi deve essere dichiarato come tale. > Le direttive "uri" devono stare sotto/dopo la direttiva "database meta". > > Cosa intendi per direttiva "database meta"., nel mio caso come dovrebbe > essere dichiarata? >
> Ti ho perso quando dici "saranno sincronizzati a due server remoti". > Chiarisci se stai dicendo che faranno da producer (master) o da consumer > (slave). > > > In pratica presso la sede del polo didattico mi trovo uno o due server che > si sincronizzano con i server in remoto e utilizzo questi server che si > trovano presso la sede del polo didattico per l'autenticazione. funziona > cosi: > > server remoto--->syncrepl su server locale --->datababe ldap in locale > usato come backend dallo stesso server locale per l'autenticazione in PDC di > samba > > Spero di essere stato chiaro e scusate ancora, non sono esperto su ldap. > > Ciao > Luigi > > > > > > > > Marco Pizzoli ha scritto: > > > > > > 2011/3/25 Luigi Augello <lauge...@unipa.it> > >> Vediamo se ho capito >> inserendo >> >> suffix "dc=unipa,dc=it" >> >> uri "ldap://xxxxxx.xx/*ou=Studenti,dc=unipa,dc=it*"; >> "ldap://yyyyy.yyy/*ou=Utenti,dc=unipa,dc=it*"; >> >> Qualora dovessi fare un'interrogazione di uno studente "proxa" sul server >> xxxxxx.xx, mentre se faccio un interrogazione di un utente, >> allora "proxa" sul server yyyyy.yyy. >> >> >> > Detta cosi' e' un po' troppo semplice... > Con back_meta ottieni una fusione logica degli oggetti, quindi ottieni un > database virtuale che presenta sotto un unico suffix tutti gli oggetti > reperiti da fonti "esterne". Tu devi definire la regola su come viene > effettuata la conversione tra il dit sorgente e quello virtuale presentato > al client. > Venendo al tuo esempio, tu stai creando una radice chiamata > "dc=unipa,dc=it" e sotto questa radice stai inserendo tutti gli oggetti che > sugli altri server si trovano sotto "ou=Studenti,dc=unipa,dc=it" (nel primo) > e "ou=Utenti,dc=unipa,dc=it" (nel secondo). > > Quindi: > dc=unipa,dc=it > |- cn: studente1 > |- cn: utente1 > |- cn: utente2 > |- cn: studente2 > |- ecc... > > il fatto che un utente venga trovato sul server degli studenti o quello > degli utenti e' diretta conseguenza di come il client ha fatto la ricerca, o > meglio di quale condizione di filtro ha impostato nella search. > > Chiaritemi ancora dei dubbi >> >> - Su server back_meta fisicamente noni risiede nessun database? >> >> >> Esatto > > >> - Se così fosse e volessi invece che o entrambi i database o uno solamente >> risieda sul mio server allora dovrei fare >> >> >> uri "ldap://127.0.0.1/*ou=Studenti,dc=unipa,dc=it*"; >> "ldap://yyyyy.yyy/*ou=Utenti,dc=unipa,dc=it*"; >> >> >> >> giusto? >> >> >> Esatto anche questo. > Vedo che anche nell'esempio che citi sotto non indichi mai la direttiva > "database meta". > Il meta, nonostante sia "virtuale", e' pur sempre un database di OpenLDAP e > quindi deve essere dichiarato come tale. > Le direttive "uri" devono stare sotto/dopo la direttiva "database meta". > > >> - nella mia attuale configurazione utilizzo la clausola syncrepl >> >> per replicare un database remoto e la clausola subordinate come artificio >> per poter aggiungere degli utenti in locale. >> >> Di seguito la configurazione >> ########################################################################## >> include /etc/openldap/schema/core.schema >> include /etc/openldap/schema/cosine.schema >> include /etc/openldap/schema/inetorgperson.schema >> include /etc/openldap/schema/nis.schema >> include /etc/openldap/schema/samba.schema >> >> allow bind_v2 >> >> #referral ldap://root.openldap.org >> >> pidfile /var/run/slapd/slapd.pid >> argsfile /var/run/slapd/slapd.args >> >> # modulepath /usr/sbin/openldap >> # moduleload back_bdb.la >> # moduleload back_ldap.la >> # moduleload back_ldbm.la >> # moduleload back_passwd.la >> # moduleload back_shell.la >> >> # TLSCACertificateFile /usr/share/ssl/certs/ca-bundle.crt >> # TLSCertificateFile /usr/share/ssl/certs/slapd.pem >> # TLSCertificateKeyFile /usr/share/ssl/certs/slapd.pem >> >> # security ssf=1 update_ssf=112 simple_bind=64 >> >> >> >> >> >> >> >> database hdb >> suffix "ou=Studenti,dc=unipa,dc=it" >> directory /home/dati/studenti >> rootdn "cn=xxxx,ou=Studenti,dc=unipa,dc=it" >> rootpw xxxxxxx >> >> subordinate ###### con questa >> direttiva dico che "ou=Studenti,dc=unipa,dc=it" >> ###### è subordinata a >> dc=unipa,dc=it e in questo modo in >> ###### dc=unipa,dc=it >> posso aggiungere degli utenti locali >> >> index objectClass eq >> index uid,uidNumber,gidNumber,memberUid eq >> index cn,mail,surname,givenname eq,subinitial >> index sambaSid eq >> index sambaPrimaryGroupSID eq >> index sambaDomainName eq >> index entryUUID eq >> >> syncrepl rid=1 >> provider=ldaps://xxx.xxx.it >> type=refreshAndPersist >> interval=00:00:00:30 >> searchbase="ou=Studenti,dc=unipa,dc=it" >> filter="(objectClass=*)" >> attrs="*,+" >> scope=sub >> schemachecking=off >> retry="60 +" >> bindmethod=simple >> binddn="uid=xxx,ou=Studenti,dc=unipa,dc=it" >> credentials=XXX >> >> >> >> >> database hdb >> suffix "dc=unipa,dc=it" >> directory /var/lib/ldap/unipa >> rootdn "cn=xxxx,dc=unipa,dc=it" >> rootpw xxxx >> sizelimit -1 >> cachesize 10000 >> >> ##################################################### >> A me in due altri server occorre realizzare >> - il primo server dovrà avere un database che chiameremo utenti locali che >> potrebbe essere con questo suffix >> >> suffix "ou=UtentiLocali,dc=unipa,dc=it" >> >> >> e due "proxati" quindi non residenti sul server locale che saranno >> >> >> "ou=Utenti,dc=unipa,dc=it" >> "ou=Studenti,dc=unipa,dc=it" >> >> e quì se non ho capito male la configurazione per proxare come dicevo >> all'inizio con in più una direttiva subordinate per il database locale >> >> la configurazione dovrebbe essere >> >> >> >> uri "ldap://xxxxxx.xx/*ou=Studenti,dc=unipa,dc=it*"; >> "ldap://yyyyy.yyy/*ou=Utenti,dc=unipa,dc=it*"; >> >> >> database hdb >> suffix "ou=UtentiLocali,dc=unipa,dc=it" >> directory /home/dati/utentiLocali >> rootdn "cn=xxxx,ou=UtentiLocali,dc=unipa,dc=it" >> rootpw xxxxxxx >> >> >> >> >> >> >> - sull'altro server gli stessi database "ou=UtentiLocali,dc=unipa,dc=it", >> "ou=Utenti,dc=unipa,dc=it" e "ou=Studenti,dc=unipa,dc=it" >> dovranno invece risiedere sul server e gli ultimi due, Studenti e Utenti >> saranno sincronizzati con la direttiva syncrepl a due server remoti >> in questo caso, se non ho capito male, dovrei fare un "glue" dei tre pezzi >> in questo modo >> >> >> Ti ho perso quando dici "saranno sincronizzati a due server remoti". > Chiarisci se stai dicendo che faranno da producer (master) o da consumer > (slave). > > Ciao > M. > > >> ########################################################## >> >> database hdb >> suffix "ou=Studenti,dc=unipa,dc=it" >> directory /home/dati/studenti >> rootdn "cn=xxxx,ou=Studenti,dc=unipa,dc=it" >> rootpw xxxxxxx >> >> subordinate >> index objectClass eq >> index uid,uidNumber,gidNumber,memberUid eq >> index cn,mail,surname,givenname eq,subinitial >> index sambaSid eq >> index sambaPrimaryGroupSID eq >> index sambaDomainName eq >> index entryUUID eq >> >> syncrepl rid=1 >> provider=ldaps://xxx.xxx.it >> type=refreshAndPersist >> interval=00:00:00:30 >> searchbase="ou=Studenti,dc=unipa,dc=it" >> filter="(objectClass=*)" >> attrs="*,+" >> scope=sub >> schemachecking=off >> retry="60 +" >> bindmethod=simple >> binddn="uid=xxx,ou=Studenti,dc=unipa,dc=it" >> credentials=XXX >> >> >> >> >> database hdb >> suffix "ou=Utenti,dc=unipa,dc=it" >> directory /home/dati/utenti >> rootdn "cn=xxxx,ou=Utenti,dc=unipa,dc=it" >> rootpw xxxxxxx >> >> >> >> subordinate >> >> index objectClass eq >> index uid,uidNumber,gidNumber,memberUid eq >> index cn,mail,surname,givenname eq,subinitial >> index sambaSid eq >> index sambaPrimaryGroupSID eq >> index sambaDomainName eq >> index entryUUID eq >> >> syncrepl rid=1 >> provider=ldaps://xxx.xxx.it >> type=refreshAndPersist >> interval=00:00:00:30 >> searchbase="ou=Utenti,dc=unipa,dc=it" >> filter="(objectClass=*)" >> attrs="*,+" >> scope=sub >> schemachecking=off >> retry="60 +" >> bindmethod=simple >> binddn="uid=xxx,ou=Utenti,dc=unipa,dc=it" >> credentials=XXX >> >> >> >> database hdb >> suffix "ou=UtentiLocali,dc=unipa,dc=it" >> directory /home/dati/utentiLocali >> rootdn "cn=xxxx,ou=UtentiLocali,dc=unipa,dc=it" >> rootpw xxxxxxx >> >> >> >> Scusate se sono stato prolisso, ma ho parecchi dubbi e quindi vi ho voluto >> dare più elementi possibili, scusate eventuali strafalcioni >> >> Grazie sempre >> Luigi >> >> >> >> >> >> >> >> >> >> >> >> 25/03/2011 17.31, Marco Pizzoli ha scritto: >> >> >> Era quello che ti suggerivo nella prima risposta al tuo primo quesito su >> come "fondere" logicamente i 2 directory con cui stai avendo a che fare. >> >> back_meta e' l'oggetto (database) OpenLDAP che ti consente di ottenere una >> visione logica unica "sopra" a diversi oggetti alberi ldap, strutturati >> potenzialmente in modo molto diverso. E' quello che ti consente di >> implementare un meta-directory. >> >> http://www.manpagez.com/man/5/slapd-meta/ >> >> Guarda la parte SCENARIOS di quel link per farti un'idea. >> >> Ciao >> M. >> >> >> 2011/3/25 Luigi Augello <lauge...@unipa.it> >> >>> Il 25/03/2011 15.38, Luca Scamoni ha scritto: >>> >>> La risposta di Marco è corretta. >>> Per fare quello che vuoi dovresti configurare un back-meta... >>> >>> Scusa la mia ignoranza, che significa back-meta...? >>> Grazie >>> Luigi >>> >>> >>> >>> ciao >>> Il 25/03/2011 15:18, Marco Pizzoli ha scritto: >>> >>> Ciao, >>> premetto che non ho esperienza diretta di samba con questa >>> configurazione, ma in scenari analoghi questa configurazione ti garantisce >>> soltanto il fail-over tra ldapserver multipli. Ergo, se il primo elencato >>> non risponde allora viene contattato il secondo. >>> Ma se il primo risponde, (sia che il dato esista sia che non esista) il >>> secondo non verra' mai contattato. >>> >>> Gli altri sistemi client configurati per puntare a piu' server ldap, di >>> solito, lavorano cosi'. >>> >>> Marco >>> >>> 2011/3/25 Luigi Augello <lauge...@unipa.it> >>> >>>> Salve >>>> Ho necessità che il mio server samba utilizzi più backend, in pratica se >>>> non trova l'utente in un database ldap , interrogi il successivo, se non ho >>>> capito male in samba doverei inserire la seguente direttiva >>>> >>>> >>>> passdb backend = "ldapsam:ldap://192.168.1.60/ >>>> ldap://192.168.1.61/ldap://192.168.1.62/"; >>>> >>>> Non ho modo di provarlo, qundi mi cheidevo se qualcuno può darmi conferma. >>>> Grazie >>>> LUigi Augello >>>> >>>> Ok, provo a fare un po' di chiarezza... - Hai 2 server remoti sui quali non hai accesso diretto - Hai 1 tuo server locale (serverA) sul quale: - hai definito syncrepl come consumer dei 2 server remoti - hai usato lo stratagemma del glue per consentire di miscelare dati replicati (dai server remoti) con dati salvati esclusivamente in locale - Hai 1 tuo server locale (serverB) che vuoi configurare semplicemente come replica di tutto il contenuto di serverA: dati locali + dati remoti E' uno scenario su cui non ho esperienza diretta. Qui Luca ci puo' sicuramente venire in aiuto. Molto probabilmente avrai bisogno di definire su serverA l'overlay syncprov, in quanto serverA (oltre che essere consumer dei server remoti) deve diventare a sua volta producer di serverB. Quello di cui non sono sicuro e' se: - va fatto a livello di (ogni) singolo database di serverA - configurando back_meta, se va fatto a livello di meta - avendo usato glue, e quindi avedo detto a slapd che il database "logico" e' uno solo, se e' sufficiente impostarlo sul database "radice" M. P.s. In merito alla tua domanda sulla direttiva "database meta", leggi qua: http://www.manpagez.com/man/5/slapd-meta/ Guarda la sezione SCENARIOS
_______________________________________________ OpenLDAP mailing list OpenLDAP@mail.sys-net.it https://www.sys-net.it/mailman/listinfo/openldap
