3.4. General Database Directives

Directives in this section apply only to the database in which they are defined. They are supported by every type of database.

database <type>

This directive marks the beginning of a new database instance definition. <type> should be one of the backend types listed on the previous item.

Example:

database bdb

This marks the beginning of a new BDB backend database instance definition.

readonly { on | off }

This directive puts the database into "read-only" mode. Any attempts to modify the database will return an "unwilling to perform" error.

Default:

readonly off

replica uri=ldap[s]://<hostname>[:<port>] | host=<hostname>[:<port>]
                [bindmethod={simple|kerberos|sasl}]
                ["binddn=<DN>"]
                [saslmech=<mech>]
                [authcid=<identity>]
                [authzid=<identity>]
                [credentials=<password>]
                [srvtab=<filename>]

This directive specifies a replication site for this database. The uri= parameter specifies a scheme, a host and optionally a port where the slave slapd instance can be found. Either a domain name or IP address may be used for <hostname>. If <port> is not given, the standard LDAP port number (389 or 636) is used.

Note: host is deprecated in favor of the uri parameter.

uri allows the replica LDAP server to be specified as an LDAP URI such as ldap://slave.example.com:389 or ldaps://slave.example.com:636

The binddn= parameter gives the DN to bind as for updates to the slave slapd. It should be a DN which has read/write access to the slave slapd's database. It must also match the updatedn directive in the slave slapd's config file. Generally, this DN should not be the same as the rootdn of the master database. Since DNs are likely to contain embedded spaces, the entire "binddn=<DN>" string should be enclosed in double quotes.

The bindmethod is simple or kerberos or sasl, depending on whether simple password-based authentication or Kerberos authentication or SASL authentication is to be used when connecting to the slave slapd.

Simple authentication should not be used unless adequate integrity and privacy protections are in place (e.g. TLS or IPSEC). Simple authentication requires specification of binddn and credentials parameters.

Kerberos authentication is deprecated in favor of SASL authentication mechanisms, in particular the KERBEROS_V4 and GSSAPI mechanisms. Kerberos authentication requires binddn and srvtab parameters.

SASL authentication is generally recommended. SASL authentication requires specification of a mechanism using the saslmech parameter. Depending on the mechanism, an authentication identity and/or credentials can be specified using authcid and credentials respectively. The authzid parameter may be used to specify an authorization identity.

Check this URL for additional details: Replication with Slurpd.

replogfile <filename>

This directive specifies the name of the replication log file to which slapd will log changes. The replication log is typically written by slapd and read by slurpd. Normally, this directive is only used if slurpd is being used to replicate the database. However, you can also use it to generate a transaction log, if slurpd is not running. In this case, you will need to periodically truncate the file, since it will grow indefinitely otherwise.

Check this URL for additional details: Replication with Slurpd.

rootdn <dn>

This directive specifies the DN that is not subject to access control or administrative limit restrictions for operations on this database. The DN need not refer to an entry in the directory. The DN may refer to a SASL identity.

Entry-based Example:

rootdn "cn=Manager, dc=example, dc=com"

SASL-based Example:

rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"

rootpw <password>

This directive can be used to specify a password for the rootdn (when the rootdn is set to a DN within the database).

Example:

rootpw secret

It is also permissible to provide hash of the password in RFC 2307 form. slappasswd may be used to generate the password hash.

Example:

rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN

The hash was generated using the command slappasswd -s secret.

suffix <dn suffix>

This directive specifies the DN suffix of queries that will be passed to this backend database. Multiple suffix lines can be given, and at least one is required for each database definition.

Example:

suffix "dc=example, dc=com"

Queries with a DN ending in "dc=example, dc=com" will be passed to this backend.

Note: When the backend to pass a query to is selected, slapd looks at the suffix line(s) in each database definition in the order they appear in the file. Thus, if one database suffix is a prefix of another, it must appear after it in the config file.

syncrepl

This directive is used to keep a replicated database synchronized with the master database, so that the replicated database content will be kept up to date with the master content.

This document doesn't cover in details this directive, because we're configuring a single LDAP Server. For more informations about this directive, please visit : LDAP Sync Replication.

updatedn <dn>

This directive is only applicable in a slave slapd. It specifies the DN allowed to make changes to the replica. This may be the DN slurpd binds as when making changes to the replica or the DN associated with a SASL identity.

Entry-based Example:

updatedn "cn=Update Daemon, dc=example, dc=com"

SASL-based Example:

updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"

Check this URL for additional details: Replication with Slurpd.

updateref <URL>

This directive is only applicable in a slave slapd. It specifies the URL to return to clients which submit update requests upon the replica. If specified multiple times, each URL is provided.

Example:

updateref ldap://master.example.net