OpenLDAPAdminGuide/TheSlapdConfigurationFile
The slapd Configuration File(slapd 配置文件)
Once the software has been built and installed, you are ready to configure slapd(8) for use at your site. The slapd runtime configuration is primarily accomplished through the slapd.conf(5) file, normally installed in the /usr/local/etc/openldap directory.
一旦成功编译和安装软件之后,您就要准备为您站点配置 slapd(8) 了。slapd 运行时配置主要是通过 slapd.conf(5) 文件来完成的,通常该文件安装在 /usr/local/etc/openldap 目录下。
An alternate configuration file can be specified via a command-line option to slapd(8) or slurpd(8). This chapter describes the general format of the config file, followed by a detailed description of commonly used config file directives.
还可以通过命令行选项来为 slapd(8) 或 slurpd(8) 其它的配置文件。本章描述了配置文件的通用格式,然后是常用配置文件指令的详细说明。
Configuration File Format(配置文件格式)
The slapd.conf(5) file consists of three types of configuration information: global, backend specific, and database specific. Global information is specified first, followed by information associated with a particular backend type, which is then followed by information associated with a particular database instance. Global directives can be overridden in backend and/or database directives, and backend directives can be overridden by database directives.
slapd.conf(5) 文件由三部分的配置信息组成:全局的、特定后台的和特定数据库的。首先是指定全局信息,随后是特定后台类型的关联信息,再后面是特定数据库实例的关联信息。全局指令可以被特定后台和特定数据库的指令覆盖,并且后台指令也能被数据库指令覆盖。
Blank lines and comment lines beginning with a '#' character are ignored. If a line begins with white space, it is considered a continuation of the previous line (even if the previous line is a comment).
空白行和以“#”开始的注释行被忽略。如果一行以空格开始,它被认为是上一行的延续(甚至上一行是注释行)。
The general format of slapd.conf is as follows:
slapd.conf 通用格式如下所示:
# global configuration directives <global config directives> # backend definition backend <typeA> <backend-specific directives> # first database definition & config directives database <typeA> <database-specific directives> # second database definition & config directives database <typeB> <database-specific directives> # second database definition & config directives database <typeA> <database-specific directives> # subsequent backend & database definitions & config directives ...
A configuration directive may take arguments. If so, they are separated by white space. If an argument contains white space, the argument should be enclosed in double quotes "like this". If an argument contains a double quote or a backslash character `\', the character should be preceded by a backslash character `\'.
配置语句是可以有参数,如果是那样的话,参数之间用空白符分隔。如果参数中包含空白符,那么参数将被双引号引起来:"就象这样"。如果参数中包含双引号或反斜线 “\”,那么应该在它们前面加一个“\”。
The distribution contains an example configuration file that will be installed in the /usr/local/etc/openldap directory. A number of files containing schema definitions (attribute types and object classes) are also provided in the /usr/local/etc/openldap/schema directory.
发行版包含了一个配置示例文件,被安装在 /usr/local/etc/openldap 目录下。软件还提供了许多包含模式定义(属性类型 attribute types 和对象类 inject classes)文件,它们在 /usr/local/etc/openldap/schema 目录下。
Configuration File Directives(配置文件指令)
This section details commonly used configuration directives. For a complete list, see the slapd.conf(5) manual page. This section separates the configuration file directives into global, backend-specific and data-specific categories, describing each directive and its default value (if any), and giving an example of its use.
本部分详细描述了常用的配置指令。要得到完整的列表,请参阅 slapd.conf(5) 的手册页。本部分将配置文件指令分为全局的,特定后台的和特定数据的三类,并描述了每条指令及其缺省值(如果有的话),并就其使用给出了示例。
Global Directives(全局指令)
Directives described in this section apply to all backends and databases unless specifically overridden in a backend or database definition. Arguments that should be replaced by actual text are shown in brackets <>.
本部分描述的指令应用于所有的后台和数据库,除非其在后台或者数据库的定义中被明确覆盖。显示在尖括号<>中的参数应该被实际文本替换。
access to <what> [ by <who> <accesslevel> <control> ]+
This directive grants access (specified by <accesslevel>) to a set of entries and/or attributes (specified by <what>) by one or more requesters (specified by <who>). See the Access Control section of this chapter for a summary of basic usage.
这个指令授予一个或多个(被 <who> 指定的)请求者以访问(被 <what> 指定的)条目及其属性集的(被 <accesslevel> 所指定的)权限。参阅本章的访问控制部分以获得基本用法的简介。
Note: If no access directives are specified, the default access control policy, access to * by * read, allows all both authenticated and anonymous users read access.
注意:如果没有指定访问指令,那么缺省的访问控制策略,to * by * read,将允许所有用户(包括授权和匿名用户)有读的权限。
attributetype <RFC2252 Attribute Type Description>
This directive defines an attribute type. Please see the Schema Specification chapter for information regarding how to use this directive.
这个指令定义一个属性类型。如何使用该指令的相关信息请参阅模式说明这一章的内容。
idletimeout <integer>
Specify the number of seconds to wait before forcibly closing an idle client connection. An idletimeout of 0, the default, disables this feature.
指定关闭一个空闲客户连接前所需等待的秒数。缺省值是0,表示禁用本特性。
include <filename>
This directive specifies that slapd should read additional configuration information from the given file before continuing with the next line of the current file. The included file should follow the normal slapd config file format. The file is commonly used to include files containing schema specifications.
这个指令指定 slapd 在读取当前文件的下一行之前必须从给定的文件中读取附加配置信息。被包含的文件应该符合 slapd 配置文件的一般格式。该文件常被用来包含模式说明。
Note: You should be careful when using this directive - there is no small limit on the number of nested include directives, and no loop detection is done.
注意:您应该小心使用本指令 - 它对 include 指令的嵌套数没有限制,同时不做循环保护。
loglevel <integer>
This directive specifies the level at which debugging statements and operation statistics should be syslogged (currently logged to the syslogd(8) LOG_LOCAL4 facility). You must have configured OpenLDAP --enable-debug (the default) for this to work (except for the two statistics levels, which are always enabled). Log levels are additive. To display what numbers correspond to what kind of debugging, invoke slapd with -? or consult the table below. The possible values for <integer> are:
本指令指定调试状态和操作统计应该被记录的级别(当前被 syslogd(8) LOG_LOCAL4 工具记录)。您需要在编译时使用 OpenLDAP --enable-debug (缺省)才能正常使用本指令(两个统计级别除外,它们总是被启用)。日志级别可以使用整数或通过关键词来指定。可以使用多日志级别,级别是可以累加的。要显示哪种级别对应哪种调试,在运行 slapd 时使用 -? 或查阅下表。<level> 可能的值如下所示:
Table 5.1: Debugging Levels
level | Keyword | Description |
0 | no debugging | |
1 | Trace | trace function calls |
2 | Packets | debug packet handling |
4 | Args | heavy trace debugging |
8 | Conns | connection management |
16 | BER | print out packets sent and received |
32 | Filter | search filter processing |
64 | Config | configuration processing |
128 | ACL | access control list processing |
256 | Stats | stats log connections/operations/results |
512 | Stats2 | stats log entries sent |
1024 | Shell | print communication with shell backends |
2048 | Parse | print entry parsing debugging |
4096 | Cache | database cache processing |
8192 | Index | database indexing |
16384 | Sync | syncrepl consumer processing |
Example:
loglevel -1
This will cause lots and lots of debugging information to be logged. 这将引起非常非常多的调试信息被记录。
Default:
loglevel 256
objectclass <RFC2252 Object Class Description>
This directive defines an object class. Please see the Schema Specification chapter for information regarding how to use this directive.
这个指定定义一个对象类。请参阅模式说明章节以获取如何使用该命令的相关信息。
referral <URI>
This directive specifies the referral to pass back when slapd cannot find a local database to handle a request.
该指令指定了在 slapd 处理请求时如果不能在本地数据库中找到信息将返回的引用。
Example:
referral ldap://root.openldap.org
This will refer non-local queries to the global root LDAP server at the OpenLDAP Project. Smart LDAP clients can re-ask their query at that server, but note that most of these clients are only going to know how to handle simple LDAP URLs that contain a host part and optionally a distinguished name part.
它将非本地的查询引向 OpenLDAP 项目中的全局根 LDAP 服务器。LDAP 的智能客户端可以向该服务器上重新提交请求,但请注意大多数这样的客户端只知道如何处理简单的 LDAP URLs,它们包括一个主机部分和一个可选的标识名部分。
sizelimit <integer>
This directive specifies the maximum number of entries to return from a search operation.
本指令指定搜索返回的条目最大数。
Default:
sizelimit 500
timelimit <integer>
This directive specifies the maximum number of seconds (in real time) slapd will spend answering a search request. If a request is not finished in this time, a result indicating an exceeded timelimit will be returned.
该指令说明了 slapd 在应答搜索请求时花费的最长秒数(真实时间)。如果一个请求在该时间内没有完成将会返回一个表示超时的结果。
Default:
timelimit 3600
General Backend Directives(常用后台指令)
Directives in this section apply only to the backend in which they are defined. They are supported by every type of backend. Backend directives apply to all databases instances of the same type and, depending on the directive, may be overridden by database directives.
本部分说明的指令只应用于定义它们的后台。它们被所有类型的后台所支持。后台指令应用于所有相同类型的数据库实例,并且根据指令的不同也可能被数据库指令覆盖。
backend <type>
This directive marks the beginning of a backend declaration. <type> should be one of the supported backend types listed in Table 5.2.
该指令表示一个后台声明的开始。<type> 应该是表 5.2 中列出被支持的后台类型之一。
Table 5.2: Database Backends
Types | Description |
bdb | Berkeley DB transactional backend |
config | Slapd configuration backend |
dnssrv | DNS SRV backend |
hdb | Hierarchical variant of bdb backend |
ldap | Lightweight Directory Access Protocol (Proxy) backend |
ldbm | Lightweight DBM backend |
ldif | Lightweight Data Interchange Format backend |
meta | Meta Directory backend |
monitor | Monitor backend |
passwd | Provides read-only access to passwd(5) |
perl | Perl Programmable backend |
shell | Shell (extern program) backend |
sql | SQL Programmable backend |
Example:
backend bdb
This marks the beginning of a new BDB backend definition.
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 database instance declaration. <type> should be one of the supported backend types listed in Table 5.2.
该指令表示一个数据库实例声明的开始。<type> 应该是表 5.2 中列出被支持的后台类型之一。
Example:
database bdb
This marks the beginning of a new BDB database instance declaration.
这表明声明一个新的BDB数据库实例的开始。
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.
这个指令将数据库置入“只读”模式。任何对该数据库所做的修改尝试将返回“unwilling to perform”的错误。
Default:
readonly off
replica
replica uri=ldap[s]://<hostname>[[UbuntuHelp:<port>] | host=<hostname>[|<port>]] [bindmethod={simple|sasl}] [[UbuntuHelp:binddn=<DN>]] [saslmech=<mech>] [authcid=<identity>] [authzid=<identity>] [credentials=<password>]
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.
这个指令为这个数据库指定了一个复制站点。 uri=parameter 指定了一个可以找到从 slapd 服务的主机加端口号(可选)的组合,<hostname> 可以使用域名也可以用 IP 地址。如果没有指定 <port>,那么将使用标准的 LDAP 端口号(389 或 636)。
host is deprecated in favor of the uri parameter.
不推荐用 host 来取代 uri 参数。
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.
uri 允许复制 LDAP 服务器到指定的 LDAP URI 去,如 ldap://slave.example.com:389 或 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.
binddn= parameter 给出了更新从 slapd 的 DN。该 DN 应该对从 slapd 数据库有读/写权限。它也应该与从 slapd 配置文件中的 updatedn 指令相吻合。通常该 DN 不应该与主数据库中的 rootdn 相同。因为 DN 有可能包含空格,所以条目 "binddn=<DN>" 字符串应该包含在双引号中。
The bindmethod is simple or sasl, depending on whether simple password-based authentication or SASL authentication is to be used when connecting to the slave slapd.
bindmethod 是 simple 或是 sasl,这将取决于当连接从 slapd 时所使用的是基于密码的简单认证,还是 SASL 认证。
Simple authentication should not be used unless adequate data integrity and confidentiality protections are in place (e.g. TLS or IPSEC). Simple authentication requires specification of binddn and credentials parameters.
除非有着足够的数据完整性和私密性保护措施(如 TLS 或 IPSEC),否则不应使用简单认证。简单认证要求指定 binddn 和 credentials 参数。
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.
SASL 认证通常是被推荐的。SASL 认证要求使用 saslmech 参数来指定一种(认证)机制。根据该机制,需要分别使用 authcid 和 credentials 来指定一个认证 ID 和 证书。authzid 参数则被用来指定一个授权 ID。
See the chapter entitled Replication with slurpd for more information on how to use this directive.
参见使用 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.
本指令指定记录 slapd 改变的复制日志文件名。复制日志通常被 slapd 写而被 slurpd 读。一般情况下,只有在 slurpd 用于复制数据库时才使用本指令。不过在 slurpd 没有运行的情况下,您也可以用它来生成事务日志。在这种情况下,您将需要定期截断文件,否则它将会无限增长下去。
See the chapter entitled Replication with slurpd for more information on how to use this directive.
如何使用本指令可参阅用 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 this database or even in the directory. The DN may refer to a SASL identity.
本指令指定的 DN 对本数据库的操作不受访问控制或管理权限的限制。该 DN 不应该指向本数据库甚至是在目录中的(任何)条目。它也可以指向 SASL ID。
Entry-based Example:
rootdn "cn=Manager,dc=example,dc=com"
SASL-based Example:
rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"
See the SASL Authentication section for information on SASL authentication identities.
SASL 认证 ID 的信息可参见 SASL 认证部分
rootpw <password>
This directive can be used to specifies a password for the DN for the rootdn (when the rootdn is set to a DN within the database).
本指定常被用于指定 rootdn 的 DN 密码(当 rootdn 被设置成在数据库中的 DN 时)
Example:
rootpw secret
It is also permissible to provide hash of the password in RFC 2307 form. slappasswd(8) may be used to generate the password hash.
它也允许提供 RFC 2307 格式的密码哈希值。slappasswd(8) 可以用来生成密码哈希值。
Example:
rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
The hash was generated using the command slappasswd -s secret.
该哈希值可以使用命令 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.
本指令指定发送到本后台数据库查询的 DN 后缀。可以给出多个后缀行,并且通常每个数据库定义至少要求一个。(有些使用硬编码后缀的后台类型象前台和监视,可能不会被配置中的覆盖。)
Example:
suffix "dc=example,dc=com"
Queries with a DN ending in "dc=example,dc=com" will be passed to this backend.
以 "dc=example,dc=com" 结尾的查询将发送到本后台。
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.
注意:当选择了一个传递给后台的查询时,slapd 在每个数据库定义中按照它们在文件中出现的顺序查找后缀行。因此如果一个数据库后缀是另一个(数据库)的前缀,那么它在配置文件中就必须出现在另一个的后面。
syncrepl
syncrepl rid=<replica ID> provider=ldap[s]://<hostname>[[UbuntuHelp:port]] [type=refreshOnly|refreshAndPersist] [interval=dd:hh:mm:ss] [retry=[<retry interval> <# of retries>]+] [searchbase=<base DN>] [filter=<filter str>] [scope=sub|one|base] [attrs=<attr list>] [attrsonly] [sizelimit=<limit>] [timelimit=<limit>] [schemachecking=on|off] [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(8) 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.
本指令指定作为主(数据库)内容副本的当前数据库,该数据库是通过运行着 syncrepl 复制引擎的复制客户站点的 slapd(8) 创建的。主数据库是通过 provider 参数所指定的复制提供站点来定位的。副本数据库通过使用 LDAP 内容同步协议来与主(数据库)内容保持一致。有关该协议的更多信息请参阅 draft-zeilenga-ldup-sync-xx.txt (a work in progress)。
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.
rid 参数被用作复制客户服务器中当前同步复制指令的 ID,<replica ID> 唯一标识当前同步复制指令的同步复制详细描述。 <replica ID> 不能是负数,长度也不能超过三位十进制数。
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.
provider 参数以 LDAP URI 的形式指定包含主(数据库)内容的复制提供站点。指定了一个可以找到从 slapd 服务的主机加端口号(可选)的组合,<hostname> 可以使用域名也可以用 IP 地址。如果没有指定 <port>,那么将使用标准的 LDAP 端口号(389 或 636)。注意 syncrepl 使用的是客户初始化协议,因此它是在客户站点上进行指定的,而 replica 的指定则是在提供站点上。syncrepl 和 replica 指令定义了两个不同的复制机制。它们并不意味着能相互进行复制。
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.
syncrepl 复制的内容是指用搜索明细表来作为结果集。客户端的 slapd 将发送搜索请求给提供端的 slapd 以使搜索明细表一致。该搜索明细表按照正常搜索明细表来说包括 searchbase、scope、filter、attrs、attrsonly、sizelimit 和 timelimit 等参数。syncrepl 搜索明细表就象 ldapsearch(1) 客户端搜索工具一样有着相同的值语法和缺省值。
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.
LDAP 内容同步协议有两种操作类型:refreshOnly
和 refreshAndPersist
。操作类型是由类型参数指定的。在 refreshOnly
操作中,下一个同步搜索操作在每次同步操作完成后的时间间隔内被周期性地重新安排。时间间隔由 interval 参数指定,缺省为一天。在 refreshAndPersist
操作中,同步搜索一直由提供端的 slapd 持续更新。到主复制的更多更新将生成 searchResultEntry
并做为持续同步搜索的搜索结果发送给客户端 slapd。
If an error occurs during replication, the consumer will attempt to reconnect according to the retry parameter which is a list of the <retry interval> and <# of retries> pairs. For example, retry="60 10 300 3" lets the consumer retry every 60 seconds for the first 10 times and then retry every 300 seconds for the next three times before stop retrying. + in <# of retries> means indefinite number of retries until success.
如果在复制过程中产生错误,客户端将按照 retry 参数尝试重新连接,该参数是 <retry interval> 和 <# of retries> 对的列表。举个例子,retry="60 10 300 3" 就是将客户端在开始的10次里每60秒重试一次,然后在接下来的3次里每300秒重试一次,然后停止重试。在 <# of retries> 中的 + 表示在成功之前不限定重试次数。
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.
模式检查可以在 LDAP 同步客户端中通过打开 schemachecking 参数的方式强制执行。如果它被打开的话,那么每个复制条目在其被保存到复制内容时都将被其模式。每个在复制中的条目都应包括被模式定义所要求的那些属性。如果它被关闭的话,那么条目将在没进行模式确认的情况下被保存。缺省是关闭。
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.
binddn 参数指定到提供端 slapd 进行 syncrepl 搜索的 DN。该 DN 应该对主数据库中复制内容有读权限。
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.
bindmethod 是 simple 还是 sasl,取决于在联连提供端 slapd 时是使用简单基于密码的认证还是 SASL 认证。
Simple authentication should not be used unless adequate data integrity and confidentiality protections are in place (e.g. TLS or IPSEC). Simple authentication requires specification of binddn and credentials parameters.
除非有着足够的数据完整性和私密性保护措施(如 TLS 或 IPSEC),否则不应使用简单认证。简单认证要求指定 binddn 和 credentials 参数。
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.
SASL 认证通常是被推荐的。SASL 认证要求使用 saslmech 参数的特定机制。根据该机制,一个认证 ID 或证书将被指定使用各自的 authcid 或证书。authzid 参数可能被用来指定一个授权 ID。
The realm parameter specifies a realm which a certain mechanisms authenticate the identity within. The secprops parameter specifies Cyrus SASL security properties.
realm 参数指定一个在其中运行某种认证 ID 机制的 realm。secprops 参数指定 Cyrus SASL 安全参数。
The syncrepl replication mechanism is supported by the three native backends: back-bdb, back-hdb, and back-ldbm.
syncrepl 复制机制被当前三个后台支持:back-bdb、back-hdb 和 back-ldbm。
See the LDAP Sync Replication chapter of the admin guide for more information on how to use this directive.
请参阅 LDAP 同步复制一章以了解关于如何使用该指令的更多信息。
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.
本指令只适用于从 slapd。它指定了允许对副本进行改变的 DN。这可能是 slurpd(8) 在改变复本时所绑定的 DN,或是与 SASL ID 相关联的 DN。
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.
请参阅 使用 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.
本指令只适用于从 slapd。它指定了当客户端对副本提交更新请求时返回给客户端的 URL。如果是多次指定的话就要提供每次的 URL。
Example:
updateref ldap://master.example.net
BDB and HDB Database Directives(BDB 和 HDB 数据库指令)
Directives in this category only apply to both the BDB and the HDB database. That is, they must follow a "database bdb" or "database hdb" line and come before any subsequent "backend" or "database" line. For a complete reference of BDB/HDB configuration directives, see slapd-bdb(5).
本类指令只能应用于 BDB 和 HDB 数据库。也就是说,它们必须跟在“database ldbm”语句行之后,下一个“backend”或“database”语句行之前。
directory <directory>
This directive specifies the directory where the BDB files containing the database and associated indices live.
本指令指定包含数据库和相关索引的 BDB 文件所在的目录
Default:(缺省)
directory /usr/local/var/openldap-data
LDBM Database Directives(LDBM 数据库指令)
Directives in this category only apply to a LDBM database. That is, they must follow a "database ldbm" line and come before any subsequent "backend" or "database" line. For a complete reference of LDBM configuration directives, see slapd-ldbm(5).
本类指令只能应用于 LDBM 数据库。也就是说,它们必须跟在“database ldbm”语句行之后,下一个“backend”或“database”语句行之前。
cachesize <integer>
This directive specifies the size in entries of the in-memory cache maintained by the LDBM backend database instance.
本指令指定 LDBM 后台数据库实例维护的内存缓存中条目数。
Default:
cachesize 1000
dbcachesize <integer>
This directive specifies the size in bytes of the in-memory cache associated with each open index file. If not supported by the underlying database method, this directive is ignored without comment. Increasing this number uses more memory but can cause a dramatic performance increase, especially during modifies or when building indices.
本指令指定了与每个打开的索引文件相关联的内存缓存的字节数。如果它不被数据库底层方法所支持,那么该指令将被无条件忽略。增加本字节数将会使用更多的内存,但可以使得性能大幅度上升,尤其是在修改或创建索引时。
Default:(缺省)
dbcachesize 100000
dbnolocking
This option, if present, disables database locking. Enabling this option may improve performance at the expense of data security.
该选项如果存在将禁止数据库锁定。允许该选项可以在牺牲数据安全性的情况下提高性能。
dbnosync
This option causes on-disk database contents to not be immediately synchronized with in memory changes upon change. Enabling this option may improve performance at the expense of data integrity.
本选项使得当发生改变时,磁盘上的数据库内容不会立即和内存中的内容进行同步。允许该选项可以在牺牲数据安全性的情况下提高性能。
directory <directory>
This directive specifies the directory where the LDBM files containing the database and associated indices live.
本指令指定包含数据库和相关索引的 LDBM 文件所在的目录
Default:(缺省)
directory /usr/local/var/openldap-data
index {<attrlist> | default} [pres,eq,approx,sub,none]
This directive specifies the indices to maintain for the given attribute. If only an <attrlist> is given, the default indices are maintained.
本指令指定维护所给属性的索引。如果给定 <attrlist> ,那么将维护缺省的索引。
Example:
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.
第1行设置缺省的索引集来维护 present 和 equality,第2行是因为 uid 属性类型才维护缺省的 (pres,eq) 索引集。第3行是因为 cn 和 sn 属性类型才维护 present、equality 和 substring 索引。第4行是因为 objectClass 属性类型才维护 equality 索引。
By default, no indices are maintained. It is generally advised that minimally an equality index upon objectClass be maintained.
默认情况下,不做任何索引维护。通常建议对 objectClass 做 equality 索引。
index objectClass eq
mode <integer>
This directive specifies the file protection mode that newly created database index files should have.
本指令指定新建数据库索引文件应有的文件保护模式:
Default:(缺省)
mode 0600
Access Control(访问控制)
Access to slapd entries and attributes is controlled by the access configuration file directive. The general form of an access line is:
访问 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]
where the <what> part selects the entries and/or attributes to which the access applies, the <who> part specifies which entities are granted access, and the <access> part specifies the access granted. Multiple <who> <access> <control> triplets are supported, allowing many entities to be granted different access to the same set of entries and attributes. Not all of these access control options are described here; for more details see the slapd.access(5) man page.
<what> 部分选择访问权限所应用的条目和属性。<who> 部分指出哪个实体被赋予了访问权限,<access> 部分说明赋予了怎样的访问权限。可以指定多个 <who> <access> <control> 三元组,允许对多个实体指定不同的访问权限到相同的条目属性集。这里并未列出所有的访问控制选项,更多细节请参阅 slapd.access(5) 手册页。
What to control access to(控制什么的访问权限)
The <what> part of an access specification determines the entries and attributes to which the access control applies. Entries are commonly selected in two ways: by DN and by filter. The following qualifiers select entries by DN:
指明访问权限的 <what> 部分决定了访问控制应用于哪些条目和属性。条目一般可通过两种方式选择:通过 DN 和 通过过滤器。下列是通过 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 the target entry's normalized DN. (The second form is not discussed further in this document.) The third form is used to select entries which are within the requested scope of DN. The <DN> is a string representation of the Distinguished Name, as described in RFC2253.
第一种格式被用来选择所有的条目。第二种格式是通过匹配一个正则表达式来选择那些 DN 合乎标准的条目。(第二种格式将不在本文档做进一步讨论。)第三种格式被用来在指定的 DN 范围里选择选择条目。就象 RFC2253 中描述的那样,<DN> 则是用来表示标识名(DN)的一个字符串。
The scope can be either base, one, subtree, or children. Where base matches only the entry with provided DN, one matches the entries whose parent is the provided DN, subtree matches all entries in the subtree whose root is the provided DN, and children matches all entries under the DN (but not the entry named by the DN).
范围可以是 base、one、subtree 或 children。base 只匹配给定 DN 的条目,one 匹配父节点是给定 DN 的条目,subtree 匹配根是给定 DN 子树的全部条目,children 则匹配该 DN 下的全部条目(但不含以该 DN 命名的条目)。
For example, if the directory contained entries named:
例如,如果目录包括以下条目名:
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
Then:
那么:
dn.base="ou=people,o=suffix" match 2; dn.one="ou=people,o=suffix" match 3, and 5; dn.subtree="ou=people,o=suffix" match 2, 3, 4, and 5; and dn.children="ou=people,o=suffix" match 3, 4, and 5.
Entries may also be selected using a filter:
条目也可以通过使用过滤器来选择:
to filter=<ldap filter>
where <ldap filter> is a string representation of an LDAP search filter, as described in RFC2254. For example:
就象 RFC2254 中描述的那样,<ldap filter> 是用来表示 LDAP 搜索过滤器的一个字符串。例如:
to filter=(objectClass=person)
Note that entries may be selected by both DN and filter by including both qualifiers in the <what> clause.
注意可以通过在 <what> 子句中包括 DN 和过滤器的限定词的方式同时通过两者进行选择条目。
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:
通过在 <what> 选择器中包含一个用逗号分隔的属性列表来选择条目中的属性:
attrs=<attribute list>
A specific value of an attribute is selected by using a single attribute name and also using a value selector:
属性的特定值可以通过使用单一属性名或值选择器来进行选择:
attrs=<attribute> val[.<style>]=<regex>
There are two special pseudo attributes entry and children. To read (and hence return) a target entry, the subject must have read access to the target's entry attribute. To add or delete an entry, the subject must have write access to the entry's entry attribute AND must have write access to the entry's parent's children attribute. To rename an entry, the subject must have write access to entry's entry attribute AND have write access to both the old parent's and new parent's children attributes. The complete examples at the end of this section should help clear things up.
这有两个特殊的伪属性条目及其子条目。要读目的条目,则必须要有目的条目属性的读权限。要添加或删除条目,则必须要有对条目属性的写权限以及对该条目父节点的子节点属性的写权限。要重命名条目,则必须对条目的条目属性要有写权限以及对老的父节点和新的父节点的子节点属性要有写权限。本部分最后的完整示例将会帮助搞清楚。
Lastly, there is a special entry selector "*" that is used to select any entry. It is used when no other <what> selector has been provided. It's equivalent to "dn=.*"
最后,有一个特殊的条目选择器“*”,它被用来选择任何条目。当没有提供其他的 <what> 选择器时使用该选择器。它等同于“dn=.*”。
Who to grant access to(谁被赋予权限)
The <who> part identifies the entity or entities being granted access. Note that access is granted to "entities" not "entries." The following table summarizes entity specifiers:
<who> 部分标明了被赋予访问权限的实体。注意,权限是被赋予“实体”而非“条目”。下表是对实体说明符的概述:
Table 5.3: Access Entity Specifiers
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 范围内的用户) |
The DN specifier behaves much like <what> clause DN specifiers.
DN 说明符与 <what> 子句中的 DN 说明符表现非常相似。
Other control factors are also supported. For example, a <who> can be restricted by an entry listed in a DN-valued attribute in the entry to which the access applies:
它也支持其他控制要素。如,<who> 可以被条目的 DN 值属性中所列的条目所限定其权限的应用:
dnattr=<dn-valued attribute name>
The dnattr specification is used to give access to an entry whose DN is listed in an attribute of the entry (e.g., give access to a group entry to whoever is listed as the owner of the group entry).
dnattr 说明符被用来将权限赋予一个条目,其 DN 被列在该条目的属性中(如将权限赋予一个组条目,无论是谁在其中都将被认为是该组条目的所有者)。
Some factors may not be appropriate in all environments (or any). For example, the domain factor relies on IP to domain name lookups. As these can easily spoofed, the domain factor should not be avoided.
某些因素也许并不适用于所有(或某些)环境。例如,域因素有赖于 IP 到域名的查找。当这些可能很容易的欺骗时,域因素也不能避免。
The access to grant(要赋予的权限)
The kind of <access> granted can be one of the following:
要赋予的 <access> 种类可以是下列之一:
Table 5.4: Access Levels
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(需要修改/重命令) |
Each level implies all lower levels of access. So, for example, granting someone write access to an entry also grants them read, search, compare, and auth access. However, one may use the privileges specifier to grant specific permissions.
每个级别都隐含着所有更低的权限级别。因此,举个例子,赋予某人有某条目的 write 权限,也就赋予他们 read、search、compare 和 auth 权限。然而,也可以使用 privileges 说明符用来赋予特定的权限。
Access Control Evaluation(访问控制计算)
When evaluating whether some requester should be given access to an entry and/or attribute, slapd compares the entry and/or attribute to the <what> selectors given in the configuration file. For each entry, access controls provided in the database which holds the entry (or the first database if not held in any database) apply first, followed by the global access directives. Within this priority, access directives are examined in the order in which they appear in the config file. Slapd stops with the first <what> selector that matches the entry and/or attribute. The corresponding access directive is the one slapd will use to evaluate access.
当计算某些请求者是否应该被赋予访问条目或属性的权限时,slapd 将比较条目或属性与配置文件中的 <what> 选择器相比较。对每个条目而言,包含该条目的数据库所提供的访问控制将被首先应用,(或者是第一个数据库,如果它没有包含在任何数据库中的话),然后是全局的访问控制指令。在这种优先级的情况下,权限指令按照它们在配置文件中出现的顺序被检查。Slapd 在找到第一个匹配该条目或属性的 <what> 选择器时停止。相应的权限指令就是 slapd 用来计算权限的。
Next, slapd compares the entity requesting access to the <who> selectors within the access directive selected above in the order in which they appear. It stops with the first <who> selector that matches the requester. This determines the access the entity requesting access has to the entry and/or attribute.
接下来,slapd 对比实体所要求的权限与上述权限指令中 <who> 选择器所选的,按其出现顺序进行比较。它将在找到第一个匹配该请求的 <who> 选择器时停止。这决定了实体访问条目或属性时所要求的权限。
Finally, slapd compares the access granted in the selected <access> clause to the access requested by the client. If it allows greater or equal access, access is granted. Otherwise, access is denied.
最后,slapd 对比在所选的 <access> 子句中所赋予的权限与客户所要求的权限。如果它允许更大或相等的权限,那么权限将被赋予,否则将拒绝授权。
The order of evaluation of access directives makes their placement in the configuration file important. If one access directive is more specific than another in terms of the entries it selects, it should appear first in the config file. Similarly, if one <who> selector is more specific than another it should come first in the access directive. The access control examples given below should help make this clear.
权限指令的计算顺序使得它们在配置文件中的顺序十分重要。如果一个权限指令在所选的条目方面比另一个更加明确,那么它应该最先出现在配置文件中。同样,如果一个<who> 选择器比另一个更加明确,那么它应该最先出现在存取控制指令中。下面给出的访问控制示例可以让它更加清楚。
Access Control Examples(访问控制示例)
The access control facility described above is quite powerful. This section shows some examples of its use for descriptive purposes.
上述的访问控制应用十分强大。这部分将分类演示它的用法。
A simple example:(一个简单的例子)
access to * by * read
This access directive grants read access to everyone.
这个权限指令赋予每个人有读的权限。
access to * by self write by anonymous auth by * read
This directive allows the user to modify their entry, allows anonymous to authentication against these entries, and allows all others to read these entries. Note that only the first by <who> clause which matches applies. Hence, the anonymous users are granted auth, not read. The last clause could just as well have been "by users read".
该指令允许用户去修改它们的条目,允许匿名者验证这些条目,并允许所有其他人读这些条目。注意只有第一个 by <who> 子句匹配应用。因此,匿名用户被赋予 auth,而非 read。最后的子句和“by users read”效果相同。
It is often desirable to restrict operations based upon the level of protection in place. The following shows how security strength factors (SSF) can be used.
常常要基于适当的保护级别来限制操作。下面显示了如何使用安全强度因子(SSF)。
access to * by ssf=128 self write by ssf=64 anonymous auth by ssf=64 users read
This directive allows users to modify their own entries if security protections have of strength 128 or better have been established, allows authentication access to anonymous users, and read access when 64 or better security protections have been established. If client has not establish sufficient security protections, the implicit by * none clause would be applied.
如果安全保护强度为128或更好时,该指令允许用户修改它们自己的条目,允许在有64或更好的安全保护的情况下给匿名用户 auth 权限以及读权限。如果客户没有生成足够的安全保护时,隐含的 by * none 将被应用。
The following example shows the use of a style specifiers to select the entries by DN in two access directives where ordering is significant.
下面的例子显示在两个权限指令中 style 说明符通过 DN 选择条目的用法,它们的顺序是有意义的。
access to dn.children="dc=example,dc=com" by * search access to dn.children="dc=com" by * read
Read access is granted to entries under the dc=com subtree, except for those entries under the dc=example,dc=com subtree, to which search access is granted. No access is granted to dc=com as neither access directive matches this DN. If the order of these access directives was reversed, the trailing directive would never be reached, since all entries under dc=example,dc=com are also under dc=com entries.
在 dc=com 子树下,除了 dc=example,dc=com 子树下的那些条目被赋予了搜索权限之外,其他条目都被赋予了读权限。没有任何权限被赋予给 dc=com,因为没有任何权限指令能匹配该 DN。如果这些权限指令顺序颠倒的话,后面的权限将永远无法到达,因为所有在 dc=example,dc=com 下的条目也一定在 dc=com 条目下。
Also note that if no access to directive matches or no by <who> clause, access is denied. That is, every access to directive ends with an implicit by * none clause and every access list ends with an implicit access to * by * none directive.
也注意如果没有权限匹配指令或 by <who> 子句,那么权限将被拒绝。这个因为每个权限指令的最后都有隐含了一个 by * none 子句,而每个访问列表的最后都有隐含一个 access to * by * none 指令。
The next example again shows the importance of ordering, both of the access directives and the by <who> clauses. It also shows the use of an attribute selector to grant access to a specific attribute and various <who> selectors.
接下来的例子也通过权限指令和 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.regex=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
This example applies to entries in the "dc=example,dc=com" subtree. To all attributes except homePhone, an entry can write to itself, entries under example.com entries can search by them, anybody else has no access (implicit by * none) excepting for authentication/authorization (which is always done anonymously). The homePhone attribute is writable by the entry, searchable by entries under example.com, readable by clients connecting from network 10, and otherwise not readable (implicit by * none). All other access is denied by the implicit access to * by * none.
该示例应用于 "dc=example,dc=com" 子树的条目。除 homePhone 外的所有属性,条目可以被它自己写,example.com 下的条目可以被他们搜索,其他人除了授权/认证外(总是匿名做的)将没有任何权限(隐含 by * none)。homePhone 属性则可被该条目写,被 example.com 下的条目搜索,除了能被来自 10 网段连接的客户读取外其他将不能读(隐含 by * none)。所有其他的权限将被隐含的 access to * by * none 所拒绝。
Sometimes it is useful to permit a particular DN to add or remove itself from an attribute. For example, if you would like to create a group and allow people to add and remove only their own DN from the member attribute, you could accomplish it with an access directive like this:
有时允许特定 DN 从属性中增加或删除自己是有用的。例如,如果您想创建一个组并允许人们从成员属性中删除添加或删除他们自己的 DN,您可以如下所示通过权限指令来完成它:
access to attr=member,entry by dnattr=member selfwrite
The dnattr <who> selector says that the access applies to entries listed in the member attribute. The selfwrite access selector says that such members can only add or delete their own DN from the attribute, not other values. The addition of the entry attribute is required because access to the entry is required to access any of the entry's attributes.
dnattr <who> 选择器说明权限应用于 member 属性中所列的条目。selfwrite 权限选择器说明来自该属性的成员只能添加或删除它们自身的 DN,而不是其他的值。要求要加入条目属性是因为访问条目要求访问该条目的任何属性。
Configuration File Example(配置文件示例)
The following is an example configuration file, interspersed with explanatory text. It defines two databases to handle different parts of the X.500 tree; both are BDB database instances. The line numbers shown are provided for reference only and are not included in the actual file. First, the global configuration section:
下面是一个配置示例文件,其中有着说明文本。它定义了两个数据库来处理 X.500 树的不同部分;两个都是 BDB 数据库实例。行号显示只是为了提供参考,它并不包括在实际文件中。首先是全局配置部分:
** # example config file - global configuration section ** include /usr/local/etc/schema/core.schema ** referral ldap://root.openldap.org ** access to * by * read
Line 1 is a comment. Line 2 includes another config file which contains core schema definitions. The referral directive on line 3 means that queries not local to one of the databases defined below will be referred to the LDAP server running on the standard port (389) at the host root.openldap.org.
第1行是注释行。第2行包含了定义核心模式 (schema) 定义的另一个配置文件。在第3行的 referral 指令意味着如果无法在下面定义的数据库之一中定位的查询将被指向在主机 root.openldap.org 标准端口 (389) 上运行的 LDAP 服务。
Line 4 is a global access control. It applies to all entries (after any applicable database-specific access controls).
第4行是一个全局的访问控制。它应用在所有条目上(其后是应用特定数据库的访问控制)。
The next section of the configuration file defines a BDB backend that will handle queries for things in the "dc=example,dc=com" portion of the tree. The database is to be replicated to two slave slapds, one on truelies, the other on judgmentday. Indices are to be maintained for several attributes, and the userPassword attribute is to be protected from unauthorized access.
配置文件的下一部分定义了一个 BDB 后台,它将在该树的 "dc=example,dc=com" 部分处理查询。数据库将被复制到两个从属 slapd,一个在 truelies,另一个在 judgmentday。将为几个属性维护索引,userPassword 属性将被保护,未经授权的将无法访问它。
** # BDB definition for the example.com ** database bdb ** suffix "dc=example,dc=com" ** directory /usr/local/var/openldap-data ** rootdn "cn=Manager,dc=example,dc=com" * rootpw secret * # replication directives * replogfile /usr/local/var/openldap/slapd.replog * replica uri=ldap://slave1.example.com:389 * binddn="cn=Replicator,dc=example,dc=com" * bindmethod=simple credentials=secret * replica uri=ldaps://slave2.example.com:636 * binddn="cn=Replicator,dc=example,dc=com" * bindmethod=simple credentials=secret * # 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
Line 5 is a comment. The start of the database definition is marked by the database keyword on line 6. Line 7 specifies the DN suffix for queries to pass to this database. Line 8 specifies the directory in which the database files will live.
第5行是个注释行。在第6行数据库定义的开始是通过数据库关键字来标识。第7行为通往该数据库的查询指定 DN 后缀。第8行指定数据库文件所在的目录。
Lines 9 and 10 identify the database super-user entry and associated password. This entry is not subject to access control or size or time limit restrictions.
第9行和第10行标明数据库超级用户条目及其密码。该条目不受访问控制、大小及时间的限制。
Lines 11 through 18 are for replication. Line 12 specifies the replication log file (where changes to the database are logged - this file is written by slapd and read by slurpd). Lines 13 through 15 specify the hostname and port for a replicated host, the DN to bind as when performing updates, the bind method (simple) and the credentials (password) for the binddn. Lines 16 through 18 specify a second replication site. See the Replication with slurpd chapter for more information on these directives.
第11行到18行是关于复制的。第12行指定复制日志文件(在这里任何数据库的改变将被记录-该文件被 slapd 写而被 slurpd 读)。第13行到15行指定了复制主机的主机名和端口,当执行更新时所绑定的 DN,binddn 的绑定方式(simple)以及 credentials(密码)。第16行到18行指定第二个复制站点。关于这些指令的更多信息请参阅使用 SLURPD 进行复制一章。
Lines 20 through 22 indicate the indices to maintain for various attributes.
第20行到22行显示维护不同属性的索引。
Lines 24 through 32 specify access control for entries in this database. As this is the first database, the controls also apply to entries not held in any database (such as the Root DSE). For all applicable entries, the userPassword attribute is writable by the entry itself and by the "admin" entry. It may be used for authentication/authorization purposes, but is otherwise not readable. All other attributes are writable by the entry and the "admin" entry, but may be read by all users (authenticated or not).
第24行到32行为该数据库中的条目指定访问控制。因为这是第一个数据库,因此控制应用的条目也不被约束在任何数据库中(如 Root DSE)。对于那些有着 userPassword 属性的条目而言,该条目本身以及 "admin" 条目有写权限,它可以用于授权认证,否则将不能被读取。所有其它属性可以被该条目及 "admin" 条目写入,也可以被所有用户(包括授权和未授权的)读取。
The next section of the example configuration file defines another BDB database. This one handles queries involving the dc=example,dc=net subtree but is managed by the same entity as the first database. Note that without line 39, the read access would be allowed due to the global access rule at line 4.
配置示例文件的下一部分内容定义另一个 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