关于自定义模式

如果标准模式无法满足您的目录需求，则可以扩展标准模式。自定义模式时应遵循以下准则：

• 尽可能重新使用现有的模式元素。

• 尽可能减少为每个对象类定义的必需属性的数量。

• 不要针对同一用途定义多个对象类或属性。

• 使模式尽可能简单。

自定义模式时，不要修改、删除或替换标准模式中属性或对象类的任何现有定义。否则，可能会导致与其他目录和 LDAP 客户端应用程序的兼容性问题。

不要修改任何目录服务器内部操作属性。但是，您可以创建自己的操作变量以用于外部应用程序。

应始终定义对象类，而不要使用 objectClass: extensibleObject。目录服务器不会对具有对象类 extensibleObject 的条目执行模式检查，因此不会限制或检查该条目中存在的属性。目录服务器无法检测到应用程序中的拼写错误，例如，将 givenName 属性类型写成 giveName。此外，目录服务器还必须假定 extensibleObject 条目所有其他未定义的属性都是多值属性，并且使用区分大小写的字符串语法。而且，某些应用程序依赖于具有特定对象类的条目。通常，如果您的应用程序要求扩展对象类，请不要放弃模式管理，而应创建一个包含该应用程序所需属性的辅助对象类。

本部分包含有关默认目录模式以及创建自定义属性和对象类的信息。

默认目录服务器模式

instance-path/config/schema/ 目录中存储的一组文件对目录服务器随附的模式进行了介绍。

此目录包含目录服务器和相关产品的所有通用模式。LDAP v3 标准用户和组织模式位于 00core.ldif 文件中。此目录的早期版本所使用的配置模式位于 50ns-directory.ldif 文件中。

当服务器正在运行时，不要修改此目录中的文件。

对象标识符

必须为每个 LDAP 对象类或属性指定唯一的名称和对象标识符 (object identifier, OID)。定义模式时，您需要一个在组织中具有唯一性的 OID。一个 OID 即可满足您的所有模式需求。然后，您可以在该 OID 上为您的属性和对象类添加新的分支。

获取和指定模式中的 OID 时，您需要执行以下操作：

• 从互联网号码分配机构 (Internet Assigned Numbers Authority, IANA) 或国家组织为您的组织获取 OID。

  在某些国家/地区，已经为公司指定了 OID。如果您的组织还没有 OID，则可以从 IANA 获取 OID。

• 创建一个 OID 注册表，以便可以跟踪 OID 分配。

  OID 注册表是由您维护的列表，它提供目录模式中所使用的 OID 及 OID 描述。OLD 注册表可确保任何 OID 都不会用于多种用途。

• 在 OID 树中创建分支以容纳模式元素。

  在 OID 分支或目录模式下至少创建两个分支，OID.1 用于属性，OID.2 用于对象类。如果您要定义自己的匹配规则或控制，则可以根据需要添加新的分支（如 OID.3）。

命名属性和对象类

创建新属性和对象类的名称时，应使用有意义的名称，以使模式更易于使用。

通过在自定义元素上包含唯一的前缀，可以避免在自定义模式元素和现有模式元素之间出现命名冲突。例如，Example.com 公司可以在其每个自定义模式元素之前添加前缀 Example。它还可以添加一个名为 ExamplePerson 的特殊对象类，以便在目录中标识 Example.com 员工。

请注意，在 LDAP 中，属性类型名称和对象类名称区分大小写。应用程序应将其视为区分大小写的字符串。

定义新对象类

如果现有对象类不支持需要在目录条目中存储的所有信息，则可以添加新的对象类。

可以使用两种方法创建新对象类：

• 创建许多新对象类，分别用于要添加属性的每个对象类结构。

• 创建一个对象类，使其支持您为目录创建的所有属性。创建这种对象类的方法是将其定义为 AUXILIARY 对象类。

  假定您的站点要创建属性 ExampleDepartmentNumber 和 ExampleEmergencyPhoneNumber。您可以创建多个允许这些属性中的部分属性的对象类。可以创建一个名为 ExamplePerson 的对象类，并使其允许 ExampleDepartmentNumber 和 ExampleEmergencyPhoneNumber 属性。ExamplePerson 的父条目将是 inetOrgPerson。然后可以创建一个名为 ExampleOrganization 的对象类，并使其允许 ExampleDepartmentNumber 和 ExampleEmergencyPhoneNumber 属性。ExampleOrganization 的父条目将是 organization 对象类。

  新对象类将以 LDAP v3 模式格式显示，如下所示：

  objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.3 NAME 'ExamplePerson'
   DESC 'Example Person Object Class' SUP inetorgPerson STRUCTURAL MAY
   (ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) )
  objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.4 NAME
   'ExampleOrganization' DESC 'Example Organization Object Class' SUP
   organization STRUCTURAL MAY (ExampleDepartmentNumber
   $ ExampleEmergencyPhoneNumber) )

  或者，您还可以创建一个允许所有这些属性的对象类。然后，可以将此对象类用于要使用这些属性的任何条目。单个对象类将如下所示：

  objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.5 NAME 'ExampleEntry'
   DESC  'Example Auxiliary Object Class' SUP top  AUXILIARY MAY
   (ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) )

  新的 ExampleEntry 对象类被标记为 AUXILIARY，这意味着它可以用于任何条目，无论该条目的结构对象类如何。

