主题303：配置
在你开始前
了解这些教程可以教给您什么以及如何从中获得最大收益。
关于本系列
Linux Professional Institute （LPI）通过三个级别对Linux®系统管理员进行认证： 初级 （也称为“认证级别1”）， 高级 （也称为“认证级别2”）和高级 （也称为“认证级别3”） ”）。 要获得认证1级，您必须通过考试101和102。要达到认证2级，您必须通过考试201和202。要达到认证3级，您必须具有有效的高级认证并通过考试301（“核心”）。 您可能还需要通过其他高级专业考试。
developerWorks提供了教程，以帮助您准备五个初级，高级和高级认证考试。 每个考试涵盖几个主题，并且每个主题在developerWorks上都有一个相应的自学教程。 表1列出了LPI 301考试的六个主题和相应的developerWorks教程。
表1. LPI 301考试：教程和主题
| LPI 301考试主题 | developerWorks教程 | 教程总结 |
|---|---|---|
| 主题301 | LPI 301考试准备： 概念，体系结构和设计 |
了解有关LDAP概念和体系结构，如何设计和实现LDAP目录以及架构的信息。 |
| 主题302 | LPI 301考试准备： 安装与开发 |
了解如何安装，配置和使用OpenLDAP软件。 |
| 主题303 | LPI 301考试准备： 组态 |
（本教程）学习如何详细配置OpenLDAP软件。 请参阅详细目标 。 |
| 主题304 | LPI 301考试准备： 用法 |
快来了。 |
| 主题305 | LPI 301考试准备： 整合与迁移 |
快来了。 |
| 主题306 | LPI 301考试准备： 容量规划 |
快来了。 |
要通过301考试（并达到3级认证），必须满足以下条件：
- 您应具有多年在各种用途的计算机上安装和维护Linux的经验。
- 您应该具有与各种技术和操作系统的集成经验。
- 您应该具有作为企业级Linux专业人员的专业经验或接受过培训（包括作为其他角色的一部分的经验）。
- 您应该了解Linux管理的高级和企业级别，包括安装，管理，安全性，故障排除和维护。
- 您应该能够使用开源工具来衡量容量计划并解决资源问题。
- 您应该具有使用LDAP与UNIX®服务和Microsoft®Windows®服务（包括Samba，可插拔身份验证模块（PAM），电子邮件和Active Directory）集成的专业经验。
- 您应该能够使用Samba和LDAP进行规划，架构，设计，构建和实施完整的环境，以及衡量服务的容量规划和安全性。
- 您应该能够使用Bash或Perl创建脚本，或者至少了解一种系统编程语言（例如C）。
Linux Professional Institute不特别认可任何第三方考试准备材料或技术。
关于本教程
欢迎使用“配置”，这是为您准备LPI 301考试而设计的六个教程中的第三个教程。在本教程中，您将学习LDAP服务器配置，包括访问控制，安全性，复制和数据库性能。
本教程根据该主题的LPI目标进行组织。 大致来说，对于更高权重的目标，应该在考试中遇到更多问题，如表2所示。
目标
表2列出了本教程的详细目标。
表2.配置：本教程涵盖的考试目标
| LPI考试目标 | 客观体重 | 客观总结 |
|---|---|---|
| 303.2 OpenLDAP中的访问控制列表 |
2 | 计划和实施访问控制列表。 |
| 303.3 LDAP复制 |
5 | 设置OpenLDAP以在多个服务器之间复制数据。 |
| 303.4 保护目录 |
4 | 配置对LDAP服务器的加密访问，并在防火墙级别限制访问。 |
| 303.5 LDAP服务器性能调优 |
2 | 测量LDAP服务器的性能，并进行调整以达到最佳性能。 |
| 303.6 OpenLDAP守护程序配置 |
2 | 了解基本的slapd.conf配置指令，并熟悉基本的slapd命令行选项。 |
先决条件
为了从本教程中获得最大收益，您应该具有Linux的高级知识以及可以在其上实践所涵盖命令的Linux系统。
如果您的基本Linux技能有点生锈，那么您可能需要先阅读LPIC-1和LPIC-2考试的教程 。
程序的不同版本可能会不同地格式化输出，因此您的结果可能看起来与本教程中的清单和图不完全相同。
系统要求
要遵循这些教程中的示例，您需要具有OpenLDAP软件包并支持PAM的Linux工作站。 大多数现代发行版都满足这些要求。
LDAP中的访问控制列表
本节介绍了高级Linux专业人员（LPIC-3）考试301的主题303.2的材料。此主题的权重为2。
在本节中，学习如何：
- 计划LDAP访问控制列表
- 了解访问控制语法
- 授予和撤销LDAP访问权限
各种数据可以存储在LDAP树中，包括电话号码，生日和工资信息。 其中一些可能是公开的，有些可能只有某些人可以访问。 相同的信息可能会基于用户而有不同的限制。 例如，也许只有记录的所有者和管理员可以更改电话号码，但是每个人都可以读取该号码。 访问控制列表（ACL）处理这些限制的配置。
规划LDAP访问控制列表
在开始编写配置之前，应确定要实现的目标。 树的哪些部分包含敏感信息？ 哪些属性需要保护，哪些需要保护？ 该树将如何使用？
ACL的组成部分
ACL条目提供三项信息：
- ACL指定哪些条目和属性
- ACL适用于谁
- 授予的访问级别
指定“ what”子句时，可以选择过滤对象的专有名称（DN），LDAP样式的查询过滤器，属性列表或这三者的组合。 最简单的子句允许所有内容，但您可以得到更多限制。 通过DN过滤，您可以指定完全匹配的内容，例如ou=People,dc=ertw,dc=com或正则表达式（请参见“ 正则表达式 ”）。 查询过滤器可以匹配特定的objectClass或其他属性。 属性列表是用逗号分隔的属性名称列表。 更为复杂的匹配条件可能是“管理员的ou=People,dc=ertw,dc=com下的所有密码条目”。
确定ACL适用于谁时，您具有很大的灵活性。 通常，用户通过绑定到树的DN来标识用户，这称为bindDN 。 每个LDAP条目都可以具有用于验证该特定用户的userPassword属性。 在某些情况下，您可以将当前登录的用户称为self ，这对于允许用户编辑他或她自己的详细信息很有用。
如果用户不绑定，则将其视为匿名用户 。 默认情况下，匿名用户可以读取树，因此您必须确定是否需要更改此行为。 您可以通过IP地址或用于连接的方法（例如纯文本或加密的）进一步细分匿名用户（或任何用户）。
一旦确定了什么和谁，就必须确定访问级别。 访问范围可以从无到写访问。 您还可以指定用户可以针对条目进行身份验证但无法读取； 或者，您可以授予用户读取，搜索和比较访问权限的权限。
无论您如何配置ACL，任何已配置的rootDN用户都可以完全控制其数据库。 除了从slapd.conf中删除rootDN配置之外，您无法更改此设置。
了解访问控制语法
以Backus-Naur形式表示的ACL的基本形式为：
access to <what> [ by <who> [ <access> ] [ <control> ] ]+
描述什么
内容描述了ACL强制执行的属性和条目。 清单1显示了这样做的BNF表示法。
清单1. ACL的什么部分的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> <attr> ::= <attrname> | entry | children清单1中的某些元素未在此处定义，例如DN和regex。 专有名称的形式是已知的，并且最好在BNF之外研究正则表达式。
清单1显示了对ACL的哪个部分的描述可以是与所有内容匹配的星号（*），也可以是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 ，也不匹配父项。
第二个示例与第一个示例相似，但是它使用了正则表达式，并使用美元符号（$） 锚定了搜索字符串。 锚点匹配字符串的位置而不是字符串的一部分。 美元符号匹配字符串的结尾，因此第二个示例匹配以ou=people,dc=ertw,dc=com结尾的任何内容，其中包括cn=Sean Walberg,ou=people,dc=ertw,dc=com 。 请注意，没有锚点，搜索字符串可以在目标内的任何位置，例如ou=people,dc=ertw,dc=com,o=MegaCorp 。
清单2中的第三个示例显示了另一个锚^ ，它匹配字符串的开头。 第三个示例还使用另一个正则表达式.* 。 句点匹配任何一个字符，星号匹配零个或多个前一个字符。 因此， .*匹配零个或多个字符的任何字符串。 放在一起，第三个示例匹配从cn=Sean到dc=com所有条目。
您还可以基于LDAP查询进行过滤，最有用的是在objectClass上进行搜索。 例如， filter=(objectClass=posixAccount)的what子句仅匹配filter=(objectClass=posixAccount)的objectClass的posixAccount 。 有关objectClass ，请参阅本系列的第一个教程LPI 301考试准备：概念，体系结构和设计 。
what子句的最后一个选项是指定属性。 最常见的用法是限制谁可以看到私有属性，尤其是密码。 使用attrs=userPassword匹配密码属性。
一旦确定了要匹配的条目和属性，就必须描述该规则适用于谁。
描述谁
根据客户端绑定到树时提供的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>] [ssf=<n>] [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的哪一部分一样，星号匹配所有内容。 为了更具体，您有很多选择。 OpenLDAP定义了三个快捷方式，分别名为anonymous ， users和self 。 这些快捷方式分别与未注册用户，经过身份验证的用户和当前登录的用户匹配。 后者self经常用于允许登录用户编辑其个人资料的组件。 这基于DN的完全匹配； 如果您的用户信息分散在不同的条目中，则self关键字仅适用于与该用户绑定的条目。
关于self关键字的一个有趣的事情是，您还可以使用level关键字使ACL应用于用户条目的父级或子level 。 使用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到Fred Smith的条目中，则当Joe Blow访问Fred Smith的条目时，ACL将匹配。
group关键字与dnattr相似，不同之处在于参数引用的是树中其他位置定义的组，而不是条目中的属性。 默认情况下，该组具有groupOfNames的objectClass ，并且在member属性中引用了member 。
使用peername ， sockname和domain关键字来匹配客户端连接的属性。 peername是指客户端的IP地址，例如peernameip=127.0.0.1 。 sockname用于通过命名管道（通常不使用）进行连接。 domain与与IP地址关联的主机名匹配，可以很容易地对其进行欺骗。
最后一组选项是指连接的安全强度因子（SSF），这是OpenLDAP的术语，表示连接的安全级别。 当向您介绍用于连接到OpenLDAP的安全性机制（例如传输层安全性（TLS）和简单身份验证和安全性层（SASL））时，这些选项将变得更加清晰。
前面的所有项目都可以一起使用。 例如，您可以只允许来自特定IP地址范围，具有特定加密级别的某些管理员对密码字段进行写访问。 您也可以做得更少，例如只需要一个有效的登录名，甚至可以接受任何人，而无需进行身份验证。
描述访问
一旦确定了谁在访问您的树以及他们正在尝试访问的树，就必须指定他们具有的访问级别。 清单4显示了ACL访问部分的BNF表示法。
清单4.描述访问子句格式的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表示写入， 0表示无。 使用priv格式指定访问权限时，与level一样，没有隐含的进行情况。 如果要提供完全访问权限，则必须使用wrscx 。
字母前的=/+/-符号表示如果应用多个规则，指定的访问权限如何与当前访问权限级别合并。 使用= ，将忽略所有先前定义的访问，并且要使用的值在等号之后。 使用+和-访问添加到当前级别或从当前级别中减去。
了解控制
默认情况下，OpenLDAP采用优先匹配的方法来应用访问列表。 OpenLDAP查找与what子句匹配的第一个ACL条目，并在该条目内找到与who部分匹配的第一个条目。 这与在描述访问级别之后将关键字stop放置相同。 其他两个选项是continue和break 。 如果使用continue ，那么将在当前ACL条目中搜索与who部分匹配的下一行。 如果使用break ，则将停止当前ACL条目的处理，但是OpenLDAP将查找与who子句匹配的下一个ACL条目。
将什么，谁和访问放在一起
既然您已经看到了ACL的三个（如果算上控件，则是四个）部分，您可以将它们组合成一个策略。 清单5显示了一个典型的ACL列表，该列表允许注册用户读取树并允许用户更新自己的密码（但不能读取）。
清单5.一个简单的ACL设置
access to attrs=userPassword by self =xw by anonymous auth access to * by self write by users read 第一个子句与尝试访问userPassword字段的任何人匹配。 用户将获得对自己条目的写入和认证权限，该权限通过等号强制执行。 匿名用户被授予身份验证权限。 用户绑定到树时是匿名的。 因此，匿名用户需要auth权限，这样他们才能以常规特权用户auth登录。
如果请求的信息不是密码，则查询第二个ACL条目。 同样，用户对他或她自己的条目具有完全控制权（由于第一个ACL条目， userPassword字段除外），而所有经过身份验证的用户都具有对树的其余部分的读取权限。
清单6显示了一个ACL条目，该条目使用正则表达式将what和who子句绑定在一起。
清单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复制
本节介绍了高级Linux专业人员（LPIC-3）考试301的主题303.3的材料。此主题的权重为5。
在本节中，您将学习如何执行以下操作：
- 了解复制概念
- 配置OpenLDAP复制
- 执行和管理
- 分析复制日志文件
- 了解副本集线器
- 配置LDAP引用
- 配置LDAP同步复制
在某些时候，您的需求可能会超出一台服务器。 如果LDAP服务器的丢失是不可接受的，那么您的组织可能会依赖LDAP，或者查询量可能很高，以至于您不得不将查询拆分到多个服务器上。 它甚至可以是两者的结合。 但无论如何，您都需要使用多个服务器。
使用多台服务器，您可以将树划分到不同的服务器上，但这会导致可靠性下降-更不用说正确平衡查询可能很困难。 理想情况下，每个服务器都具有树的相同副本。 任何写操作都会及时传播到其他服务器，以便所有其他服务器都是最新的。 这称为复制 。
这种情况称为多主服务器 ，很复杂，因为数据没有明确的单一所有者。 大多数情况下，形成主从关系，其中一台服务器承担所有写入并将其发送到从属。 可以对任何服务器进行LDAP查询。 这可以扩展到副本集线器方案，在该方案中，单个从属服务器从主服务器复制数据，然后将数据复制到其他几个从属服务器。
OpenLDAP提供了两种实现复制的方法。 首先是通过slurpd ，这是一个单独的守护程序，它监视主服务器上的更改并将更改推送到从属服务器。 第二种是使用slapd的LDAP同步复制引擎，也称为syncrepl 。 现在认为slurpd方法已经过时了； 敦促人们改用syncrepl。 本节将对这两种方法进行研究。
基于slurpd的复制
基于Slurpd的复制是推送复制，其中主服务器将所有更改推送到从服务器。 如果客户端尝试更新从服务器，则将从服务器配置为将引荐发送回客户端，从而将客户端指向主机。 客户端负责将请求重新发送给主服务器。 Slurpd是从slapd.conf配置的独立守护程序。
slurpd复制模型中的数据流
主服务器是处理来自客户端的所有写入并保存权威数据源的服务器。 对主树的任何更改都将写入复制日志 ，该日志由slurpd监视。 当注意到复制日志中的更改时，slurpd将更改推送到所有从属服务器。
图1显示了slurpd的典型行为。
图1. slurpd复制模型中的数据流
流程如下：
- 客户端发送一个更新请求，恰好被从机接收到。
- 从服务器知道写操作只能来自其复制伙伴，因此从服务器将引用转回给客户端，将其指向主服务器。
- 客户端将更新请求重新发布给主服务器。
- 主服务器执行更新，并将更改写入复制日志
- 也在主服务器上运行的slurpd注意到复制日志中的更改。
- slurpd将更改发送到从属服务器。
这样，从属设备可以与主设备保持最新，而几乎没有滞后。 如果发生任何中断，或者从站发生错误，slurpd始终知道哪些从站需要哪个更新。
配置slurpd
配置基于Slurpd的复制需要执行以下步骤：
- 创建一个副本帐户，slurpd将使用该帐户对从属副本进行身份验证。
- 使用从服务器的名称配置主服务器。
- 将从站配置为副本，包括所有需要的ACL。
- 将数据库从主机复制到从属服务器。
创建副本非常简单； 唯一的要求是该帐户必须在userPassword属性中具有密码。 您可以像大多数属于人的帐户一样使用inetOrgPerson objectClass ，也可以使用更通用的objectClass例如添加了simpleSecurityObject辅助objectClass account 。 回顾第一篇教程，结构objectClass定义了条目（因此每个条目只能使用一个），而辅助objectClass则将属性添加到任何条目，而与结构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://slaveserver.ertw.com suffix="dc=ertw,dc=com" binddn="uid=replica1,dc=ertw,dc=com" credentials="replica1" bindmethod=simple replogfile /var/tmp/replicationlog 复制的配置在数据库模式下进行，因此请确保在第一次配置database后将replica命令放在某处。 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://masterserver.ertw.com updatedn指的是您先前在主服务器上创建的帐户，slurpd将使用该帐户将更新推送到从属服务器。 updateref是另一个LDAP URI，该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://masterserver.ertw.com/cn=David%20Walberg,ou=People,dc=ertw,dc=comOpenLDAP命令行客户端不遵循引用，但是其他LDAP库遵循。 如果在复制环境中使用LDAP，则应验证您的应用程序正确遵循了引用。
最后一个难题是确保主服务器和从服务器以相同的数据库开头。 这样做，请按照下列步骤操作：
- 关闭主服务器。
- 关闭从属服务器。
- 将所有数据库文件从主服务器复制到从属服务器。
- 启动主服务器和从服务器。
- 启动时大吃一惊。
必须关闭两个服务器以复制数据库，以确保不进行任何更改并且所有数据都已写入磁盘。 两台服务器必须从相同的数据集开始，这一点至关重要。 否则，它们稍后可能会不同步。 基于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: slaveserver.ertw.com:389 time: 1203798375.0 dn: sendmailMTAKey=testing,ou=aliases,dc=ertw,dc=com changetype: add objectClass: sendmailMTAAliasObject sendmailMTAAliasGrouping: aliases sendmailMTACluster: external sendmailMTAKey: testing sendmailMTAAliasValue: [email protected] structuralObjectClass: sendmailMTAAliasObject entryUUID: 5375b66c-7699-102c-822b-fbf5b7bc4860 creatorsName: cn=root,dc=ertw,dc=com createTimestamp: 20080223202615Z entryCSN: 20080223202615Z#000000#00#000000 modifiersName: cn=root,dc=ertw,dc=com modifyTimestamp: 20080223202615Z清单11中的拒绝文件以文本错误开头（“ ERROR：无效DN语法：无效DN”），其余的看起来像LDIF。 请注意，第一个属性是plicate ，它是无法处理更新的副本的名称，第二个属性time是错误发生的时间（UNIX时间戳格式）。 接下来的几个属性来自被拒绝的条目。
最后7个属性称为操作属性 。 它们不是原始更改的一部分，而是由LDAP服务器添加的，用于内部跟踪。 条目具有通用唯一标识符（UUID），以及有关何时以及由谁更改记录的一些信息。
在清单11中，错误很可能是由于从属服务器上缺少模式而引起的。 从属服务器不了解sendmailMTAKey属性是什么，因此该条目的DN无效。 从属必须先更新其架构，然后复制才能继续。
要修复被拒绝的条目，您必须评估错误并修复树的根本问题。 一旦知道被拒绝的条目将干净地应用，请使用slurpd的单发模式通过slurpd -r /path/to/rejection.rej -o应用更新。 -r参数告诉slurpd从给定的复制日志中读取，而-o导致slurpd使用单发模式，这意味着它在处理日志后退出，而不是等待将更多条目添加到日志的默认行为。
如果复制根本不起作用，最好的方法是从主服务器开始，然后一直到从服务器。 首先，杀死slurpd并对树进行更改。 然后，检查复制日志是否正在增长。 如果不是，则主机设置不正确。 接下来，启动slurpd，然后在命令行中传递-d 255 。 这将跟踪slurpd在处理日志时的动作。 查找错误，尤其是与打开文件和访问控制有关的错误。
最后，在从属服务器上，使用loglevel auth sync来检查复制时是否发生任何错误（使用local4工具将日志记录到syslog，因此您可能需要将local4.* /var/log/slapd.log添加到/ etc / syslog.conf）。
LDAP同步复制
slurpd是解决复制问题的直接方法，但是它有几个缺点。 关闭主服务器以使您可以同步从服务器最多是很不方便的，最坏的情况是会影响服务。 slurpd的推送架构也可能会受到限制。 slurpd在这段时间内运作良好，但必须创造更好的东西。 RFC 4533概述了LDAP内容同步操作，该操作由LDAP Sync复制引擎（也称为syncrepl）在OpenLDAP中实现。
syncrepl是作为覆盖层构建的，该覆盖层被插入slapd的核心与后端数据库之间。 对树的所有写入均由syncrepl引擎跟踪，而不需要单独的服务器实例。 除了复制的机制和角色（如下所述）外，这些概念与slurpd类似。 拒绝对副本的写操作，并将引用传递回主服务器。
syncrepl是从设备启动的，从设备现在被命名为消费者 。 主角色称为provider 。 在syncrepl中，使用者连接到提供程序以获取树的更新。 在最基本的模式下，称为refreshOnly ，使用者将接收自上次刷新以来所有已更改的条目，并请求一个cookie来跟踪上次同步的更改，然后断开连接。 On the next connection, the cookie is presented to the provider, which sends only the entries that changed since the last synchronization.
Another syncrepl mode, called refreshAndPersist , starts off like the refreshOnly operation; but instead of disconnecting, the consumer stays connected to receive any updates Any changes that happen after the initial refresh are immediately sent over the connection to the consumer by the provider.
Configure syncrepl
Listing 12 shows the provider's configuration for both syncrepl modes (refreshOnly and refreshAndPersist).
Listing 12. Provider configuration for syncrepl
overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 The first line of Listing 12 enables the syncprov overlay. Overlays must be configured against a database; therefore, this configuration must go after your database configuration line. The next two lines are optional, but they improve reliability. syncprov-checkpoint 100 10 tells the server to store the value of contextCSN to disk every 100 write operations or every 10 minutes. contextCSN is part of the cookie mentioned earlier that helps consumers pick up where they left off after the last replication cycle. syncprov-sessionlog 100 logs write operations to disk, which again helps in the refresh cycle.
More details about configuring the provider are found in the slapo-syncprov(5) manpage.
Listing 13 shows the consumer side of the replication pair.
Listing 13. Consumer configuration for syncrepl in refreshOnly mode
updateref ldap://masterserver.ertw.com syncrepl rid=1 provider=ldap://masterserver.ertw.com type=refreshOnly interval=00:01:00:00 searchbase="dc=ertw,dc=com" bindmethod=simple binddn="uid=replica1,dc=ertw,dc=com" credentials=replica1 Like the replica command from the slurpd configuration, the syncrepl command requires an updateref , information about the tree you're trying to replicate, and the authentication credentials you're going to use. This time, the credentials go on the consumer side and require enough access on the provider to read the part of the tree being replicated. The updates to the database on the consumer are run as the rootdn .
Items in Listing 13 specific to syncrepl are the rid , provider , type , and interval . The rid identifies this consumer to the master. The consumer must have a unique ID between 1 and 999. The provider is an LDAP URI pointing back to the provider. type specifies that you only want periodic synchronization through refreshOnly , and the interval is every hour. The interval is specified in DD:hh:mm:ss format.
Start the consumer with an empty database, and it will replicate its data from the provider and update every hour.
Making the transition to refreshAndPersist mode is simple. In Listing 13, remove the interval , and change the type to refreshAndPersist
syncrepl Filtering
It's worth noting that you don't have to replicate the whole LDAP tree. You can use the following commands to filter the data that is replicated.
Table 3. Commands for filtering replication traffic
| 命令 | 描述 |
|---|---|
| searchbase | A DN pointing to the node in the tree where replication will start. OpenLDAP will fill in any necessary parent nodes to make the tree complete. |
scope |
One of sub , one , or base . This determines how far down the tree, starting at the searchbase , that data is replicated. The default is sub , which covers the searchbase and all children |
filter |
A LDAP search filter, such as (objectClass=inetOrgPerson) that controls which records are replicated. |
attrs |
A list of attributes that will be copied over from the selected entries. |
Like the other options for syncrepl , these options are entered in the form of key=value
Topic 303.4
This section covers material for topic 303.4 for the Senior Level Linux Professional (LPIC-3) exam 301. This topic has a weight of 4.
In this section, you learn how to do the following:
- Secure the directory with SSL and TLS
- Configure and generate client / server certificates
- Understand firewall considerations
- Configure unauthenticated access methods
- Configure User / password authentication methods
Up to this point, all access to slapd has been over unencrypted channels using cleartext passwords. This is called simple authentication. This section looks at adding encryption to the client-server connection.
Use SSL and TLS to secure communications
You may be familiar with Secure Sockets Layer (SSL) and Transport Layer Security (TLS) as the protocols that secure Web transactions. Whenever you browse an https type URI, you're using SSL or TLS. TLS is an improvement on SSLv3 and in some cases is backward compatible to SSL. Because of their shared heritage and compatibility, they're often referred to collectively as SSL.
SSL makes use of X.509 certificates, which are a piece of data in a standard format that has been digitally signed by a trusted third party known as a Certificate Authority (CA). A valid digital signature means the data that was signed hasn't been tampered with. If the data being signed changes, even by one bit, then the signature won't validate. Independent parties, such as the client and the server, can validate signatures because they both start off by trusting the CA.
Within the server's certificate is information about the ownership of the server, including its name on the Internet. Thus you can be sure you're connecting to the right server because the name of the server you connected to exactly matches the name in the certificate, and you've trusted the CA to validate this before signing. The certificate also includes the server's public key, which can be used to encrypt data such that only the holder of the secret key can decrypt it.
Public and secret keys form the basis of public key or asymmetric cryptography. It's asymmetric because data encrypted by the public key can only be decrypted by the secret key, and data encrypted with the secret key can only be decrypted by the public key. For what you normally think of as encryption, such as keeping a message secret, the first case is used. The public key is made public, and the secret key is made secret. Because of the asymmetric behavior of the keys, the secret key can encrypt a message, and anyone with the public key can decrypt it. This is how digital signatures work.
After the client connects to the server and receives the server's certificate, the client can validate that the server name is correct, which prevents a man in the middle attack . The public key can be used to run through a protocol that ends up with the client and server agreeing on a shared secret that no one observing the conversation can determine. This secret is then used to encode the rest of the conversation between the client and the server, called symmetric cryptography because the same key both encrypts and decrypts the data. The divide between asymmetric and symmetric cryptography exists because the latter is orders of magnitude faster. Public key cryptography is used to authenticate and come up with a shared secret, and then symmetric key cryptography takes over.
To apply this all to OpenLDAP, you must create a certificate for the server and then configure the server to use it. This example uses a self-signed certificate rather than creating a Certificate Authority, which means the final certificate has been signed by itself. It doesn't provide the level of trust that a CA does, but it's adequate for testing. Listing 14 shows the generation of the key.
Listing 14. Generating the TLS key pair
[root@bob ssl]# openssl genrsa -out ldap.key 1024 Generating RSA private key, 1024 bit long modulus .................................++++++ .........................++++++ e is 65537 (0x10001) Listing 14 shows the key being generated with the openssl genrsa command. The key is 1024 bits long, which is currently considered adequate for public keys (note that using much larger values makes cryptographic operations much slower and may confuse some clients). Next, openssl req takes the public part of the freshly generated key pair, adds some location information, and packages the result -- a Certificate Signing Request (CSR) -- to be signed by a CA (see Listing 15).
Listing 15. Generating the 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) []:masterserver.ertw.com Email Address []:[email protected] Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:The generated file, ldap.csr, can be sent off to a CA (along with a hefty payment) to be signed. This is also the procedure you follow to generate a certificate for a Web server. If you do send this off for signing, make sure all the information you've provided is spelled correctly, that abbreviations are used only for the Country Name, and that the Common Name exactly matches the DNS name people will use to connect to your server.
Instead of getting a CA to sign the CSR, in this example you'll sign it yourself, as shown in Listing 16.
Listing 16. Signing the 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=masterserver.ertw.com/[email protected] Getting Private key Listing 16 signs the key with the openssl x509 command. Using -req tells openssl that the input is a CSR. The validity of this certificate is 1095 days, or 3 years. Now you have ldap.key (the private key) and ldap.cert (the certificate and public key).
Before continuing, add a line to /etc/openldap/ldap.conf containing TLS_REQCERT allow . This tells the OpenLDAP client utilities to ignore the fact that they're seeing a self-signed certificate. Otherwise, the default settings deny the certificate as invalid.
Getting OpenLDAP to use the new key and certificate is easy. Assuming you stored the generated keys in /etc/openldap/ssl/, the lines in Listing 17 set up your server for TLS connections after you restart slapd.
Listing 17. Configuring slapd for SSL
TLSCertificateFile /etc/openldap/ssl/ldap.cert TLSCertificateKeyFile /etc/openldap/ssl/ldap.key The commands in Listing 17 point slapd to your certificate and private key. To test your new server, issue the ldapwhoami -v -x -Z command, which binds anonymously to your secure port. If you receive a "success" message, then everything is working correctly. Otherwise, the debugging information generated by -v will point you to the cause or any errors.
You can generate a client certificate, which is optional, the same way as the server certificate. Instead of Listing 17, use the TLS_KEY and TLS_CERT commands in ldap.conf, which set your client key and certificate, respectively. Client certificates are required only if you need to have the certificate itself identify the client.
Firewall considerations
LDAP uses TCP port 389, and LDAPS (LDAP over SSL) uses TCP port 636. If you have a firewall between your servers and your clients, these ports must be allowed through the firewall for connections to succeed. Clients always connect to servers, and, depending on your replication strategy, servers connect to other servers.
Linux iptables
If you have an iptables-based firewall on your LDAP server, you need to modify your rule set to allow the incoming connections. Generally, the commands in Listing 18 suffice.
Listing 18. Adding iptables rules to allow LDAP connections
iptables -A INPUT -p tcp --dport 389 -j ACCEPT iptables -A INPUT -p tcp --dport 636 -j ACCEPT Listing 18 works if your policy is simple. -A INPUT appends the rule to the INPUT table, where all incoming packets are checked. You may have to insert these rules at the top (use -I INPUT instead) or use your distribution's firewall tools to allow TCP ports 389 and optionally 636 if you need LDAPS connectivity.
If you're using your Linux firewall as a router, such that the clients are attached to another interface and the LDAP server is attached to another interface, you must use the FORWARD chain instead of INPUT . You may also want to specify the incoming interface with -i , such as -i eth0 to indicate that only packets coming in eth0 will be accepted. Once a packet has been accepted, the return packets are also accepted.
Protection through TCP Wrappers
One of the configuration options available when compiling OpenLDAP is --enable-wrappers , which links the resulting binaries against the TCP Wrappers libraries. The wrappers use two files, /etc/hosts.allow and /etc/hosts.deny, to permit or deny access to incoming clients.
First check to see if slapd uses TCP Wrappers with ldd /usr/sbin/slapd | grep libwrap . If anything is returned, then your binary is using TCP Wrappers. If not, you need to recompile with --enable-wrappers or use the iptables method shown earlier.
With wrappers support, you can deny everybody access by adding slapd: ALL in /etc/hosts.deny. You can then allow people in with slapd: 192.168.1.,127.0.0.1 , which lets anyone from the 192.168.1.0/24 network or the localhost connect. Note that connections denied through TCP Wrappers connect at first but are then disconnected automatically. Contrast this to a firewall, where the packet is dropped before it reaches slapd.
The format of hosts.allow and hosts.deny allows for many different ways to allow and deny connections; consult the hosts_access(5) manpage for all the details.
More on authentication
So far, the discussion of authentication has been limited to cleartext passwords defined in slapd.conf and simple authentication used between the client and the server. Cleartext passwords can be solved with slappasswd . Enter slappasswd at the shell, and you're prompted for a password and then to verify that password. The output is a secure hash of the password, such as {SSHA}oxmMsm9Ff/xVQ6zv+bgmMQjCUFL5x22+ . This hash is mathematically guaranteed not to be reversible, although given the hash, someone could guess repeatedly by trying various passwords and seeing if the hash is the same.
You've already experienced the anonymous bind, where no username or password has been provided, and the authenticated bind, where both the username and password are provided and valid. OpenLDAP also supports an unauthenticated bind, where the username is provided with no password. An unauthenticated bind is usually disabled unless you have allow bind_anon_cred in your configuration. If allowed, an unauthenticated bind is considered anonymous.
The alternative to simple authentication is Simple Authentication and Security Layer (SASL), a framework for providing a plug-in architecture for authentication and encryption methods. A detailed look at SASL will appear in a forthcoming tutorial; in the meantime, SASL allows for different authentication methods from plaintext to Kerberos.
Earlier, when investigating ACLs, this tutorial mentioned that access can be influenced by the connection method. This is called the Security Strength Factor (SSF). An unencrypted session has an SSF of 0, and an encrypted session generally has an SSF corresponding to the key length. Thus, you can require an encrypted session for a particular ACL by adding ssf=1 to the who clause of your ACL.
LDAP server performance tuning
This section covers material for topic 303.5 for the Senior Level Linux Professional (LPIC-3) exam 301. This topic has a weight of 2.
In this section, you learn how to do the following:
- Measure LDAP performance
- Tune software configuration to increase performance
- Understand indexes
OpenLDAP is a database. You provide it with a query or a task to run, and it finds the data and returns it to you. In order to do so as fast as possible, you must assign resources to the places they will be best used, such as caching of frequently accessed data, and indexing databases.
Measure performance
Before you can try to make slapd run faster, you must be able to measure the current state. This may mean timing a certain operation in your application and looking for an improvement. It may also mean performing several queries yourself and calculating the average. The metric may not even be time based; it may be to reduce disk load on the LDAP server because the current configuration is causing too many reads and writes.
Either way, it's helpful to take several measurements of different metrics before and after any changes. Helpful commands are as follows:
-
vmstatto show input/output (IO) statistics and CPU usage, notably the user time and wait time -
iostatto show more details about reads and writes to disk, along with the disk controller usage -
psto show memory usage of the slapd process (not that using more memory is a bad thing, but it's important to make sure you don't run out of RAM) -
timefor timing various command-line operations
Tune the daemon
Tuning always involves tradeoffs. Often, you increase the amount of resources (usually memory or disk) to a process to get the process to respond faster. Doing so decreases the resources that other processes can use. Similarly, if you make your process run faster, it often consumes more resources, such as CPU cycles or disk IO, that are unavailable to other processes.
Tradeoffs can also occur at the application level. By sacrificing some write performance, you're often able to drastically improve read performance You can also make your application run faster by turning off various safety features such as transaction logging. Should you have a crash, you may end up restoring your database from a backup, but only you know if this is an acceptable tradeoff.
Most people use the Berkeley Database (BDB) backend. This backend is based on the Sleepycat Berkeley Database, now owned by Oracle, which is a fast embedded database. It doesn't support a query language; instead, it's based on hash-table lookups. Tuning this backend occurs in two places: one in slapd.conf and another in a special file used by the BDB runtime.
slapd.conf configuration directives
The BDB database is linked against the binary that uses it, rather than being a standalone server like most SQL servers. As such, the application using the BDB database is responsible for some of the behavior of the database. The slapd-bdb(5) manpage describes all the directives that are controllable by slapd through slapd.conf; this tutorial covers only the most important.
Like many SQL backends, BDB databases write their changes to a transaction log to ensure reliability in the case of a failure; they also keep data in memory to save on disk writes. The operation that flushes all the in-memory data to disk and writes the transaction log out is called a checkpoint . The checkpoint command tells slapd how often to write out the data, in terms of kbytes of stored changes and minutes since the last checkpoint. Adding checkpoint 128 15 to slapd.conf means that data will be flushed every 128KB of changes or at least every 15 minutes. By default, no checkpoint operations are performed which is the same as checkpoint 0 0 .
Recently accessed entries can be cached in RAM for faster access. By default, 1000 entries are cached. To change this number, use cachesize along with the number of entries. The higher the cachesize , the more likely an entry is to be cached in RAM, but the more RAM is consumed by the slapd process. Your choice of value here depends on how many different entries are in your tree and the pattern of access. Make sure you have enough space in the cache to hold your commonly accessed items, such as the user list.
Similar to cachesize is idlcachesize , which has to do with how big the memory cache for indexes is. Your setting will depend on how many indexes you have configured (discussed later), but it's wise to start by making idlcachesize the same as cachesize .
Tune the BDB databases
As mentioned earlier, some of the tuning parameters for the BDB databases are handled in a separate file that is read by the BDB runtime and ignored by slapd. This file is called DB_CONFIG, and it lives in the same directory as your database. The most important parameter in that file is set_cachesize , which sets the internal BDB cache size, not the slapd entry cache. The format is set_cachesize <GigaBytes> <Bytes> <Segments;> , where GigaBytes and Bytes refer to the size of the cache (the two are added together), and Segments allows you to split the cache across separate memory blocks to get around 32-bit address limitations (both 0 and 1 have the same effect, allowing only a single memory segment). For a 1GB cache, use set_cachesize 1 0 0 .
To determine the best BDB cache size, it's often easiest to look at the cache statistics of a working system and increase as needed. The command to look at the memory usage statistics of a BDB database is db_stat -h /path/to/database -m . The first 20 lines show the relevant details. If you have a high number of pages forced from the cache, or the number of pages found in the cache is low (< 95%), consider increasing the BDB cache size. On some distributions, db_stat may be called slapd_db_stat to separate it from the system BDB libraries and tools.
In addition to cache, you need to make sure the transaction logs are monitored. Set the path to the transaction logs with set_lg_dir . If you can put the transaction log on a different set of disk spindles than the database, you'll have much better performance.
Even though BDB is a simple database, it still needs to be able to lock files for writing. The default settings for the number of locks is usually large enough, but you should monitor the output of db_stat -h /path/to/database -c for any mention of hitting the maximum number of locks. In BDB, locks are split into three types (and reported separately): lockers, locks, and lock objects The difference between them isn't important, but the maximum number of each is controlled through set_lk_max_lockers , set_lk_max_locks , and set_lk_max_objects , respectively.
Whenever you make changes to DB_CONFIG, you must restart slapd. Listing 19 shows a sample DB_CONFIG file based on the directives mentioned previously.
Listing 19. Sample DB_CONFIG file
# 256K cache set_cachesize 0 268435456 0 set_lg_dir /var/log/openldap set_lk_max_lockers 1000 set_lk_max_locks 1000 set_lk_max_objects 1000Index your database
Most LDAP operations involve some sort of search on an attribute, such as a username, a phone number, or an email address. Without anything to help it, slapd must search each entry when performing a query. Adding an index to an attribute creates a file that lets slapd search much more quickly because the data in an index is stored in a way that allows for fast lookups. The tradeoff for an index is slower write speed and increased disk and memory usage. Therefore, it's best to index attributes that are searched on frequently.
OpenLDAP supports several index types, depending on the type of search being performed. The index types are listed in Table 4.
Table 4. OpenLDAP index types
| 类型 | 关键词 | 描述 | Search example |
|---|---|---|---|
| Presence | 压力 | Used for lookups that want to know whether an attribute exists. | uid=* |
| 平等 | 当量 | Used for lookups that are looking for a specific value. | uid=42 |
| Substring | 子 | Used for lookups that are looking for a string somewhere within a value. Within this type, you can specify three other optimized types or use the generic sub type. |
cn=Sean* |
| subinitial | A substring index looking for a string at the beginning of a value. | cn=Sean* |
|
| subany | A substring index looking for a string in the middle of a value. | cn=*jone* |
|
| subfinal | A substring index looking for a string at the end of a value. | cn=*Smith |
|
| Approximate | 大约 | Used for sound-alike searches, where you want to find a value that sounds like your search string. | cn~=Jason |
To apply an index to an attribute, use the syntax index [attrlist] [indices] , where [attrlist] is a comma-separated list of the attributes and [indices] is a comma-separated list of the index types from Table 4 You may have several index lines. Specifying default as the attribute list sets the type of indexes that are used when the list of indexes is empty. Consider the indexes defined in Listing 20.
Listing 20. A sample set of indexes
index default eq,sub index entryUUID,objectClass eq index cn,sn,mail eq,sub,subinitial,subany,subfinal index userid,telephonenumber index ou eq Listing 20 first defines the default indexes as an equality and a basic substring match. The second line places an equality index on the entryUUID attribute (good for syncrepl performance) and the objectClass attribute (a common search). Line 3 places an equality index and all substring indexes on the cn , sn , and mail attributes because these fields often have different wildcard searches. The userid and telephonenumber attributes receive the default indexes because nothing more specific was entered. Finally, the ou attribute has an equality index.
After changing your index definitions, you must rebuild the indexes by stopping slapd and running slapindex as the ldap user (or, if you're running as root, make sure to reassign ownership of all the files in the database directory to the ldap user after running slapindex ). Start up slapd, and your indexes are used.
Topic 303.6
This section covers material for topic 303.6 for the Senior Level Linux Professional (LPIC-3) exam 301. This topic has a weight of 2.
In this section, you learn how to do the following:
- Understand slapd.conf configuration directives
- Understand slapd.conf database definitions
- Manage slapd and its command-line options
- Analyze slapd log files
The contents of slapd.conf have been largely covered earlier in this tutorial and in the previous tutorial. Of particular interest in this section are the command-line options and logging commands available to slapd.
Command-line options
The simplest way to start slapd is to run it without any arguments. Slapd then reads the default configuration file, forks to the background, and disassociates from the terminal.
Table 5 lists some helpful command-line arguments.
Table 5. slapd command-line arguments
| 论据 | 值 | 描述 |
|---|---|---|
-d |
Integer | Runs slapd with extended debugging, and causes slapd to run in the foreground |
-f |
Filename | Specifies an alternate configuration file |
-h |
URL list | Specifies the addresses and ports that slapd listens on |
-s |
Sysloglevel | Specifies the syslog priority used for messages |
-l |
Integer | Specifies the local syslog facility (such as LOCAL4) used for messages |
-u |
用户名 | Runs slapd as the given user |
-g |
团队名字 | Runs slapd in the given group |
The URL list allows you to bind slapd to different interfaces. For example, -h "ldap://127.0.0.1/ ldaps:///" causes slapd to listen on TCP port 389 (unencrypted LDAP) only on the loopback, and encrypted LDAP (TCP port 636) on all interfaces. You can even alter port numbers: for example, ldap://:5565/ causes unencrypted LDAP to run on port 5565 of all interfaces.
Understand logging
Slapd uses the Unix syslog daemon for logging. By default, all messages are sent to the LOCAL4 facility, so you need at least local4.* /var/log/openldap.log in syslog.conf to capture the messages to /var/log/openldap.log. The loglevel command in slapd.conf then tells slapd what type of messages to log. Table 6 lists the possible message types.
Table 6. slapd message logging types
| 关键词 | Integer value | 描述 |
|---|---|---|
trace |
1个 | Trace function calls |
packet |
2 | Debug packet handling |
args |
4 | Heavy trace debugging (function args) |
conns |
8 | Connection management |
BER |
16 | Print out packets sent and received |
filter |
32 | Search filter processing |
config |
64 | Configuration file processing |
ACL |
128 | ACL processing |
stats |
256 | Stats log connections/operations/results |
stats2 |
512 | Stats log entries sent |
shell |
1024 | Print communication with shell backends |
parse |
2048 | Entry parsing |
sync |
16384 | LDAPSync replication |
You may use a space-separated list of keywords, integer values, or the sum of the integer values for the loglevel keyword. For example, loglevel args ACL , loglevel 4 128 , and loglevel 132 all enable debugging of function arguments and ACLs.
摘要
In this tutorial, you learned about access control lists, replication, security, tuning, and more details about general configuration.
ACLs dictate who gets what access to what set of entries and attributes. You need to configure your ACLs using the form access to <what> [ by <who> [ <access> ] [ <control> ] ]+ . You can use a variety of forms, including direct matches and regular expressions to specify the what. The who can also use matches and regular expressions, but it can also use keywords like self , users , and anonymous . The who clause can also look for things like the strength of the connection or the network the user is coming from.
Replication involves keeping a remote server up to date with the primary LDAP server. Two methods exist for replication: slurpd and syncrepl. In the slurpd model, a separate daemon runs on the master server and pushes all changes to the slaves. The slaves must start with a copy of the master's data; this requires downtime on the master. In syncrepl, the provider (master) server runs an overlay to handle the replication tasks. The consumers (slaves) connect to the master and download any updates. If a consumer downloads updates on a periodic basis, it's said to be in refreshOnly mode. If the consumer downloads the updates and then stays connected, it's in refreshAndPersist mode, and it receives updates as they happen on the provider.
TLS and SSL let you encrypt communications between the client and server, and even replication traffic. You must generate server keys and have them signed by a CA for TLS to work. Regular LDAP traffic runs over TCP port 389, and encrypted LDAP traffic runs over TCP port 636, so you must have your firewalls configured accordingly.
Performance tuning involves assigning system resources to various caches and buffers and applying indexes on frequently searched columns. System resources are controlled in both the slapd.conf and DB_CONFIG files. Indexes can be equality, substring, presence, or approximate, depending on the type of search for which you're trying to optimize.
Most of slapd's behavior is controlled in slapd.conf, so there are only a few command-line parameters to control the addresses and ports that slapd listens on, the user it runs as, and some parameters about how it logs. What slapd logs is controlled by the loglevel directive in slapd.conf.
At this point, you have the skills to install, configure, and manage a functional OpenLDAP server, including security, replication, and performance tuning. The next two tutorials will focus on applications of LDAP, such as integrating LDAP with e-mail and authentication systems, and searching your tree from the command line.
翻译自: https://www.ibm.com/developerworks/linux/tutorials/l-lpic3303/index.html