Mandi! Pierangelo Masarati
  In chel di` si favelave...

> Suggerisco vivamente di fare riferimento alla guida 
> (<http://www.openldap.org/doc/admin23/>, in particolare 
> <http://www.openldap.org/doc/admin23/syncrepl.html>), che e' stata di 
> molto migliorata (e lo sara' parecchio di piu' con 2.4, c'e' una persona 
> che si occupa "a tempo pieno" dell'aggiornamento dei documenti).

Due note. La guida è sicuramente molto chiara, ma mi è sembrata un
ninin poco 'pratica': in fase di detup 'sul campo' ho incontrato dei
problemi che ho risolto solo con google.
Alcune cose non me le spiego, e quindi vi stresso. ;)

Innanzitutto una inezia: il modulo va caricato!!! dieciminuti di
panico per questo... ;)))

La mia configurazione sul master ora è:

  # Questo è il master, istanziamo l'overlay di replica.
  #
  moduleload      syncprov
  overlay syncprov
        syncprov-checkpoint 100 10
        syncprov-sessionlog 100   

  # Diamo profondità di ricerca senza limiti all'utente di replica
  #
  limits dn.exact="cn=replica,dc=sv,dc=lnf,dc=it" time.soft=unlimited 
time.hard=unlimited size.soft=unlimited size.hard=unlimited

la riga che toglie all'utente usato ogni limite l'ho trovata nel wiki
di samba, e mi è parsa una buona idea:
        
http://wiki.samba.org/index.php/2.0:_Configuring_LDAP#2.2.2._slapd.conf_Master_delta-syncrepl_Openldap2.3

e poi ovviamente su ogni ACL ho aggiunto un:

  by dn="cn=replica,dc=sv,dc=lnf,dc=it" read

Prima domanda: è possibile, invece di andare a modificare ogni ACL
aggiungere una ACL su match wildcard (*) ma che venga usata solo per un
dato utente?

Ho provato ad aggiungere una entry come:

  access to *
          by dn="cn=replica,dc=sv,dc=lnf,dc=it" read

ma poi vengono, e credo anche giustamente per come è costruito il
parser, saltate tutte le altre.


Sullo slave ho invece:

  # Questo è lo slave, configuriamo il poller
  #
  syncrepl rid=1
        provider=ldaps://ldap.sv.lnf.it/
        type=refreshAndPersist
        retry="60 +"
        searchbase="dc=sv,dc=lnf,dc=it"
        filter="(objectClass=*)"
        scope=sub
        attrs="*,+"
        schemachecking=off
        bindmethod=simple 
        binddn="cn=replica,dc=sv,dc=lnf,dc=it"
        credentials=nontelado

  # Ovviamente abilitiamo l'updateref per disabilitare le operazioni di
  # scrittura
  # e ridirezionarle al master
  #
  updateref ldaps://ldap.sv.lnf.it/


Finalmente i due alberi LDAP si sincronizzano da soli, è moooolto
carino semplicemente 'rasare' lo slave e vedere che in pochi secondi si
è ripreso tutto...


Seconda domanda: i due documenti del samba wiki fanno riferimento
entrambi all'utilizzo di 'rootdn', che nella configurazione standard
debian è commentato.

Scommentato, l'unica differenza che noto è che le ACL vengono
bellamente ignorate (stampa un warning slapd, anche) e che non c'è
nessun limite, ergo 'rootdn' è a quel punto veramente a potete totale.
La cosa sinceramente non mi dispiace, mi chiedo quali criteri ci siano
dietro al non abilitare la 'rootdn', e ad aggiungere invece ACL e
eliminazione di limitazioni specifiche.

Grazie.

-- 
dott. Marco Gaiarin                                 GNUPG Key ID: 240A3D66
  Associazione ``La Nostra Famiglia''                http://www.sv.lnf.it/
  Polo FVG  -  Via della Bontà, 7 - 33078  -  San Vito al Tagliamento (PN)
  marco.gaiarin(at)sv.lnf.it      tel +39-0434-842711  fax +39-0434-842797



_______________________________________________
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap


Rispondere a