软件体系结构概念视图
在你开始前
了解这些教程可以教给您什么以及如何从中获得最大收益。
关于本系列
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考试准备： 安装与开发 | 快来了。 |
| 主题303 | LPI 301考试准备： 组态 | 快来了。 |
| 主题304 | LPI 301考试准备： 用法 | 快来了。 |
| 主题305 | LPI 301考试准备： 整合与迁移 | 快来了。 |
| 主题306 | LPI 301考试准备： 容量规划 | 快来了。 |
要通过301考试（并达到3级认证），您应该：
- 具有多年在各种用途的计算机上安装和维护Linux®的经验。
- 具有与各种技术和操作系统的集成经验。
- 具有作为企业级Linux专业人员的专业经验或接受过培训（包括作为其他角色的一部分的经验）。
- 熟悉Linux管理的高级和企业级别，包括安装，管理，安全性，故障排除和维护。
- 能够使用开源工具来衡量容量计划并解决资源问题。
- 具有使用LDAP与UNIX®和Microsoft®Windows®服务集成的专业经验，这些服务包括Samba，可插拔身份验证模块（PAM），电子邮件和Microsoft Active Directory目录服务。
- 能够使用Samba和LDAP进行规划，架构，设计，构建和实施完整的环境，以及衡量服务的容量规划和安全性。
- 能够使用Bash或Perl创建脚本，或者至少了解一种系统编程语言（例如C）。
Linux Professional Institute不特别认可任何第三方考试准备材料或技术。
关于本教程
欢迎阅读“概念，体系结构和设计”，这是旨在为LPI 301考试做准备的六篇教程中的第一篇。在本教程中，您将学习LDAP概念和体系结构，如何设计和实现LDAP目录以及架构。
本教程根据该主题的LPI目标进行组织。 粗略地说，对于权重较高的目标，应在考试中遇到更多问题。
目标
表2提供了本教程的详细目标。
表2.概念，体系结构和设计：本教程涵盖的考试目标
| LPI考试目标 | 客观体重 | 客观总结 |
|---|---|---|
| 301.1 概念与架构 | 3 | 熟悉LDAP和X.500概念。 |
| 301.2 目录设计 | 2 | 在计划适当的目录信息树以避免冗余的同时，设计并实现LDAP目录。 您应该了解适合存储在LDAP目录中的数据类型。 |
| 301.3 模式 | 3 | 熟悉模式概念和OpenLDAP安装随附的基本模式文件。 |
先决条件
为了从本教程中获得最大收益，您应该具有Linux的高级知识以及可以在其上实践所涵盖命令的Linux系统。
如果您的基本Linux技能有点生锈，那么您可能需要先阅读LPIC-1和LPIC-2考试的教程 。
程序的不同版本可能会不同地格式化输出，因此您的结果可能看起来与本教程中的清单和图不完全相同。
系统要求
要遵循这些教程中的示例，您需要具有OpenLDAP软件包并支持PAM的Linux工作站。 大多数现代发行版都满足这些要求。
概念与架构
本部分介绍了高级Linux专业人员（LPIC-3）考试301的主题301.1的材料。此主题的权重为3。
在本节中，了解以下内容：
- LDAP和X.500技术规范
- 属性定义
- 目录名称空间
- 著名的名字
- LDAP数据交换格式
- 元目录
- 变更类型操作
LPIC-3考试的大部分内容都集中在轻量级目录访问协议（LDAP）的使用上。 因此，第一个目标涉及了解LDAP是什么，它做什么以及该概念背后的一些基本术语。 了解这一点后，您将可以继续设计目录并将应用程序与目录集成。
LDAP，这是什么？
在讨论LDAP之前，让我们回顾一下目录的概念。 目录的经典示例是电话簿，其中按字母顺序列出了人员以及他们的电话号码和地址。 每个人（或家庭）代表一个对象，电话号码和地址是该对象的属性。 尽管乍一看并不总是很明显，但有些对象是企业而不是人员，并且这些对象可能包括传真号码或营业时间。
与印刷版目录不同，计算机目录本质上是分层的，允许将对象放置在其他对象下以指示父子关系。 例如，电话目录可以扩展为具有代表城市区域的对象，每个人和商业对象都属于其各自的区域对象。 然后，这些区域对象将落在城市对象下，而城市对象又可能落在州或省对象下，依此类推，如图1所示。这将使打印副本更加难以使用，因为您需要知道名称和名称。地理位置，但是可以使用计算机对信息进行排序并搜索目录的各个部分，因此这不是问题。
图1.示例目录
查看图1，了解Simpson的记录在哪里，不仅可以告诉您地址和电话号码。 您也知道他们位于斯普林菲尔德镇的东端。 这种结构称为树。 在这里，树的根是Springfield对象，各种对象表示分支的进一步级别。
这种基于目录的数据存储方法与您可能熟悉的关系数据库完全不同。 为了比较这两种模型，图2显示了将其建模为关系数据库时电话数据的外观。
图2.以关系形式建模的目录数据
在关系模型中，每种数据类型都是一个单独的表，该表允许保存不同类型的信息。 每个表还具有指向其父表的链接，以便可以保留对象之间的关系。 请注意，必须更改表以添加更多信息字段。
请记住，关于目录模型的任何内容都对如何将数据存储在磁盘上没有任何限制。 实际上，OpenLDAP支持许多后端，包括平面文件和结构化查询语言（SQL）数据库。 在磁盘上布置表的机制在很大程度上对您而言是隐藏的。 例如，Active Directory向其专有后端提供LDAP接口。
LDAP的历史
LDAP在请求注释（RFC）1487中被认为是一种轻巧的方法来访问X.500目录，而不是更复杂的目录访问协议。 （请参阅“ 相关主题”部分，以获取到此RFC和相关RFC的链接。）X.500是国际电信联盟（ITU，前身为CCITT）制定的标准（以及一系列标准），用于指定如何实现目录。 您可能熟悉X.509标准，该标准构成了大多数公钥基础结构（PKI）和安全套接字层（SSL）证书的核心。 LDAP从那时起已发展到版本3，并在RFC 4511中定义。
最初，连接到X.500数据库需要使用开放系统互连（OSI）协议套件，并且必须以真正的ITU方式来理解大量的协议文档。 LDAP允许基于Internet协议（IP）的网络以比OSI协议少得多的开发周期连接到同一目录。 最终，IP网络的普及导致创建了仅支持必要的X.500概念的LDAP服务器。
尽管LDAP和IP战胜了X.500和OSI，但目录数据的基础组织仍然是X.500-ish。 您将在本教程中学习的概念（如专有名称和对象标识符）从X.500中提出。
X.500旨在作为一种创建全局目录系统的方法，主要用于协助X.400系列电子邮件标准。 可以将LDAP用作全局目录，但是它通常在企业内部使用。
仔细看看命名和属性
在LDAP世界中，名称很重要。 通过名称可以访问和搜索记录，并且名称通常可以指示记录在LDAP树中的位置。 图3显示了典型的LDAP树。
图3.显示用户的典型LDAP树
在树的顶部（即根）是一个名为dc=ertw,dc=com的实体。 dc是域组件的缩写。 由于ertw在.com顶级域下，因此两者被分为两个不同的单元。 使用X.500命名法时，名称的组成部分以逗号连接，新的组成部分被添加到左侧。 从技术上讲，没有什么可以阻止您将根称为dc=ertw.com ，尽管为了将来的互操作性，最好将域组件分开（实际上，RFC 2247建议使用单独的域组件）。
dc=ertw,dc=com是一种在树中唯一标识该实体的方法。 在X.500中，这称为专有名称或DN 。 DN很像关系数据库世界中的主键，因为树中只能有一个具有给定DN的实体。 最顶层条目的DN称为Root DN 。
在根DN下是DN为ou=people,dc=ertw,dc=com 。 ou表示组织单位 ，您可以确定它属于根DN，因为ou立即出现在根DN的左侧。 您也可以将ou=people称为相对专有名称 ，即RDN ，因为它在其级别内是唯一的。 用递归的术语来说，实体的DN是实体的RDN加上父实体的DN。 大多数LDAP浏览器仅显示RDN，因为它消除了冗余。
在树上向下移动到cn=Sean Walberg,ou=people,dc=ertw,dc=com ，您将找到一个人的记录。 cn表示通用名称 。 但是，记录第一次以属性的形式具有一些附加信息。 属性提供有关实体的其他信息。 实际上，您将看到DN的最左侧部分已重复； 在这种情况下，它是cn属性。 换句话说，实体的RDN由该实体的一个（或多个）属性组成。
尽管mail和description很容易理解，但objectClass却不那么明显。 对象类是一组与特定实体类型相对应的属性。 一个对象类可能包含人员的属性，而另一个则包含UNIX帐户的属性。 通过将两个对象类应用于实体，可以存储两组属性。
每个对象类都分配有一个唯一标识它的对象标识符（OID）。 对象类还指定属性，哪些是必需的，哪些是可选的。 强制属性必须具有一些数据才能保存实体。 对象类还标识保存的数据类型以及是否允许使用相同名称的多个属性。 例如，一个人可能只有一个员工编号，但有多个名字（例如，Bob，Robert和Rob）。
并非只有底层对象具有与之关联的对象类。 这些称为容器的对象也具有对象类和属性。 people ou的类型为organizationalUnit并具有描述属性以及ou=people来创建RDN。 树的根类型为dcObject和organization 。 知道要分配对象的对象类取决于对象中及其下所包含的内容。 有关更多详细信息，请参考“架构”部分。
根DN也定义树的名称空间 ，或者更详细地说，是目录信息树 （DIT）。 以dc=ibm,dc=com结尾的内容将落在图3的名称空间之外，而Sean Walberg的记录则在名称空间内。 不过，考虑到这一点，一台LDAP服务器可能包含多个名称空间。 有点抽象的项目称为Root DSE，其中包含有关服务器上所有可用名称空间的信息。 DSE表示特定于DSA的条目，DSA表示目录系统代理（即LDAP服务器）。
图4总结了与LDAP树相关的术语。
图4. LDAP术语摘要
最后，LDAP树可以与其他树或数据源同步。 例如，树的一个分支可能来自安全系统，另一分支可能来自客户数据库，其余的可以存储在LDAP服务器中。 这称为元目录 ，旨在成为应用程序（如单点登录）的单一数据源。
LDIF文件
数据可以通过以下两种方式之一进入LDAP服务器。 可以使用LDAP协议通过网络将其加载，也可以通过LDAP数据交换格式 （LDIF）的文件从服务器导入它。 LDIF可以随时使用，例如创建初始树，并在以后的某个时间执行批量添加或修改数据。 搜索的输出也可以在LDIF中，以方便解析或导入到另一台服务器。 为LDIF的完整规范在RFC 2849（见相关信息中的链接）。
添加记录
清单1显示了从图3生成树的LDIF。
清单1.一个简单的LDIF文件填充一棵树
# This is a comment
dn: dc=ertw,dc=com
dc: ertw
description: This is my company
the description continues on the next line
indented by one space
objectClass: dcObject
objectClass: organization
o: ERTW.COM
dn: ou=people,dc=ertw,dc=com
ou: people
description: Container for users
objectclass: organizationalunit
dn: cn=Sean Walberg,ou=people,dc=ertw,dc=com
objectclass: inetOrgPerson
cn: Sean Walberg
cn: Sean A. Walberg
sn: Walberg
homephone: 555-111-2222
mail: sean@ertw.com
description: Watch out for this guy
ou: Engineering 在深入研究LDIF文件的细节之前，请注意属性名称不区分大小写。 也就是说， objectclass与objectClass和OBJECTCLASS相同。 许多人选择大写每个单词的第一个字母（首字母除外），例如objectClass ， homePhone和thisIsAReallyLongAttribute 。
LDIF的第一行显示UNIX样式的注释，该注释的前缀是井号（＃），也称为井号或八字形。 LDIF是标准的ASCII文件，可以由人类编辑，因此注释可能会有所帮助。 但是，LDAP服务器将忽略注释。
LDIF文件中的记录用空白行分隔，并包含用冒号（:)分隔的属性和值的列表。 记录以dn属性开头，该属性标识记录的专有名称。 因此， 图1显示了三个记录：分别为dc=ertw ， ou=people和cn=Sean Walberg RDN。
回顾图1 ，您可以看到定义的第一个记录是树的根。 专有名称优先。 接下来是所有属性和值的列表，以冒号分隔。 价值内的冒号不需要任何特殊处理。 LDAP工具了解第一个冒号将属性与值分开。 如果您需要为一个属性定义两个值，则只需将它们作为两行分开列出即可。 例如，根对象定义了两个对象类。
每条记录必须定义至少一个对象类。 反过来，对象类可能要求存在某些属性。 对于根对象， dcObject对象类要求定义一个域组件 dc ，而organization对象类要求定义一个组织属性o 。 由于对象必须具有与RDN相对应的属性和值，因此需要dcObject对象类来导入dc属性。 创建有效记录不需要定义o属性。
甲description还用于根对象上描述该公司。 这里的目的是演示注释格式。 如果您的值需要跨越多行，请在每个新行的开头加一个空格而不是一个值。 请记住，指定多个attribute: value对定义了该属性的多个实例。
图1中的第二条记录定义了organizationalUnit ，在这种情况下，它是用于人员对象的容器。 第三个定义了inetOrgPerson类型的用户，该用户提供了用于定义组织内人员的通用属性。 注意，定义了两个cn属性。 记录的DN中也使用了一个。 第二个带有中间的首字母，将有助于搜索，但它是满足定义RDN的条件所需要的第一个。
在用户记录中，还存在一个与用户所在的organizationalUnit不对应的ou 。始终可以通过解析DN来找到用户对象所属的容器。 此ou属性指的是用户（在本例中为部门）定义的内容。 尽管应用程序可能正在寻找有效的DN，例如ou=Engineering,ou=Groups,dc=ertw,dc=com ，但服务器没有强加参照完整性。
LDIF文件上添加记录的唯一其他限制是必须从根开始按顺序构建树。 图1显示了正在构建的根对象，然后是ou ，然后是该ou的用户。 现在已经构建了结构，可以将用户直接添加到people容器，但是如果要使用新的容器，则必须首先创建它。
添加对象背后的LDIF非常容易。 当必须更改或删除对象时，格式变得更加复杂。 LDIF定义了一个changetype ，它可以是以下之一：
-
add添加一个项目（默认）。 -
delete删除DN指定的项目。 -
modrdn重命名当前容器中的指定对象，或将对象移至树的另一部分。 -
moddn是modrdn同义词。 -
modify对当前DN中的属性进行更改。
删除用户
删除项目是最简单的情况，只需要dn和changetype 。 清单2显示了一个被删除的用户。
清单2.使用LDIF删除用户
dn: cn=Fred Smith,ou=people,dc=ertw,dc=com
changetype: delete操作DN
操作对象的DN稍微复杂一些。 尽管有两个命令moddn和modrdn ，但它们执行相同的操作！ 该操作包括三个单独的部分：
- 指定新的RDN（DN最左侧的组件）。
- 确定是在记录中用新的RDN替换旧的RDN，还是将其保留。
- （可选）通过指定新的父DN将记录移到树的新部分。
考虑一下简史密斯（Jane Smith），她将她的名字改成了简·多伊（Jane Doe）。 首先要做的是更改其cn属性以反映名称更改。 因为新名称是她希望被引用的主要方式，并且通用名称构成DN的一部分，所以moddn操作是适当的。 （如果通用名是不是DN的组成部分，这将是一个属性的变化，这是覆盖在下一节。）第二种选择是，以确定是否cn: Jane Smith应该留在除cn: Jane Doe ，这使人们可以使用任一名称搜索她。 清单3显示了执行更改的LDIF。
清单3.更改用户的RDN的LDIF
# Specify the record to operate on
dn: cn=Jane Smith,ou=people,dc=ertw,dc=com
changetype: moddn
# Specify the new RDN, including the attribute
newrdn: cn=Jane Doe
# Should the old RDN (cn=Jane Smith) be deleted? 1/0, Default = 1 (yes)
deleteoldrdn: 0 清单3首先确定Jane的记录，然后是moddn运算符。 指定了新的RDN，继续使用通用名称类型，但使用新名称。 最后， deleteoldrdn指示服务器保留旧名称。 请注意，尽管newrdn是moddn更改类型的唯一必需选项，但是如果省略deleteoldrdn ，则操作是删除旧的RDN。 根据RFC 2849， deleteoldrdn是必需元素。
如果将新的Jane Doe夫人发送到树的新部分，例如移至ou=managers,dc=ertw,dc=com ，则LDIF必须以某种方式指定树的新部分，如清单1所示。 4。
清单4.将记录移动到树的新部分
dn: cn=Jane Doe,ou=people,dc=ertw,dc=com
changetype: modrdn
newrdn: cn=Jane Doe
deleteoldrdn: 0
newsuperior: ou=managers,dc=ertw,dc=com 奇怪的是，即使新的RDN与旧的RDN相同，也必须指定它，并且OpenLDAP解析器现在要求存在deleteoldrdn ，尽管当RDN保持不变时它毫无意义。 newsuperior是newsuperior ，它是树中新父代的DN。
关于modrdn操作的最后一点是，顺序很重要，这与大多数其他LDIF格式不同。 changetype是newrdn ，然后是deleteoldrdn ，还可以是newsuperior 。
修改属性
最后changetype是modify ，这是用来修改记录的属性。 根据前面对moddn讨论，应该清楚的是， modify不适用于记录的DN或RDN。
清单5显示了对单个记录的几种修改。
清单5.通过LDIF修改记录
dn: cn=Sean Walberg,dc=ertw,dc=com
changetype: modify
replace: homePhone
homePhone: 555-222-3333
-
changetype: modify
add: title
title: network guy
-
changetype: modify
delete: mail
- modify操作的LDIF看起来与其他类似。 它从记录的DN开始，然后是changetype 。 之后是replace: ， add:或delete:然后是属性。 对于delete ，这是足够的信息。 其他则需要attribute：value对。 每次更改后，在空白行上都包含破折号（-），包括最终更改。
LDIF具有易于阅读的格式，适用于人类和计算机。 对于批量导入和导出数据，LDIF是有用的工具。
目录设计
本部分介绍了高级Linux专业人员（LPIC-3）考试301的主题301.2的材料。该主题的权重为2。
在本节中，了解以下内容：
- 定义LDAP目录内容
- 目录组织
- 如何计划适当的目录信息树
确定LDAP是否合适
像任何其他工具一样，LDAP并非适用于每种解决方案。 选择LDAP之前，您必须问自己一些问题：
- 多久进行一次更改，这些更改是什么？
- 什么将使用数据？
- 将对数据进行哪种查询？
- 信息本质上是分层的吗？
LDAP数据库适合于读取密集型操作。 人们每年可能只更改几次个人信息，但是我们可以期望查找的属性远远超过该属性，例如在浏览目录时将拥有文件的UserID解析为可打印的名称。 LDAP数据倾向于建立大量索引，这意味着对基础数据的每次更改都需要对索引进行多次更改，以帮助服务器稍后查找数据。 LDAP除了执行搜索然后修改每个DN之外，还没有提供对树进行大量更新的方法。
LDAP规范没有定义事务，这在关系数据库中很常见。 事务确保事务内的所有操作都成功，否则数据将回滚到事务前状态（单个服务器可以实现此目的，但这不是必需的）。 这些对更新数据的限制以及缺少事务使LDAP对于银行事务来说是一个糟糕的选择。
确定数据的用户或使用者也很重要。 如果没有一个消费者使用LDAP，那么LDAP可能不是一个合适的选择。 值得称赞的是，它是一种非常简单的协议，在大多数平台上适用于大多数语言。 仅定义了少量可用操作，便可以轻松将其集成到现有应用程序中。
LDAP提供了搜索功能，但是没有关系数据库的水平。 LDAP服务器可以使用SQL存储基础数据，但是您作为用户是从中抽象出来的，因此无法使用它。 因此，您仅限于LDAP服务器支持的搜索过滤器。 在本系列的后续文章中将对这些过滤器进行更详细的研究，但现在了解到这些过滤器就是这些过滤器。 您可以执行一些有力的搜索，例如“向我显示居住在华盛顿的所有员工和居住在德克萨斯州的40岁以上的员工”。 但是，等效于SQL GROUP BY语句不可用。 LDAP最适合于查找样式的操作，例如“向我显示UID 4131用户的用户名”和“给我为Jim Smith工作的每个人的名字”。
最后，您要存储的信息应该适合于分层存储。 您可以在LDAP服务器中存储平面数据列表，但这可能会浪费资源。
当您可以回答这些问题并确定LDAP是正确的解决方案时，就该设计目录树了。
整理你的树
要记住的最重要的想法是重组树是不可取的。 目标是分解对象，以使树的每个分支都包含相似类型的对象，但是必须移动对象的机会很小。 原因有两个。 一个是做起来很麻烦。 第二个是移动将更改对象的DN，然后您必须更新所有引用已移动对象的对象。
根DN
树的根应该代表公司。 RFC 2247要求使用dc属性和熟悉的dc=example,dc=com格式将公司的主域映射到DN。 您的公司可能有许多Internet域，但是有一个首选域。 在local顶级域（TLD）下选择某些内容也是很常见的，而该域当前不在Internet上。 Microsoft长期以来一直建议将此TLD用于其Active Directory实现，尽管它不是保留的TLD。
如果您不想在根DN中使用域名，则可以简单地使用objectclass: organization ，其根DN为o=My Corporation 。
填写结构
决定在DIT的下一个级别上做什么是困难的。 通常将公司的组织结构描述为一系列嵌套的organizationalUnit对象很诱人，但是公司不断进行重组，这违反了第一条规则。 而是考虑使用属性来存储此信息。
根据您对LDAP服务器的使用以及选择命名对象的方式，您可能希望将所有用户保留在一棵树中或根据角色将它们分开。 例如，您可以为员工创建一个容器，为客户创建一个容器，也可以将它们全部分组到一个容器中。 选择取决于您的应用程序以及您计划如何管理树。 如果销售部门负责管理客户清单，而系统管理员负责工作人员，则最好创建两个容器。 图5显示了已细分为客户和用户的DIT。
图5. LDAP树，为用户和客户提供单独的分支
图5显示了一个针对员工的分组和一个针对客户的分组。 所有员工都住在同一个组织单位（OU）中，但是按地区将客户分类。 在这种情况下，这使不同的人可以管理自己区域的客户。
如果计划使用LDAP对UNIX资源进行身份验证，则必须决定将信息存储在何处。 用户帐户已在前面讨论过，但是您将需要存储组，还可能需要存储其他映射，例如主机，服务，网络和别名。 哪些存储在LDAP中，哪些存储在本地文件中取决于您以及是否需要能够集中更新它们。
最简单的情况是将每个地图存储在单独的organizationalUnit 。 您会发现，将UNIX系统配置为读取此信息时，需要指定容器的DN和所有过滤器。 如果将组存储在用户OU中，则必须编写一些过滤器。 如果您对人员OU进行了任何结构更改，则可能还需要调整过滤器。
确定对象类别
到目前为止，讨论集中在LDAP树的布局上，其基本目标是避免将来不得不重命名对象。 确定树之后，必须确定要使用的对象类。 当然可以为树的同一分支下的对象分配不同的对象类，但这几乎肯定会导致将来的维护问题。
为了给情况增加更多的压力，如果您犯了错误，并非总是可以向对象添加更多的对象类。 LDAP模式定义了两种类型的对象类： 结构类和辅助类。 结构对象类通常从链中的其他对象类继承属性，这些属性最终以称为top的对象类结尾。 可以说结构对象类定义了对象的标识，而辅助对象类则用于添加属性。 organizationalUnit是结构对象类， inetOrgPerson 。 回到清单1 ，顶层条目有两个对象类： dcObject和organization 。 organization是结构对象类。 dcObject通过定义dc属性起到辅助作用
。
可能引起问题的部分是，一个条目只能具有一个结构对象类。 有时，您会在同一记录中看到inetOrgPerson ， organizationalPerson ， person和top ，但是它们都是同一继承树的一部分。 inetOrgPerson和account都是结构化的，不在同一个继承树中，因此不能一起使用。 某些LDAP服务器允许这样做，但最终此行为可能会更改并引起问题。
第三种对象类称为abstract 。 它非常类似于结构化，只是必须继承才能使用。 top是这样的一类。
在不涉及每个应用程序细节的情况下，有一些有用的常规结构对象类：
-
inetOrgPerson：定义普通人以及一些联系信息。 -
organizationalRole：非常类似于一个人，但是它定义了一个通用角色，例如IT Helpdesk或Fire Warden。 -
organizationalUnit：通用容器，可以描述容器中的部门，也可以用于分隔LDAP树的各个部分，例如组，人员和服务器 -
organization：公司或其他组织。 -
groupOfNames：存储引用一个组成员的一个或多个DN。 Not necessarily useful for UNIX groups, but helpful for meeting invitations or other simple things.
Stick to these for your people and organizations and you will be safe. Most extensions, such as authentication, use auxiliary attributes. When in doubt, consult the schema.
The final design consideration is the choice of DNs. Most branches are fairly easy because there is no chance of duplication. A UNIX group's name and ID is unique, so using cn as the RDN of a group is possible. What happens when you have two employees called Fred Smith? Because the DN must be unique, cn=Fred Smith,ou=People,dc=example,dc=com could be either of them. Either something else must be used, such as employeeNumber , or the RDN will have to be made from two different attributes separated by a plus sign (+). For example, cn=Fred Smith+userid=123, ou=people, dc=example, dc=com has an RDN made from two different attributes. Whatever you do, do it consistently!
模式
This section covers material for topic 301.3 for the Senior Level Linux Professional (LPIC-3) exam 301. The topic has a weight of 3.
In this section, learn about:
- LDAP schema concepts
- How to create and modify schemas
- Attribute and object class syntax
Up until now, the schema has been mentioned several times but not fully explained. The schema is a collection of object classes and their attributes. A schema file contains one or more object classes and attributes in a text format the LDAP server can understand. You import the schema file into your LDAP server's configuration, and then use the object classes and attributes in your objects. If the available schemas don't fit your needs, you can create your own or extend an existing one.
LDAP schema concepts
Technically, a schema is a packaging mechanism for object classes and attributes. However, the grouping of object classes is not random. Schemas are generally organized along an application, such as a core, X.500 compatibility, UNIX network services, sendmail, and so on. If you have a need to integrate an application with LDAP, you generally have to add a schema to your LDAP server.
A more in-depth look at OpenLDAP configuration will be in a later tutorial in this series, but the way to add a schema is with include /path/to/file.schema . After restarting the server, the new schema will be available.
When the schema is loaded, you then apply the new object classes to the relevant objects. This can be done through an LDIF file or through the LDAP application program interface (API). Applying the object classes gives you more attributes to use.
Creating and modifying schemas
Schemas have a fairly simple format. Listing 6 shows the schema for the inetOrgPerson object class along with some of its attributes.
Listing 6. Part of the inetOrgPerson definition
attributetype ( 2.16.840.1.113730.3.1.241
NAME 'displayName'
DESC 'RFC2798: preferred name to be used when displaying entries'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
attributetype ( 0.9.2342.19200300.100.1.60
NAME 'jpegPhoto'
DESC 'RFC2798: a JPEG image'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )
objectclass ( 2.16.840.1.113730.3.2.2
NAME 'inetOrgPerson'
DESC 'RFC2798: Internet Organizational Person'
SUP organizationalPerson
STRUCTURAL
MAY (
audio $ businessCategory $ carLicense $ departmentNumber $
displayName $ employeeNumber $ employeeType $ givenName $
homePhone $ homePostalAddress $ initials $ jpegPhoto $
labeledURI $ mail $ manager $ mobile $ o $ pager $
photo $ roomNumber $ secretary $ uid $ userCertificate $
x500uniqueIdentifier $ preferredLanguage $
userSMIMECertificate $ userPKCS12 )
) Line spacing is not important in schema files -- it is mostly there for human readability. The first definition is an attributetype , which means an attribute. The parentheses enclose the definition of the attribute. First comes a series of numbers, separated by periods, called the object ID , or OID, which is a globally unique number. The OID is also hierarchical, such that if you're assigned the 1.1 tree, you can create anything like 1.1.1 or 1.1.2.3.4.5.6 without having to register it.
Following the OID is a series of keywords, each of which may have a value after it. First the NAME of the attribute defines the name that humans will use, such as in the LDIF file or when retrieving the information through the LDAP API. Sometimes you might see the name in the form of NAME ( 'foo' 'bar' ) , which means that either foo or bar are acceptable. The server, however, considers the first to be the primary name of the attribute.
DESC provides a description of the attribute. This helps you understand the attribute if you're browsing the schema file. EQUALITY , SUBSTR , and ORDERING (not shown) require a matching rule . This defines how strings are compared, searched, and sorted, respectively. caseIgnoreMatch is a case-insensitive match, and caseIgnoreSubstringsMatch is also case insensitive. See the Related topics section for Web sites that define all the standard matching rules. Like most things in LDAP, a server can define its own matching methods for its own attributes, so there are no comprehensive lists of matching rules.
The SYNTAX of the attribute defines the format of the data by referencing an OID. RFC 2252 lists the standard syntaxes and their OIDs. If the OID is immediately followed by a number in curly braces ({}), this represents the maximum length of the data. 1.3.6.1.4.1.1466.115.121.1.15 represents a DirectoryString that is a UTF-8 string.
Finally, the SINGLE-VALUE keyword has no arguments and specifies that only one instance of displayName is allowed.
The jpegPhoto attribute has a very short definition: just the OID, the name and description, and a syntax meaning a JPEG object, which is an encoded string of the binary data. It is not practical to search or sort a picture, and multiple photos can exist in a single record.
Defining an object class follows a similar method. The objectclass keyword starts the definition, followed by parentheses, the OID of the object class, and then the definitions. NAME and DESC are the same as before. SUP defines a superior object class, which is another way of saying that the object class being defined inherits from the object class specified by the SUP keyword. Thus, an inetOrgPerson carries the attributes of an organizationalPerson .
The STRUCTURAL keyword defines this as a structural object class, which can be considered the primary type of the object. Other options are AUXILIARY , which adds attributes to an existing object, and ABSTRACT , which is the same as structural but cannot be used directly. Abstract object classes must be inherited by another object class, which can then be used. The top object class is abstract. It is inherited by most other structural object classes, including person , which is the parent of organizationalPerson , which, in turn, is inherited by inetOrgPerson .
Two keywords, MAY and MUST , define the attributes that are allowed and mandatory, respectively, for records using that particular object class. For mandatory items, you may not save a record without all the items being defined. Each attribute is separated by a dollar sign ($), even if the line continues on the next line.
It is not a good idea to modify structural object classes, or even existing, well-known, auxiliary object classes. Because these are well known, you may cause incompatibility issues in the future if your server is different. Usually the best solution is to define your own auxiliary object class, create a local schema, and apply it to your records. For instance, if you are a university and want to store student attributes, you might consider creating a student object class that is inherited from either organizationalPerson or inetOrgPerson and adding your own attributes. You could then create auxiliary object classes to add more attributes such as class schedules.
Understanding which schemas to use
After learning about how schemas are created, it is tempting to start fresh -- to create your own schema based on your environment. This would certainly take care of your present needs, but it could quite possibly make things more difficult in the long run as you add more functionality to your LDAP tree and integrate other systems. The best approach is to stick with standard object classes and attributes when you can and extend when you must.
OpenLDAP usually stores its schema files in /etc/openldap/schema, in files with a .schema extension. Table 3 lists the default schemas along with their purposes.
Table 3. Schemas that ship with OpenLDAP
| File name | 目的 |
|---|---|
| corba.schema | Defines some object classes and attributes for handling Common Object Request Broker Architecture (CORBA) object references across multiple machines. |
| core.schema | Defines many common attributes and object classes. This schema is where you will find the organizationalUnit , top , dcObject , and organizationalRole . core.schema is the first place you should look if you need to find something. |
| cosine.schema | Attributes and object classes from the X.500 specifications. While there are some useful things in here, there are often better alternatives in others such as core and inetorgperson. |
| dyngroup.schema | An experimental set of objects used with Netscape Enterprise Server. |
| inetorgperson.schema | Defines the inetOrgPerson object (which extends objects from core.schema). |
| java.schema | Like corba.schema, this schema defines a series of object classes and attributes to handle the lookup of Java™ classes within an LDAP tree. |
| misc.schema | Implements some objects to handle mail lookups within the tree. It is best to consult your e-mail server's documentation to see which schema it uses. |
| nis.schema | This is the schema you use if you move authentication to LDAP. nis.schema defines posixAccount , which provides attributes for storing authentication data within the user's object. It also has the various map types to handle groups, networks, services, and other files that go into network-based authentication mechanisms such as the Network Information System (NIS). |
| openldap.schema | This is more for example purposes and shows some basic objects. |
| ppolicy.schema | A set of objects to implement password policies in LDAP, such as aging. Note that some of these are handled by the traditional UNIX shadow mechanisms and are already handled in nis.schema. |
In addition, RFC 4519 explains common attributes. After finding the attributes you want, you can then look through the schema files to determine which files need to be included in your LDAP configuration and which object classes you must use for your records.
摘要
In this tutorial you learned about LDAP concepts, architecture, and design. LDAP grew out of a need to connect to X.500 directories over IP in a simplified way. A directory presents data to you in a hierarchical manner, much like a tree. Within this tree are records that are identified by a distinguished name and have many attribute-value pairs, including one or more object classes that determine what data can be stored in the record.
LDAP itself refers to the protocol used to search and modify the tree. Practically though, the term LDAP is used for all components, such as LDAP server, LDAP data, or just "It's in LDAP".
Data in LDAP is often imported and exported with LDIF, which is a textual representation of the data. An LDIF file specifies a changetype , such as add , delete , modrdn , moddn , and modify . These operations let you add entries, delete entries, move data around in the tree, and change attributes of the data.
Designing the tree correctly is crucial to long-term viability of the LDAP server. A correct design means fewer change operations are needed, which leads to consistent data that can easily be found by other applications. By choosing common attributes, you ensure that other consumers of the LDAP data understand the meaning of the attributes and that fewer translations are required.
The LDAP schema dictates which attributes can be used in your server. Within the schema are definitions of the attributes, including OIDs to uniquely identify them, instructions on how to store and sort the data, and textual descriptions of what the attributes do. Object classes group attributes together and can be defined as structural, auxiliary, or abstract.
Structural object classes define the record, so a record may only have one structural object class. Auxiliary object classes add more attributes for specific purposes and can be added to any record. An abstract object class must be inherited and cannot be used directly.
翻译自: https://www.ibm.com/developerworks/linux/tutorials/l-lpic3301/index.html
软件体系结构概念视图
1653
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
