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

Versione delle 15:02, 6 mag 2012

Versioni Compatibili

Tutte le versioni supportate di Debian

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.
Le vecchie versioni di OpenLDAP usavano un modello push 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 slurpd. Le nuove versioni di OpenLDAP hanno introdotto un modello di replica pull, appoggiato ad un modulo chiamato syncrepl. Debian Etch 4.0 installa OpenLDAP 2.3, che supporta entrambi i moduli, ma dalla versione 2.4 OpenLDAP eliminerà il supporto al modulo slurpd (come si legge nella documentazione ufficiale di OpenLDAP 2.4). Pertanto in questa guida verrà preso in considerazione l'approccio syncrepl 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 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 syncrepl affinchè vengano trasferiti a un consumer o slave server LDAP).

File /etc/ldap/slapd.conf:

# Allow LDAPv2 binds
allow bind_v2

# 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

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

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

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 dn=”uid=replicant,ou=Users,dc=dominio,dc=local” read

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

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

# smbldap-useradd replicant -P

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

moduleload syncprov
index entryCSN,entryUUID eq
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 200

Queste direttive servono per configurare il modulo syncprov che ha il compito di tracciare i cambiamenti nel database LDAP e di marcarli per renderli identificabili dallo slave server LDAP, affinché vengano replicati.
Per il master server LDAP questo è tutto. Per rendere valide le modifiche basta riavviare il demone:

# /etc/init.d/slapd restart

Lo slave server LDAP

Per lo slave server LDAP è sufficiente prendere il file originale di configurazione e aggiungere la sezione in grassetto:

File /etc/ldap/slapd.conf:

# Allow LDAPv2 binds
allow bind_v2
# 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
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
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

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 searchbase=”dc=dominio,dc=local” e filter=”(objectClass=*)” assicurano che tutti i dati del dominio saranno replicati. Il server slave, infine, si connette al master utilizzando le credenziali dell'utente replicant che abbiamo creato in precedenza e a cui già abbiamo dato permessi di completa lettura sul database LDAP del server master.
Su entrambi i server è stata impostata la direttiva loglevel sync, che avrà come risultato un logging dettagliato delle attività di OpenLDAP sul server Syslog di default.
È da notare il fatto che utilizzando questo sistema di configurazione è possibile installare più di un server slave LDAP.
Per rendere valide le modifiche sullo slave server basta riavviare il demone:

# /etc/init.d/slapd restart

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:

/etc/smbldap-tools/smbldap.conf

slaveLDAP="127.0.0.1"
slavePort="389"
masterLDAP="127.0.0.1"
masterPort="389"

Gli indirizzi IP vanno modificati con quelli dei due server LDAP.

/etc/samba/smb.conf'

La direttiva:

passdb backend = ldapsam:ldap://127.0.0.1

va sostituita con:

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

Client LDAP

/etc/ldap/ldap.conf

URI ldap://localhost

va sostituito con:

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

Autenticazione Unix

/etc/libnss-ldap.conf

URI ldap://localhost

va sostituito con:

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

Verifiche Finali

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

# ldapsearch -H ldap://IP.MASTER.SERVER -b "dc=dominio,dc=local" -LLL "cn=nome.utente*" -x

dovrebbe coincidere con:

# ldapsearch -H ldap://IP.SLAVE.SERVER -b "dc=dominio,dc=local" -LLL "cn=nome.utente*" -x

.

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

SLAPD_OPTIONS=”-c rid=1,csn=0″

# /etc/init.d/slapd restart

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

Approfondimenti

Samba e OpenLDAP: creare un controller di dominio
Samba e OpenLDAP: creare un controller di dominio con Debian Etch
Samba e OpenLDAP: creare un controller di dominio con Debian Lenny
Implementare un'architettura ridondante master/slave OpenLDAP
Samba: guida estesa
Samba: creare un cestino di rete per le condivisioni
ClamAV: scansione antivirus delle condivisioni samba

Guida scritta da: Ferdybassi	Debianized 40%
Estesa da:
Verificata da: porkyhttp 17:04, 06 mag 2012 (CEST)
Verificare ed estendere la guida \| Cos'è una guida Debianized

@@ Riga 220: / Riga 220: @@
 {{Autori
 |Autore = [[Utente:Ferdybassi|Ferdybassi]]
+|Verificata_da=
+:[[Utente:porkyhttp|porkyhttp]] 17:04, 06 mag 2012 (CEST)
+|Numero_revisori=1
 }}
 [[Categoria:Reti con Windows]][[Categoria:Samba]]

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

Versione delle 15:02, 6 mag 2012

Indice

Introduzione

Il master server LDAP

Lo slave server LDAP

Modifica dei servizi che utilizzano LDAP

Samba

Client LDAP

Autenticazione Unix

Verifiche Finali

Approfondimenti

Menu di navigazione

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

Versione delle 15:02, 6 mag 2012

Introduzione

Il master server LDAP

Lo slave server LDAP

Modifica dei servizi che utilizzano LDAP

Samba

Client LDAP

Autenticazione Unix

Verifiche Finali

Approfondimenti

Menu di navigazione

Ricerca