第 12 章 管理目录架构

Red Hat Directory Server 附带了一个标准的模式，其中包括数百个对象类和属性。虽然标准对象类和属性应当满足大多数部署的要求，但可能需要扩展特定目录数据的模式。通过创建新对象类和属性来扩展架构。
Red Hat Directory Server 11 Configuration, Command, and File Reference 是大多数标准目录服务器属性和对象类的引用，包含允许和所需属性的信息，对象类采用哪个属性，以及 OID 和值信息。这是识别目录的有用模式元素的良好资源，并确定需要创建哪些自定义架构。

12.1. 架构概述

目录架构是一组规则，用于定义如何将数据存储在目录中。目录信息存储分散条目，每个条目由一组属性及其值组成。条目中描述的身份种类在条目的对象类中定义。对象类指定条目通过对象类定义的属性集合描述的对象类型。
在 LDAP 中，对象类定义可用于定义条目的属性集合。LDAP 标准为许多常用条目提供对象类，包括人员、组、位置、机构以及设备。身份在包含属性及其值的目录条目中描述，对名为 attribute-value assertions 或 AVAs。目录中的任何信息都与描述性属性关联。目录服务器配置的其他方面（包括匹配的规则和 LDAP 控制）也在架构中定义。所有这些组合在以前成为 schema 元素。
每个 schema 元素都由一个唯一、以点分开的数字来标识。这称为 对象标识符 或 OID。

12.1.1. 默认架构文件

目录服务器的 schema 在几个不同的架构文件中定义（LDIF 文件，它们定义 schema 元素。目录服务器模式文件位于 /usr/share/dirsrv/schema/ 目录中。此目录中的文件用作新目录服务器实例的模板。在此目录中添加新架构，使其可供任何新实例使用。
目录服务器用于执行操作和管理条目的属性介绍了红帽目录服务器 11 配置、命令和文件参考 中的其他配置设置。

12.1.2. 对象类

在 LDAP 中，对象类定义可用于定义条目的属性集合。LDAP 标准为许多常用条目提供对象类，例如人员 (person 和 inetOrgPerson)，组 (groupOfNames), 位置 (locality), 机构和部门 (organization 和 organizationalUnit), 以及设备 (device)。
在 schema 文件中，对象类由 对象类 行标识，后跟其 OID、名称、描述、其直接高级对象类（需要与对象类一起使用的对象类），并在此对象类共享其属性，以及允许(MUST)属性以及允许(MAY)属性。
这在 例 12.1 “人员对象类条目” 中显示。

例 12.1. 人员对象类条目

objectClasses: ( 2.5.6.6 NAME 'person' DESC 'Standard LDAP objectclass' SUP top MUST ( sn $ cn ) MAY ( description $ seeAlso $ telephoneNumber $ userPassword ) X-ORIGIN 'RFC 4519' )
每个对象类定义了多个所需的属性(schema 中的MUST 关键字)，以及允许的属性(schema 中的MAY 关键字)。使用指定对象类的条目中必须存在所需的属性，而允许的属性可以感知且可供使用，但不需要该条目有效。
如 例 12.1 “人员对象类条目” 一样，person 对象类需要 cn、sn 和 objectClass 属性，并允许 description,seeAlso,telephoneNumber, 和 userPassword 属性。
除了自己的必需和允许的属性外，对象类也可以继承另一类的属性。第二个对象类是第一个 对象类 的首选或 父 对象类。
例如，用户的条目必须具有 inetOrgPerson 对象类。在这种情况下，该条目还必须包括用于 inetOrgPerson, organizationalPerson 的超级对象类，以及用于 organizationalPerson 的超级对象类 person： 
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
对象类定义是 cn=schema 条目的 对象类 属性。objectclasses 属性的格式如下： 
objectclasses: ( definition )
对象类定义包含多个组件：
  • OID，通常是以点分开的数字
  • 唯一名称，格式为 NAME name
  • 描述，格式为 DESC 描述
  • 此对象类的正式或父对象类，格式为 SUP object_class; 如果没有相关的父项，请使用 SUP top
  • AUXILIARY 一词，它提供了对象类应用到的条目的类型； UXILILIARY 表示它可以应用到任何条目
  • 在 MUST; 之前包括所需属性的列表，若要包含多个属性，用括号括起组，并使用带有符号($)的属性分隔。
  • 允许的属性列表，前面带有 MAY; 以包含多个属性，用括号括起组，并使用符号($)分隔属性。
在使用命令行或 Web 控制台修改 cn=schema 条目时，客户对象类定义存储在 /etc/dirsrv/slapd-instance_name/schema/99user.ldif 中。

12.1.3. 属性

目录条目由属性及其值组成。这些对称为 attribute-value assertions 或 AVAs。目录中的任何信息都与描述性属性关联。例如，cn 属性用于存储个人的完整名称，如 cn: John Smith。
其它属性可以提供有关 John Smith 的更多信息： 
givenname: John
surname: Smith
mail: jsmith@example.com
在 schema 文件中，会通过以下方法描述属性：
  • OID
  • name
  • 语法匹配规则（可选）
  • 子字符串匹配规则（可选）
  • 排序规则（可选）
  • 描述（可选）
  • 语法
  • 单值或多值属性
  • 有关定义属性的位置的详情
这在 例 12.2 “uid 属性架构条目” 中显示。

例 12.2. uid 属性架构条目

( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' ) EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 4519' )

12.1.3.1. 目录服务器属性语法

