Ciao Luca, Grazie delle informazioni, per quanto riguarda il db ti ringrazio dei consigli, io sono arrivato in questo progetto che era già abbondantemente avviato e sto cercando di aggiornare le versioni e migliorare le performance (con risultati altalenanti :-) ).
Ma come avrai capito dalle mie mail non sono un esperto di openLdap. Se posso farti alcune domande riguardo hai due db che mi hai suggerito quale dei due è più performante in termini di lettura/scrittura? dbd o hdb? Ed in ottica di utilizzare il syncrepl? Nel nostro ldap sono attive le ppolicy. La dimensione del nostro db è circa 250 Mb. Il db è composto da 16 file (cpn estensione dbb). Seguendo le tue indicazioni sto scaricando la versione 2.3.39 hai qualche suggerimento per la compilazione? Grazie per la Tua disponibilità. Saluti, Mirko. -----Messaggio originale----- Da: Luca Scamoni [mailto:[EMAIL PROTECTED] Inviato: venerdì 9 novembre 2007 9.13 A: Stefanelli Mirko Cc: [email protected]; [EMAIL PROTECTED] Oggetto: Re: [OpenLDAP] (grossi) problemi con syncrepl Stefanelli Mirko wrote: > > Ciao a tutti, > > > > Ho alcuni problemi con la replica attraverso syncrepl. > > > > Ho creato un utente per il syncrepl che si chiama syncuser e questo > utente ha > > i seguenti diritti di accesso specificati sul file slapd.conf: > > > > by dn="cn=syncuser,ou=Profile,dc=xxxxx,dc=xxxxxx,dc=xxxxx" read > > > > il master e configurato per il syncprov con i seguenti parametri: > > > > overlay syncprov > > syncprov-checkpoint 100 10 > > syncprov-sessionlog 100 > > > > > > mentre la parte slave è configurata nel seguente modo: > > > > syncrepl rid=001 > > provider=ldap://10.10.216.167:890 > > type=refreshOnly > > interval=00:00:02:00 > > retry="15 10 120 +" > > searchbase="dc=xxxxx,dc=xxxxxxxxxx,dc=xxxxx" (root dell'albero) > > filter="(objectClass=*)" > > attrs="*" > > scope=sub > > schemachecking=off > > bindmethod=simple > > > binddn="cn=syncuser,ou=Profile,dc=xxxx,dc=xxxxxxxxxxx,dc=xxxxxx" > > credentials=xxxxxx > > > > updateref ldap://10.10.216.167:890 > > > > Ho effettuato le seguenti prove con risultati disastrosi: > > > > 1) slave senza db, al memento dello startup dello slave il suo db > inizia a popolarsi ma dopo 8h di attesa > > si è popolato solo parzialmente (lo slapd slave e configurato per > tracciare le info relative al syncrepl (-d 16384) > > > > nel di log trovo un mare di righe tipo queste: > > > > syncrepl_entry: rid 001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) > > syncrepl_entry: rid 001 be_search (0) > > syncrepl_entry: rid 001 > uid=DC_PIPPO|rm_ip2|434212|USER43|People,ou=expiredAccounts,dc=xxxx,dc=xxxxxxx,dc=xxxx > > syncrepl_entry: rid 001 be_add (0) > > syncrepl_entry: rid 001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) > > syncrepl_entry: rid 001 be_search (0) > > syncrepl_entry: rid 001 > uid=DC_PIPPO|rm_ip3|434212|USER43|People,ou=expiredAccounts,dc=xxxx,dc=xxxxxxx,dc=xxxxx > > syncrepl_entry: rid 001 be_add (0) > > syncrepl_entry: rid 001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) > > syncrepl_entry: rid 001 be_search (0) > > syncrepl_entry: rid 001 > uid=DC_PIPPO|rm_ip4|434212|USER43|People,ou=expiredAccounts,dc=xxxxx,dc=xxxxx,dc=xxxxx > > syncrepl_entry: rid 001 be_add (0) > > request done: ld 13bb588 msgid 2 > > do_syncrep2: rid 001 LDAP_RES_SEARCH_RESULT > > > > se effettuo delle query con ldapsearch (da riga di comando vedo che > nel db sono presenti alcune entry con ou=expiredAccounts, > > ma attreverso un qualsiasi browser non è visibile tale ramo. > > > > > > 2) Test con i due DB allineati, ho effettuato diverse prove sia > effettuando cancellazioni che inserimenti sul master ed > > il risultato è sempre il medesimo il Master si impalla e non si ferma > inviando il comando kill -15 <pid>. Non è > > più possibile lavorare con il master ne utilizzando vari browser ne da > riga di comando, l'unica soluzione per fermarlo > > è il kill -9 e una successiva ripartenza. > > Per ogni prova effettuavo un refresh del db (cancellazione dei file di > dati e slapadd da file ldif) > > > > Alcune informazione la versione openldap è la 2.3.38 sia per il master > sia per lo slave, girano su sistemi solaris 9. > > Il tipo di db che utilizziamo è ldbm e le entry presenti nel db > (intendo dn) sono 132285. > > > > Qualche suggerimento? o idea? > Intanto ci sono poche informazioni. Il db quanto e' grande? 8 ore possono essere tante o poche a seconda della dimensione del DB. Poi non sappiamo se il db master esisteva gia' o e' stato caricato da zero con slapadd. Nel qual caso hai usato il flag -w per far aggiornare il contextCSN con il piu' alto contextCSN generato? Ancora, openldap-2.3.38 non e' l'ultima versione rilasciata. La 2.3.39 fixa alcuni bug proprio su syncrepl. Dal punto di vista della configurazione: schemachecking=on e attrs="*,+" potrebbero aiutarti Le righe che trovi nel log dicono che le macchine si stanno sincronizzando. La replica trova una entry sul master e la aggiunge (i result code sono 0) correttamente. Il fatto che ldapsearch trovi le entry vuol dire che funziona. Il fatto che i "browser" non le trovino vuol dire che sono mal configurati. Infine... ldbm e' obsoleto e deprecato (da anni). Nella versione 2.4 e' stato completamente rimossso (cosi' come slurpd). Ci sono vari warning nella documentazione sul fatto che syncrepl non funziona (bene) con ldbm. Perche' continuare a farsi del male? Passa a bdb o hdb e vedrai che tutto funziona perfettamente. Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Mobile: +39 347 1014425 Email: [EMAIL PROTECTED] ----------------------------------- _______________________________________________ OpenLDAP mailing list [email protected] https://www.sys-net.it/mailman/listinfo/openldap
