Il giorno mer, 06/05/2009 alle 17.06 +0200, Pierangelo Masarati ha scritto: > Michele Codutti wrote: > > 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? > > Il rootdn di cosa? Il rootdn e' rootdn per un database specifico, il > root DSE non ha un rootdn. Prova a vedere che cosa dicono i log di "-d > acl". > > 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 > ----------------------------------- > > Si, ho detto la cavolata. Comunque grazie all'impostazione del debuglevel a acl ho scoperto quali sono le regole che mi creano il problema: access to * by peername.ip=192.168.1.0%255.255.255.0 break by peername.ip=0.0.0.0%0.0.0.0 ssf=128 break by peername.ip=0.0.0.0%0.0.0.0 stop by * break Queste regole erano state impostate grazie ad un suggerimento richiesto in questa ML: http://www.sys-net.it/pipermail/openldap/2007-September/000736.html Servivano per imporre la cifratura per le connessioni in arrivo dall'interfaccia pubblica.
Mi ricordo che qualcosa relativamente alle ACL era cambiato ma adesso non riesco a trovare più quell'informazione mi sapete fornire qualche indicazione? Grazie -- 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
