Blank lines and comment lines beginning with a '{{EX:#}}' character
are ignored. If a line begins with white space, it is considered a
-continuation of the previous line. The general format of slapd.conf is
-as follows:
+continuation of the previous line (even if the previous line is a
+comment).
+
+The general format of slapd.conf is as follows:
> # global configuration directives
> <global config directives>
URI such as {{EX:ldap://slave.example.com:389}} or
{{EX:ldaps://slave.example.com:636}}.
-The {{EX: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, typically given as a
-{{EX:rootdn}} in the slave's config file. It must also match the
-{{EX:updatedn}} directive in the slave slapd's config file. Since DNs are
-likely to contain embedded spaces, the entire {{EX:"binddn=<DN>"}}
-string should be enclosed in double quotes.
+The {{EX: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 {{EX:updatedn}}
+directive in the slave slapd's config file. Generally, this DN
+{{should not}} be the same as the {{EX:rootdn}} of the master
+database. Since DNs are likely to contain embedded spaces, the
+entire {{EX:"binddn=<DN>"}} string should be enclosed in double
+quotes.
The {{EX:bindmethod}} is {{EX:simple}} or {{EX:kerberos}} or {{EX:sasl}},
depending on whether simple password-based authentication or Kerberos
information on how to use this directive.
-H4: rootdn <dn>
+H4: rootdn <DN>
This directive specifies the DN that is not subject to
access control or administrative limit restrictions for
prefix of another, it must appear after it in the config file.
-H4: 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}}(8) 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"
-
-See the {{SECT:Replication with slurpd}} chapter for more information
-on how to use this directive.
-
-H4: 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 {{TERM:URL}} is provided.
-
-\Example:
-
-> updateref ldap://master.example.net
-
-
H4: syncrepl
-> syncrepl id=<replica ID>
+> syncrepl rid=<replica ID>
> provider=ldap[s]://<hostname>[:port]
> [type=refreshOnly|refreshAndPersist]
> [interval=dd:hh:mm:ss]
> [sizelimit=<limit>]
> [timelimit=<limit>]
> [schemachecking=on|off]
-> [updatedn=<dn>]
+> [updatedn=<DN>]
> [bindmethod=simple|sasl]
-> [binddn=<dn>]
+> [binddn=<DN>]
> [saslmech=<mech>]
> [authcid=<identity>]
> [authzid=<identity>]
> [realm=<realm>]
> [secprops=<properties>]
-This directive specifies the current database as a replica of the
-master database at the provider site. The replica database at the
-replication consumer site is kept up-to-date with the master
-database using the LDAP Content Synchronization protocol.
-See {{REF:draft-zeilenga-ldup-sync-04.txt}} for more information
-on the protocol.
-The {{EX:id}} parameter is used for identification of the current
-syncrepl directive in the database, where the three-digit integer
-{{EX:<replica ID>}} uniquely identifies the syncrepl specification
-described by the current syncrepl directive.
+This directive specifies the current database as a replica of the
+master content by establishing the current {{slapd}}(8) as a
+replication consumer site running a syncrepl replication engine.
+The master database is located at the replication provider site
+specified by the {{EX:provider}} parameter. The replica database is
+kept up-to-date with the master content using the LDAP Content
+Synchronization protocol. See {{EX:draft-zeilenga-ldup-sync-xx.txt}}
+({{a work in progress}}) for more information on the protocol.
+
+The {{EX:rid}} parameter is used for identification of the current
+{{EX:syncrepl}} directive within the replication consumer server,
+where {{EX:<replica ID>}} uniquely identifies the syncrepl specification
+described by the current {{EX:syncrepl}} directive. {{EX:<replica ID>}}
+is non-negative and is no more than three decimal digits in length.
The {{EX:provider}} parameter specifies the replication provider site
-containing the master database as an LDAP URI. The {{EX:provider}}
+containing the master content as an LDAP URI. The {{EX:provider}}
parameter specifies a scheme, a host and optionally a port where the
provider slapd instance can be found. Either a domain name or IP
address may be used for <hostname>. Examples are
{{EX:ldap://provider.example.com:389}} or {{EX:ldaps://192.168.1.1:636}}.
If <port> is not given, the standard LDAP port number (389 or 636) is used.
-Note that syncrepl uses a consumer-initiated protocol, and hence its
+Note that the syncrepl uses a consumer-initiated protocol, and hence its
specification is located at the consumer site, whereas the {{EX:replica}}
specification is located at the provider site. {{EX:syncrepl}} and
-{{EX:replica}} are two independent replication mechanisms and they do
-not represent the replication peers of each other.
+{{EX:replica}} directives define two independent replication
+mechanisms. They do not represent the replication peers of each other.
The content of the syncrepl replica is defined using a search
-specification as its result set. The consumer slapd will send
-search requests to the provider slapd according to the search
+specification as its result set. The consumer slapd will
+send search requests to the provider slapd according to the search
specification. The search specification includes {{EX:searchbase}},
{{EX:scope}}, {{EX:filter}}, {{EX:attrs}}, {{EX:attrsonly}},
{{EX:sizelimit}}, and {{EX:timelimit}} parameters as in the normal
-search specification. The syncrepl search specification
-has the same default value semantics as the {{REF:ldapsearch(1)}}
-client search tool.
+search specification. The syncrepl search specification has
+the same value syntax and the same default values as in the
+{{ldapsearch}}(1) client search tool.
The LDAP Content Synchronization protocol has two operation
types: {{EX:refreshOnly}} and {{EX:refreshAndPersist}}.
The operation type is specified by the {{EX:type}} parameter.
-In the {{EX:refreshOnly}} mode, the next synchronization search operation
+In the {{EX:refreshOnly}} operation, the next synchronization search operation
is periodically rescheduled at an interval time after each
synchronization operation finishes. The interval is specified
by the {{EX:interval}} parameter. It is set to one day by default.
-In the {{EX:refreshAndPersist}} mode, a synchronization search
+In the {{EX:refreshAndPersist}} operation, a synchronization search
remains persistent in the provider slapd. Further updates to the
-master replica will generate searchResultEntry to the consumer slapd
+master replica will generate {{EX:searchResultEntry}} to the consumer slapd
as the search responses to the persistent synchronization search.
The schema checking can be enforced at the LDAP Sync consumer site
-by turning on the {{EX:schemachecking}} parameter. The default is off.
-
-The {{EX:updatedn}} paramter specifies the DN in the consumer site
+by turning on the {{EX:schemachecking}} parameter.
+If it is turned on, every replicated entry will be checked for its
+schema as the entry is stored into the replica content.
+Every entry in the replica should contain those attributes
+required by the schema definition.
+If it is turned off, entries will be stored without checking
+schema conformance. The default is off.
+
+The {{EX:updatedn}} parameter specifies the DN in the consumer site
which is allowed to make changes to the replica. This DN is used
-locally by the syncrepl engine when updating the replica with
-the entries received from the provider site by using the
-internal operation mechanism. The update of the replica content
-is subject to the access control privileges of the DN.
-The DN should have read/write access to the replica database.
-It is typically given as a {{EX:rootdn}} in the consumer site's
-config file.
+locally by the syncrepl engine when updating the replica with the
+entries received from the provider site by using the internal
+operation mechanism. The update of the replica content is subject
+to the access control privileges of the DN. The DN should have
+read/write access to the replica database. Generally, this DN
+{{should not}} be the same as {{EX:rootdn}}.
The {{EX:binddn}} parameter gives the DN to bind as for the
syncrepl searches to the provider slapd. It should be a DN
for more information on how to use this directive.
+H4: 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}}(8) 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"
+
+See the {{SECT:Replication with slurpd}} chapter for more information
+on how to use this directive.
+
+H4: 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 {{TERM:URL}} is provided.
+
+\Example:
+
+> updateref ldap://master.example.net
+
+
H3: BDB Database Directives
Directives in this category only apply to a {{TERM:BDB}} database.
subsequent "backend" or "database" line. For a complete reference
of BDB configuration directives, see {{slapd-bdb}}(5).
+
H4: directory <directory>
This directive specifies the directory where the BDB files
> directory /usr/local/var/openldap-data
+H4: sessionlog <sid> <limit>
+
+This directive specifies a session log store in the syncrepl
+replication provider server which contains information on
+the entries that have been scoped out of the replication
+content identified by {{EX:<sid>}}.
+The first syncrepl search request having the same {{EX:<sid>}} value
+in the cookie establishes the session log store in the provider server.
+The number of the entries in the session log store is limited
+by {{EX:<limit>}}. Excessive entries are removed from the store
+in the FIFO order. Both {{EX:<sid>}} and {{EX:<limit>}} are
+non-negative integers. {{EX:<sid>}} has no more than three decimal digits.
+
+The LDAP Content Synchronization operation that falls into a pre-existing
+session can use the session log store in order to reduce the amount
+of synchronization traffic. If the replica is not so outdated that
+it can be made up-to-date by the information in the session store,
+the provider slapd will send the consumer slapd the identities of the
+scoped-out entries together with the in-scope entries added to or
+modified within the replication content. If the replica status is
+outdated too much and beyond the coverage of the history store,
+then the provider slapd will send the identities of the unchanged
+in-scope entries along with the changed in-scope entries.
+The consumer slapd will then remove those entries in the replica
+which are not identified as present in the provider content.
+
+
H3: LDBM Database Directives
Directives in this category only apply to a {{TERM:LDBM}} database.
> [aci=<attrname>]
> <access> ::= [self]{<level>|<priv>}
> <level> ::= none | auth | compare | search | read | write
-> <priv> ::= {=|+|-}{w|r|s|c|x}+
+> <priv> ::= {=|+|-}{w|r|s|c|x|0}+
> <control> ::= [stop | continue | break]
where the <what> part selects the entries and/or attributes to which
commonly selected in two ways: by DN and by filter. The following
qualifiers select entries by DN:
-> by *
-> by dn[.<basic-style>]=<regex>
-> by dn.<scope-style>=<DN>
+> to *
+> to dn[.<basic-style>]=<regex>
+> to dn.<scope-style>=<DN>
The first form is used to select all entries. The second form may
be used to select entries by matching a regular expression against
Entries may also be selected using a filter:
-> by filter=<ldap filter>
+> to filter=<ldap filter>
where <ldap filter> is a string representation of an LDAP
search filter, as described in {{REF:RFC2254}}. For example:
-> by filter=(objectClass=person)
+> to filter=(objectClass=person)
Note that entries may be selected by both DN and filter by
including both qualifiers in the <what> clause.
-> by dn.one="ou=people,o=suffix" filter=(objectClass=person)
+> to dn.one="ou=people,o=suffix" filter=(objectClass=person)
Attributes within an entry are selected by including a comma-separated
list of attribute names in the <what> selector:
!block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
title="Table 5.4: Access Levels"
Level Privileges Description
-none no access
+none =0 no access
auth =x needed to bind
compare =cx needed to compare
search =scx needed to apply search filters
projects / openldap / blobdiff