Implementare un'architettura ridondante master/slave OpenLDAP

Come implementare un'architettura ridondante master/slave OpenLDAP

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 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 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, utilizzanzo i smbldap-tools:

smbldap-useradd replicant -P