确定如何实现新对象类时，请考虑以下事项。

• 多个 STRUCTURAL 对象类将导致需要创建和维护更多的模式元素。

  通常，元素的数量始终很少，并且几乎不需要维护。但是，如果您计划向模式中添加两个或三个以上的对象类，则使用单个对象类可能会更容易一些。

• 多个 STRUCTURAL 对象类要求在设计数据时更加仔细和严格。

  严格的数据设计将迫使您考虑放置每份数据的对象类结构。此限制可能很有用，但也可能带来麻烦。

• 如果要将数据放在多种类型的对象类结构上，则单个 AUXILIARY 对象类可简化数据设计。

  例如，假定您要将 preferredOS 同时放在个人条目和组条目上。您可能只想创建一个对象类以允许此属性。

• 设计与实际对象和组元素相关、且可构成合理分类的对象类。

• 避免为新对象类设置必需属性。

  必需属性可能会使模式缺乏灵活性。创建新对象类时，请设置允许属性，而不要设置必需属性。

  定义新对象类之后，您需要确定该对象类允许和需要哪些属性，以及该对象类是从哪个或哪些对象类继承而来的。

定义新属性

如果现有属性不支持需要在目录条目中存储的所有信息，则可以添加新的属性。请尽可能使用标准属性。请搜索默认目录模式中已存在的属性，并使用与新对象类关联的那些属性。

例如，除了 person、organizationalPerson 或 inetOrgPerson 对象类所支持的信息之外，您可能还想在个人条目上存储更多信息。如果要在目录中存储生日，标准目录服务器模式内却不存在任何属性。您可以创建一个名为 dateOfBirth 的新属性。通过定义允许此属性的新辅助类，可以将此属性用于表示人员的条目上。

创建自定义模式文件

创建自定义模式文件时（特别是使用复制时），请注意以下事项：

• 添加新的模式元素时，所有属性都必须先进行定义，然后才能用于对象类。可以在同一模式文件中定义属性和对象类。

• 您所创建的每个自定义属性或对象类都只应在一个模式文件中进行定义。这样做可防止服务器在装入最新创建的模式时覆盖任何以前的定义。目录服务器首先按数字顺序装入模式文件，然后再按字母顺序装入。

• 手动定义新的模式定义时，最佳做法通常是将这些定义添加到 99user.ldif 文件中。

  使用 LDAP 更新模式元素时，新元素将自动写入 99user.ldif 文件。因此，您在自定义模式文件中所做的任何其他模式定义更改都可能被覆盖。只使用 99user.ldif 文件可防止出现重复的模式元素，并可避免覆盖模式更改的危险。

• 由于目录服务器按字母数字顺序（先装入数字）装入模式文件，因此应按以下方式命名自定义模式文件：

  [00-99] filename.ldif

  数字应高于已定义的任何目录标准模式。

  如果使用低于标准模式文件的数字命名模式文件，则服务器在装入模式时可能会发生错误。此外，只有在装入自定义模式元素之后，才会装入所有标准属性和对象类。

• 请确保自定义模式文件名称在数字和字母顺序上都不高于 99user.ldif，因为目录服务器将使用具有最高顺序的文件进行内部模式管理。

  例如，如果您创建一个名为 99zzz.ldif 的模式文件，则在下次更新模式时，所有 X-ORIGIN 值为 'user defined' 的属性都会写入 99zzz.ldif。这样会出现两个包含重复信息的 LDIF 文件，并且 99zzz.ldif 文件中的某些信息可能会被删除。

• 作为一般规则，应使用以下两项内容标识要添加的自定义模式元素：

  • 自定义模式文件 X-ORIGIN 字段中的 'user defined'，

  • 描述性较强的标签（如 X-ORIGIN 字段中的 'Example.com Corporation defined'），以便其他管理员可以更容易理解自定义模式元素。例如， X-ORIGIN ('user defined' 'Example.com Corporation defined')。

    如果要手动添加模式元素，且不使用 X-ORIGIN 字段中的 'user defined'，则模式元素在 DSCC 中显示为只读状态。

    如果使用 LDAP 或 DSCC 添加自定义模式定义，服务器将自动添加 'user defined' 值。但是，如果不在 X-ORIGIN 字段中添加描述性较强的值，则日后可能会难以理解此模式的相关用途。

  应手动将所有自定义模式文件传播到所有服务器中，因为这些更改不会自动复制。

  更改目录模式时，服务器将保留模式更改的时间戳。在每个复制会话开始时，服务器会将其时间戳与使用方的时间戳进行比较，然后在必要的情况下发送所有模式更改。对于自定义模式文件，服务器只保留一个与 99user.ldif 文件关联的时间戳。这意味着您对 99user.ldif 以外的文件所做的任何自定义模式文件更改或添加都不会进行复制。因此，必须将自定义模式文件传播到所有其他服务器，以确保所有模式信息存在于整个拓扑中。