2013/12/5 Francesco Malvezzi <francesco.malve...@unimore.it>:
> Ciao a tutti,
Ciao
> Ma voi come gestite i referral ombra? Ho dei problemi a identificare una
> strategia intelligente di equilibrio tra liberta' negli slave e
> facilita' di sincronizzazione con i master.
>
> Ad esempio: e' comodissimo mettere l'albero cn=schema,cn=config in
> replica dal master, cosi' quando di cambia uno schema le variazioni
> arrivano a tutti gli slave.
>
> Pero' se faccio cosi' l'intero albero cn=config diventa uno shadow referral.
>
> Come faccio a cambiare una acl su un cn=config in replica?
Premetto che il tuo scenario non l'ho mai sperimentato in prima
persona e quindi non posso darti una soluzione provata e testata.
Posso solo ipotizzare una soluzione...
Prima di tutto, essendo la tua topologia master/slave allora si' il
tuo slave non si lascia modificare esternamente. Devi dirgli di
diventare un master, creare quindi un cluster multi-master, anche se
di fatto poi ai tuoi slave non dirai di replicarsi.
Cmq la replica la fai per mezzo di un utente, che non per forza deve
essere cn=manager. Potresti usare un tuente tecnico dedicato con i
privilegi minimi necessari (read-only) per leggere la conf. Usando le
ACL gli potresti proibire di leggere le ACL stesse, quindi evitando
che esse vengano modificate dal meccanismo di replica.
> Adesso edito a mano con vim il file dentro slapd.d/cn=config, ma c'e' un
> modo piu' furbo?
Questo e' il meccanismo ufficialmente SBAGLIATO per modificare
cn=config. In futuro potrebbero cambiare il formato di "storing" del
backend senza dirti niente e ti ritrovi fregato.
Lo sai vero che eventualmente esiste (oltre al normale ldapmodify)
l'utility slapmodify che ti consente di editare la conf a sistema
spento?
> E poi: se cn=config diventa uno shadow referral e' una strada di sola
> andata? Come faccio a liberare cn=config?
>
> Con un ldif cosi':
> dn: olcDatabase={0}config,cn=config
> changetype: modify
> delete: olcSyncrepl
>
> ottengo:
> sudo ldapmodify -H ldapi:/// -Y EXTERNAL -f free_replica.ldif
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> modifying entry "olcDatabase={0}config,cn=config"
> ldap_modify: Server is unwilling to perform (53)
> additional info: shadow context; no update referral
La (possibile) risposta te l'ho data sopra. Se la provi, poi fammi
sapere come va.
> Ho poi anche un quesito operativo: come faccio a passare da hdb a mdb su
> due server in mirrormode? Siccome il database secondo lui e' in replica
> non mi fa fare variazioni, neanche a mano con il vim (mi spiego meglio:
> pensavo che cancellare le due direttive olcSyncrepl e olcMirrorMode
> fossero sufficienti per liberare il database, poi avrei fatto il
> passaggio a mdb, riavviato il nodo vuoto e atteso il ripopolamento delle
> utenze e ripetuto con l'altro nodo -- non funziona: non si riavvia
> neppure).
Hai provato con slapmodify a slave spento?
Se segui il mio suggerimento di usare un utente tecnico dedicato per
la replica, anche questa parte di conf dovrai inibirla via ACL...
>
> ciao e grazie!
>
> Francesco
Fammi sapere
Ciao
Marco
> _______________________________________________
> OpenLDAP mailing list
> OpenLDAP@mail.sys-net.it
> https://www.sys-net.it/mailman/listinfo/openldap
_______________________________________________
OpenLDAP mailing list
OpenLDAP@mail.sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap
