3.4. 自定义架构

PDF

如果标准模式对于目录需求太小，则可以进行扩展。Directory 服务器中的 Web 控制台可用于通过轻松添加属性和对象类来扩展 schema。也可以创建 LDIF 文件并手动添加 schema 元素。如需更多信息，请参阅 红帽目录服务器管理指南。

在自定义 Directory 服务器模式时请注意以下规则：

使架构尽可能简单。
尽可能重复使用现有的 schema 元素。
尽可能减少为每个对象类定义的必要属性数量。
不要为相同目的（数据）定义多个对象类或属性。
不要修改属性或对象类的任何现有定义。

注意

在自定义 schema 时，从删除或替换标准模式。这样做可能会导致与其他目录或其他 LDAP 客户端应用程序兼容性。

自定义对象类和属性在 99user.ldif 文件中定义。每个实例在 /etc/dirsrv/slapd-instance_name/schema/ 目录中维护自己的 99user.ldif 文件。也可以创建自定义模式文件，并将架构动态重新加载到服务器中。

3.4.1. 当扩展架构时

虽然 Directory 服务器提供的对象类和属性应该满足最常见的公司需求，但给定对象类可能无法存储有关机构的专门信息。此外，该架构可能需要扩展来支持启用了 LDAP 的应用的唯一数据需要的对象类和属性。

3.4.2. 获取和分配对象标识符

必须为每个 LDAP 对象类或属性分配一个唯一名称和 对象标识符 (OID)。当定义了 schema 时，元素需要一个基础 OID，它与您的机构是唯一的。个 OID 足以满足所有架构需求。只需添加另外一种层次结构级别，为属性和对象类创建新的分支。在 schema 中获取和分配 OID 涉及以下步骤：

从互联网编号分配机构(IANA)或国家组织获取 OID。
在某些国家/地区，公司已分配给他们的 OID。如果您的组织还没有 OID，可以从 IANA 获取。有关更多信息，请访问 IANA 网站 http://www.iana.org/cgi-bin/enterprise.pl。
创建 OID registry 以跟踪 OID 分配。
OID registry 是目录 schema 中使用的 OID 和描述的列表。这样可确保不使用 OID 用于多个目的。然后使用 schema 发布 OID 注册表。
在 OID 树中创建分支以容纳 schema 元素。
在 OID 分支或目录 schema 下至少创建两个分支，将 OID.1 用于属性，OID.2 用于对象类。要定义自定义匹配规则或控制，请根据需要添加新分支（例如OID.3）。

3.4.3. 命名属性和对象类

为新属性和对象类创建名称时，请尽可能有意义的名称。这样，可以更轻松地将架构用于 Directory 服务器管理员。

通过在所有 schema 元素上包含唯一前缀，避免架构元素和现有 schema 元素间的命名冲突。例如，Example Corp. 可能会在每个自定义 schema 元素前添加前缀示例。它们可能会添加一个名为 examplePerson 的特殊对象类，以识别其目录中的 Example Corp. employees。

3.4.4. 定义新对象类的策略

创建新对象类的方法有两种：

创建多个新对象类，每个对象类结构对应一个属性。
创建一个对象类，它支持为目录创建的所有自定义属性。这种对象类的方法是将它定义为辅助对象类。

这两种方法可能最容易。

例如，假设管理员希望创建属性 exampleDateOfBirth、examplePreferredOS、exampleBuildingFloor 和 exampleViceP 常处。简单的解决方案是创建多个对象类，允许其中的一些部分属性。

一个对象类( examplePerson )被创建，并允许 exampleDateOfBirth 和 examplePreferredOS。examplePerson 的父项是 inetOrgPerson。
第二个对象类 exampleOrganization 允许 exampleBuildingFloor 和 exampleViceP 常常。exampleOrganization 的父是机构对象类。

新对象类以 LDAPv3 模式格式显示，如下所示：

objectclasses: ( 2.16.840.1.117370.999.1.2.3 NAME 'examplePerson' DESC 'Example Person Object Class'
     SUP inetorgPerson MAY (exampleDateOfBirth $ examplePreferredOS) )

objectclasses: ( 2.16.840.1.117370.999.1.2.4 NAME 'exampleOrganization' DESC 'Organization Object Class'
     SUP organization MAY (exampleBuildingFloor $ exampleVicePresident) )

或者，创建一个允许所有这些属性的单一对象类，并将其与需要这些属性的任何条目一起使用。单个对象类如下所示：

objectclasses: (2.16.840.1.117370.999.1.2.5 NAME 'exampleEntry' DESC 'Standard Entry Object Class' SUP top
     AUXILIARY MAY (exampleDateOfBirth $ examplePreferredOS $ exampleBuildingFloor $ exampleVicePresident) )

新的 exampleEntry 对象类被标记为 AUXILIARY，这意味着它可以与任何条目一起使用，而不考虑其 structural 对象类。

注意

示例中的新对象类的 OID (2.16.840.1.117370)基于以前的 Netscape OID 前缀。要创建自定义对象类，请获取第 3.4.2 节 “获取和分配对象标识符” 所述的 OID。

根据组织环境，可以通过几种不同的方法来组织新对象类。在决定如何实施新对象类时请考虑以下几点：

多个对象类会导致更多架构元素来创建和维护。
通常，元素数量较小且需要较少的维护。但是，如果架构中增加了两个或多个对象类，那么使用单个对象类可能更易于使用。
多个对象类需要更小心、更严格的数据设计。
严格数据设计强制注意用于放置每个数据的对象类结构，这可能很有帮助或繁琐。
当数据被应用到多个对象类（如人员和资产条目）时，单一对象类简化了数据设计。
例如，可以在 person 和 group 条目上设置自定义 preferredOS 属性。单个对象类可以在这两类条目上允许此属性。
避免新对象类的必要属性。
指定 require 而不是 允许 新对象类中的属性，可能会导致 schema 不灵活。在创建新对象类时，请使用 allow 而不是 需要 尽可能多的内容。
定义新对象类后，决定其允许和需要哪些属性，以及它继承属性的对象类。

3.4.5. 定义新属性的策略

对于应用程序兼容性和长期维护，尽量尝试使用标准属性。搜索默认目录架构中已存在的属性，并使用它们与新对象类关联或签出 Directory Server Schema 指南。但是，如果标准模式不包含您需要的所有信息，则添加新的属性和新对象类。

例如，个人条目可能需要超过人员、机构管理员 或 inetOrgPerson 对象类支持的属性。例如，标准目录服务器架构中不存在任何属性来存储 birth 日期。可以创建新属性 dateOfBirth，并在新的辅助对象类 examplePerson 中设置为允许的属性。

attributetypes: ( dateofbirth-oid NAME 'dateofbirth' DESC 'For employee birthdays'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Example defined')

objectclasses: ( 2.16.840.1.117370.999.1.2.3 NAME 'examplePerson' DESC 'Example Person Object Class'
     SUP inetorgPerson MAY (exampleDateOfBirth $ cn) X-ORIGIN 'Example defined')

要记住的一个重要事项：从不添加或删除自定义属性到标准架构元素。如果目录需要自定义属性，请添加自定义对象类来包含它们。

3.4.6. 删除架构元素

不要删除 Directory Server 默认包含的架构元素。未使用的模式元素代表没有操作或管理开销。删除标准 LDAP 模式的部分可能会导致目录服务器和其他启用了目录的应用程序安装间的兼容性问题。

但是，未使用的自定义模式元素可以被删除。在从 schema 中删除对象类定义前，使用对象类修改每个条目。首先删除定义可能会阻止使用对象类的条目被修改。修改条目的 schema 检查也会失败，除非从条目中删除了未知对象类值。

3.4.7. 创建自定义架构文件

除了由 Directory Server 提供的 99user.ldif 文件外，管理员还可以为 Directory 服务器创建自定义架构文件。这些架构文件保存特定于组织的新自定义属性和对象类。新的模式文件应位于 schema 目录中，/etc/dirsrv/slapd-instance_name/schema/。

所有标准属性和对象类仅在加载自定义 schema 元素后加载。

注意

自定义架构文件不应以数字方式或字母顺序高于 99user.ldif，或者服务器可能会遇到问题。

在创建自定义模式文件后，可通过两种方式在所有服务器中分发架构更改：

手动将这些自定义模式文件复制到实例的 schema 目录 /etc/dirsrv/slapd-instance/schema。要载入架构，请通过运行 schema-reload.pl 脚本来动态重新加载模式。
使用 LDAP 客户端（如 Web 控制台或 ldapmodify ）修改服务器上的 schema。
如果服务器被复制，则允许复制过程将架构信息复制到每个使用者服务器。
通过复制，所有复制模式元素都复制到消费者服务器的 99user.ldif 文件中。要将架构保留在自定义模式文件中，如 90example_schema.ldif，必须手动将文件复制到消费者服务器。复制不会复制架构文件。

如果这些自定义模式文件没有复制到所有服务器，则当供应商服务器上的使用 LDAP 客户端（如 Web 控制台或 ldapmodify ）更改时，模式信息才会复制到副本（消费者服务器）。

当架构定义复制到不存在的消费者服务器时，它们存储在 99user.ldif 文件中。目录无法跟踪存储架构定义的位置。在消费者的 99user.ldif 文件中存储架构元素不会产生问题，只要该架构仅在供应商服务器上维护。

如果自定义架构文件被复制到每台服务器上，必须再次复制到每台服务器上更改架构文件。如果没有再次复制文件，则更改可能会复制并存储在消费者的 99user.ldif 文件中。在 99user.ldif 文件中进行了更改可能会导致架构管理困难，因为一些属性将出现在消费者上的两个独立模式文件中，一次在从供应商复制的原始自定义模式文件中，并在复制后再次出现在 99user.ldif 文件中。

有关复制模式的更多信息，请参阅第 7.4.4 节 “模式复制”。

3.4.8. 自定义架构最佳实践

使用架构文件时，请确保创建兼容且易于管理的 schema。

3.4.8.1. 命名架构文件

在命名自定义模式文件时，使用以下命名格式：

[00-99]yourName.ldif

将自定义架构文件命名为 lower （按字母和字母顺序）而不是 99user.ldif。这可让目录服务器通过 LDAP 工具和 Web 控制台写入 99user.ldif。

99user.ldif 文件包含 X-ORIGIN 值为 'user defined' 的属性；但是，目录服务器将所有"用户定义的"模式元素写入最高命名的文件，然后按字母顺序排列。如果存在一个名为 99zzz.ldif 的模式文件，下一次更新 schema 时（通过 LDAP 命令行工具或 Web 控制台）所有带有 X-ORIGIN 的值为 'user defined' 的属性都会写入 99zzz.ldif。结果是两个包含重复信息的 LDIF 文件，而 99zz.ldif 文件中的一些信息可能会被清除。

3.4.8.2. 使用"用户定义的"作为 Origin

不要在 自定义架构文件的 X-ORIGIN 字段中使用 'user defined' （如 60example.ldif），因为当通过 LDAP 添加模式时，目录服务器在内部使用 'user defined'。在自定义架构文件中，使用更多描述性，如 'Example Corp. defined'。

但是，如果自定义架构元素直接添加到 99user.ldif 中，请使用 'user defined' 作为 X-ORIGIN 的值。如果设置了不同的 X-ORIGIN 值，则服务器可能会覆盖它。

使用值 'user defined' 的 X-ORIGIN 可确保 99user.ldif 文件中的模式定义不会被 Directory 服务器从文件中删除。目录服务器不会删除它们，因为它依赖于值 'user defined' 的 X-ORIGIN 来告知它哪些元素应驻留在 99user.ldif 文件中。

例如：

attributetypes: ( exampleContact-oid NAME 'exampleContact'
DESC 'Example Corporate contact'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN 'Example defined')

在 Directory Server 加载 schema 条目后，它如下所示：

attributetypes: ( exampleContact-oid NAME 'exampleContact'
DESC 'Example Corporate contact'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN ('Example defined' 'user defined') )

3.4.8.3. 在对象类前定义属性

在添加新的架构元素时，需要定义所有属性，然后才能在对象类中使用它们。属性和对象类可以在相同的架构文件中定义。

3.4.8.4. 在单个文件中定义架构

每个自定义属性或对象类都应该只在一个 schema 文件中定义。这可防止服务器在加载最早创建的模式时覆盖任何以前的定义（因为服务器首先载入数字顺序，然后按字母顺序载入该 schema）。决定如何在重复的文件中保留 schema：

请注意每个架构文件中包括哪些 schema 元素。
在命名和更新模式文件中要小心。通过 LDAP 工具编辑模式元素时，更改会自动写入最后一个文件（通常）。大多数架构更改，然后写入默认文件 99user.ldif，而不是自定义架构文件，如 60example.ldif。另外，99user.ldif 中的架构元素会覆盖其他架构文件中的重复元素。
将所有架构定义添加到 99user.ldif 文件。这在通过 Web 控制台管理模式时很有用。