Ok, per il read-only non ho problemi perche', ancora in questa fase, tutti quelli che cercano di modificare puntano ancora secchi alla macchina 1. Ma cmq se volessi metterlo read-only, ho visto che la direttiva "readonly" lavora per singolo database. Nessun problema per me, ma sono cmq curioso di sapere se esiste anche una direttiva (o un metodo) globale che mi metta in readonly tutti i database, magari sia fisici che virtuali (es. back-ldap/back-meta).
Grazie ancora! Marco 2010/4/25 Luca Scamoni <luca.scam...@gruppopa.it> > Immagini correttamente > La scaletta è buona. Io aggiungerei che nel tempo in cui fai l'attività sul > nodo 1 il nodo 2 deve essere read-only > ciao > Il 23/04/2010 21:20, Marco Pizzoli ha scritto: > > 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 > > > > -- > > *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
