1 508
contributi
Implementare un'architettura ridondante master/slave OpenLDAP: differenze tra le versioni
Implementare un'architettura ridondante master/slave OpenLDAP (visualizza wikitesto)
Versione delle 17:47, 7 feb 2010
, 7 feb 2010corretta gerarchia titoli
S3v (discussione | contributi) Nessun oggetto della modifica |
(corretta gerarchia titoli) |
||
| Riga 1: | Riga 1: | ||
{{Versioni compatibili|Debian Sarge 3.1<br/>Debian Etch 4.0<br/>Debian Lenny 5.0<br/>Debian Squeeze<br/>Debian Sid|}} | {{Versioni compatibili|Debian Sarge 3.1<br/>Debian Etch 4.0<br/>Debian Lenny 5.0<br/>Debian Squeeze<br/>Debian Sid|}} | ||
=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/> | 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 <code>push</code> 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 <code>slurpd</code>. Le nuove versioni di OpenLDAP hanno introdotto un modello di replica <code>pull</code>, appoggiato ad un modulo chiamato <code>syncrepl</code>. | Le vecchie versioni di OpenLDAP usavano un modello <code>push</code> 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 <code>slurpd</code>. Le nuove versioni di OpenLDAP hanno introdotto un modello di replica <code>pull</code>, appoggiato ad un modulo chiamato <code>syncrepl</code>. | ||
Debian Etch 4.0 installa OpenLDAP 2.3, che supporta entrambi i moduli, ma dalla versione 2.4 OpenLDAP eliminerà il supporto al modulo <code>slurpd</code> (come si legge nella documentazione ufficiale di OpenLDAP 2.4). Pertanto in questa guida verrà preso in considerazione l'approccio <code>syncrepl</code> alla replicazione di LDAP, in modo da garantirci possibilità di aggiornamento dell'infrastruttura. | Debian Etch 4.0 installa OpenLDAP 2.3, che supporta entrambi i moduli, ma dalla versione 2.4 OpenLDAP eliminerà il supporto al modulo <code>slurpd</code> (come si legge nella documentazione ufficiale di OpenLDAP 2.4). Pertanto in questa guida verrà preso in considerazione l'approccio <code>syncrepl</code> 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 file 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 file 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 <code>syncrepl</code> affinchè vengano trasferiti a un consumer o slave server LDAP).<br/> | 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 file 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 file 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 <code>syncrepl</code> affinchè vengano trasferiti a un consumer o slave server LDAP).<br/> | ||
<br/> | <br/> | ||
| Riga 85: | Riga 85: | ||
</pre> | </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''': | Per lo slave server LDAP è sufficiente prendere il file originale di configurazione e aggiungere la sezione in '''grassetto''': | ||
<br/><br/> | <br/><br/> | ||
| Riga 152: | Riga 152: | ||
</pre> | </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. | 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 file: | Vanno modificati i file: | ||
* <code>'''/etc/smbldap-tools/smbldap.conf'''</code><br/> | * <code>'''/etc/smbldap-tools/smbldap.conf'''</code><br/> | ||
| Riga 174: | Riga 174: | ||
</code> | </code> | ||
==Client LDAP== | === Client LDAP === | ||
* <code>'''/etc/ldap/ldap.conf'''</code> | * <code>'''/etc/ldap/ldap.conf'''</code> | ||
<code> | <code> | ||
| Riga 183: | Riga 183: | ||
: URI ldap://IP.MASTER ldap://IP.SLAVE | : URI ldap://IP.MASTER ldap://IP.SLAVE | ||
</code> | </code> | ||
==Autenticazione Unix== | === Autenticazione Unix === | ||
* <code>'''/etc/libnss-ldap.conf'''</code> | * <code>'''/etc/libnss-ldap.conf'''</code> | ||
<code> | <code> | ||
| Riga 192: | Riga 192: | ||
: URI ldap://IP.MASTER ldap://IP.SLAVE | : URI ldap://IP.MASTER ldap://IP.SLAVE | ||
</code> | </code> | ||
=Verifiche Finali= | == Verifiche Finali == | ||
Dopo qualche tempo i due server LDAP dovrebbero essersi sincronizzati e una ricerca effettuata con <code>ldapsearch</code> sul master server dovrebbe dare gli stessi risultati di una effettuata sullo slave server: | Dopo qualche tempo i due server LDAP dovrebbero essersi sincronizzati e una ricerca effettuata con <code>ldapsearch</code> sul master server dovrebbe dare gli stessi risultati di una effettuata sullo slave server: | ||
<pre> | <pre> | ||
| Riga 209: | Riga 209: | ||
</pre> | </pre> | ||
Non dimentichiamoci, a risincronizzazione avvenuta, di arrestare nuovamente il demone, eliminare o commentare la riga aggiunta e riavviare <code>slapd</code>. | Non dimentichiamoci, a risincronizzazione avvenuta, di arrestare nuovamente il demone, eliminare o commentare la riga aggiunta e riavviare <code>slapd</code>. | ||
=Per approfondimenti= | == Per approfondimenti == | ||
[[Samba e OpenLDAP: creare un controller di dominio]]<br/> | [[Samba e OpenLDAP: creare un controller di dominio]]<br/> | ||
[[Samba e OpenLDAP: creare un controller di dominio con Debian Etch]]<br/> | [[Samba e OpenLDAP: creare un controller di dominio con Debian Etch]]<br/> | ||