3.4. 自定义模式


您可以通过添加属性和对象类,在 Directory Server 中使用 Web 控制台来扩展标准模式。您还可以创建 LDIF 文件并手动添加 schema 元素。

在自定义模式时,以下规则适用:

  • 您必须保持架构简单。
  • 您必须重复使用 schema 元素。
  • 您必须最小化为每个对象类定义的强制属性数量。
  • 不要为同一目的(数据)定义多个对象类或属性。
  • 不要修改属性或对象类的任何现有定义。
注意

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

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

当给定对象类无法存储机构的专用信息时,您可以扩展架构,而 Directory 服务器提供的对象类和属性应该满足最常见的企业需求。您还可以扩展架构,以支持支持支持支持支持支持支持支持 LDAP 应用的唯一数据需要的对象类和属性。

3.4.1. 分配对象标识符

您必须为每个 LDAP 对象类或属性分配唯一名称和 对象标识符 (OID)。当您定义架构时,元素需要您的机构的唯一基本 OID。添加另一个层次结构级别,以便为属性和对象类创建新分支。在 schema 中获取和分配 OID 涉及以下步骤:

  1. 从互联网分配号机构( IANA )或国家机构获取 OID。在某些国家/地区,公司已经为他们分配了 OID。
  2. 创建 OID registry 来跟踪 OID 分配。OID registry 是目录 schema 中使用的 OID 和描述的列表。这样可确保没有 OID 用于多个目的。然后使用 schema 发布 OID 注册表。
  3. 在 OID 树中创建分支以容纳 schema 元素。在 OID 分支或目录架构下至少创建两个分支,将 OID.1 用于属性,而 OID.2 用于对象类。根据需要添加新分支,以定义自定义匹配规则或控制(如 OID.'3)。

3.4.2. 定义新对象类的策略

您可以通过以下两种方式创建新对象类:

  • 创建新对象类,一个用于可以添加属性的每个对象类结构。
  • 创建一个对象类,它支持为目录创建的所有自定义属性。您可以通过将对象类定义为辅助对象类来创建此对象类。

您可以混合使用这两种方法。例如,您要创建属性 exampleDateOfBirth,examplePreferredOS,exampleBuildingFloor, 和 exampleVicePresident。简单的解决方案是创建多个对象类,允许其中的一些部分属性。

  • examplePerson 对象类允许 exampleDateOfBirthexamplePreferredOSexamplePerson 的父对象是 inetOrgPerson
  • exampleOrganization 对象类允许 示例BuildingFloorexampleViceP located。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) )
Copy to Clipboard Toggle word wrap

或者,您可以创建一个单一对象类来允许所有这些属性,并将其与需要它们的任何条目一起使用。单个对象类显示如下:

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) )
Copy to Clipboard Toggle word wrap

新的 exampleEntry 对象类标记为 AUXILIARY,这意味着它可用于任何条目,而不考虑其结构对象类。

您可以根据机构环境来组织新对象类。决定新对象类的实现时请考虑以下几点:

  • 如果架构中添加了超过两个或三个对象类,则必须使用单个对象类。
  • 多个对象类需要严格的数据设计。严格数据设计强制注意对象类结构,其中放置每个数据的对象类结构很有用或繁琐。
  • 当数据可应用于多个对象类(如人员和资产条目)时,您可以使用单个对象类使用数据。例如,您可以在个人和组条目上设置自定义 preferredOS 属性。单个对象类可以在这两类条目上允许此属性。
  • 您必须避免新对象类所需的属性。当您指定 require 而不是 允许 新对象类中的属性时,它可以使架构变得不灵活。在定义了新对象类后,决定其允许和需要哪些属性,以及它继承属性的对象类。

3.4.3. 定义新属性的策略

您必须将标准属性用于应用程序兼容性和长期维护。您必须搜索默认目录中已存在的属性,并将它们与新对象类一起使用,或检查 Directory Server 架构指南。但是,如果标准模式不包含所有必要的信息,请添加新的属性和新对象类。

例如,一个个人条目可能需要比个人、organizationalPersoninetOrgPerson 对象类默认支持更多的属性。标准目录服务器模式中没有属性来存储生日期。您可以在新的辅助对象类 examplePerson 中创建和设置新属性 dateOfBirth 作为允许的属性:

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')
Copy to Clipboard Toggle word wrap
注意

