====== Replica di LDAP con Syncrepl ======

Installare i pacchetti Debian

  * **slapd**
  * **ldap-utils**

Viene chiesta la password di amministratore LDAP, potrà essere diversa da quella dell'amministratore master?

  * [[http://www.openldap.org/doc/admin22/syncrepl.html|LDAP Sync Replication]]
  * [[http://times.usefulinc.com/2008/06/20-secure-ldap|Secure LDAP replication]]

===== Configurazione LDAP master server =====

Nella sezione globale di **''/etc/ldap/slapd.conf''** si aggiunge il caricamento del **modulo syncprov** (i moduli sono in ''/usr/lib/ldap/''):

<file>
moduleload syncprov
</file>

Nella sezione relativa al database da esportare si dichiara l'uso dell'**overlay syncprov**:

<file>
database        hdb
overlay         syncprov
</file>

===== Configurazione LDAP slave server =====

**''/etc/ldap/slapd.conf''**

Si deve aggiungere la dichiarazione del **rootdn** e il necessario per la replica

<file>
rootdn "cn=admin,dc=rigacci,dc=org"

syncrepl rid=001
    provider=ldaps://ldap.rigacci.org/
    tls_reqcert=allow
    type=refreshAndPersist
    retry="60 +"
    searchbase="dc=rigacci,dc=org"
    filter="(objectClass=*)"
    scope=sub
    attrs="*"
    schemachecking=off
    bindmethod=simple
    binddn="cn=admin,dc=rigacci,dc=org"
    credentials=SuperSecret
</file>

Tutte **le ACL configurate sul master** devono essere riportate anche nella configurazione dello slave (se si vuole utilizzare la stessa politica di accesso).

Volendo essere paranoici, l'accesso al master LDAP potrebbe avvenire con credenziali diverse da quelle di admin, basta creare l'account e dare le giuste credenziali sul master.

Se lo slave viene interrogato dai suoi client via ldaps, è necessario generare un certificato ed utilizzarlo:

<file>
TLSCertificateFile     /etc/ldap/tls/slaveldap.rigacci.org.pem
TLSCertificateKeyFile  /etc/ldap/tls/slaveldap.rigacci.org.pem
</file>

**''/etc/ldap/ldap.conf''**

Per accettare certificati autofirmati dal server (ed eventualmente dei mismatch tra hostname e resolv DNS):

<file>
TLS_REQCERT     never
</file>

Durante la replica lo slave si rivolge al master in qualità di client, se è necessario possedere un certificato (nel caso in cui il master accetti solo client certificati) è necessario ottenere il certificato firmato dalla CA e il certificato della CA stessa. Per utilizzarli è necessario configurare ''/etc/ldap/ldap.conf'' e assicurarsi che durante la replica siano impostate le variabili di ambiente **''LDAPTLS_CERT''** e **''LDAPTLS_KEY''**

===== Troubleshooting =====

:-) Verificare che lo slave possa accedere al master via ldaps, che le credenziali siano giuste, ecc.:

<code>
ldapsearch -v -x -H "ldaps://ldap.rigacci.org/" -D "cn=admin,dc=rigacci,dc=org" -W \
    -b "dc=rigacci,dc=org"
</code>

:-( Errore di replica, nel log dello slave si legge:

<file>
slapd[2857]: do_syncrep2: rid=123 got search entry without Sync State control
slapd[2857]: do_syncrepl: rid=123 retrying
</file>

sul master si trova un errore corrispondente:

<file>
slapd[2260]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.1.9.1.1
</file>

soluzione: sul master manca la direttiva globale **moduleload syncprov** e la dichiarazione per il database **overlay syncprov**.

:-( Altro errore, sullo slave si legge:

<file>
slapd[3068]: syncrepl_message_to_entry: rid=123 mods check 
    (objectClass: value #4 invalid per syntax)
</file>

in questo caso sullo slave manca il **samba.schema** (fornito come esempio dal pacchetto ''samba-doc'') necessario ad accettare il database:

<file>
include         /etc/ldap/schema/samba.schema
</file>

:-( Sul server slave si legge il seguente errore:

<file>
slapd[3448]: /etc/ldap/slapd.conf: line 84: rootDN must be defined before syncrepl may be used
</file>

il problema è chiaro: sullo slave è indispensabile definire il **rootdn**.