Il giorno mer, 06/05/2009 alle 15.21 +0200, Pierangelo Masarati ha scritto: > Michele Codutti wrote: > > Salve a tutti, sto migrando dalla release 2.3.30 di OpenLDAP alla 2.4.11 > > in conseguenza della migrazione da Debian Etch a Lenny. > > La configurazione che ho utilizzato non è cambiata nel passaggio da una > > versione all'altra e nemmeno il database da gestire. > > Ho notato subito una differenza che mi crea qualche dubbio. > > Essendo il servizio LDAP clusterizzato, effettuo ad intervalli regolari, > > la seguente query per testare l'effettiva salute del servizio: > > ldapsearch -LLL -x -h localhost -b '' -s base '(objectclass=*)' > > namingContexts > > Ora mentre con la versione 2.3 ottenevo il seguente risultato: > > namingContexts: dc=example,dc=com > > Ora ricevo una risposta vuota (nessun errore ma nemmeno nessun > > risultato). > > > > Inoltre ho notato che quando mi collego al server utilizzando Apache > > Directory Studio ricevo un warning con il seguente messaggio: > > 'Open Connection' has encountered a problem. > > - Missing schema location in RootDSE, using default schema. > > Sul log del server trovo le seguenti entry relative alla connessione di > > cui sopra: > > conn=3 fd=16 ACCEPT from IP=192.168.1.100:40533 (IP=0.0.0.0:389) > > conn=3 op=0 BIND dn="cn=admin,dc=example,dc=com" method=128 > > conn=3 op=0 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 > > conn=3 op=0 RESULT tag=97 err=0 text= > > conn=3 op=1 SRCH base="" scope=0 deref=3 filter="(objectClass=*)" > > conn=3 op=1 SRCH attr=subschemaSubentry > > conn=3 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= > > conn=3 op=2 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" > > conn=3 op=2 SRCH attr=namingContexts subschemaSubentry > > supportedLDAPVersion supportedSASLMechanisms supportedExtension > > supportedControl supportedFeatures vendorName vendorVersion + > > objectClass > > conn=3 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= > > conn=3 op=3 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" > > conn=3 op=3 SRCH attr=* > > conn=3 op=3 SEARCH RESULT tag=101 err=0 nentries=0 text= > > conn=3 op=4 SRCH base="dc=uniud,dc=it" scope=0 deref=3 > > filter="(objectClass=*)" > > conn=3 op=4 SRCH attr=hasSubordinates objectClass > > conn=3 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text= > > > > C'è qualcosa che è cambiato di cui dovrei essere a conoscenza e che mi è > > sfuggito? > > Sembra un problema di ACL (non ricordo se sono cambiate). Prova a > mettere esplicitamente leggibile il rootDSE nelle ACL globali. Ovvero, > prima di ogni database, aggiungi > > access to dn="" by * read > access to dn="cn=subschema" by * read > > Ciao, p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: a...@sys-net.it > ----------------------------------- > > Ho provato a testare le ACL che hai suggerito ma il risultato non cambia. NB: questo problema lo rilevo anche quando faccio la query con il rootdn, con questo utente le ACL non dovrebbero avere nessuna influenza giusto?
-- Michele Codutti Centro Servizi Informatici e Telematici (CSIT) Universita' degli Studi di Udine via Delle Scienze, 208 - 33100 UDINE tel +39 0432 558928 fax +39 0432 558911 e-mail: michele.codutti at uniud.it
_______________________________________________ OpenLDAP mailing list OpenLDAP@mail.sys-net.it https://www.sys-net.it/mailman/listinfo/openldap