您不能在标准 schema 元素中添加或删除自定义属性。如果目录需要自定义属性,请添加自定义对象类使其包含它们。

3.4.4. 删除模式元素

您无法删除目录服务器中默认包含的 schema 元素。未使用的模式元素并不代表操作或管理开销。删除标准 LDAP 模式的部分,可能会导致与将来的 Directory Server 安装和其他启用了目录的应用程序的兼容性问题。

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

3.4.5. 创建自定义模式文件

除了 Directory Server 提供的 99user.ldif 文件外,您还可以为 Directory 服务器创建自定义架构文件。这些架构文件具有特定于组织的新自定义属性和对象类。新架构文件位于 schema 目录中,/etc/dirsrv/slapd-instance_name/schema/ 中。所有标准属性和对象类仅在加载自定义 schema 元素后加载。

注意

自定义架构文件不能以数字方式或字母顺序高于 99user.ldif

创建自定义模式文件后,模式更改可以通过以下方式分布到所有服务器中:

  • 您可以将这些自定义模式文件复制到实例的 schema 目录 /etc/dirsrv/slapd-instance/schema 并加载 schema,通过运行 schema-reload.pl 脚本来动态重新载入 schema。
  • 您可以使用 LDAP 客户端(如 Web 控制台)或使用 ldapmodify 命令修改服务器上的模式。
  • 使用复制时,所有复制模式元素都复制到使用者服务器 99user.ldif 文件中。要将架构保留在自定义架构文件中,如 90example_schema.ldif,必须手动将文件复制到消费者服务器。复制不会复制架构文件。

当您不将这些自定义模式文件复制到所有服务器时,只有在供应商服务器上的 schema 更改时,架构信息才会复制到消费者服务器中。当架构定义复制到尚不存在的消费者服务器时,它们会存储在 99user.ldif 文件中。

注意

目录无法跟踪存储架构定义的位置。如果只对供应商服务器维护 schema,您可以在消费者的 99user.ldif 文件中存储 schema 元素。

3.4.6. 自定义模式的最佳实践

以下建议可帮助您定义兼容和可管理的自定义模式。

命名架构文件

以数字方式命名自定义模式文件,按字母顺序低于 99user.ldif99user.ldif 文件包含 带有 X-ORIGIN 值 'user defined' 的属性。目录服务器将所有"用户定义的"模式元素写入最高命名的文件,然后按字母顺序将。如果架构文件的名称是 99zzz.ldif,并且更新了 schema,则所有 X-ORIGIN 值为 'user defined' 的属性都会写入 99zzz.ldif 文件。因此,包含两个包含重复信息的 LDIF 文件,以及 99zzz.ldif 文件中 的一些信息可能会被删除。

在命名自定义模式文件时,使用以下命名格式 :[00-99]yourName.ldif

使用 'user defined' 作为原始卷

不要在自定义模式文件的 X-ORIGIN 字段中使用 'user defined',如 60example.ldif,因为在通过 LDAP 添加架构时,目录服务器在内部使用 'user defined'。

如果自定义架构元素直接添加到 99user.ldif,则使用 'user defined' 作为 X-ORIGIN 的值。如果设置了不同的 X-ORIGIN 值,则服务器只需覆盖它即可。

使用值 'user defined' 的 X-ORIGIN 会阻止 Directory Server 删除 99user.ldif 文件中的 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')
Copy to Clipboard Toggle word wrap

目录服务器加载 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') )
Copy to Clipboard Toggle word wrap

在对象类前定义属性

当您添加新的 schema 元素时,请在对象类中使用所有属性前定义所有属性。属性和对象类可以在相同的架构文件中定义。

在单个文件中定义架构

在一个模式文件中定义每个自定义属性或对象类,以防止服务器在加载最近创建的模式时覆盖任何以前的定义。服务器首先以数字顺序加载模式,然后是字母顺序。决定如何在重复文件中保留模式:

  • 请注意每个架构文件中包括哪些 schema 元素。
  • 在命名和更新 schema 文件时要小心。通过 LDAP 工具编辑模式元素时,更改将按字母顺序自动写入最后一个文件。大多数架构更改都会写入默认的 99user.ldif 文件,而不是自定义模式文件,如 60example.ldif99user.ldif 文件中的 schema 元素覆盖其他模式文件中的重复元素。
  • 如果使用 Web 控制台管理架构,请将所有架构定义添加到 99user.ldif 文件中。
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat