Le direttive contenute in questa sezione si applicano soltanto ai database in cui esse sono definite. Sono supportate da ogni tipo di database.
database <type>
Questa istruzione contrassegna l'inizio di nuova definizione di istanza di database. <type> dovrebbe essere uno dei tipi backend elencati al punto precedente.
Esempio:
database ldbm
Ciò contrassegna l'inizio di un detabase backend LDBM.
readonly { on | off }Questa istruzione pone il database in modalità "read-only". Ogni tentativo di modificare il database restituirà l'errore "unwilling to perform".
Default:
readonly off
replica host=<hostname>[:<port>]
[bindmethod={ simple | kerberos | sasl }]
["binddn=<DN>"]
[mech=<mech>]
[authcid=<identity>]
[authzid=<identity>]
[credentials=<password>]
[srvtab=<filename>]Questa direttiva specifica un luogo di replica per questo database. Il parametro uri= specifica uno schema, un host e facoltativamente una porta a cui l'istanza slave slapd può essere trovata. Un nome completo di dominio o un indirizzo IP può essere usato per l'<hostname>. Se <port> non è dato, viene usato il numero di porta standard di LDAP (389 o 636).
Il parametro bindnn= fornisce il DN con cui collegarsi allo slapd secondario per gli aggiornamenti. Dovrebbe essere un DN che ha accesso in lettura /scrittura al database dello slapd secondario, impostato tipicamente come un root dn nel file di configurazione dello slapd secondario. Deve anche accordarsi con la direttiva update dn nel file di configurazione dello slapd secondario. Generalmente questo DN non deve essere lo stesso del rootdn del master database. Poiché i DN contengono facilmente spazi, l'intera stringa "binddn=<DN>" deve essere racchiusa tra doppi apici.
L'istruzione bindmethod accetta come argometo i valori simple o Kerberos o sasl, a seconda che nella connessione allo slapd secondario si usi per l'autenticazione il metodo semplice basato su password o Kerberos o SASL.
L'autenticazione simple non dovrebbe essere usata a meno che non siano in funzione adeguate protezioni di segretezza e di integrità (per esempio TLS o IPSEC). L'autenticazione simple richiede la descrizione dettagliata di binddn e dei parametri delle credenziali.
L'autenticazione Kerberos è deprecata a favore dei meccanismi di autenticazione SASL, in particolare i meccanismi di GSSAPI e di KERBEROS_V4. L'autenticazione Kerberos richiede i parametri srvtab e binddn.
L'autenticazione SASL è generalmente raccomandata. L'autenticazione SASL richiede la specifica di un meccanismo usando il parametro saslmech. A seconda del meccanismo, un'identità e/o delle credenziali di autenticazione possono essere specificate usando authcid e le rispettive credenziali. Il parametro authzid può essere usato per specificare un'identità di autorizzazione.
Controllare questo URL per dettagli aggiuntivi: Replication with Slurpd.
replogfile <filename>
Questa direttiva specifica il nome del file di log della replica in cui lo slapd registrerà i cambiamenti. Il log della replica è tipicamente scritto da slapd e letto da slurpd. Normalmente, questa direttiva è usata soltanto se slurpd è stato usato per replicare il database. Tuttavia, si può anche usare per generare un log di transazione, se lo slurpd non sta funzionando. In questo caso, dovrete troncare periodicamente il file, altrimenti crescerebbe indefinitamente.
Controllare questo URL per vedere dettagli addizionali: Replication with Slurpd.
rootdn <dn>
Questa direttiva specifica il DN che non è soggetto a restrizioni di controllo di accesso o di limiti amministrativi per le operazioni su questo database. Il DN non ha bisogno riferirsi ad un oggetto nella directory. Il DN può riferirsi ad un'identità di SASL.
Entry-based Esempio:
rootdn "cn=Manager, dc=example, dc=com"
SASL-based Esempio:
rootdn "uid=root@EXAMPLE.COM"
rootpw <password>
Questa direttiva può essere usata per specificare una password per il rootdn (quando il rootdn è impostato a DN all'interno del database).
Esempio:
rootpw secret
È anche permesso fornire l'hash della password in forma RFC 2307. slappasswd può essere usato per generare l'hash della password.
Esempio:
rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
L'hash è stato generato usando il comando slappasswd -s secret.
suffix <dn suffix>
Questa direttiva specifica il suffisso DN delle interrogazioni che saranno passate a questo database backend. Possono essere date più linee di suffisso e per ogni definizione di database è necessaria ce ne sia almeno una.
Esempio:
suffix "dc=example, dc=com"
Le interrogazioni con un DN che termina in "dc=example, dc=com" saranno passate a questo backend.
Nota: quando viene selezionato il backend a cui passare una interrogazione, lo slapd guarda alla/e linee di suffisso in ogni definizione del database nell'ordine che compaiono nel file. Quindi, se un suffisso di database è un prefisso di un altro, deve comparire dopo esso nel file di configurazione.
syncrepl
Questa direttiva può essere usata per tenere sincronizzato un database replicato con il database master, in modo che il contenuto del database replicato sia aggiornato con il contenuto del master.
Questo documento non copre in dettaglio questa direttiva, poiché si configura un server LDAP singolo. Per maggiori informazioni su questa direttiva, visitare: LDAP Sync Replication.
updatedn <dn>
Questa direttiva è applicabile soltanto a uno slapd secondario. Essa specifica il DN a cui è permesso di apportare modifiche alla replica. Questo può essere il DN con cui si connette slurpd quando apporta modifiche alla replica o il DN associato con un'identità SASL.
Entry-based Esempio:
updatedn "cn=Update Daemon, dc=example, dc=com"
SASL-based Esempio:
updatedn "uid=slurpd@EXAMPLE.COM"
Controllare questo URL per maggiori dettagli: Replication with Slurpd.
updateref <URL>
Questa istruzione è applicabile soltanto in uno slapd secondario. Essa Specifica l'URL da restituire ai client che inoltrano richieste di aggiornamento alla replica. Se specificato più volte, viene fornito ogni URL.
Esempio:
update ldap://master.example.net