Implementare un'architettura ridondante master/slave OpenLDAP: differenze tra le versioni

===Versioni compatibili===

===Introduzione===

Le vecchie versioni di OpenLDAP usavano un modello <tt>push</tt> per la replica. Questo modello si basava sull'assunto che il server LDAP master eseguisse periodicamente un push dei propri dati verso i server LDAP slave, utilizzando un modulo chiamato <tt>slurpd</tt>. Le nuove versioni di OpenLDAP hanno introdotto un modello di replica <tt>pull</tt>, appoggiato ad un modulo chiamato <tt>syncrepl</tt>.

Debian Etch 4.0 installa OpenLDAP 2.3, che supporta entrambi i moduli, ma dalla versione 2.4 OpenLDAP eliminerà il supporto al modulo <tt>slurpd</tt> (come si legge nella documentazione ufficiale di OpenLDAP 2.4). Pertanto in questa guida verrà preso in considerazione l'approccio <tt>syncrepl</tt> alla replicazione di LDAP, in modo da garantirci possibilità di aggiornamento dell'infrastruttura.

===Il master server LDAP===

Il master server LDAP su cui ci baseremo viene usato per fornire servizi di autenticazione centralizzata agli utenti Samba e Unix così come indicato da [[Samba e OpenLDAP: creare un controller di dominio con Debian Etch | questa guida]]. I files di configurazione di OpenLDAP sono perciò gli stessi presenti nella guida indicata; sono state evidenziate in '''grassetto''' le modifiche e/o le aggiunte rispetto ai files originali di partenza della guida, modifiche necessarie per convertire il master server LDAP in un provider (il termine usato da OpenLDAP per indicare il server che fornisce i dati a <tt>syncrepl</tt> affinchè vengano trasferiti a un consumer o slave server LDAP).<br/>

'''File <tt>/etc/ldap/slapd.conf</tt>''':<br/><br/>

: # Schema and objectClass definitions

: include /etc/ldap/schema/core.schema

: include /etc/ldap/schema/cosine.schema

: include /etc/ldap/schema/nis.schema

: include /etc/ldap/schema/inetorgperson.schema

: include /etc/ldap/schema/samba.schema

Da notare che la configurazione prevede che venga aggiunto al database LDAP un nuovo utente (<tt>uid=replicant,ou=Users,dc=dominio,dc=local</tt>) per le operazioni di sincronizzazione tra i due server. Creiamo quindi il nuovo utente, utilizzando i soliti smbldap-tools:

All'interno del file di configurazione <tt>/etc/ldap/slapd.conf</tt> sono state poi inserite le direttive:

<tt>

: moduleload syncprov

: index entryCSN,entryUUID eq

: overlay syncprov

: syncprov-checkpoint 100 10

: syncprov-sessionlog 200

</tt>

Queste direttive servono per configurare il modulo <tt>syncprov</tt> che ha il compito di tracciare i cambiamenti nel database LDAP e di marcarli per renderli identificabili dallo slave server LDAP, affinchè vengano replicati.<br/>

===Lo slave server LDAP===

: '''syncrepl rid=1'''

: '''provider=ldap://INDIRIZZO.IP.DEL.MASTER:389'''

: '''type=refreshAndPersist'''

: '''searchbase=”dc=dominio,dc=local”

: '''filter=”(objectClass=*)”'''

: '''scope=sub'''

: '''schemachecking=off'''

: '''bindmethod=simple'''

: '''binddn=”uid=replicant,ou=Users,dc=dominio,dc=local”'''

: '''credentials=Password_Impostata_per_Utente_Replicant'''

Il server slave LDAP è configurato per connettersi al server master avente indirizzo IP INDIRIZZO.IP.DEL.MASTER e in ascolto sulla porta 389. Le direttive <tt>searchbase=”dc=dominio,dc=local”</tt> e <tt>filter=”(objectClass=*)”</tt> assicurano che tutti i dati del dominio saranno replicati. Il server slave, infine, si connette al master utilizzando le credenziali dell'utente <tt>replicant</tt> che abbiamo creato in precedenza e a cui già abbiamo dato permessi di completa lettura sul database LDAP del server master.<br/>

Su entrambi i server è stata impostata la direttiva <tt>loglevel sync</tt>, che avrà come risultato un logging dettagliato delle attività di OpenLDAP sul server Syslog di default.<br/>

E' da notare il fatto che utilizzando questo sistema di configurazione è possibile installare più di un server slave LDAP.<br/>

===Modifica dei servizi che utilizzano LDAP===

====Samba====

Vanno modificati i files:

* <tt>'''/etc/smbldap-tools/smbldap.conf'''</tt><br/>

<tt>

: slaveLDAP="127.0.0.1"

: slavePort="389"

: masterLDAP="127.0.0.1"

: masterPort="389"

</tt>

* <tt>'''/etc/samba/smb.conf''''</tt><br/>

<tt>

: passdb backend = ldapsam:ldap://127.0.0.1

</tt>

<tt>

: passdb backend = ldapsam:"ldap://IP.MASTER ldap://IP.SLAVE"

</tt>

====Client LDAP====

* <tt>'''/etc/ldap/ldap.conf'''</tt>

<tt>

: URI ldap://localhost

</tt>

va sostituito con

<tt>

: URI ldap://IP.MASTER ldap://IP.SLAVE

</tt>

====Autenticazione Unix====

* <tt>'''/etc/libnss-ldap.conf'''</tt>

<tt>

: URI ldap://localhost

</tt>

va sostituito con

<tt>

: URI ldap://IP.MASTER ldap://IP.SLAVE

</tt>

===Verifiche Finali===

Dopo qualche tempo i due server LDAP dovrebbero essersi sincronizzati e una ricerca effettuata con <tt>ldapsearch</tt> sul master server dovrebbe dare gli stessi risultati di una effettuata sullo slave server:

</pre>.

Se si rende necessaria una risincronizzazione completa dello slave server, è possibile riavviare il demone <tt>slapd</tt> dopo aver inserito la riga seguente nel suo file di configurazione <tt>/etc/default/slapd</tt>:

Non dimentichiamoci, a risincronizzazione avvenuta, di arrestare nuovamente il demone, eliminare o commentare la riga aggiunta e riavviare <tt>slapd</tt>.

<br/>

<br/>

: [[Utente:Ferdybassi|Ferdybassi]]

[[Categoria:Server]]

[[Categoria:Networking]]