Guide@Debianizzati.Org

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

Pagina Discussione

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

Versione delle 17:59, 22 mag 2015

6 757 byte aggiunti ,  22 mag 2015
m
nessun oggetto della modifica
mNessun oggetto della modifica
 
(33 versioni intermedie di 6 utenti non mostrate)
Riga 1: Riga 1:
==Come implementare un'architettura ridondante master/slave OpenLDAP==
{{Versioni compatibili|Squeeze|Wheezy}}
== 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 <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>.
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 <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.
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 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.<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/>
'''File <tt>/etc/ldap/slapd.conf</tt>''':
'''File <code>/etc/ldap/slapd.conf</code>''':<br/>
<tt>
: # Allow LDAPv2 binds
: allow bind_v2


: # Schema and objectClass definitions
# Allow LDAPv2 binds
: include /etc/ldap/schema/core.schema
allow bind_v2 <br/>
: include /etc/ldap/schema/cosine.schema
# Schema and objectClass definitions
: include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/core.schema
: include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/cosine.schema
: include /etc/ldap/schema/samba.schema
include /etc/ldap/schema/nis.schema
:'''include /etc/ldap/schema/samba.schema'''
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/samba.schema <br/>
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
'''loglevel sync'''
modulepath /usr/lib/ldap
moduleload back_bdb
sizelimit 500
tool-threads 1
backend bdb
checkpoint 512 30
database bdb <br/>
suffix "dc=dominio,dc=local"
rootdn "cn=admin,dc=dominio,dc=local"
rootpw "password"
'''moduleload syncprov'''
'''index entryCSN,entryUUID eq'''
'''overlay syncprov'''
'''syncprov-checkpoint 100 10'''
'''syncprov-sessionlog 200''' <br/>
directory "/var/lib/ldap"
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500 <br/>
index objectClass eq
index uid,uidNumber,gidNumber,memberUid eq
index cn,mail,surname,givenname eq,subinitial
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq <br/>
lastmod on
access to attrs=userPassword,shadowLastChange,sambaLMPassword,sambaNTPassword
by dn="cn=admin,dc=dominio,dc=local" write <br/>
'''by dn=”uid=replicant,ou=Users,dc=dominio,dc=local” read''' <br/>
by anonymous auth
by self write
by * none
access to dn.base="" by * read
access to *
by dn="cn=admin,dc=dominio,dc=local" write
by * read


: pidfile /var/run/slapd/slapd.pid
<br/>
: argsfile /var/run/slapd/slapd.args
Da notare che la configurazione prevede che venga aggiunto al database LDAP un nuovo utente (<code>uid=replicant,ou=Users,dc=dominio,dc=local</code>) per le operazioni di sincronizzazione tra i due server. Creiamo quindi il nuovo utente, utilizzando i soliti smbldap-tools:
: '''loglevel sync'''
<pre>
: modulepath /usr/lib/ldap
# smbldap-useradd replicant -P
: moduleload back_bdb
</pre>
: sizelimit 500
All'interno del file di configurazione <code>/etc/ldap/slapd.conf</code> sono state poi inserite le direttive:
tool-threads 1
<pre>
backend bdb
moduleload syncprov
checkpoint 512 30
index entryCSN,entryUUID eq
database bdb
overlay syncprov
suffix "dc=dominio,dc=local"
syncprov-checkpoint 100 10
rootdn          "cn=admin,dc=dominio,dc=local"
syncprov-sessionlog 200
rootpw          "password"
</pre>
directory "/var/lib/ldap"
Queste direttive servono per configurare il modulo <code>syncprov</code> 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/>
dbconfig set_cachesize 0 2097152 0
Per il master server LDAP questo è tutto. Per rendere valide le modifiche basta riavviare il demone:
dbconfig set_lk_max_objects 1500
<pre>
dbconfig set_lk_max_locks 1500
# /etc/init.d/slapd restart
dbconfig set_lk_max_lockers 1500
</pre>
index objectClass eq
 
index uid,uidNumber,gidNumber,memberUid eq
== Lo slave server LDAP ==
index cn,mail,surname,givenname eq,subinitial
Per lo slave server LDAP è sufficiente prendere il file originale di configurazione e aggiungere la sezione in '''grassetto''':
index sambaSID eq
 
index sambaPrimaryGroupSID eq
'''File <code>/etc/ldap/slapd.conf</code>''':<br/>
index sambaDomainName eq
 
