[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.
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.
See the chapter entitled Replication with slurpd for more information on how to use this directive.
5.2.3.4. 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.
See the chapter entitled Replication with slurpd for more information on how to use this directive.
5.2.3.5. rootdn <DN>;
该指令指定一个不受当前数据库的访问控制和操作限制的的DN。<DN>;不必是一个当前数据库或者当前目录中的条目。<DN>;也可能一个SASL身份证（identity）。
基于条目的示例：
rootdn "cn=Manager,dc=example,dc=com"
基于SASL的示例：
rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"
参看”SASL认证“一节获得更多关于SASL认证身份的信息。
5.2.3.6. rootpw <password>;
该指令用来为rootdn（当rootdn被设置为数据库中的一个条目时）设定一个密码。
示例：
rootpw secret
将密码设为RFC 2307中的格式也是可以的。slapdpasswd可以用来产生哈希密码。
示例：
rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
哈希密码用命令slappasswd -s secret产生。
5.2.3.7. suffix <dn suffix>;
该指令指定了将传递给后端数据库的请求的DN的后缀。一个数据库可以有多个后缀，但是每个数据库定义中至少要有一个。
示例：
suffix "dc=example,dc=com"
只有当发出的请求是以"dc=example,dc=com"为DN的后缀的时候这个请求才可以传递给这个后端。
-----------------------------------------------------------------------------------------------------------
注意：当请求传递的对象，即后端选定之后，slapd在每个数据库定义中顺序查找suffix行。因此，如果一个数据库后缀是另一个的前缀的话，在配置文件中它必须出现在另一个之后。
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.
-----------------------------------------------------------------------------------------------------------
5.2.3.8. syncrepl
syncrepl rid=<replica ID>;
provider=ldap
[type=refreshOnly|refreshAndPersist]
[interval=dd]
[searchbase=<base DN>;]
[filter=<filter str>;]
[scope=sub|one|base]
[attrs=<attr list>;]
[attrsonly]
[sizelimit=<limit>;]
[timelimit=<limit>;]
[schemachecking=on|off]
[updatedn=<DN>;]
[bindmethod=simple|sasl]
[binddn=<DN>;]
[saslmech=<mech>;]
[authcid=<identity>;]
[authzid=<identity>;]
[credentials=<passwd>;]
[realm=<realm>;]
[secprops=<properties>;]
This directive specifies the current database as a replica of the master content by establishing the current slapd(
as a replication consumer site running a syncrepl replication engine. The master database is located at the replication provider site specified by the provider parameter. The replica database is kept up-to-date with the master content using the LDAP Content Synchronization protocol. See draft-zeilenga-ldup-sync-xx.txt (a work in progress) for more information on the protocol.The rid parameter is used for identification of the current syncrepl directive within the replication consumer server, where <replica ID>; uniquely identifies the syncrepl specification described by the current syncrepl directive. <replica ID>; is non-negative and is no more than three decimal digits in length.
The provider parameter specifies the replication provider site containing the master content as an LDAP URI. The 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 ldap://provider.example.com:389 or ldaps://192.168.1.1:636. If <port>; is not given, the standard LDAP port number (389 or 636) is used. Note that the syncrepl uses a consumer-initiated protocol, and hence its specification is located at the consumer site, whereas the replica specification is located at the provider site. syncrepl and 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. The search specification includes searchbase, scope, filter, attrs, attrsonly, sizelimit, and timelimit parameters as in the normal 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: refreshOnly and refreshAndPersist. The operation type is specified by the type parameter. In the 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 interval parameter. It is set to one day by default. In the refreshAndPersist operation, a synchronization search remains persistent in the provider slapd. Further updates to the master replica will generate 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 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 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. Generally, this DN should not be the same as rootdn.
The binddn parameter gives the DN to bind as for the syncrepl searches to the provider slapd. It should be a DN which has read access to the replication content in the master database.
The bindmethod is simple or sasl, depending on whether simple password-based authentication or SASL authentication is to be used when connecting to the provider 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.
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.
The realm parameter specifies a realm which a certain mechanisms authenticate the identity within. The secprops parameter specifies Cyrus SASL security properties.
The syncrepl replication mechanism is supported by the three native backends: back-bdb, back-hdb, and back-ldbm.
See the LDAP Sync Replication chapter of the admin guide for more information on how to use this directive.
5.2.3.9. 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"
See the Replication with slurpd chapter for more information on how to use this directive.
5.2.3.10. 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
5.2.4. BDB数据库指令
这一类指令只会作用于BDB数据库上。也就是说，它们必须跟在一个"database bdb"行之后并且出现在任何随后的"backend" 或者 "database"行之前。要想获得BDB配置指令的完整参考，请参阅slapd-bdb。
5.2.4.1. directory <directory>;
该指令指定包含数据和索引的BDB文件所在的目录。
默认：
directory /usr/local/var/openldap-data
5.2.4.2. 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 <sid>;. The first syncrepl search request having the same <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 <limit>;. Excessive entries are removed from the store in the FIFO order. Both <sid>; and <limit>; are non-negative integers. <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.
5.2.5. LDBM数据库指令
这一类指令只会作用于LDBM数据库上。也就是说，它们必须跟在一个"database ldbm"行之后并且出现在任何随后的"backend" 或者 "database"行之前。要想获得LDBM配置指令的完整参考，请参阅slapd-ldbm。
5.2.5.1. cachesize <integer>;
该指令指定LDBM后端数据库实例在缓存中维护的条目的大小。
默认：
cachesize 1000
5.2.5.2. dbcachesize <integer>;
该指令指定了与每个打开的索引文件相关联的缓存的字节大小。如果不被下层的数据库方法支持的话，该指令将会不给出任何提示地被忽略。增加这个值会占用更多的内存但是却会带来性能上的大幅提升，尤其是在修改或者建立索引的时候。
默认：
dbcachesize 100000
5.2.5.3. dbnolocking
这个选项，如果出现，将会禁止锁定数据库。启用这个选项可能会提高性能，但付出的代价是增大了数据安全的风险。
5.2.5.4. dbnosync
这个选项作用在磁盘上。当内存中的数据发生改变之后，磁盘上的数据库内容并不立即与之保持同步。启用这个选项可能会提高性能，但付出的代价是增大了数据一致性上的风险。
5.2.5.5. directory <directory>;
该指令指定包含数据和索引的LDBM文件所在的目录。
默认：
directory /usr/local/var/openldap-data
5.2.5.6. index {<attrlist>; | default} [pres,eq,approx,sub,none]
该指令指定了为所给属性所维护的索引。如果仅给出一个<attrlist>;，默认的索引也会被维护。
示例：
index default pres,eq
index uid
index cn,sn pres,eq,sub
index objectClass eq
The first line sets the default set of indices to maintain to present and equality. The second line causes the default (pres,eq) set of indices to be maintained for the uid attribute type. The third line causes present, equality, and substring indices to be maintained for cn and sn attribute types. The fourth line causes an equality index for the objectClass attribute type.
By default, no indices are maintained. It is generally advised that minimally an equality index upon objectClass be maintained.
index objectClass eq
5.2.5.7. mode <integer>;
该指令指定了新近创建的数据库索引文件所应具有的文件保护模式。
默认：
mode 0600
5.3 访问控制
对slapd的条目和属性的访问是由访问配置文件指令控制的。通用的访问控制格式是这样的：
<access directive>; ::= access to <what>;
[by <who>; <access>; <control>;]+
<what>; ::= * |
[dn[.<basic-style>;]=<regex>; | dn.<scope-style>;=<DN>;]
[filter=<ldapfilter>;] [attrs=<attrlist>;]
<basic-style>; ::= regex | exact
<scope-style>; ::= base | one | subtree | children
<attrlist>; ::= <attr>; [val[.<basic-style>;]=<regex>;] | <attr>; , <attrlist>;
<attr>; ::= <attrname>; | entry | children
<who>; ::= * | [anonymous | users | self
| dn[.<basic-style>;]=<regex>; | dn.<scope-style>;=<DN>;]
[dnattr=<attrname>;]
[group[/<objectclass>;[/<attrname>;][.<basic-style>;]]=<regex>;]
[peername[.<basic-style>;]=<regex>;]
[sockname[.<basic-style>;]=<regex>;]
[domain[.<basic-style>;]=<regex>;]
[sockurl[.<basic-style>;]=<regex>;]
[set=<setspec>;]
[aci=<attrname>;]
<access>; ::= [self]{<level>;|<priv>;}
<level>; ::= none | auth | compare | search | read | write
<priv>; ::= {=|+|-}{w|r|s|c|x|0}+
<control>; ::= [stop | continue | break]
这里的<what>;选择条目和/或属性并在其上应用访问控制，<who>;则指定什么样的实体可以访问条目和属性，<access>;指定访问级别。多个<who>; <access>; <control>;是受支持的，以允许多种实体可以有不同的访问级别访问相同的条目和属性。不是所有的访问控制选项都在这里描述；更多信息可参见slapd.access手册。
5.3.1. 控制对什么的访问（What to control access to）
<what>;决定了将要应用访问控制的条目和属性。条目通常通过两种方式选定：通过DN或者通过过滤器。下面的示例通过DN选择条目：
to *
to dn[.<basic-style>;]=<regex>;
to dn.<scope-style>;=<DN>;
第一种格式用于选择所有的条目。第二种格式用于选择标准化的DN与所给正则表达式相匹配的条目（第二种格式不会在本文档中深入讨论）。第三种格式用语选择在所请求的DN范围之内的条目。<DN>;是一个标识名的字符串表示，如RFC2253中所述。
DN范围可以是以下四种之一：base, one, subtree, 或者 children。这里的base只与所给的DN相匹配，one只与父条目是所给DN的条目相匹配，subtree只与根为所给DN的子树下是所有条目相匹配，而children匹配所有位于DN之下的条目（除了以DN为标识名的条目以外）。
比如，如果目录包含以如下方式命名的条目：
0: o=suffix
1: cn=Manager,o=suffix
2: ou=people,o=suffix
3: uid=kdz,ou=people,o=suffix
4: cn=addresses,uid=kdz,ou=people,o=suffix
5: uid=hyc,ou=people,o=suffix
那么：
dn.base="ou=people,o=suffix" 匹配 2;
dn.one="ou=people,o=suffix" 匹配 3, 和 5;
dn.subtree="ou=people,o=suffix" 匹配 2, 3, 4, 和 5;
dn.children="ou=people,o=suffix" 匹配 3, 4, 和 5。
条目也可以通过过滤器收集起来：
to filter=<ldap filter>;
这里的<ldap filter>;是LDAP搜索过滤器的一个字符串表示，如RFC2254所述。比如：
to filter=(objectClass=person)
注意到条目可以同时通过DN和过滤器来搜集，只需要同时把两者都包含在<what>;子句中即可：
to dn.one="ou=people,o=suffix" filter=(objectClass=person)
条目的属性通过在<what>;搜集器中包含用逗号分隔的属性名列表指定：
attrs=<attribute list>;
一个属性的具体取值通过单个的属性名和值选取器来指定：
attrs=<attribute>; val[.<style>;]=<regex>;
有两个特殊的的伪属性entry 和 children。要读取（也就是得到）一个条目，必须要有对目标条目的entry属性的读权限。要添加或者删除一个条目，必须要有对目标条目的entry属性的写权限，并且还必须要有对条目的父条目的children属性的写权限。要重命名一个条目，必须要同时拥有对目标条目的entry属性的写权限，对原父条目的children属性的写权限，以及对新的父条目的children属性的写权限。本节末尾的完全示例将会把所有这一切将清楚的。
最后要说明一点，选取器“*”是一个特殊的条目选取器，用来选取所有的条目。在没有其他的<what>;选取器给出的情况下它将被使用。等价于"dn=.*"。
5.3.2. 谁可以访问（Who to grant access to）
<who>;用于确定允许进行访问的一个或多个实体。注意访问权限是被授权给“实体”（entities）而非“条目”（entries）。下面的表格总结了代表实体的符号（specifier）：
表 5.3: 访问实体符号
Specifier Entities
* All, including anonymous and authenticated users
anonymous Anonymous (non-authenticated) users
users Authenticated users
self User associated with target entry
dn[.<basic-style>;]=<regex>; Users matching a regular expression
dn.<scope-style>;=<DN>; Users within scope of a DN
此处的DN符号表现得非常像<what>;子句中的DN符号：
其他的控制因素也被支持。比如，a <who>; can be restricted by an entry listed in a DN-valued attribute in the entry to which the access applies:
dnattr=<dn-valued attribute name>;
dnattr用来授权给一个条目，而该条目的DN是在所列的条目的属性当中（比如，可以给一个条目组的拥有者所在的条目授权）。
一些因素可能不是在所有的环境下都是正确的。比如，域名因素依赖于域名查询。因为这些很容易spoofed，所以域名因素不可避免。
5.3.3. 访问权限（The access to grant）
允许的<access>;可以是以下所列之一：
表 5.4: 访问级别
Level Privileges Description
none =0 no access
auth =x needed to bind
compare =cx needed to compare
search =scx needed to apply search filters
read =rscx needed to read search results
write =wrscx needed to modify/rename
每一个级别都暗含着所有更低级别的访问权限被允许。所以，如果允许某人都一个条目有写权限也就给了他读取，搜索，比较，验证（auth）的权限。然而，可以使用优先级来批准某些特权。
5.3.4. 访问控制评估（Access Control Evaluation）
在评估某个请求者是否具有对一个条目和/或属性的访问权限时，slapd将条目和/或属性与配置文件中的<what>;选取器进行比较。对每一个条目，数据库级的访问控制首先生效，跟着生效的是全局访问控制指令。按照这样的先后顺序，访问控制指令以它们在配置文件中出现的先后次序被检查。slapd在碰到第一个匹配条目和/或属性的<what>;选取器时终止。对应的访问控制指令就是slapd将要用来评估访问控制权限的。
接下来，slapd把提出访问的实体与访问控制指令中的<who>;选取器依次比较。当它遇到第一个匹配请求实体的<who>;选取器是它将停止。这也就决定了实体能够拥有的对条目和/或属性的访问权限。
最后，slapd将访问控制指令中的<access>;与客户的请求权限相比较。如果它允许大于或等于的访问权限，访问就被批准。否则，访问将被拒绝。
访问控制指令的评估顺序使它们在配置文件中的位置变得很重要。如果一个访问控制指令就它所选的条目而言比另一个更具体，那么它应当出现在配置文件的前面。类似地，如果一个<who>;选取器比另一个更具体，它也应该在配置文件的前面出现。下面给出的访问控制示例将会使这一切变得更清晰。
5.3.5. 访问控制示例（Access Control Examples）
上面所提到的访问控制的措施是相当强大的。本节将给出一些它的使用示例。首先，举几个简单的例子：
access to * by * read
这个指令允许所有人具有读权限。
access to *
by self write
by anonymous auth
by * read
这条指令允许用户修改他们自己的条目，允许匿名用户鉴定这些条目，允许所有其他的用户读取这些条目。注意，仅仅第一个匹配<who>;子句的才起作用。因此，匿名用户可以auth,而不是read。最后的子句也可以写成"by users read"。
经常需要对不同的保护级别执行不同的受限操作。以下显示了security strength factors (SSF)可以怎样被使用。
access to *
by ssf=128 self write
by ssf=64 anonymous auth
by ssf=64 users read
这条指令允许用户修改他们自己的条目，如果安全保护强度为128或者更高的话；允许匿名用户拥有auth权限，一般用户拥有读权限，如果确定了级别为64或者更高的安全保护强度的话。如果客户没有确定足够的安全保护强度的话，暗含的by * none字据将会起作用。
下面的例子显示了通过style specifiers 在两个访问指令中通过DN选择条目的用法，其中，访问指令的顺序是很重要的。
access to dn.children="dc=example,dc=com"
by * search
access to dn.children="dc=com"
by * read
所有用户都拥有对dc=com 子树下的条目的读权限，例外的是，对那些dc=example,dc=com 子树下的条目，用户仅仅有搜索的权限。dc=com 是不可访问的，因为没有访问指令匹配该条DN。如果这里的指令顺序颠倒了的话，那么尾部的指令将永远不会被用到，因为所有dc=example,dc=com 下的条目也都是dc=com 下的条目。
同时要注意到如果没有与指令相匹配的访问权限或者没有by <who>;子句的话，访问将被拒绝。也就是说，每一个access to 指令都是以一个暗含的by * none 子句结尾的，并且每一个访问列表都以一个暗含的access to * by * none 指令结尾。
下面的示例再一次说明了对access指令和by <who>;子句而言出现顺序的重要性。它也显示了属性选取器和各种<who>;选取器的用法。
access to dn.subtree="dc=example,dc=com" attr=homePhone
by self write
by dn.children="dc=example,dc=com" search
by peername=IP:10\..+ read
access to dn.subtree="dc=example,dc=com"
by self write
by dn.children="dc=example,dc=com" search
by anonymous auth
本例对"dc=example,dc=com"子树中的条目起作用。除了homePhone之外，一个条目可以写它所有的属性，example.com 下的条目可以被它自己搜索，其他任何人都没有权限访问（暗含by * none），例外是经过认证/授权的用户可以（总是匿名进行）。homePhone属性对条目自身而言是可写的，对example.com下的条目是可搜索的，对来自10网络的客户总是可读的，否则就是不可读的（暗含by * none）。所有其他的访问都将被拒绝，因为暗含有access to * by * none子句。
有时允许一个特定的DN可以从一个属性添加或者删除它自身是很有用的。比如，如果你想创建一个组并且允许人们从member属性添加和删除自己的DN，你可以通过一个访问指令来实现这个目的：
access to attr=member,entry
by dnattr=member selfwrite
<who>;选取器dnattr表明访问应用到member属性所列的条目上。selfwrite访问选取器表明这些成员仅仅能从属性中添加或者删除他们自己的DN，不能是别人的。额外的条目属性是必须的，因为对条目的访问要求能访问条目的任何属性。
5.4 配置文件示列
下面是一个配置文件示例，被文中的说明分隔问几段。它定义了两个数据库对立X.500目录信息树的不同部分；两个数据库都是BDB数据库实例。行号仅仅是为了参考，并不是包含在实际文件当中的。首先，全局的配置部分：
1. # example config file - global configuration section
2. include /usr/local/etc/schema/core.schema
3. referral ldap://root.openldap.org
4. access to * by * read
行1是注释。行2把核心模式定义文件包含到了本配置文件当中。行3的referral指令意味着不能在本地数据库上完成的请求将会被重定向到在root.openldap.org主机的389端口上运行的LDAP服务器上。
行4是一个全局的访问控制指令。它对所有的条目都起作用（在特定数据库的访问控制指令之后）。
配置文件的下一节定义了一个BDB后端来处理针对目录树中"dc=example,dc=com"部分的请求。这个数据库将被复制到两个从属的slapd上，一个位于truelies，另一个位于judgmentday。其中几个属性的索引会被维护，并且userPassword属性被保护起来防止未经授权的访问。
5. # BDB definition for the example.com
6. database bdb
7. suffix "dc=example,dc=com"
8. directory /usr/local/var/openldap-data
9. rootdn "cn=Manager,dc=example,dc=com"
10. rootpw secret
11. # replication directives
12. replogfile /usr/local/var/openldap/slapd.replog
13. replica uri=ldap://slave1.example.com:389
14. binddn="cn=Replicator,dc=example,dc=com"
15. bindmethod=simple credentials=secret
16. replica uri=ldaps://slave2.example.com:636
17. binddn="cn=Replicator,dc=example,dc=com"
18. bindmethod=simple credentials=secret
19. # indexed attribute definitions
20. index uid pres,eq
21. index cn,sn,uid pres,eq,approx,sub
22. index objectClass eq
23. # database access control definitions
24. access to attr=userPassword
25. by self write
26. by anonymous auth
27. by dn.base="cn=Admin,dc=example,dc=com" write
28. by * none
29. access to *
30. by self write
31. by dn.base="cn=Admin,dc=example,dc=com" write
32. by * read
行5是注释。数据库定义的开始以行6的关键字database为标志。行7指定了传给此数据库的请求的DN的后缀。行8指定了数据库文件所在的目录。
行9和行10指定数据库的超级用户条目和相应的口令。该条目不受访问控制，大小，时间的限制。
行11到行18是为复制操作服务。行12指定了复制的日志文件（对数据库的改动都由slapd登记到这里并且被slurpd读取）。行13到行15指定复制主机的主机名和端口号，以及在进行更新的时候要绑定到的DN，还有绑定的方式（simple）以及绑定DN的信任方式（credential，即口令password）。行16到行18指定了第二个复制站点。参看“用slurpd进行拷贝”章节以获得更多有关该指令的信息。
行20到行22表明需要维护索引的各种属性。
行24到行32指定对本数据库中的条目的访问控制。因为是第一个数据库，这里的控制信息也会作用到不由任何数据库保存的条目上面（比如Root DSE）。对所有应用型的条目，userPassword属性对条目自身和“admin”条目是可写的。它可能用于认证/授权之类的目的，否则对其他用户就应该不可读。所有其他的属性都可以被条目自身和“admin”条目所写，但可以被所有的用户读（可能是通过认证的用户也可能是没有通过认证的用户）。
本配置文件的下一节定义了另外一个BDB数据库。这个数据库处理涉及到dc=example,dc=net子树的请求但是由相同的实体管理。注意到如果没有行39，因为行4中定义的全局访问策略将允许读权限。
33. # BDB definition for example.net
34. database bdb
35. suffix "dc=example,dc=net"
36. directory /usr/local/var/openldap-data-net
37. rootdn "cn=Manager,dc=example,dc=com"
38. index objectClass eq
39. access to * by users read
作者: rockins 时间: 2004-10-11 20:39
标题: [翻译]OpenLDAP管理员指南(仅前七章)
6.运行slapd
slapd被设计为以独立的服务器运行。这允许服务器利用缓存，管理下层数据库的同步，并且节约系统资源。通过inetd来运行是不行的。
6.1 命令行选项
slapd支持许多命令行选项，这些选项在操作手册中都有详细的描述。本节将讲述一些常用的选项。
-f <filename>;
这个选项给slapd指定了另外一个配置文件。默认的配置文件通常是/usr/local/etc/openldap/slapd.conf。
-h <URLs>;
这个选项指定了一个替代的监听器（listener）。默认的是ldap:///，意味着LDAP服务器监听所有网络接口上的来自LDAP默认端口389的TCP连接。你可以指定一个具体的主机-端口对或者其他的协议方案（比如ldaps:// 或者 ldapi://）。例如，-h "ldaps:// ldap://127.0.0.1:666"将会创建两个监听器：一个监听所有网络接口上通过默认的LDAP/SSL端口636的SSL连接，另一个监听来自本地主机（loopback）上的666端口的TCP连接。主机可以用IPv4的点分十进制形式或者主机名来指定。端口值必须是数值。
-n <service-name>;
这个选项指定用于日志记录和其他目的的服务的名称。默认的服务名是slapd.
-l <syslog-local-user>;
这个选项指定了syslog的本地用户。可以取LOCAL0, LOCAL1, LOCAL2, ..., 到 LOCAL7的值。默认值是LOCAL4。这个选项可能不被所有的系统所支持。
-u user -g group
这两个选项分别指定了运行slapd的用户和用户组。user可以是用户名，也可以是uid。group可以是组名，也可以是gid。
-r directory
这个选项指定了一个运行时目录。slapd将会在打开监听器并且准备读取任何配置文件或者初始化任何后端之前chroot到这个目录。
-d <level>; | ?
这个选项将slapd的调试（debug）级别设为<level>;。当级别是“？”的时候，slapd将打印出全部的调试级别并终止，无论你除此之外还给出了其他什么选项。目前的调试级别有下面的这些：
表 6.1: 调试级别
Level Description
-1 enable all debugging
0 no debugging
1 trace function calls
2 debug packet handling
4 heavy trace debugging
8 connection management
16 print out packets sent and received
32 search filter processing
64 configuration file processing
128 access control list processing
256 stats log connections/operations/results
512 stats log entries sent
1024 print communication with shell backends
2048 print entry parsing debugging
你可以启用多个调试级别，通过为每个需要的级别指定一次调试选项。或者，因为调试级别是可加的，你也可以自己去做这样的数学运算。也就是说，如果你想跟踪函数调用并且查看正在处理的配置文件，你可以把调试级别设为这两个级别之和（在这种情况下是，-d 65）。或者，你也可以让slapd来做这个数学运算，（比如，-d 1 -d 64）。更多细节可咨询<ldap_log.h>;头文件。
-----------------------------------------------------------------------------------------------------------
注意：要得到两种状态级别之外的其他调试信息，必须在编译slapd的时候指定-DLDAP_DEBUG。
-----------------------------------------------------------------------------------------------------------
6.2 启动slapd
通常，slapd是像这样启动的：
/usr/local/etc/libexec/slapd [<option>;]*
这里的/usr/local/etc/libexec是由configure决定的，<option>;是上面所给出的选项中的一个（或者参考slapd的使用手册）。除非你指定了一个调试级别（包括0级别也是这样），否则slapd将fork自身并且将它自己从控制终端转到后台运行。
6.3 停止slapd
要安全地终止slapd，你应该使用下面这样的命令：
kill -INT `cat /usr/local/var/slapd.pid`
这里的/usr/local/var是由configure决定的。
其他的杀死slapd进程的方法过于激烈，可能会造成信息丢失或者数据库崩溃。
7.数据库创建和维护工具
本节将告诉你如何从草稿创建slapd数据库，以及如何在遇到问题的时候解决问题。有两种方式创建数据库。首先，你可以使用LDAP在线创建数据库。如果使用的是这种方式，你只需要简单的启动slapd并且用你的客户端添加条目就行了。这种方式对相对比较小的数据库是很合适的（根据你的需要，可能是几百或者几千条）。这种方式仅仅工作在支持更新操作的数据库之下。
第二种创建数据库的方式是用slapd自带的特殊工具脱机创建。这种方式最适合于当你有好几千个条目要创建的情况，--如果你用前一种方式来创建所需要的时间无法接受，或者是因为你想确保数据库在创建的时候不能被访问。注意不是所有的数据库都支持这种方式。
7.1 在LDAP上创建数据库
使用这种方式，你可以通过你喜欢的客户端（比如，ldapadd）来添加条目，这和你在数据库创建好之后添加条目的操作是一样的。你应当在启动slapd之前确保下列选项已经在配置文件中做了设置。
suffix <dn>;
如“通用数据库指令”一节中所述，这个选项定义了由这个数据库保存的条目。你应该把这个选项设置为你准备创建的目录子树的根DN。比如：
suffix "dc=example,dc=com"
你应当确保指定了一个索引文件所在的目录。
directory <directory>;
比如：
directory /usr/local/var/openldap-data
你需要拥有足够的权限创建该目录以使slapd可以写入它。
你需要配置slapd以便你能够以一个有权限添加条目的目录用户连接到这个服务器上面。你可以把目录配置成支持超级用户或者根用户的形式。这是通过数据库定义中的下面两个选项来实现的：
rootdn <dn>;
rootpw <passwd>;
比如：
rootdn "cn=Manager,dc=example,dc=com"
rootpw secret
这两个选项指定了一个DN和口令来验证超级用户条目（也就是说，这个条目可以做任何事）。无论条目和口令是否在数据库中实际存在，这里指定的条目和口令都会起作用。这解决了“鸡和蛋的问题”--也就是如果条目还不存在的话如何验证有权添加条目的根用户条目。
最后，你要确保数据库定义当中包含了你想要的索引定义：
index {<attrlist>; | default} [pres,eq,approx,sub,none]
比如，要为cn, sn, uid 和 objectclass属性建立索引，应当使用下面的index指令：
index cn,sn,uid pres,eq,approx,sub
index objectClass eq
这将为cn, sn, 和 uid属性创建presence, equality, approximate, 和 substring索引，为objectClass属性创建equality索引。注意到不是对任何属性类型都有全部的索引类型可用。参看“slapd配置文件”一节可获得有关该选项的更多信息。
一旦你已经按照你的要求完成了配置，就启动slapd，同时用你的LDAP客户端连接到服务器上，开始添加条目。比如，要用ldapadd工具添加一个组织的条目和其内一个成员的条目，你可以创建一个名为entries.ldif的LDIF文件如下：
# Organization for Example Corporation
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
dc: example
o: Example Corporation
description: The Example Corporation
# Organizational Role for Directory Manager
dn: cn=Manager,dc=example,dc=com
objectClass: organizationalRole
cn: Manager
description: Directory Manager
然后使用类似下面的命令实际创建数据库：
ldapadd -f entries.ldif -x -D "cn=Manager,dc=example,dc=com" -w secret
上面的这个命令假定所有的选项都是按照上面的示例进行设置的。
7.2 脱机创建数据库
第二中创建数据库的方式是使用下面所列的slapd数据库工具脱机创建数据库。这种方式最适合于有好几千个条目需要创建的情况，因为如果还是按照上面所描述的方式来添加的话，花费的时间将是不可接受的。这些工具读取slapd配置文件和一个输入文件，这个输入文件包含着要添加的数据库条目的文本表示。对支持这些工具的数据库，它们将直接生成数据库文件（否则你就必须要用在线方式添加）。你要首先确保下面几个重要的配置选项在配置文件的数据库定义部分做了设置：
suffix <dn>;
如“通用数据库指令”一节中所述，这个选项定义了由这个数据库保存的条目。你应该把这个选项设置为你准备创建的目录子树的根DN。比如：
suffix "dc=example,dc=com"
你应当确保指定了一个索引文件所在的目录。
directory <directory>;
比如：
directory /usr/local/var/openldap-data
最后，你要确保数据库定义当中包含了你想要的索引定义：
index {<attrlist>; | default} [pres,eq,approx,sub,none]
比如，要为cn, sn, uid 和 objectclass属性建立索引，应当使用下面的index指令：
index cn,sn,uid pres,eq,approx,sub
index objectClass eq
这将为cn, sn, 和 uid属性创建presence, equality, approximate, 和 substring索引，为objectClass属性创建equality索引。注意到不是对任何属性类型都有全部的索引类型可用。参看“slapd配置文件”一节可获得有关该选项的更多信息。
7.2.1. slapadd程序
一旦你已经按照你的要求完成了配置，你就应当运行slapadd程序创建主（primary）数据库和相应的索引：
slapadd -l <inputfile>; -f <slapdconfigfile>;
[-d <debuglevel>;] [-n <integer>;|-b <suffix>;]
各项参数的意义如下：
-l <inputfile>;
指定了LDIF输入文件，这个文件包含了要以文本格式添加到数据库中的条目（在”LDIF文本条目格式“一节有详细描述）。
-f <slapdconfigfile>;
指定了slapd的配置文件，该配置文件指明了在什么地方创建什么样的索引，等等。
-d <debuglevel>;
打开调试开关，调试级别由<debuglevel>;指定。调试级别和slapd的调试级别是一样的。详情请参看“运行slapd”章节的“命令行选项”小节。
-n <databasenumber>;
一个可选的参数，用来指定修改哪一个数据库。在配置文件中最先出现的数据库编号为1，第二个为2，以此类推。默认情况下，会使用配置文件中的第一个数据库。注意该选项不应该和-b选项同时使用。
-b <suffix>;
一个可选的参数，用来指定修改哪一个数据库。通过把所给的后缀和数据库定义中的suffix指令匹配来决定数据库的序号。注意该选项不应该和-n选项同时使用。
7.2.2. slapindex程序
有时候可能需要重新生成索引（比如在修改了slapd.conf之后）。这可以通过slapindex程序来完成。slapindex是这样用的：
slapindex -f <slapdconfigfile>;
[-d <debuglevel>;] [-n <databasenumber>;|-b <suffix>;]
这里的-f, -d, -n 和 -b选项和slapadd程序当中的是一样的。slapindex在当前数据库内容的基础上重建所有索引。
7.2.3. slapcat程序
slapcat程序是用来将数据库转储（dump）到LDIF文件中。当你想把数据库以直观可读的方式进行备份或者你想脱机编辑数据库的时候，这都会是很有用的。这个是程序是像下面这样用的：
slapcat -l <filename>; -f <slapdconfigfile>;
[-d <debuglevel>;] [-n <databasenumber>;|-b <suffix>;]
这里的-n 或者 -b是用来选取slapd.conf中定义的数据库的。对应的LDIF输出到标准输出上或者输出到-l选项指定的文件中。
7.3 LDIF文本的条目格式
LDAP数据交换格式（LDIF）是用来简单的文本格式来表示LDAP条目的。本节将给出LDIF条目格式的一个简短描述，LDIF格式的详细情况在ldif手册和RFC2849技术手册中有更详尽的补充说明。
条目的基本格式是这样的：
# comment
dn: <distinguished name>;
<attrdesc>;: <attrvalue>;
<attrdesc>;: <attrvalue>;
...
以'#'开头的行是注释。属性类型可以是像cn 或者 objectClass 或者 1.2.3（与属性类型相对应的OID）或者可以包含像cn;lang_en_US 或者 userCertificate;binary这样的选项。
一个以单个空格或者制表符开头的新行是接着上一行的。比如：
dn: cn=Barbara J Jensen,dc=example,dc=
com
cn: Barbara J
Jensen
等价于：
dn: cn=Barbara J Jensen,dc=example,dc=com
cn: Barbara J Jensen
多个属性值可以在不同的行上指定。比如，
cn: Barbara J Jensen
cn: Babs Jensen
如果属性值<attrvalue>;包含不可打印字符或者以空格，冒号(':'),，小于号（'<'）开头的话，那么属性描述<attrdesc>;后跟的将是两个冒号与所给值的base64编码。比如，值" begins with a space"将会被编码成下面这样：
cn:: IGJlZ2lucyB3aXRoIGEgc3BhY2U=
你也可以指定一个包含属性值的URL。比如，下面的示例指定jpegPhoto应该来源于/path/to/file.jpeg。
cn:< file:///path/to/file.jpeg
相同的LDIF文件中的多个条目是用空行分隔开的。这里有一个包含三个条目的LDIF文件示例。
# Barbara's Entry
dn: cn=Barbara J Jensen,dc=example,dc=com
cn: Barbara J Jensen
cn: Babs Jensen
objectClass: person
sn: Jensen
# Bjorn's Entry
dn: cn=Bjorn J Jensen,dc=example,dc=com
cn: Bjorn J Jensen
cn: Bjorn Jensen
objectClass: person
sn: Jensen
# Base64 encoded JPEG photo
jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD
A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ
ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG
# Jennifer's Entry
dn: cn=Jennifer J Jensen,dc=example,dc=com
cn: Jennifer J Jensen
cn: Jennifer Jensen
objectClass: person
sn: Jensen
# JPEG photo from file
jpegPhoto:< file:///path/to/file.jpeg
注意到Bjorn条目中的jpegPhoto是base 64编码而Jennifer条目中的jpegPhoto是从URL指定的位置获取的。
-----------------------------------------------------------------------------------------------------------
注意：在LDIF文件中行末的空格是没有被截去的。行间的多个空格也不被压缩。如果你本意不是想让她们出现在那儿，那就不要把它们放进去。
-----------------------------------------------------------------------------------------------------------
作者: yj11 时间: 2004-10-12 21:32
标题: [翻译]OpenLDAP管理员指南(仅前七章)
厉害!!!
作者: zxpmyth 时间: 2004-10-22 15:34
标题: [翻译]OpenLDAP管理员指南(仅前七章)
这里有完整版的
http://i18n.linux.net.cn/others/OpenLDAP2.htm
作者: rockins 时间: 2004-10-31 17:02
标题: [翻译]OpenLDAP管理员指南(仅前七章)
恕在下愚钝，不知道如何删贴，斑竹删掉吧。
作者: andy820303 时间: 2008-05-03 09:20
这么好的文章为啥要删除掉呢?
作者: fish_happy 时间: 2008-05-05 18:54
dddddddddddddddd
| 欢迎光临 Chinaunix (http://bbs.chinaunix.net/) | Powered by Discuz! X3.2 |