保持登录。
单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.
在您首次登录 developerWorks 时，会为您创建一份个人概要。您的个人概要中的信息（您的姓名、国家/地区，以及公司名称）是公开显示的，而且会随着您发布的任何内容一起显示，除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。
所有提交的信息确保安全。
当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。
单击提交则表示您同意developerWorks
的条款和条件。 .
所有提交的信息确保安全。
developerWorks 社区:
我的概要信息
选择语言：
在本教程中，Sean Walberg 帮助您准备 Linux
Professional Institute Senior Level Linux Professional (LPIC-3) 考试。，本教程是第三篇，Sean 介绍如何配置 Lightweight
Directory Access Protocol (LDAP) 服务器，包括访问控制、安全性和性能。学完本教程后，您将掌握 LDAP 服务器配置。
, 高级网络工程师
从 1994 开始，Sean Walberg 就一直在学术、企业和 Internet 服务提供者环境中从事 Linux 和 UNIX 系统的研究。在过去几年里，他撰写了大量有关系统管理的文章。
开始之前了解这些教程所塔伦的内容，并从这些教程中获得最大收益。关于本系列 (LPI) 认证 Linux® 系统管理员分为三级：初级（也称 “认证级别 1”），中级（也称 “认证级别 2”）和高级（也称 “认证级别 3”）。要获得认证级别 1，必须通过 101 和 102 考试。要获得认证级别 2，必须通过 201 和 202 考试。要获得认证级别 3，必须已经获得中级认证并通过 301 考试（“核心”）。高级认证可能还要通过其他专业考试。developerWorks 提供教程帮助您准备初级、中级和高级认证的 5 门考试。每门考试都包含几个主题，且每个主题在 developerWorks 上都有对应的自学教程。表 1 列出 LPI 301 考试的 6 个主题和对应的
developerWorks 教程。表 1. LPI 301 考试：教程和主题LPI 301 考试主题developerWorks 教程教程摘要主题 301学习 LDAP 的概念和体系结构，了解如何设计和实现
LDAP 目录，以及模式。主题 302学习如何安装、配置和使用 OpenLDAP 软件。主题 303 LPI
301 考试准备：配置（本教程）详细学习如何配置 OpenLDAP 软件。请参阅详细的 。主题 304 LPI 301 考试准备：使用即将推出。主题 305 LPI
301 考试准备：集成和迁移即将推出。主题 306 LPI 301 考试准备：容量计划即将推出。要通过 301 考试（并获得认证级别 3），您：应该具有在许多计算机上针对各种用途安装和维护
Linux 的多年经验。应具有不同技术和操作系统的集成经验。具备企业级 Linux 专业人员的经验（或者受过相关培训），包括作为其他角色从事企业级 Linux 管理的经验。应掌握高级和企业级的 Linux 管理，包括安装、管理、安全性、故障诊断和维护。应能够使用开源工具评估容量计划和解决资源问题。应具有使用 LDAP 集成
UNIX® 服务和 Microsoft® Windows® 服务的经验，包括
Samba、Pluggable Authentication Modules (PAM)、电子邮件和 Active
Directory。应能使用 Samba 和 LDAP 计划、架构、设计、构建和实现一个完整的环境，还可以评估服务的容量计划和安全性。应能用 Bash 或 Perl 创建脚本，或至少了解一种系统编程语言（比如 C 语言）。Linux Professional Institute 不为任何第三方考试准备资料或技术做担保。关于本教程欢迎阅读 “配置”，这是针对 LPI 301 考试而设计的 6 篇教程中的第 3 篇。在本教程中，您将学习配置 LDAP 服务器，包括访问控制、安全性、复制和数据库性能。
本教程按照此主题的 LPI 目标进行组织。一般来讲，权值越高的学习目标，考试中涉及到的内容就越多。如表 2 所示。目标表 2 列出了本教程的详细目标。表 2. 配置：本教程涵盖的考试目标LPI 考试目标目标权值目标摘要303.22计划和实现访问控制列表。303.35设置 OpenLDAP 以在多个服务器之间复制数据。303.44配置对 LDAP 服务器的加密访问，并在防火墙级别限制访问。303.52评估 LDAP 服务器的性能，并调优实现最大性能。303.62了解基本的 slapd.conf 配置指令，并熟悉基本的 slapd 命令行选项。先决条件要从本教程获得最大收益，应具有 Linux 的高级知识和一个能正常运行的 Linux 系统，在此系统上练习本文所涉及的命令。如果您对基本 Linux 技能比较生疏，可以先复习
。不同版本的程序可能产生不同格式的输出，因此您的结果可能看起来与本教程中的清单和插图不太一样。系统要求要执行本教程中的示例，您需要一个带有 OpenLDAP 包并支持 PAM 的 Linux 工作站。大多数现代发行版都能满足这些要求。LDAP 中的访问控制列表本节介绍 Senior Level Linux
Professional (LPIC-3) 301 考试的 303.2 主题的内容。此主题的权值是 2。在本节中，学习如何：计划 LDAP 访问控制列表了解访问控制语法授予和撤消 LDAP 访问权限LDAP 树中可以存储各种数据，包括电话号码、出生日期和工资表信息。其中一些数据可能是公开的，一些数据可能只能由由特定的人访问。根据用户的不同，同样的信息可能有不同的限制。例如，也许只有记录的所有者和管理员可以更改电话号码，但是每个人都可以读取这些号码。访问控制列表 (ACL) 处理这些限制的配置。计划 LDAP 访问控制列表在开始编写配置之前，应该确定要实现的目标。树的哪部分包含敏感信息？哪些属性需要保护，保护其不被谁访问？如何使用树？ACL 的组件ACL 条目提供三条信息：
ACL 指定 what 条目和属性
ACL 应用于 who授予的 access 级别指定 “what” 子句时，可以选择根据对象的区分名（distinguished
name，DN）、LDAP 风格的查询筛选器、属性列表或以上三者的组合来进行筛选。最简单的子句允许一切内容，但也可以有很多限制。根据 DN 筛选允许您指定精确匹配，比如
ou=People,dc=ertw,dc=com 或正则表达式
（参阅 “”）。查询筛选器可以匹配特定的
objectClass 或其他属性。属性列表中的属性名称用逗号分隔。更复杂的匹配条件可以是 “身份是管理员的 ou=People,dc=ertw,dc=com 下的所有密码条目”。可以灵活地确定将 ACL 应用于 who。用户一般由绑定到树上的 DN 来识别，这称为 bindDN。每个 LDAP 条目可以具有一个
userPassword 属性，用于对特定的用户进行身份验证。在一些上下文中，您可以将当前登录的用户称为自己， 这有利于允许用户编辑自己的详细信息。如果用户没有绑定，则被视为匿名用户。默认情况下，匿名用户可以读取树，所以您必须决定是否需要更改此行为。可以通过 IP 地址或用于连接的方法（比如明文和加密的方法）来对匿名用户（或任何用户）进行分割。一旦确定了 what 和 who，必须确定访问级别。访问权限可以是无 一直到写 访问。还可以指定用户可以验证条目，但不可以读取；或可以允许用户读取、搜索和比较访问。 无论如何配置您的 ACL，任何已配置的
rootDN 用户可以完全控制其数据库。不可以对此进行更改，除非将 rootDN 配置从 slapd.conf 中移除。了解访问控制语法ACL 的基本格式使用 Backus-Naur Form 表示，也就是：access to &what& [ by &who& [ &access& ] [ &control& ] ]+描述 whatwhat 描述 ACL 强制的属性和条目。实现此目标的 BNF 表示法如清单 1 所示。清单 1. ACL 的 what 部分的 BNF 描述&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&
::= &attrname& | entry | children清单 1 的一些元素在此处没有定义，例如 DN 和 正则表达式。区分名的形式是已知的，正则表达式最好在 BNF 之外研究。清单 1 显示了 ACL 的 what 部分的描述可以是星号字符 (*)（它可以匹配一切内容），或者是 DN、LDAP 筛选器、属性列表的组合。后者可以使用三个组件中的一个或多个，因为它们分别被方括号括起来。清单 2 显示了与 DN 匹配的三个 what 子句清单 2. 三个示例 what 子句dn.exact="ou=people,dc=ertw,dc=com"
dn.regex="ou=people,dc=ertw,dc=com$"
dn.regex="^cn=Sean.*,dc=com$"第一个示例仅与
ou=people,dc=ertw,dc=com 条目匹配。如果使用此 ACL，则它不与任何子条目匹配，例如
cn=Sean Walberg,ou=people,dc=ertw,dc=com，也不与父条目匹配。第二个示例与第一个相似，但是它使用正则表达式，并使用美元符号 ($) 字符锚定（anchor） 搜索字符串。锚与字符串的位置匹配，而不是与字符串的一部分匹配。美元符号与字符串的结尾部分匹配，因此第二个示例与以 ou=people,dc=ertw,dc=com 结尾的任何条目匹配，包括 cn=Sean Walberg,ou=people,dc=ertw,dc=com。注意，如果没有锚，搜索字符串可以位于目标内的任何位置，例如
ou=people,dc=ertw,dc=com,o=MegaCorp。清单 2 中的第三个示例显示另一个锚，^，它与字符串的开始部分匹配。第三个示例也使用另一个正则表达式 .*。句点与任何一个字符匹配，星号与 0 个或多个前导字符匹配。因此
.* 与一个或多个字符的任何字符串匹配。总之，第三个示例与以
cn=Sean 开始、以
dc=com 结尾的任何条目匹配。还可以根据 LDAP 查询进行筛选，这对
objectClass 上的搜索最有帮助。例如，
filter=(objectClass=posixAccount) 的 what 子句仅与具有 posixAccount 的 objectClass 的条目匹配。要复习
objectClass，请查看此系列的第一篇教程，
what 子句的最后一个选项是指定属性。最常见的用法是限制谁可以查看私有属性，尤其是密码。使用
attrs=userPassword 匹配密码属性。一旦确定了要匹配的的条目和属性，就必须描述规则将应用于谁。描述 who访问将根据在客户机绑定到树时提供的 DN 来应用到用户。DN 通常可以在树上找到，但也可能是 slapd.conf 中提供的 rootDN。清单 3 显示 ACL 的 who 部分的 BNF 表示法。清单 3. 匹配 ACL 的 who 部分的 BNF 表示法&who& ::= * | [anonymous | users | self[.&selfstyle&]
| dn[.&basic-style&]=&regex& | dn.&scope-style&=&DN&]
[dnattr=&attrname&]
[group[/&objectclass&[/&attrname&][.&basic-style&]]=&regex&]
[peername[.&peernamestyle&]=&peername&]
[sockname[.&style&]=&sockname&]
[domain[.&domainstyle&[,&modifier&]]=&domain&]
[transport_ssf=&n&]
[tls_ssf=&n&]
[sasl_ssf=&n&]
&style& ::= {exact|regex|expand}
&selfstyle& ::= {level{&n&}}
&dnstyle& ::= {{exact|base(object)}|regex
|one(level)|sub(tree)|children|level{&n&}}
&groupstyle& ::= {exact|expand}
&peernamestyle& ::= {&style&|ip|path}
&domainstyle& ::= {exact|regex|sub(tree)}
&modifier& ::= ={expand}与 ACL 的 what 部分中一样，星号匹配一切内容。要想获得更特定的功能，还有许多选项。OpenLDAP 定义
anonymous、users 和
self 三种快捷方式。这些快捷方法分别与未注册用户、已验证用户和当前登录用户匹配。后面的
self 通常用于允许登录用户编辑自己的配置文件的组件。这基于 DN 的精确匹配；如果将用户的信息分割在不同的条目中，则
self 关键字仅适用于与用户绑定的条目。有关 self 关键字的一个有趣的特性是：还可以使用 level
关键字将 ACL 应用于用户条目的父条目或子条目。使用
self.level{1} 匹配用户的条目和父条目，而 self.level{-1} 匹配用户的条目和任何直接附加的子条目。继续讨论 DN，可以分别使用 dn.exact="DN" 和
dn.regex="regex"
执行正则表达式或精确匹配。稍后一个示例将显示如何使用正则表达式动态地将 what 和 who 捆绑到一起。可以使用 dnattr
关键字保护任意条目，此关键字还需要属性名称。如果请求者的 DN 出现在目标的特定属性中，则与 ACL 匹配。例如，如果将 dnattr=manager 添加到您的 ACL
中，然后将
manager: cn=Joe Blow,ou=people,dc=ertw,dc=com 添加到
Smith 的条目中，ACL 将在 Joe Blow 访问 Fred Smith 的条目时进行匹配。group 关键字与
dnattr 类似，除了参数表示在树中其他地方定义的组，而非条目中的属性。默认情况下，此组具有 groupOfNames 的
objectClass，其成员在
member 属性中引用。使用 peername、
sockname 和 domain
关键字匹配客户机连接的属性。
peername 表示客户机的 IP 地址，例如 peernameip=127.0.0.1。
sockname 用于命名管道上的连接，并不常用。domain 匹配与 IP 地址相关的主机名，它容易被假冒。最后一组选项表示连接的 Security Strength Factor (SSF)，它是连接安全级别的 OpenLDAP 术语。当涉及到用于连接 OpenLDAP 的安全机制时，比如 Transport Layer Security (TLS)
和 Simple Authentication and Security Layer (SASL)，这些选项将变得更加清楚。前面所有的项可以一起使用。例如，可以仅允许来自特定 IP 地址范围的特定管理员对具有特定加密级别的密码字段进行写访问。也可以不这么严格，例如仅要求有效登录，或甚至接受每个人，而不考虑身份验证。描述 access一旦已经确定谁在访问树，以及他们准备访问什么内容，就必须指定访问的级别。清单 4 显示 ACL 的 access 部分的 BNF 表示法。清单 4. 描述 access 子句格式的 BNF 表示法&access&
[[real]self]{&level&|&priv&}
&level& ::= none|disclose|auth|compare|search|read|write
&priv& ::= {=|+|-}{w|r|s|c|x|d|0}+使用 level 格式指定访问时，每个后续的级别都包括其前面的级别。也就是说，
read 访问级别包括 search、
compare、auth 和
disclose 访问级别。none 和
disclose 两者都拒绝任何访问，但一些可能泄漏有关树内容的信息的错误消息会在
none 下移除，在
disclose 下允许。还可以使用 priv 格式按照允许的 LDAP
操作指定访问级别。这些选项与 level 格式的运行机制相反，这里的
w 代表 write，0 代表 none。当使用 priv 格式指定 access 时，与使用
level 时的情况一样没有隐含的进展。如果想提供完全访问，则必须使用
wrscx。在字母前的 =/+/- 符号表示如果应用多个规则，那么指定的访问如何与当前的访问级别合并。使用 =，则忽略所有先前定义的访问，要使用的值跟在等号后面。使用
+ 和 - 分别在当前级别中添加或减少访问。 了解控制默认情况下，OpenLDAP 采用首次匹配法来应用访问列表。OpenLDAP 查找与 what 子句匹配的第一个 ACL 条目，并在此条目中查找与 who 部分匹配的第一个条目。这与在描述访问级别之后放置关键字 stop 一样。其他两个选项是 continue 和
break。如果使用
continue，则在与 who 部分匹配的下一行中搜索当前 ACL 条目。如果使用 break，则当前 ACL 条目的处理停止，但是 OpenLDAP 查找下一个与 who 子句匹配的 ACL
条目。组合
what、who 和 access现在已经看到 ACL 的三个（四个，如果将 control 算上的话）部分，可以将其放到一个策略中。清单 5 显示了典型的
ACL 列表，允许已注册的用户读取树并允许用户更新自己的密码（但不能读取）。清单 5. 简单的 ACL 设置access to attrs=userPassword
by self =xw
by anonymous auth
access to *
by self write
by users read第一个子句匹配尝试访问
userPassword 字段的任何用户。授予用户对自己的条目的写权限和身份验证权限，这是通过等号强制执行的。授予匿名用户身份验证权限。当用户绑定到树上时，它就是匿名用户；因此，匿名用户需要
auth 权限，这样他们才能登录成为正常的有权限的用户。如果要请求的信息不是密码，则考虑第二个 ACL 条目。另外，用户对自己的条目（由于第一个 ACL 条目，userPassword 字段除外）具有完全的控制，而所有经过验证的用户对树的其余部分具有读访问。清单 6 显示了使用正则表达式将 what 和 who 子句捆绑到一起的 ACL 条目。清单 6. 应用正则表达式access to dn.regex="cn=([^,]+),ou=addressbook,dc=ertw,dc=com"
by dn.regex="cn=$1,ou=People,dc=ertw,dc=com" write
by users read清单 6 允许用户编辑树的
ou=addressbook,dc=ertw,dc=com 部分下的相应记录。[^,]+ 匹配逗号之前的一切内容，但不包括逗号，对于第一个圆括号集合，圆括号将匹配的文本保存到
$1 中，对于下一个，保存到
$2 中，依此类推直到包括
$9。who 子句重新使用用户的名称来确定谁可以访问条目。如果用户的名称与要访问的条目名称相同，则授予用户写访问。否则，就授予验证的用户读访问。实际问题由于首次匹配行为，应该将比较具体的 ACL 条目置于列表的顶部；否则，先前的 ACL 很有可能导致列表中较低的 ACL 被忽略。这种技术还可以用于授予和撤销特定用户的访问。仅将您特定的 ACL 子句放在列表顶部。保持您的 ACL 尽量简单。这样做可以减少错误的可能性，还可以改善性能。每次对树执行操作时必须解析 ACL。 LDAP 复制本节介绍 Senior Level Linux
Professional (LPIC-3) 301 考试的 303.3 主题的内容。本主题的权值是 5。 在本节中，将完成以下任务： 了解复制概念配置 OpenLDAP 复制执行和管理 slurpd分析复制日志文件了解副本中心（replica hub）配置 LDAP 参考配置 LDAP 同步复制有时候，您的需求可能不仅是一个服务器。您的组织可能依赖 LDAP，以至于您的 LDAP 服务器损失是不可接受的，或者您的查询量太高了，以至于必须将您的查询分割到多个服务器上。甚至可能是二者的组合；但是在任何情况下，您都需要使用多个服务器。 使用多个服务器，可以将您的树分隔到不同的服务器上，但是这将导致可靠性下降 —— 更不要说难以平衡您的查询了。理想情况是，每个服务器都有树的相同副本。任何写操作都将以实时方式传播到其他服务器，从而其他所有服务器都保持更新。此操作称为复制。这种称为多主体（multi-master） 的场景十分复杂，因为数据没有一个清晰的所有者。还常常会形成主从关系。LDAP 查询可以针对所有服务器进行。这可以扩展为副本中心 场景，其中一个从服务器从主服务器复制数据，然后再依次复制到其他一些从服务器上。OpenLDAP 提供两种方法来完成复制。第一种方法是通过
slurpd，这个单独的后台程序监视主服务器上的更改并将更改应用到从服务器。第二种方法是使用 slapd 的 LDAP 同步复制引擎，称为 syncrepl。slurpd 方法现在已经过时了；人们都使用 syncrepl。这两种方法都将在本节中介绍。基于 slurpd 的复制基于 slurpd 的复制是推式复制，原因在于主服务器将任何更改都推给从服务器。如果客户机试图更新从服务器，则从服务器配置并发送一个转介（referral） 到客户机，而将客户机指向主服务器。客户机重新向主服务器发送请。Slurpd 是从 slapd.conf 中配置的独立后台程序。slurpd 复制模型内的数据流主服务器处理来自客户机的所有写操作，并拥有权威的数据源。对主服务器树的任何更改都将写入复制日志 中，它由 slurpd 监视。slurpd 注意到复制日志中的更改时，就会将更改推至所有从服务器。图 1 显示了典型的 slurpd 行为。图 1. slurpd 复制模型中的数据流过程如下：客户机发送更新请求，此请求正好被从服务器接收。从服务器知道写操作只能来自其复制伙伴，因此将转介发送回客户机，将其指向主服务器。客户机将更新请求重新发送给主服务器。主服务器执行更新并将更改写入复制日志中。slurpd，也在主服务器上运行，注意到复制日志中的更改。slurpd 将更改发送给从服务器。这样，从服务器可以在几乎没有延迟的情况下与主服务器保持更新。如果发生任何中断，或者从服务器上发生错误，slurpd 始终知道哪个从服务器需要哪些更新。配置 slurpd配置基于 slurpd 的复制需要下列步骤：创建副本帐户，slurpd 用其对从服务器副本进行验证。使用从服务器的名称配置主服务器。将从服务器配置为副本，包括任何需要的 ACL。将数据库从主服务器复制到从服务器。创建副本很简单；惟一的要求是帐户必须拥有 userPassword
属性中的密码。可以使用 inetOrgPersonobjectClass，就像属于人们的大多数帐户一样，
或者可以使用更一般的 objectClass，比如添加了
simpleSecurityObject 辅助
objectClass 的
account。回忆第一篇教程，结构化的 objectClasses 定义条目（因此每个条目仅可以使用一个），然而辅助
objectClasses 将属性添加到任何条目，而不考虑结构化的 objectClass。清单 7 显示要添加
副本帐户的 LDIF 代码。清单 7. 副本帐户的 LDIF 代码dn: uid=replica1,dc=ertw,dc=com
uid: replica1
userPassword: replica1
description: Account for replication to slave1
objectClass: simpleSecurityObject
objectClass: account清单 7 显示了一个稀疏条目 —— 只有用户名、密码和描述，这对于复制已经足够了。描述是可选项，但建议在文档中使用。记住密码；下一步将需要它！主服务器现在必须配置来将所有更改存储在复制日志中，而且副本必须配置，以便 slurpd 可以工作。必须记住，slurpd 从 slapd.conf 读取其配置，且 slurpd 将更新推至从服务器。这将帮助您记住在何处配置复制以及验证凭证属于主服务器。从服务器可以验证凭证，因为帐户是树的一部分。清单 8 显示了在主服务器上启用复制的配置。清单 8. slurpd 复制的主服务器配置replica
uri=ldap://
suffix="dc=ertw,dc=com"
binddn="uid=replica1,dc=ertw,dc=com"
credentials="replica1"
bindmethod=simple
replogfile /var/tmp/replicationlog复制配置在数据库模式中执行，所以一定要确保 replica 命令位于第一个 database 配置之后的某个位置。
replica 接受
key=value 形式的几个参数。uri 键使用统一资源标识符 (URI) 格式指定从服务器的名称或 IP 地址，在从服务器的名称前面加上前缀
ldap://。指定从服务器的名称之后，可以通过 suffix 选项有选择地配置要复制的数据库名称。默认情况下，复制所有的数据库。最后一个要求是提供验证信息，以便 slurpd 可以连接到指定的
uri。对于简单验证，只需要
binddn、bindmethod 和
credentials（以前分配的
userPassword）。最后一个难题是告诉 slapd 在何处存储其复制日志。您需要提供完整路径，因为相对文件名不起作用。不要担心创建文件，因为 slapd 将为您创建；但是指定的路径必须可由运行 slapd 和 slurpd 的用户进行写操作。在从服务器上，必须配置复制帐户，还要告诉从服务器对于任何写操作都应该将转介返回给主服务器。清单 9 显示了此配置。清单 9. 从服务器的配置updatedn uid=replica1,dc=ertw,dc=com
updateref ldap://updatedn 引用以前在主服务器上创建的帐户，slurpd 将使用此帐户将更新推至从服务器。updateref 是另一个 LDAP URI，它指向主机。清单 10 显示了在加载前面的配置之后，客户机尝试更新从服务器并接收转介。清单 10. 客户机在尝试更新从服务器之后接收转介[root@slave openldap]# ldapadd -x -D cn=root,dc=ertw,dc=com -w mypass -f newaccount.ldif
adding new entry "cn=David Walberg,ou=people,dc=ertw,dc=com"
ldap_add: Referral (10)
referrals:
ldap:///cn=David%20Walberg,ou=People,dc=ertw,dc=comOpenLDAP 命令行客户机不遵循转介，但其他 LDAP
库遵循。如果您正在复制的环境中使用 LDAP，应该验证您的应用程序是否正确遵循转介。最后一个难题是确保主服务器和从服务器都以相同的数据库开始。为此，请执行下列步骤：关闭主服务器。关闭从服务器。将所有数据库从主服务器复制到从服务器。启动主服务器和从服务器。启动 slurpd。两个服务器都必须关闭才能复制数据库，以确保没有任何更改并且所有数据都已写入磁盘。至关重要的一点是两个服务器具有相同的数据集；否则它们以后可能不同步。基于 slurpd 的复制本质上是在从服务器上再现发生在主服务器上的所有事务，因此任何差别都可能导致问题。根据您的发行版和启动脚本，slurpd 可以使用 slapd 自动启动。如果没有自动启动，通过在命令行运行
slurpd 来启动。现在，应该可以进行复制了。在主服务器上创建帐户并测试。如果尝试更新从服务器，还可以测试从服务器是否传回转介。监视复制了解如何监视复制非常重要，因为可能发生错误，从而导致数据不同步。监视中的一些技能还有助于调试。slurpd 将自己的文件存储在 /var/lib/ldap/replica（这与由 slapd 生成的复制日志是分开的）中。此目录中包含 slurpd 自己的复制日志和任何拒绝文件。如果 slurpd 尝试将更新发送到失败的从服务器上，数据将存储在以从服务器名称命名的文件中，其扩展名为 .rej。在文件内部是组成条目的 LDIF 代码，以及从服务器返回的错误，比如
ERROR: Already exists。清单 11 显示了具有不同错误的 .rej 文件的内容。清单 11. 复制拒绝文件ERROR: Invalid DN syntax: invalid DN
replica: :389
dn: sendmailMTAKey=testing,ou=aliases,dc=ertw,dc=com
changetype: add
objectClass: sendmailMTAAliasObject
sendmailMTAAliasGrouping: aliases
sendmailMTACluster: external
sendmailMTAKey: testing
sendmailMTAAliasValue:
structuralObjectClass: sendmailMTAAliasObject
entryUUID: 99-102c-822b-fbf5b7bc4860
creatorsName: cn=root,dc=ertw,dc=com
createTimestamp: 15Z
entryCSN: 15Z##000000
modifiersName: cn=root,dc=ertw,dc=com
modifyTimestamp: 15Z清单 11 的拒绝文件以文本错误 ("ERROR: Invalid DN
syntax: invalid DN") 开始，其余部分类似于 LDIF。注意，第一个属性是
replica，这是不能处理更新的副本名称，第二个属性是 time，它是错误发生的时间（使用的是 UNIX 时间戳格式）。接下来的几个属性来自被拒绝的条目。最后 7 个属性称为操作属性，它们不属于最初的更改，LDAP 服务器添加这些属性，以进行内部跟踪。条目还具有一个通用惟一标识符（universally unique identifier，UUID）以及有关何时、谁更改记录的一些信息。在清单 11 中，错误很可能来自从服务器上缺少的模式。从服务器不理解 sendmailMTAKey 属性是什么，因此条目的 DN 是无效的。从服务器必须更新其模式，然后复制才能继续。要修复被拒绝的条目，必须使用树评估错误并修复底层的问题。一旦知道被拒绝的条目将能够正常应用，则使用 slurpd 的单触发模式（one-shot mode），并使用命令
slurpd -r /path/to/rejection.rej -o 来应用更新。
-r 参数告诉 slurpd 从给定的复制日志中读取，-o 导致 slurpd 使用单触发模式，这意味着它在处理日志后退出，而不是执行默认行为 —— 等待将更多的条目添加到日志中。如果复制根本没有进行，最好的方法是从主服务器开始，然后处理从服务器。首先，关闭 slurpd 并且对树进行更改。然后，检查复制日志是否在增长；如果没有增长，则主服务器设置不正确。接下来，启动 slurpd，并在命令行上传递
-d 255。这将在 slurpd 处理日志时跟踪其行为。查找错误，尤其是与打开文件和访问控制有关的错误。最后，在从服务器上，使用 loglevel auth sync 检查复制发生时的任何错误（slapd 使用
local4 工具记录到 syslog 中，所以您可能需要将
/var/log/slapd.log 添加到 /etc/syslog.conf 中）。LDAP Sync 复制slurpd 对于复制问题是最直接的解决方案，但是它有一些缺点。关闭主服务器以同步从服务器通常会不方便，在最坏的情况下还可能影响服务。slurpd 的推式体系结构也存在不足。slurpd 基本上运行良好，但是必须创建一些更好的东西。RFC 4533 概述了 LDAP Content Synchronization Operation，它是由 LDAP Sync
复制引擎在 OpenLDAP 中实现的，称为 syncrepl。syncrepl 构建为一个覆盖，插入在 slapd 核心和后端数据库之间。对树的所有写入由 syncrepl 引擎跟踪，而不需要单独的服务器实例。除了复制机制和角色（下文将介绍）之外，其概念与 slurpd 相似。对副本的写操作被拒绝，并将转介传回给主服务器。syncrepl 从服务器启动，现在将其命名为消费者。主服务器角色称为提供者。在 syncrepl 中，消费者连接到提供者以更新树。在最基本的 refreshOnly 模式中，消费者接收自上一次刷新以来的所有更改条目，请求 cookie 跟踪上一次同步的更改，然后断开连接。在下一次连接时，将 cookie 呈现给提供者，它仅发送自上一次同步之后更改的条目。另一个 syncrepl 模式称为 refreshAndPersist，像
refreshOnly 操作一样启动；但是不会断开连接，消费者保持连接以接收任何更新。在最初刷新后发生的任何更改都会立即通过连接由提供者发送到消费者。配置 syncrepl清单 12 显示了两个 syncrepl 模式
（refreshOnly 和 refreshAndPersist）的提供者的配置。清单 12. syncrepl 的提供者配置overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100清单 12 的第一行启用 syncprov 覆盖。必须针对数据库配置覆盖；因此，此配置必须位于
database 配置行之后。下面两行是可选项，但是它们可以改进可靠性。
syncprov-checkpoint 100 10 告诉服务器每 100 次写操作或每隔 10 分钟将
contextCSN 的值存储到磁盘中。contextCSN 是以前提到的 cookie 的一部分，它可以帮助消费者找到自上一个复制周期之后的某个位置。
syncprov-sessionlog 100 将写操作记录到磁盘，这还有助于刷新周期。有关配置提供者的详细信息，请参见
slapo-syncprov(5) 手册页。清单 13 显示了复制对的消费者一方清单 13. refreshOnly 模式中的 syncrepl 的消费者配置updateref ldap://
syncrepl rid=1
provider=ldap://
type=refreshOnly
interval=00:01:00:00
searchbase="dc=ertw,dc=com"
bindmethod=simple
binddn="uid=replica1,dc=ertw,dc=com"
credentials=replica1像 slurpd 中的 replica 命令一样，syncrepl 命令需要
updateref、尝试复制的树的信息，以及将要使用的验证凭证。这时，凭证在消费者一方执行，并需要提供者上的足够权限来读取正被复制的树部分。在消费者上对数据库的更新以 rootdn 身份运行。清单 13 中特定于 syncrepl 的项目是
rid、provider、
type 和 interval。
rid 将此消费者标识给主服务器。消费者必须是具有介于 1 到 999 之间的惟一 ID。
provider 是指向提供者的 LDAP URI。type 指定只想通过
refreshOnly 进行定期同步，且
interval 是每小时。
interval 以
DD:hh:mm:ss 格式指定。使用空数据库启动消费者，它将从提供者那里复制数据并每小时更新一次。转换到 refreshAndPersist 模式十分简单。在清单 13 中，移除
interval，并将
type 更改为 refreshAndPersistsyncrepl 筛选值得注意的是，您不必复制整个 LDAP 树。您可以使用下列命令来筛选复制的数据。表 3. 筛选复制流量的命令命令描述searchbase指向复制将开始的树节点的 DN，OpenLDAP 将填充任何必需的父节点以保证树的完整。scopesub、one 或
base 之一。它确定从 searchbase 开始，到树下多深的数据将被复制。默认值为 sub，它涵盖
searchbase 和所有子 searchbase。filterLDAP 搜索筛选器，例如
(objectClass=inetOrgPerson)，用于控制复制哪些记录。 attrs将从所选条目中复制的属性列表。与 syncrepl 的其他选项一样，这些选项以 key=value 的形式输入
本节介绍 Senior Level Linux
Professional (LPIC-3) 301 考试的 303.4 主题的内容。本主题的权值是 4。 在本节中，学习如何执行下列操作： 使用 SSL 和 TLS 保护目录配置和生成客户机/服务器证书了解防火墙注意事项配置未验证的访问方法配置用户/密码验证方法到目前为止，对 slapd 的所有访问都是使用明文密码通过未加密通道进行的。这称为简单 验证。本节探讨如何对客户机-服务器连接进行加密。使用 SSL 和 TLS 保护通信作为保护 Web 交易的协议，您可能对 Secure Sockets Layer (SSL) 和 Transport Layer Security (TLS) 很熟悉。无论何时浏览 https 类型 URI，都要使用 SSL 或 TLS。TLS 是 SSLv3 的改进，在一些情况下它还向后兼容 SSL。由于它们共同的传统和兼容性，通常将其统称为 SSL。SSL 使用 X.509 证书，它是由可信任第三方（称为 Certificate Authority (CA)）进行了数字签名的一块标准格式的数据。有效的数字签名意味着已签名的数据没有被篡改。如果要签名的数据发生了更改，即使是一位，那么签名将不会通过验证。独立的参与方，例如客户机和服务器，可以验证签名，因为它们都基于对 CA 的信任。在服务器的证书内具有有关服务器所有权的信息，包括它在 Internet 上的名称。因此可以确信您正连接到正确的服务器，因为您连接到的服务器名称与证书中的名称完全匹配，而且在签名前您已经信任 CA 来对其进行验证。证书还包括服务器的公钥，公钥可以用来加密数据，从而只有密钥的所有者可以将其解密。公钥和私钥形成公钥 或非对称
密码学的基础。非对称是因为由公钥加密的数据只能由私钥解密，使用私钥加密的数据只能由公钥解密。对于通常认为是加密的行为，例如保密信息，使用第一种情况。公钥是公开的，但私钥是保密的。由于秘钥的非对称行为，私钥可以加密消息，具有公钥的任何人可以将其解密。这就是数字签名的工作机制。在客户机连接到服务器并接收到服务器的证书之后，客户机可以验证服务器名称是否正确，这可以预防中间人攻击。公钥可用于运行一个协议，在此协议中，客户机和服务器协商一个共同的密钥，观察此对话的任何人无法确定这个密钥。然后，此密钥用于加密客户机和服务器之间的会话的其余部分，因为加密和解密数据使用的是相同的密钥，所以称为对称 密码学。非对称和对称密码学的用途不同，因为后者比前者快几个数量级。公钥加密算法用于验证并提供共享密钥，然后将这个密钥用于对称密钥密码学。要将这些都应用于 OpenLDAP，必须为服务器创建证书，然后配置服务器来使用它。本例使用自己签名的证书而没有创建 Certificate Authority，这意味着最终的证书已由自己签名。它没有提供 CA 提供的信任级别，但是这对于测试已经足够了。清单 14 显示了密钥的生成。清单 14. TLS 密钥对的生成[root@bob ssl]# openssl genrsa -out ldap.key 1024
Generating RSA private key, 1024 bit long modulus
.................................++++++
.........................++++++
e is 601)清单 14 显示了使用
openssl genrsa 命令生成密钥。密钥长度是 1024 位，目前对于公钥已经足够了（注意，使用更大的值会使加密操作慢很多，并且可能影响到一些客户机）。下一步，openssl req 接受最新生成的密钥对的公共部分，添加一些位置信息，并将结果打包 —— Certificate Signing Request (CSR) —— 由 CA 签署（参见清单 15）清单 15. 生成 Certificate Signing Request[root@bob ssl]# openssl req -new -key ldap.key -out ldap.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [GB]:CA
State or Province Name (full name) [Berkshire]:Manitoba
Locality Name (eg, city) [Newbury]:Winnipeg
Organization Name (eg, company) [My Company Ltd]:ERTW
Organizational Unit Name (eg, section) []:Directory Services
Common Name (eg, your name or your server's hostname) []:
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:生成的 ldap.csr 文件可以发送到 CA（健壮的支付）以进行签名。此步骤也适用于为 Web 服务器生成证书。如果发送此文件以进行签名，则需要确保提供的所有信息拼写正确，缩写仅用于 Country Name，Common Name 与人们用于连接服务器的 DNS 名称完全 匹配。不使用 CA 签名 CSR，在本示例中，您将自己签名，如清单 16 所示。清单 16. 签名 CSR[root@bob ssl]# openssl x509 -req -days 1095 -in ldap.csr -signkey ldap.key -out ldap.cert
Signature ok
subject=/C=CA/ST=Manitoba/L=Winnipeg/O=ERTW/OU=Directory Services/
CN=/emailAddress=
Getting Private key清单 16 使用 openssl x509
命令签名密钥。使用 -req 告诉 openssl 输入是
CSR。此证书的有效期是 1095 天或 3 年。现在您拥有 ldap.key（私钥）和 ldap.cert（证书和公钥）。在继续之前，将包含 TLS_REQCERT allow 的行添加到 /etc/openldap/ldap.conf 中。这告诉 OpenLDAP 客户机实用工具忽略它们看到的自签名证书的事实。否则，默认设置将证书视为无效而拒绝。
要让 OpenLDAP 使用新密钥和证书很容易。假定在 /etc/openldap/ssl/ 中存储生成的密钥，清单 17 中的行在您重启 slapd 后将服务器设置为 TLS 连接。清单 17. 配置 slapd 的 SSLTLSCertificateFile /etc/openldap/ssl/ldap.cert
TLSCertificateKeyFile /etc/openldap/ssl/ldap.key清单 17 中的命令将 slapd 指向您的证书和私钥。要测试新服务器，请执行 ldapwhoami -v -x -Z
命令，它将匿名地绑定到安全端口。如果接收到 “success” 消息，那么一切正确工作。否则，由 -v 生成的调试信息将指示原因或任何错误。可以生成客户机证书，这是可选项，其方式与服务器证书相同。与清单 17 不同，在 ldap.conf 中使用
TLS_KEY 和 TLS_CERT
命令，分别设置客户机密钥和证书。仅当需要证书本身来标识客户机时才使用客户机证书。防火墙注意事项LDAP 使用 TCP 端口 389，LDAPS (LDAP over SSL) 使用 TCP 端口 636。如果在服务器和客户机之间具有防火墙，则必须让防火墙允许这些端口，连接才能成功。客户机始终连接到服务器，而且根据复制策略的不同，服务器连接到其他服务器。Linux iptables如果在 LDAP 服务器上有基于 iptables 的防火墙，则需要修改规则集合以允许入站连接。通常，清单 18 中的命令足够了。清单 18. 添加 iptables 规则以允许 LDAP 连接iptables -A INPUT -p tcp --dport 389 -j ACCEPT
iptables -A INPUT -p tcp --dport 636 -j ACCEPT如果策略比较简单，则清单 18 就可以了。-A INPUT 将规则附加到 INPUT 表，此表检查所有入站的数据包。您可能必须将这些规则插入到顶部（使用 -I INPUT），或者使用您的发行版的防火墙工具，以允许 TCP 端口 389，如果需要 LDAPS 连接，还可以允许 636。如果要使用 Linux 防火墙作为路由器，以便客户机附加到其他接口，LDAP 服务器附加到其他接口，则必须使用 FORWARD 链而非
INPUT 链。您可能还想使用 -i 指定入站接口，比如
-i eth0 用于表明仅接受在 eth0 入站的数据包。接受数据包之后，还要接受返回数据包。使用 TCP
Wrappers 进行保护编译 OpenLDAP 时可用的配置选项之一是 --enable-wrappers，它根据 TCP Wrappers 库链接结果二进制文件。包装器使用两个文件，/etc/hosts.allow
和 /etc/hosts.deny，来允许或拒绝对入站客户机的访问。首先检查 slapd 是否通过
ldd /usr/sbin/slapd | grep libwrap 命令使用 TCP Wrappers。如果返回任何内容，则表明二进制文件在使用 TCP Wrappers。如果未返回，则需要使用 --enable-wrappers 重新编译或使用前面介绍的 iptables 方法。借助包装器支持，可以通过在 /etc/hosts.deny 中添加
slapd: ALL 来拒绝每个人的访问。然后可以使用 slapd: 192.168.1.,127.0.0.1（允许来自 192.168.1.0/24 网络或本地主机连接的人）允许人们访问。注意，被 TCP Wrappers 拒绝的连接一开始处于连接状态，然后自动断开。这与防火墙相反，防火墙是在数据包到达 slapd 之前将其丢弃。hosts.allow 和 hosts.deny 的格式允许使用许多不同方法来允许和拒绝连接；有关详细信息，请查阅 hosts_access(5) 手册页。身份验证的更多信息到目前为止，身份验证的讨论仅限于 slapd.conf 中定义的明文密码，以及客户机和服务器之间的简单验证。明文密码可以使用
slappasswd 解决。在 shell 中输入
slappasswd，系统提示您输入密码，然后验证此密码。此输出是密码的安全散列值，比如
{SSHA}oxmMsm9Ff/xVQ6zv+bgmMQjCUFL5x22+。此散列值在数据上并不保证可逆，但给定了散列值，一些人可以通过尝试不同的密码并查看散列值是否相同来反复猜测。您已经实践了匿名绑定（不提供任何用户名或密码）和验证绑定（提供用户名和密码且有效）。OpenLDAP 还支持未验证的绑定（提供用户名但没有密码）。未验证的绑定通常被禁用，除非在您的配置中包含 allow bind_anon_cred。如果允许，未验证的绑定被视为匿名绑定。简单验证的备选方案是 Simple Authentication and Security
Layer (SASL)，这是一个用于为验证和加密方法提供插件体系结构的框架。有关 SASL 的详细信息将在即将推出的教程中介绍；同时，SASL 允许从明文到 Kerberos 的不同验证方法。先前在研究 ACL 时，本教程提到访问可以由连接方法影响。这称为 Security Strength
Factor (SSF)。未加密会话的 SSF 是 0，加密会话的 SSF 通常与密钥长度相对应。因此，可以通过将
ssf=1 添加到 ACL 的 who 子句中，来要求特定 ACL 的加密会话。LDAP 服务器性能调优本节介绍 Senior Level Linux
Professional (LPIC-3) 301 考试的 303.5 主题的内容。本主题的权值是 2。在本节中，学习如何执行下列操作： 测量 LDAP 性能调优软件配置来提高性能了解索引OpenLDAP 是一个数据库，可以为其提供查询或任务来运行，它找到数据并将其返回。为了尽可能快地执行此操作，必须将资源分配到最能发挥其效用的地方，比如频繁访问数据的缓存和索引数据库。评估性能在尝试使 slapd 运行得更快之前，必须能够评估当前状态。这可能意味着对应用程序中的特定操作进行定时，并期待有所改进。还可能意味着您自己执行几个查询并计算平均值。度量标准甚至可以不基于时间；它可能会减少 LDAP 服务器上的磁盘负载，因为当前配置将导致大量读写。总之，在进行任何更改之前和之后对不同度量标准进行测量是有用的。有用的命令如下： vmstat 显示输入/输出 (IO) 统计和
CPU 使用，特别是用户时间和等待时间iostat 显示有关磁盘读写的详细信息以及磁盘控制器的使用ps 显示 slapd 进程的内存使用（并不是说使用多的内存是一件坏事，但是必须确保不能将 RAM 耗尽）time 定时不同的命令行操作调优后台程序调优总要涉及权衡。通常，您增加进程的资源量（一般是内存或磁盘）以便进程响应得更快。这样做会减少其他进程可以使用的资源。同样地，如果要使进程运行得更快，通常会消耗更多资源，比如 CPU 周期或磁盘 IO，这对其他进程是不可用的。权衡也可以发生在应用程序层。通过牺牲一些写性能，可以大幅度地提高读性能。还可以通过关闭不同安全功能（比如交易日志），使应用程序运行得更快。如果发生崩溃，最后可能需要从备份中恢复数据库，但您必须知道这是否是可接受的权衡。大多数人使用 Berkeley Database (BDB) 后端。此后端基于 Sleepycat Berkeley Database（现在属于 Oracle），这是一个快速的嵌入式数据库。它不支持查询语言；相反，它基于散列表查找。可以在两个地方调优此后端：一个是在 slapd.conf 中，另一个是在由 BDB 运行时使用的特殊文件中。slapd.conf
配置指令BDB 数据库与使用它的二进制文件链接，而不是像大多数 SQL 服务器一样是独立的服务器。同样地，使用 BDB
数据库的应用程序负责数据库的一些行为。slapd-bdb(5) 手册页描述可由 slapd 通过 slapd.conf 控制的所有指令；本教程只介绍最重要的指令。与许多 SQL 后端一样，BDB 数据库将其更改写入事务日志中，以确保发生失败时的可靠性；它们还让内存中的数据在磁盘写时保存。将所有内存数据转储到磁盘上并写出事务日志的操作称为检查点。
checkpoint 命令告诉 slapd 写出数据的频率，这根据自上一检查点以来存储的更改字节数和分钟数来计量。将 checkpoint 128 15 添加到 slapd.conf
中意味着每更改 128KB 或至少每 15 分钟，数据将转储一次。默认情况下，同
checkpoint 0 0 一样，不执行任何检查点操作。为了获得快速访问，最近访问的条目可以在 RAM 中进行缓存。默认情况下，缓存 1000 个条目。要更改此数目，请使用
cachesize 和条目数。cachesize 越高，条目越有可能缓存在 RAM 中，而 slapd 进程消耗的 RAM 就越多。此处选择的值取决于树中有多少不同的条目和访问模式。确保高速缓存中具有足够的空间，以存放通常访问的项，比如用户列表。与 cachesize 类似的是
idlcachesize，它必须处理索引使用多大的内存缓存。您的设置取决于已配置的索引数（稍后讨论），但是建议在开始时将
idlcachesize 和
cachesize 设置为一样。调优 BDB 数据库正如前文所述，BDB 数据库的一些调优参数在单独的文件中处理，此文件由 BDB 运行时读取，并被 slapd 忽略。此文件称为 B_CONFIG，它与您的数据库位于相同的目录中。此文件中最重要的参数是
set_cachesize，它设置内部 BDB 缓存大小，而非 slapd 条目缓存大小。其格式是
set_cachesize &GigaBytes& &Bytes& &S&，其中 GigaBytes 和 Bytes 表示缓存的大小（这两个加在一起），Segments 允许将缓存分割为单独的内存块，以绕过 32 位地址的限制（0 和 1 具有相同的作用，仅允许单个内存区段）。对于 1GB 的缓存，使用
set_cachesize 1 0 0。要确定最佳的 BDB 缓存大小，通常最容易的做法是查看工作系统的缓存统计信息并根据需要增加。查看 BDB 数据库内存使用统计信息的命令是
db_stat -h /path/to/database -m。前 20 行显示相关详细信息。如果有大量页面被迫移出缓存，或者缓存中的页面数太低 (& 95%)，则应该考虑增加 BDB 缓存大小。在一些发行版上，db_stat 可能称作
slapd_db_stat，以将其与系统 BDB 库和工具分开。
除缓存之外，还需要确保监视事务日志。使用
set_lg_dir 设置事务日志的路径。如果可以将事务日志置于不同的磁盘轴（disk spindle）集上而不是数据库中，则会获得更好的性能。即使 BDB 是简单的数据库，仍需要能够锁定文件进行写操作。锁定数目的默认设置通常足够大，但如果突破最大锁定数，就应该监视
db_stat -h /path/to/database -c 的输出。在 BDB 中，锁分成三个类型（并单独报告）：锁定者、锁定和锁定对象。这三者的差异不太重要，但每个的最大数目分别由 set_lk_max_lockers、
set_lk_max_locks 和
set_lk_max_objects 控制。无论何时对 DB_CONFIG 进行更改，必须重启 slapd。清单 19
显示了基于前面提到的指令的示例 DB_CONFIG 文件。清单 19. 示例 DB_CONFIG 文件# 256K cache
set_cachesize 0
set_lg_dir /var/log/openldap
set_lk_max_lockers 1000
set_lk_max_locks 1000
set_lk_max_objects 1000索引数据库大多数 LDAP 操作包含对于属性的一些搜索，比如用户名、电话号码或电子邮件地址。在无任何帮助的情况下，slapd 在执行查询时必须搜索每个条目。将索引添加到属性中将创建一个让 slapd 搜索得更快的文件，因为索引中的数据以允许最快查询的方式存储。索引权 衡是降低写速度并增加磁盘和内存的使用。因此，最好是索引频繁搜索的属性。根据要执行的搜索类型，OpenLDAP 支持几种索引类型。索引类型在表 4 中列出。表 4. OpenLDAP 索引类型类型关键字描述搜索示例Presencepres用于想知道属性是否存在的查询。uid=*Equalityeq用于查找特定值的查询。uid=42Substringsub用于在值的某个位置查找字符串的查询。在此类型中，可以指定其他三个优化类型或使用一般的 sub 类型。cn=Sean*subinitial在值的开始处查找字符串的子串索引。cn=Sean*subany在值的中间查找字符串的子串索引。cn=*jone*subfinal在值的末尾查找字符串的子串索引。cn=*SmithApproximateapprox用于发音相似的搜索，以查找听起来像搜索字符串的值。cn~=Jason要将索引应用于属性，请使用
index [attrlist] [indices] 语法，其中
[attrlist] 是逗号分隔的属性列表，[indices] 是表 4 中索引类型的逗号分隔列表。可能有几行
default 指定为属性列表可以设置索引列表为空时使用的索引类型。考虑清单 20 中定义的索引。清单 20. 索引示例集index default eq,sub
index entryUUID,objectClass eq
index cn,sn,mail eq,sub,subinitial,subany,subfinal
index userid,telephonenumber
index ou eq清单 20 第一行将默认索引定义为一个等式和一个基本子串匹配。第二行将等式索引置于
entryUUID 属性（有利于 syncrepl 性能）
和 objectClass 属性（普通搜索）上。第三行将等式索引和所有子串索引置于
mail 属性上，因为这些字段通常具有不同的通配符搜索。userid 和
telephonenumber 属性接收默认索引，因为没有输入更多特定的索引。最后，ou 属性有一个等式索引。更改索引定义之后，必须通过停止 slapd 并以 ldap 用户身份运行 slapindex 来重新构建索引（或者如果正以根用户运行，则确保在运行
slapindex 之后将数据库目录中所有文件的所有权值新分配给 ldap 用户）。启动 slapd，使用您的索引。本节介绍 Senior Level Linux
Professional (LPIC-3) 301 考试的 303.6 主题的内容。本主题的权值是 2。在本节中，学习如何执行下列操作： 了解 slapd.conf 配置指令了解 slapd.conf 数据库定义管理 slapd 及其命令行选项分析 slapd 日志文件slapd.conf 的内容在本教程前面和上一篇教程中都有大篇幅介绍。本节的重点在于 slapd 可用的命令行选项和登录命令。命令行选项启动 slapd 最简单的方法是不使用任何参数来运行。然后，Slapd 读取默认配置文件，在后台创建子进程，并取消与终端关联。表 5 列出一些有用的命令行参数。表 5. slapd 命令行参数参数值描述-dInteger使用扩展调试运行 slapd ，并导致 slapd 在前台运行-fFilename指定备选配置文件-hURL list指定 slapd 监听的地址和端口-sSysloglevel指定用于消息的系统日志优先级-lInteger指定用于消息的本地系统日志工具（例如 LOCAL4）-uUsername以给定用户的身份运行 slapd-gGroupname在给定组中运行 slapd URL 列表允许将 slapd 绑定到不同接口。例如，-h "ldap://127.0.0.1/ ldaps:///" 将导致 slapd 仅在环回（loopback）中监听 TCP 端口 389（未加密的 LDAP），并在所有接口上监听加密的 LDAP（TCP 端口 636）。甚至可以更改端口号：例如，ldap://:5565/ 将导致未加密的 LDAP 在所有接口的端口 5565 上运行。了解记录Slapd 使用 Unix 系统日志后台程序进行记录。默认情况下，将所有消息发送到 LOCAL4 设备，因此 syslog.conf 中至少需要
local4.* /var/log/openldap.log 来将消息捕获到 /var/log/openldap.log。然后，slapd.conf 中的
loglevel 命令将告诉 slapd 要记录消息类型。表 6 列出可能的消息类型。表 6. slapd 消息记录类型关键字整数值描述trace1跟踪函数调用packet2调试数据包处理args4大量跟踪调试（函数参数）conns8连接管理BER16打印发送和接收的数据包filter32搜索筛选器处理config64配置文件处理ACL128ACL 处理stats256统计记录连接/操作/结果stats2512统计记录发送的条目shell1024使用 shell 后端打印通信parse2048条目解析sync16384LDAPSync 复制可以为 loglevel 关键字使用空格分隔的关键字列表、整数值或整数值之和。例如
loglevel args ACL、
loglevel 4 128 和
loglevel 132 都启用函数参数和 ACL 的调试。结束语在本教程中，学习了有关访问控制列表、复制、安全性、调优以及一般配置的更多详细信息。ACL 指定 who 获得对哪组条目和属性的 what 访问。您需要使用
access to &what& [ by &who& [ &access& ] [ &control& ] ]+ 形式来配置 ACL。可以使用许多形式，其中包括直接匹配和正则表达式来指定 what。who 也可能使用匹配和正则表达式，但它还可以使用 selfusers 和 anonymous 等关键字。who 子句还可以查找连接强度或用户来自的网络等内容。复制包括让远程服务器与主要 LDAP 服务器保持更新。复制有两种方法：slurpd 和 syncrepl。在 slurpd
模式中，单独的后台程序在主服务器上运行，并将所有更改推至从服务器。从服务器必须使用主服务器的数据的副本启动；这需要在主服务器停机时进行。在 syncrepl 中，提供者（主服务器）运行覆盖以处理复制任务。消费者（从服务器）连接到主服务器并下载任何更新。如果消费者定期下载更新，则称为 refreshOnly 模式。如果消费者下载更新，然后保持连接，则它处于 refreshAndPersist 模式，并在提供者发生更新时接收更新。TLS 和 SSL 允许您加密客户机和服务器之间的通信，甚至复制流量。必须生成服务器密钥，并由 CA 签名，TLS 才能工作。正常的 LDAP 流量运行在 TCP 端口 389 上，加密的 LDAP 流量运行在 TCP 端口 636 上，因此必须相应地配置您的防火墙。性能调优需要将系统资源分配到不同的缓存，并将索引应用到频繁搜索的列上。系统资源由 slapd.conf 和 DB_CONFIG 文件控制。根据要尝试优化的搜索类型，索引可以是等式、子串、存在或近似。slapd 的大多数行为在 slapd.conf 中控制，因此只有少数命令行参数控制 slapd 监听的地址和端口、运行的用户身份以及一些有关如何记录的参数。slapd 记录的内容由 slapd.conf 中的
loglevel 指令控制。现在，您具有了安装、配置和管理功能 OpenLDAP 服务器的技能，其中包括安全性、复制和性能调优。接下来的两个教程将重点介绍 LDAP 的应用，比如将 LDAP 与电子邮件和验证系统集成在一起，从命令行中搜索树。
回顾此 301 系列的前一篇教程，
“”（developerWorks，2007 年 12 月），或 。
参考 developerWorks 中完整的
，学习 Linux 基础知识并准备系统管理员认证考试。
中，可以找到 Linux Professional Institute 的三个 Linux 系统管理认证级别的任务清单、问题示例和详细的学习目标。
在 OpenLDAP FAQ.Get 中查找
在 Wikipedia 中查阅并深入理解有关
的内容，其中包括一些示例。如果您研究过 LDAP Data Interchange Format (LDIF) 或阅读过一些 OpenLDAP 手册页，您可能对 BNF 比较熟悉。
中的一章讲述了
，其中详细介绍了语法。slapd.access(5)
手册页是 Administrator's Guide 的好搭档。
中查看有关
的章节。其中详细描述了两种复制类型的工作原理。 ，
由 OpenLDAP Foundation 和 IBM 倡导，描述了一种比使用 slurpd 更有效的同步 LDAP 服务器的方法。 ，一本在线图书，非常不错，尽管尚未完工。
中查找针对 Linux 开发人员的更多资源，并浏览
浏览 developerWorks 上的全部
实用工具使得键入 iptables 规则更加容易；它具有友好的 GUI 和工具集，可用于更新您的防火墙。
是 LDAP 服务器的不错选择。
是一个基于 Web 的 LDAP 的管理工具。如果 GUI 更适合您的风格，那么可以考虑 。
（可以直接从 developerWorks 下载），在 Linux 上构建您的下一个开发项目。
中的博客、论坛、播客和社区主题，参与
developerWorks: 登录
标有星（*）号的字段是必填字段。
保持登录。
单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件。
在您首次登录 developerWorks 时，会为您创建一份个人概要。您的个人概要中的信息（您的姓名、国家/地区，以及公司名称）是公开显示的，而且会随着您发布的任何内容一起显示，除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。
所有提交的信息确保安全。
选择您的昵称
当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。
您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。
标有星（*）号的字段是必填字段。
(昵称长度在 3 至 31 个字符之间)
单击提交则表示您同意developerWorks 的条款和条件。 .
所有提交的信息确保安全。
IBM PureSystems(TM) 系列解决方案是一个专家集成系统
通过学习路线图系统掌握软件开发技能
软件下载、试用版及云计算
static.content.url=/developerworks/js/artrating/SITE_ID=10Zone=Linux, Open sourceArticleID=298700ArticleTitle=LPI 301 考试准备，主题 303: 配置publish-date=