Implementare un'architettura ridondante master/slave OpenLDAP: differenze tra le versioni
Vai alla navigazione
Vai alla ricerca
Wtf (discussione | contributi) |
mNessun oggetto della modifica |
||
| (3 versioni intermedie di 2 utenti non mostrate) | |||
| Riga 1: | Riga 1: | ||
{{Versioni compatibili|}} | {{Versioni compatibili|Squeeze|Wheezy}} | ||
== 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/> | ||
| Riga 5: | Riga 5: | ||
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> | 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 <code>/etc/ldap/slapd.conf</code>''':<br/> | '''File <code>/etc/ldap/slapd.conf</code>''':<br/> | ||
# Allow LDAPv2 binds | |||
allow bind_v2 <br/> | |||
# 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 <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 | |||
<br/> | <br/> | ||
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: | 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: | ||
| Riga 72: | Riga 64: | ||
</pre> | </pre> | ||
All'interno del file di configurazione <code>/etc/ldap/slapd.conf</code> sono state poi inserite le direttive: | All'interno del file di configurazione <code>/etc/ldap/slapd.conf</code> sono state poi inserite le direttive: | ||
< | <pre> | ||
moduleload syncprov | |||
index entryCSN,entryUUID eq | |||
overlay syncprov | |||
syncprov-checkpoint 100 10 | |||
syncprov-sessionlog 200 | |||
</ | </pre> | ||
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/> | 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/> | ||
Per il master server LDAP questo è tutto. Per rendere valide le modifiche basta riavviare il demone: | Per il master server LDAP questo è tutto. Per rendere valide le modifiche basta riavviare il demone: | ||
| Riga 87: | Riga 79: | ||
== 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''': | ||
: '''syncrepl rid=1''' | '''File <code>/etc/ldap/slapd.conf</code>''':<br/> | ||
# 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<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/> | 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/> | 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/> | ||
| Riga 157: | Riga 148: | ||
Vanno modificati i file: | Vanno modificati i file: | ||
* <code>'''/etc/smbldap-tools/smbldap.conf'''</code><br/> | * <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. | Gli indirizzi IP vanno modificati con quelli dei due server LDAP. | ||
* <code>'''/etc/samba/smb.conf | * <code>'''/etc/samba/smb.conf'''</code><br/> | ||
La direttiva: | La direttiva: | ||
< | <pre> | ||
passdb backend = ldapsam:ldap://127.0.0.1 | |||
</ | </pre> | ||
va sostituita con: | va sostituita con: | ||
< | <pre> | ||
passdb backend = ldapsam:"ldap://IP.MASTER ldap://IP.SLAVE" | |||
</ | </pre> | ||
=== Client LDAP === | === Client LDAP === | ||
* <code>'''/etc/ldap/ldap.conf'''</code> | * <code>'''/etc/ldap/ldap.conf'''</code> | ||
< | <pre> | ||
URI ldap://localhost | |||
</ | </pre> | ||
va sostituito con: | va sostituito con: | ||
< | <pre> | ||
URI ldap://IP.MASTER ldap://IP.SLAVE | |||
</ | </pre> | ||
=== Autenticazione Unix === | === Autenticazione Unix === | ||
* <code>'''/etc/libnss-ldap.conf'''</code> | * <code>'''/etc/libnss-ldap.conf'''</code> | ||
< | <pre> | ||
URI ldap://localhost | |||
</ | </pre> | ||
va sostituito con: | va sostituito con: | ||
< | <pre> | ||
URI ldap://IP.MASTER ldap://IP.SLAVE | |||
</ | </pre> | ||
== 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: | ||
| Riga 200: | Riga 191: | ||
<pre> | <pre> | ||
# ldapsearch -H ldap://IP.SLAVE.SERVER -b "dc=dominio,dc=local" -LLL "cn=nome.utente*" -x | # ldapsearch -H ldap://IP.SLAVE.SERVER -b "dc=dominio,dc=local" -LLL "cn=nome.utente*" -x | ||
</pre> | </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>: | 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> | <pre> | ||
| Riga 216: | Riga 207: | ||
[[Samba: guida estesa]]<br/> | [[Samba: guida estesa]]<br/> | ||
[[Samba: creare un cestino di rete per le condivisioni]]<br /> | [[Samba: creare un cestino di rete per le condivisioni]]<br /> | ||
[[ClamAV: scansione antivirus delle condivisioni | [[ClamAV: scansione antivirus delle condivisioni Samba]]<br /> | ||
{{Autori | {{Autori | ||
|Autore = [[Utente:Ferdybassi|Ferdybassi]] | |Autore = [[Utente:Ferdybassi|Ferdybassi]] | ||
|Verificata_da= | |||
:[[Utente:porkyhttp|porkyhttp]] 17:04, 06 mag 2012 (CEST) | |||
|Numero_revisori=1 | |||
}} | }} | ||
[[Categoria:Reti con Windows]][[Categoria:Samba]] | [[Categoria:Reti con Windows]][[Categoria:Samba]] | ||
Versione attuale delle 17:59, 22 mag 2015
|
Attenzione. Questa guida è da considerarsi abbandonata, per via del tempo trascorso dall'ultima verifica.
Potrà essere resa obsoleta, previa segnalazione sul forum, se nessuno si propone per l'adozione. |
 Versioni Compatibili Debian 6 "squeeze" Debian 7 "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.
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:
| |
|
Verificare ed estendere la guida | Cos'è una guida Debianized | |