Grazie per la dritta. La mia architettura e' composta da 2 nodi multi-master. Se faccio l'attivita' in un nodo, immagino di non poter sperare in una sincronizzazione funzionante sull'altro, per lo stesso motivo per il quale mi falliscono gli ldapadd/ldapmodify...
Se mi confermi questo... poi come posso pensare di fare l'attivita' con il minimo disservizio? Questa puo' essere una scaletta? - Fermo una macchina e faccio l'attivita' su di essa - Riaccendo la macchina e impedendo che possa replicare sull'altra (iptables, ad esempio..) - Fermo la seconda, cancello il database e, facendola ripartire, lascio che si popoli via replica Grazie ancora Marco 2010/4/23 Luca Scamoni <luca.scam...@gruppopa.it> > Ciao Marco, > temevo fosse il glue... > In poche parole è un meccanismo per mantenere coerenza nell'albero quando > si fanno move di oggetti. Nel tuo caso la move è fallita e OpenLDAP ha > "costruito" una entry glue per mantenere la consistenza... in qualche modo. > Temo che l'unica possibilità, ma Pierangelo magari mi può smentire, sia > quello di fare uno slapcat, modificare la entry fantasma in modo che sia > corretta e ricaricare da capo... > > Il 23/04/2010 18:22, Marco Pizzoli ha scritto: > > > Ciao Luca. > Ho indagato a mente lucida e noto questa cosa. > > Questo e' il nodo per me "fantasma": > > dn: cn=linux,ou=Service,dc=lan,dc=pippo.it > entryUUID: faf161b6-5769-102b-8dcc-f9b8eb6647eb > creatorsName: cn=Manager,dc=lan,dc=pippo.it > createTimestamp: 20070223091416Z > entryCSN: 20070223091416.000000Z#000002#000#000000 > modifiersName: cn=Manager,dc=lan,dc=pippo.it > modifyTimestamp: 20070223091416Z > objectClass: top > objectClass: glue > structuralObjectClass: glue > > > E questo invece un nodo gemello che "funziona" come serve a me. > > dn: cn=webmin,ou=Service,dc=lan,dc=pippo.it > objectClass: top > objectClass: device > cn: webmin > structuralObjectClass: device > entryUUID: faf5db4c-5769-102b-8dd2-f9b8eb6647eb > creatorsName: cn=Manager,dc=lan,dc=pippo.it > createTimestamp: 20070223091416Z > entryCSN: 20070223091416.000000Z#000008#000#000000 > modifiersName: cn=Manager,dc=lan,dc=.it > modifyTimestamp: 20070223091416Z > > Quello che capisco e' che mi si e' "corrotto" il tipo dell'oggetto. Adesso > la sua objectClass e' di tipo "glue". Mi puoi spiegare (o indirizzare ad una > spiegazione chiara su) che tipo di objectClass e' ? > > Esiste un qualche modo per far tornare il nodo > "cn=linux,ou=Service,dc=lan,dc=pippo.it" ad essere speculare all'altro > nodo "cn=webmin,ou=Service,dc=lan,dc=pippo.it"? > Provando con delle ldapadd e ldapmodify mi dice "ldapadd: Already exists > (68)". > > Il nodo "cn=linux,ecc..." ha sotto tanti nodi figli che continuano ad > esistere e ad essere acceduti. > > Grazie > Marco > > > > > > > > > 2010/4/22 Luca Scamoni <luca.scam...@gruppopa.it> > >> posso confessarti di essermi perso nella decrizione? >> non potresti farci vedere gli ldif nei vari casi? >> >> Il 20/04/2010 15:28, Marco Pizzoli ha scritto: >> >> Ciao, >> mi e' accaduto un problema con il mio albero LDAP degli utenti. >> Con phpmyadmin ho tentato di fare una copia di un nodo in un sottoramo >> diverso e la copia mi e' fallita con un errore di "objectClass violation". >> Vabbe', staro' piu' attento la prossima volta... :-) >> >> Il problema e' che adesso non riesco piu' a vedere il nodo padre di quello >> che stavo copiando, ne' da phpmyadmin ne' facendo una ldapsearch "mirata": >> ldapsearch -s one -b "ou=nodo_padre,dc=suffix_root" >> >> Mi sarei aspettato di vedere elencato anche il mio nodo >> "cn=nodo_target,ou=nodo_padre,dc=suffix_root" ed invece mi compaiono >> soltanto i 2 suoi fratelli. >> La cosa interessante e' che invece con slapcat vedo che esiste una entry >> "dn: cn=nodo_fantasma,ou=nodo_padre,dc=suffix_root". >> >> Mi sapete dire in che situazione mi trovo? >> Come posso risolvere il problema di non "trovare" il nodo fantasma facedo >> una ldapsearch come quella indicata? >> >> Grazie in anticipo >> Marco >> >> >> -- >> _________________________________________ >> Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. >> Jim Morrison >> >> >> _______________________________________________ >> OpenLDAP mailing >> listopenl...@mail.sys-net.ithttps://www.sys-net.it/mailman/listinfo/openldap >> >> >> >> -- >> >> *Luca Scamoni >> * >> *Gruppo Partners Associates* >> Tel. Milano +39 02 67380435* *- Udine +39 0432 689815 - Roma +39 06 >> 54832300 >> Fax Milano +39 02 67386214 - Udine +39 0432 570120 - Roma +39 06 91659273 >> Cell. +39 348 0471710 >> Email: luca.scam...@gruppopa.it >> Sito: *www.GruppoPA.it* <http://www.GruppoPA.it> >> >> >> Prima di stampare, pensa all'ambiente ** Think about the environment >> before printing >> >> _______________________________________________ >> OpenLDAP mailing list >> OpenLDAP@mail.sys-net.it >> https://www.sys-net.it/mailman/listinfo/openldap >> >> > > > -- > _________________________________________ > Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. > Jim Morrison > > > > -- > > *Luca Scamoni > * > *Gruppo Partners Associates* > Tel. Milano +39 02 67380435* *- Udine +39 0432 689815 - Roma +39 06 > 54832300 > Fax Milano +39 02 67386214 - Udine +39 0432 570120 - Roma +39 06 91659273 > Cell. +39 348 0471710 > Email: luca.scam...@gruppopa.it > Sito: *www.GruppoPA.it* <http://www.GruppoPA.it> > > > Prima di stampare, pensa all'ambiente ** Think about the environment before > printing > > _______________________________________________ > OpenLDAP mailing list > OpenLDAP@mail.sys-net.it > https://www.sys-net.it/mailman/listinfo/openldap > > -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison
_______________________________________________ OpenLDAP mailing list OpenLDAP@mail.sys-net.it https://www.sys-net.it/mailman/listinfo/openldap
