Newsgroup: it.comp.os.linux.sys
Titolo: OpenLDAP e repliche

Ho installato OpenLDAP in configurazione master-slave su due server e
tutto funziona correttamente, compresa la replica. Se scrivo sul master
le modifiche vengono sincronizzate con lo slave, mentre sullo slave non
posso scrivere, e questo mi sembra di aver capito che sia normale.
Nel file di configurazione slapd.conf del master ho le righe:
replica         uri=ldap://
192.168.1.59:389
 bindmethod=simple
binddn="cn=replicator,dc=test,dc=org" credentials=miapas
replogfile      /var/lib/ldap/replog
mentre nello slave:
updatedn        "cn=replicator,dc=test,dc=org"
access to *
        by dn="cn=admin,dc=test,dc=org" write
        by dn="cn=replicator,dc=test,dc=org" write
        by * read
Ho creato l'utente replicator nel master per la replica e questo
utente deve ovviamente avere permessi in scrittura nel database slave.
Fin qui tutto ok, ora il mio problema. 
Voglio avere la possibilità di avere la continuità del servizio LDAP
anche nel caso in cui il master sia down, e così ho fatto in modo che
ogni server sia contemporaneamente master e slave, ho inserito cioè sia
la direttiva 'replica' che 'updatedn' in entrambi i file di
configurazione, ma questo purtroppo non funziona. Riesco a leggere ma
non a scrivere, in nessuno dei due server.
Mi è sfuggita qualche opzione? E' il modo corretto di procedere? Ho già
letto l'administrator guide che si trova nel sito di OpenLDAP, ma non ne
parla. Come si fa per avere un LDAP in mirroring?
Grazie,
  Ivan
-- 
I am the "ILOVEGNU" signature virus. Just copy me to your signature.
This email was infected under the terms of the GNU General Public License.

 E' il modo corretto di procedere?
No.
Hai già un servizio ridondato, istruisci tutti ad usare tutti e due i
server. Così se il master cade tutto continua a funzionare, e la tua unica
preoccupazione deve essere di fare ripartire il master.
O promuovere a master lo slave.
Non certo di continuare ad aggiungere entry.
-- 
Luca Villani     NOC Manager  -  Wireless Solutions S.p.A.  (Dada Group)
http://www.wseurope.com
          via Castiglione 25, 40124 Bologna Italy
T:
+39 051 2966826
   F:
+39 051 2966800
   M:
+39 348 5298542
   UIN:76272621
GPG public key available

 O promuovere a master lo slave.
Questa potrebbe essere la soluzione, ma come fare? OpenLDAP lo prevede
con qualche opzione o metto in cron uno script bash che ogni minuto
controlla se la 389 del master risponde e in caso negativo esegue un
reload di slapd sullo slave leggendo un slapd-master.conf?
Quando e se il master torna su devo anche riconfigurarlo per farlo
diventare slave in modo che si sincronizzi... mi sembra un accrocchio.
Grazie per la risposta,
-- Ivan

 giusto? Il problema sollevato è proprio questo.
Che non e` un problema: hai un server|servizio giu`, il vero problema e` di
ritirarlo su, non di inserire nuove entry.
Se il problema fosse inserire comunque nuove entry, allora hai sbagliato a
scegliere LDAP, le prestazioni sono troppo sbilanciate in favore della
lettura per essere considerato un backend qualsiasi per la memorizzazione.
Tanto per capirci un po' di piu`, per cosa lo usi?
-- 
Ciao da Villo    -    GPG public key available
                      Ferrara LUG 
http://ferrara.linux.it
        Remove "+settanta" for email replies
Protect your Freedom: 
http://www.againsttcpa.com/index.shtml

 non a scrivere, in nessuno dei due server.
aaahhh!!!! tragedia!!!! non sta farlo!!! rischi di avere dei loop!!!!
cerca replica multimaster piuttosto, è fatta apposta!

 Tanto per capirci un po' di piu`, per cosa lo usi?
LDAP deve memorizzare utenti e ruoli per un sistema di strong
authentication (smartcard, token, lettore biometrico, ...).
Il problema è aggiungere utenti o cambiare ruoli anche in caso di
malfunzionamenti di uno dei due (o più) server, compreso il master.
A questo punto era meglio utilizzare un db relazionale (oracle,
postgres, mysql) per avere una replica simmetrica.
Grazie,
-- Ivan

 mysql) per avere una replica simmetrica. 
Per MySQL, il supporto ad una replica simmetrica si ha solo a costo di una
notevole complessità a livello applicativo (ci si deve fare carico di tutti
i lock esplicitamente). Però ci sarebbe la soluzione MySQL Cluster.


> cerca replica multimaster piuttosto, è fatta apposta!
Eccola, multimaster era la parolina magica che cercavo, da inserire su
google.
Grazie,
-- Ivan

 sbagliata, in quanto AFAIK è *molto* indietro sulla replica multimaster.
Ti ringrazio ancora degli ottimi consigli, purtroppo la scelta di usare
LDAP è proprio un requisito progettuale, giusta o sbagliata che sia.
Ora si tratta di scegliere tra una replica "normale" o multimaster.
Perché consideri indietro la replica multimaster? Non la ritieni matura
per ambienti di produzione?
Grazie,
-- Ivan

 per ambienti di produzione?
Sono loro stessi a definirla sperimentale.
IMHO ti conviene cercare di convincere i progettisti che se va giù il 
master la cosa migliore da fare è di non accettare modifiche.
Basta imparare da Microsoft: non è un bug, è una feature, visto che 
obbliga il team di supporto ad intervenire immediatamente in casi di 
failure al sistema... ;-)