lastmod on
# Allow LDAPv2 binds
access to attrs=userPassword,shadowLastChange,sambaLMPassword,sambaNTPassword
allow bind_v2
by dn="cn=admin,dc=dominio,dc=local" write
# Schema and objectClass definitions
by anonymous auth
include /etc/ldap/schema/core.schema
by self write
include /etc/ldap/schema/cosine.schema
by * none
include /etc/ldap/schema/nis.schema
access to dn.base="" by * read
include /etc/ldap/schema/inetorgperson.schema
access to *
include /etc/ldap/schema/samba.schema
by dn="cn=admin,dc=dominio,dc=local" write
pidfile /var/run/slapd/slapd.pid
by * read
argsfile /var/run/slapd/slapd.args
</tt>
'''loglevel sync'''
modulepath /usr/lib/ldap
moduleload back_bdb
sizelimit 500
tool-threads 1
backend bdb
checkpoint 512 30
database bdb
suffix "dc=dominio,dc=local"
rootdn          "cn=admin,dc=dominio,dc=local"
rootpw          "password"
directory "/var/lib/ldap"
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
index objectClass eq
index uid,uidNumber,gidNumber,memberUid eq
index cn,mail,surname,givenname eq,subinitial
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
lastmod on
access to attrs=userPassword,shadowLastChange,sambaLMPassword,sambaNTPassword
by dn="cn=admin,dc=dominio,dc=local" write
by anonymous auth
by self write
by * none
access to dn.base="" by * read
access to *
by dn="cn=admin,dc=dominio,dc=local" write
by * read<br/>
'''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 <code>searchbase=”dc=dominio,dc=local”</code> e <code>filter=”(objectClass=*)”</code> assicurano che tutti i dati del dominio saranno replicati. Il server slave, infine, si connette al master utilizzando le credenziali dell'utente <code>replicant</code> 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 <code>loglevel sync</code>, che avrà come risultato un logging dettagliato delle attività di OpenLDAP sul server Syslog di default.<br/>
È da notare il fatto che utilizzando questo sistema di configurazione è possibile installare più di un server slave LDAP.<br/>
Per rendere valide le modifiche sullo slave server basta riavviare il demone:
<pre>
# /etc/init.d/slapd restart
</pre>
 
== 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 ===
Vanno modificati i file:
* <code>'''/etc/smbldap-tools/smbldap.conf'''</code><br/>
<pre>
slaveLDAP="127.0.0.1"
slavePort="389"
masterLDAP="127.0.0.1"
masterPort="389"
</pre>
Gli indirizzi IP vanno modificati con quelli dei due server LDAP.
* <code>'''/etc/samba/smb.conf'''</code><br/>
La direttiva:
<pre>
passdb backend = ldapsam:ldap://127.0.0.1
</pre>
va sostituita con:
<pre>
passdb backend = ldapsam:"ldap://IP.MASTER ldap://IP.SLAVE"
</pre>
 
=== Client LDAP ===
* <code>'''/etc/ldap/ldap.conf'''</code>
<pre>
URI ldap://localhost
</pre>
va sostituito con:
<pre>
URI ldap://IP.MASTER ldap://IP.SLAVE
</pre>
=== Autenticazione Unix ===
* <code>'''/etc/libnss-ldap.conf'''</code>
<pre>
URI ldap://localhost
</pre>
va sostituito con:
<pre>
URI ldap://IP.MASTER ldap://IP.SLAVE
</pre>
== 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:
<pre>
# ldapsearch -H ldap://IP.MASTER.SERVER -b "dc=dominio,dc=local" -LLL "cn=nome.utente*" -x
</pre>
dovrebbe coincidere con:
<pre>
# ldapsearch -H ldap://IP.SLAVE.SERVER -b "dc=dominio,dc=local" -LLL "cn=nome.utente*" -x
</pre>
Se si rende necessaria una risincronizzazione completa dello slave server, è possibile riavviare il demone <code>slapd</code> dopo aver inserito la riga seguente nel suo file di configurazione <code>/etc/default/slapd</code>:
<pre>
SLAPD_OPTIONS=”-c rid=1,csn=0″
</pre>
<pre>
# /etc/init.d/slapd restart
</pre>
Non dimentichiamoci, a risincronizzazione avvenuta, di arrestare nuovamente il demone, eliminare o commentare la riga aggiunta e riavviare <code>slapd</code>.
== Approfondimenti ==
[[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 Lenny]]<br/>
[[Implementare un'architettura ridondante master/slave OpenLDAP]]<br/>
[[Samba: guida estesa]]<br/>
[[Samba: creare un cestino di rete per le condivisioni]]<br />
[[ClamAV: scansione antivirus delle condivisioni Samba]]<br />
 
{{Autori
|Autore = [[Utente:Ferdybassi|Ferdybassi]]
|Verificata_da=
:[[Utente:porkyhttp|porkyhttp]] 17:04, 06 mag 2012 (CEST)
|Numero_revisori=1
}}


===Lo slave server LDAP===
[[Categoria:Reti con Windows]][[Categoria:Samba]]
HAL 9000
3 581

contributi

Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/15632...38716"