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

Implementare un'architettura ridondante master/slave OpenLDAP (visualizza wikitesto)

Versione delle 18:20, 4 gen 2010

123 byte rimossi , 4 gen 2010

nessun oggetto della modifica

Ferdybassi

Burocrati, Amministratori

4 069

contributi

@@ Riga 1: / Riga 1: @@
-==Come implementare un'architettura ridondante master/slave OpenLDAP==
+=Versioni compatibili=
-===Versioni compatibili===
 * Debian Sarge 3.0
 * Debian Etch 4.0
 * Debian Lenny 5.0
-===Introduzione===
+=Introduzione=
 Questa guida illustra un metodo per fornire ridondanza ad una rete in cui sia presente un server OpenLDAP, in modo da avere una replica del database LDAP su un diverso server fisico che subentri automaticamente in caso di down del server principale.<br/>
 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=
 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/>
 <br/>
@@ Riga 89: / Riga 88: @@
 </pre>
-===Lo slave server LDAP===
+=Lo slave server LDAP=
 Per lo slave server LDAP è sufficiente prendere il file originale di configurazione e aggiungere la sezione in '''grassetto''':
 <br/><br/>
@@ Riga 156: / Riga 155: @@
 </pre>
-===Modifica dei servizi che utilizzano LDAP===
+=Modifica dei servizi che utilizzano LDAP=
 Una volta che abbiamo entrambi i server in funzione, ci resta da modificare la configurazione dei servizi che utilizzano LDAP.
-====Samba====
+==Samba==
 Vanno modificati i files:
 * <tt>'''/etc/smbldap-tools/smbldap.conf'''</tt><br/>
@@ Riga 178: / Riga 177: @@
 </tt>
-====Client LDAP====
+==Client LDAP==
 * <tt>'''/etc/ldap/ldap.conf'''</tt>
 <tt>
@@ Riga 187: / Riga 186: @@
 : URI ldap://IP.MASTER ldap://IP.SLAVE
 </tt>
-====Autenticazione Unix====
+==Autenticazione Unix==
 * <tt>'''/etc/libnss-ldap.conf'''</tt>
 <tt>
@@ Riga 196: / Riga 195: @@
 : URI ldap://IP.MASTER ldap://IP.SLAVE
 </tt>
-===Verifiche Finali===
+=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>
@@ Riga 213: / Riga 212: @@
 </pre>
 Non dimentichiamoci, a risincronizzazione avvenuta, di arrestare nuovamente il demone, eliminare o commentare la riga aggiunta e riavviare <tt>slapd</tt>.
-===Per approfondimenti vedi anche:===
+=Per approfondimenti=
 [[Samba e OpenLDAP: creare un controller di dominio]]<br/>
 [[Samba e OpenLDAP: creare un controller di dominio con Debian Etch]]<br/>