属性的语法定义属性允许的值的格式；与其他架构元素一样，语法会使用架构文件条目中的语法为属性定义。
目录服务器使用属性的语法对条目执行排序和模式匹配。
有关 LDAP 属性语法的更多信息，请参阅 RFC 4517。
支持的 LDAP 属性语法包括在 Red Hat Directory Server 10 Configuration, Command, and File Reference 中的 Directory Server Attribute Syntaxes 部分。

12.1.4. 扩展架构

可将新的自定义属性和对象类添加到目录服务器实例中来扩展架构，并可以通过多种方式添加 schema 元素。使用 LDAP 工具向实例的默认自定义模式文件添加 schema 元素 99user.ldif。也可以创建新的独立架构文件，并将其包含在默认架构文件中。
添加新架构元素需要三项：
  1. 为新架构规划和定义 OID。服务器 OID 可以识别架构元素，因此 OID 是唯一的和组织非常重要。目录服务器本身不管理 OID，但 第 12.2 节 “管理对象标识符” 中描述了一些最佳实践。
  2. 创建新属性。属性定义需要名称、语法（允许的值格式）、OID 以及每个条目是否可以使用属性的描述。
  3. 创建一个对象类以包含新属性。对象类列出了该条目 type 和允许（可能）属性所需的属性。由于默认架构不应更改，如果创建了任何新属性，则应将它们添加到自定义对象类中。
应提前规划 schema 元素；请勿将多个属性用于相同的信息。尽可能使用标准目录服务器模式。目录服务器在默认架构文件中定义了数百个属性和对象类。红帽目录服务器 11 配置、命令和文件参考 列表并描述了标准属性和对象类；所有架构都可以在 /usr/share/dirsrv/schema/ 中的 schema 文件中查看。熟悉可用的模式；然后规划缺少哪些信息属性，以及如何用自定义属性填充这些差距。部署指南 中涵盖了规划架构。
警告
目录服务器中的默认对象类和属性基于 LDAP 和 X.500 标准和 RFC。使用标准架构使目录服务器更容易与其他应用程序和服务器集成，并允许与 LDAP 客户端、旧目录服务器实例和将来的发行版本互操作性。您无法编辑标准属性或更改对象类。
在自定义目录服务器模式时请记住以下规则：
  • 使架构尽可能简单。
  • 尽可能重复使用现有架构元素。
  • 尽可能减少为每个对象类定义的必要属性数量。
  • 不要为相同的目的定义多个对象类或属性。
  • 不要修改属性或对象类的任何现有定义。
注意
永不 删除或替换标准模式。这样做可能会导致与其他目录或其他 LDAP 客户端应用程序兼容性。
实例启动时，模式会加载到目录服务器实例中；任何新的架构文件都不会加载，直到 Directory 服务器重启或启动重新加载任务为止。实例的默认自定义模式文件 99user.ldif 作为最后一个模式文件加载。如果它包含标准架构文件中已存在的定义，则自定义定义将覆盖标准。

12.1.5. 模式复制

当目录架构在 cn=schema 子树中更新时，Directory 服务器会将更改存储在本地 /etc/dirsrv/slapd-instance_name/schema/99user.ldif 文件中，包括更改状态号(CSN)。更新的模式不会自动复制到其他副本。在复制树中更新目录的内容时，模式复制将开始。例如，如果您在修改 schema 后更新用户或组条目，供应商会将存储在 nsSchemaCSN 属性中的 CSN 与消费者上的 CSN 进行比较。如果远程 CSN 低于供应商中的一个，则 schema 将复制到消费者中。要成功复制，供应商上的所有对象类和属性类型都必须是消费者定义的超集。

例 12.3. 模式子集和超集

  • 在 server1 上，demo 对象类允许 a1、 a2 和 a3 属性。
  • 在 server2 上，demo 对象类允许 a1 和 a3 属性。
在 例 12.3 “模式子集和超集” 中，server1 上 demo 对象类的 schema 定义是 server2 上对象类的超集。在验证阶段，当复制或接受架构时，Directory 服务器会检索超级用户定义。例如，如果消费者检测到本地模式中的对象类允许比供应商模式中的对象类少属性，则更新本地架构。
如果成功复制架构定义，nsSchemaCSN 属性在两个服务器上都相同，且在复制会话开始时不再比较。
在以下情况下，schema 没有复制：
  • 一个主机上的 schema 是另一主机的 schema 的子集。
    例如，在 例 12.3 “模式子集和超集” 中，server2 上的 demo 对象类的架构定义是 server1 上对象类的子集。属性也可以发生子集（单值属性是多值属性的子集），属性语法(IA5 是 Octet_string的子集)。
  • 当供应商模式和消费者模式中的定义需要合并时。
    目录服务器不支持合并模式。例如，如果在一个服务器上的一个对象类允许 a1, a2, 和 a3 属性，在其他服务器上允许 a1, a3, 和 a4，schemas 不是子集且不能合并。
  • /etc/dirsrv/slapd-instance_name/schema/99user.ldif 以外的 Schema 文件被使用。
    目录服务器允许您在 /etc/dirsrv/slapd-instance_name/schema/ 目录中添加额外的模式文件。但是，只有 99user.ldif 文件中的 CSN 被更新。因此，其他架构文件仅在本地使用，不会自动传送到复制合作伙伴。手动将更新的模式文件复制到消费者并重新载入 schema。详情请查看 第 12.10 节 “动态重新加载架构”。
    为了避免重复的架构定义并启用自动复制，请将所有自定义模式存储在 /etc/dirsrv/slapd-instance_name/schema/99user.ldif 文件中。有关创建自定义模式文件的详情，请参考 第 12.9 节 “创建自定义架构文件”。