目录服务器提供一个包含大量对象类和属性的标准模式。虽然标准对象类和属性应该能满足您的大多数要求,但您可能仍需通过创建新的对象类和属性来扩展模式。有关标准模式的概述以及设计符合部署的模式的说明,请参见《Sun Java System Directory Server Enterprise Edition 6.1 Deployment Planning Guide》。
本章介绍如何管理模式,其中包含以下主题:
打开模式检查时,目录服务器可确保所有导入、添加和修改操作都符合当前定义的目录模式。
每个条目的对象类和属性都符合模式。
条目包含其所有已定义的对象类的所有必需属性。
条目只包含其对象类所允许的属性。
修改条目时,目录服务器将对整个条目(而不仅仅是要修改的属性)执行模式检查。因此,如果条目中的任何对象类或属性不符合模式,操作都可能会失败。
但是,模式检查不会验证属性值在语法方面的有效性。
默认情况下将打开模式检查。通常都在打开模式检查的情况下运行目录服务器。许多客户端应用程序都假定,打开模式检查即表明所有条目都符合模式。但是,打开模式检查不会使目录服务器验证目录中的现有内容。保证所有目录内容都符合模式的唯一方法是,在添加任何条目或重新初始化所有条目之前打开模式检查。
在某些情况下可能需要关闭模式检查,例如,为了加快已知符合模式的 LDIF 文件的导入速度。但这样做存在风险,因为可能会导入不符合模式的条目。如果模式检查处于关闭状态,则不会检测到不符合模式的导入条目。
有关在复制环境中使用模式检查的详细信息,请参见复制目录模式。
当某个条目不符合模式时,可能无法搜索此条目,并且对此条目的修改操作可能会失败。请执行以下过程中的步骤来更正此问题。
您可以使用 DSCC 执行此任务。有关信息,请参见目录服务控制中心界面和 DSCC 联机帮助。
为了避免日后需要解决模式遵循性问题,请在部署之前规划模式,以尽可能减少模式更改。有关详细信息,请参见《Sun Java System Directory Server Enterprise Edition 6.1 Deployment Planning Guide》。
如果标准模式无法满足您的目录需求,则可以扩展标准模式。自定义模式时应遵循以下准则:
尽可能重新使用现有的模式元素。
尽可能减少为每个对象类定义的必需属性的数量。
不要针对同一用途定义多个对象类或属性。
使模式尽可能简单。
自定义模式时,不要修改、删除或替换标准模式中属性或对象类的任何现有定义。否则,可能会导致与其他目录和 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 以外的文件所做的任何自定义模式文件更改或添加都不会进行复制。因此,必须将自定义模式文件传播到所有其他服务器,以确保所有模式信息存在于整个拓扑中。
本部分介绍如何通过 LDAP 创建、查看和删除属性类型。
cn=schema 条目具有多值属性 attributeTypes,该属性包含目录模式中每个属性类型的定义。可以使用 ldapmodify(1) 命令添加这些定义。
新的属性类型定义以及您对用户定义的属性类型所做的更改都保存在 99user.ldif 文件中。
对于每个属性类型定义,至少要提供一个 OID 以定义新的属性类型。请考虑至少为新属性类型使用以下元素:
属性 OID。 与属性的对象标识符相对应。OID 是一个字符串,通常是点分十进制数字,可以唯一地标识模式对象。
为了严格遵循 LDAP v3,您必须提供有效的数字 OID。要了解 OID 的详细信息,或者为您的企业请求前缀,请向互联网号码分配机构 (Internet Assigned Number Authority, IANA) 发送电子邮件(地址为 iana@iana.org),或访问 IANA Web 站点。
属性名称。与属性的唯一名称相对应。也称为其属性类型。属性名称必须以字母开头,并且只能包含 ASCII 字母、数字和连字符。
属性名称可以包含大写字母,但任何 LDAP 客户端都不会根据大小写来区分属性。根据 RFC 4512 的 2.5 节,必须以不区分大小写的方式处理属性名称。
您可以选择为属性类型添加备用属性名称(也称为别名)。
属性描述。用于介绍属性用途的简短描述性文本。
语法。由 OID 引用,用于描述属性将包含的数据。
RFC 4517 中列出了属性语法及其 OID。
允许的值数。默认情况下属性可以具有多个值,但您可能希望将属性限制为单值属性。
您可以使用 DSCC 执行此任务。有关信息,请参见目录服务控制中心界面和 DSCC 联机帮助。
根据 RFC 4517 中指定的语法准备属性类型定义。
使用 ldapmodify(1) 命令添加属性类型定义。
请注意,目录服务器会将 X-ORIGIN 'user defined' 添加到您提供的定义中。
以下示例将使用 ldapmodify 命令添加具有目录字符串语法的新属性类型:
$ cat blogURL.ldif dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 1.2.3.4.5.6.7 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f blogURL.ldif Enter bind password: modifying entry cn=schema $ |
在生产环境中,应该提供一个唯一的有效 OID,而不是 1.2.3.4.5.6.7。
cn=schema 条目具有多值属性 attributeTypes,该属性包含目录模式中每个属性类型的定义。可以使用 ldapsearch(1) 命令读取这些定义。
您可以使用 DSCC 执行此任务。有关信息,请参见目录服务控制中心界面和 DSCC 联机帮助。
以下命令显示所有属性类型的定义:
$ ldapsearch -T -b cn=schema "(objectclass=*)" attributeTypes |
-T 选项可阻止 ldapsearch 命令折叠 LDIF 行,以便您更容易地使用 grep 或 sed 等命令处理输出。这样,如果您通过 grep 命令输送此命令的输出,则可以只查看目录模式中用户定义的扩展部分。例如:
$ ldapsearch -T -b cn=schema "(objectclass=*)" attributeTypes | grep "user defined" attributeTypes: ( 1.2.3.4.5.6.7 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' ) |
cn=schema 条目具有多值属性 attributeTypes,该属性包含目录模式中每个属性类型的定义。可以使用 ldapmodify(1) 命令删除具有 X-ORIGIN 'user defined' 的定义。
由于模式是由 LDAP 视图在 cn=schema 中定义的,因此您可以使用 ldapsearch 和 ldapmodify 实用程序联机查看和修改模式。但是,您只能删除 X-ORIGIN 字段值为 'user defined' 的模式元素。服务器不会删除其他定义。
对用户定义属性所做的更改将保存在 99user.ldif 文件中。
您可以使用 DSCC 执行此任务。有关信息,请参见目录服务控制中心界面和 DSCC 联机帮助。
查看要删除的属性类型的定义。
有关详细信息,请参见查看属性类型。
使用 ldapmodify(1) 命令删除模式中出现的属性类型定义。
以下命令将删除在示例 11–1 中创建的属性类型:
$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=schema changetype: delete delete: attributeTypes attributeTypes: ( 1.2.3.4.5.6.7 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' ) ^D |
请注意,必须包括由目录服务器添加的 X-ORIGIN 'user defined'(用于将此模式定义归类为扩展)。
本部分介绍如何通过 LDAP 创建、查看和删除对象类。
cn=schema 条目具有多值属性 objectClasses,该属性包含目录模式中每个对象类的定义。可以使用 ldapmodify(1) 命令添加这些定义。
新的对象类定义以及您对用户定义的对象类所做的更改都保存在 99user.ldif 文件中。
如果您要创建继承其他对象类的多个对象类,则必须先创建父对象类。如果新对象类使用自定义属性,还必须首先定义这些属性。
至少要为每个对象类定义提供一个 OID。请考虑至少为新对象类使用以下元素:
对象类 OID。与对象类的对象标识符相对应。OID 是一个字符串,通常是点分十进制数字,可以唯一地标识模式对象。
为了严格遵循 LDAP v3,您必须提供有效的数字 OID。要了解 OID 的详细信息,或者为您的企业请求前缀,请向互联网号码分配机构 (Internet Assigned Number Authority, IANA) 发送电子邮件(地址为 iana@iana.org),或访问 IANA Web 站点。
对象类名称。与对象类的唯一名称相对应。
父对象类。此对象类从中继承属性的现有对象类。
如果您不希望此对象类继承其他特定对象类,请使用 top。
通常,如果要为用户条目添加新属性,则父对象类将是 inetOrgPerson 对象类。如果要为公司条目添加新属性,则父对象类通常是 organization 或 organizationalUnit。如果要为组条目添加新属性,则父对象类通常是 groupOfNames 或 groupOfUniqueNames。
您可以使用 DSCC 执行此任务。有关信息,请参见目录服务控制中心界面和 DSCC 联机帮助。
根据 RFC 4517 中指定的语法准备对象类定义。
使用 ldapmodify(1) 命令添加对象类定义。
请注意,目录服务器会将 X-ORIGIN 'user defined' 添加到您提供的定义中。
以下示例使用 ldapmodify 命令添加新对象类:
$ cat blogger.ldif dn: cn=schema changetype: modify add: objectClasses objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger' DESC 'Someone who has a blog' SUP inetOrgPerson STRUCTURAL MAY blog ) $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f blogger.ldif Enter bind password: modifying entry cn=schema $ |
在生产环境中,应该提供唯一的有效 OID,而不是 1.2.3.4.5.6.8。
cn=schema 条目具有多值属性 objectClasses,该属性包含目录模式中每个对象类的定义。可以使用 ldapsearch(1) 命令读取这些定义。
您可以使用 DSCC 执行此任务。有关信息,请参见目录服务控制中心界面和 DSCC 联机帮助。
以下命令显示所有对象类的定义:
$ ldapsearch -T -b cn=schema "(objectclass=*)" objectClasses |
-T 选项可阻止 ldapsearch 命令折叠 LDIF 行,以便您更容易地使用 grep 或 sed 等命令处理输出。这样,如果您通过 grep 命令输送此命令的输出,则可以只查看目录模式中用户定义的扩展部分。例如:
$ ldapsearch -T -b cn=schema "(objectclass=*)" objectClasses | grep "user defined" objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger' DESC 'Someone who has a blog' STRUCTURAL MAY blog X-ORIGIN 'user defined' ) $ |
cn=schema 条目具有多值属性 objectClasses,该属性包含目录模式中每个对象类的定义。可以使用 ldapmodify(1) 命令删除具有 X-ORIGIN 'user defined' 的定义。
由于模式是由 LDAP 视图在 cn=schema 中定义的,因此您可以使用 ldapsearch 和 ldapmodify 实用程序联机查看和修改模式。但是,您只能删除 X-ORIGIN 字段值为 'user defined' 的模式元素。服务器不会删除其他定义。
对用户定义元素所做的更改将保存在 99user.ldif 文件中。
您可以使用 DSCC 执行此任务。有关信息,请参见目录服务控制中心界面和 DSCC 联机帮助。
查看要删除的对象类的定义。
有关详细信息,请参见查看对象类。
使用 ldapmodify(1) 命令删除模式中出现的对象类定义。
以下命令将删除在示例 11–4 中创建的对象类:
$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=schema changetype: delete delete: objectClasses objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger' DESC 'Someone who has a blog' STRUCTURAL MAY blog X-ORIGIN 'user defined' ) ^D |
请注意,必须包括由目录服务器添加的 X-ORIGIN 'user defined'(用于将此模式定义归类为扩展)。
向模式中添加新属性时,必须创建新对象类以包含这些新属性。可以直接将属性添加到已包含您所需要的大多数属性的现有对象类中,这种方法看起来比较方便,但却会影响与 LDAP 客户端之间的互操作性。
目录服务器与现有 LDAP 客户端之间的互操作性依赖于标准 LDAP 模式。如果更改标准模式,您在升级服务器时也会遇到困难。同理,您也不能删除标准模式元素。
目录服务器模式存储在 cn=schema 条目的属性中。与配置条目一样,此条目也是模式的 LDAP 视图,在服务器启动期间将从文件中读取此视图。
用于扩展目录服务器模式的方法取决于您是否要控制存储模式扩展时所使用的文件名。此外,还取决于您是否要通过复制将更改发送给使用方。请参见下表,以便根据您的具体情况确定要执行的过程。
表 11–1 扩展模式的方法
任务 |
说明 |
---|---|
您不使用复制。您打算通过添加自定义模式文件扩展模式。 | |
您打算通过 LDAP 扩展模式。 | |
您使用复制。您打算在所有服务器上保留自定义模式文件的文件名。 | |
您使用复制。您打算通过在主副本上添加自定义模式文件来扩展模式。然后通过复制机制将模式扩展复制到使用方服务器。 |
有关对象类、属性和目录模式的详细信息,以及扩展模式所应遵循的准则,请参见《Sun Java System Directory Server Enterprise Edition 6.1 Deployment Planning Guide》中的“Designing a Directory Schema”。有关标准属性和对象类的信息,请参见《Sun Java System Directory Server Enterprise Edition 6.1 Man Page Reference》。
本部分提供扩展目录模式时可使用的各种方法的相关信息。
模式文件是位于 instance-path/config/schema/ 中的 LDIF 文件。instance-path 与目录服务器实例所在的文件系统目录相对应。例如,此实例可能位于 /local/ds/ 中。这些文件可定义供目录服务器以及依赖于目录服务器的所有服务器使用的标准模式。《Sun Java System Directory Server Enterprise Edition 6.1 Reference》和《Sun Java System Directory Server Enterprise Edition 6.1 Man Page Reference》中介绍了这些文件和标准模式。
服务器只在启动时读取模式文件一次。这些 LDIF 文件的内容将被添加到 cn=schema 中模式的内存 LDIF 视图。由于模式定义的顺序非常重要,因此模式文件名称都以数字开头,并按字母数字顺序装入。只有在安装期间定义的系统用户才能对此目录中的模式文件执行写入操作。
在 LDIF 文件中直接定义模式时,不要在 X-ORIGIN 字段中使用 'user defined' 值。此值是为特定的模式元素保留的,这些元素通过 cn=schema 的 LDAP 视图进行定义,并出现在 99user.ldif 文件中。
99user.ldif 文件包含其他 ACI,用于 cn=schema 条目和所有已从命令行或使用 DSCC 添加的模式定义。添加新的模式定义时,将覆盖 99user.ldif 文件。如果要修改此文件,则必须立即重新启动服务器,以确保更改是最新的。
不要修改在其他模式文件中定义的标准模式。但是,您可以添加新文件,以定义新的属性和对象类。例如,要在许多服务器中定义新的模式元素,则可以在名为 98mySchema.ldif 的文件中定义这些元素,并将此文件复制到所有服务器上的模式目录中。然后,应重新启动所有服务器以装入新的模式文件。
您可以使用 DSCC 执行此任务。有关信息,请参见目录服务控制中心界面和 DSCC 联机帮助。
创建您自己的模式定义文件,如 98mySchema.ldif。
RFC 4517 中介绍了模式文件中的定义所使用的语法。
(可选的)如果此服务器是将更新发送到其他服务器的主副本,请将您的模式定义文件复制到复制拓扑中的每个服务器实例中。
复制机制无法检测到您直接对包含模式的 LDIF 文件所做的任何更改。因此,即使在重新启动主服务器之后,您的更改也不会复制到使用方。
重新启动将模式定义文件复制到的每个目录服务器实例。
当服务器重新启动并重新装入模式定义时,您的更改将会生效。
由于模式是由 LDAP 视图在 cn=schema 中定义的,因此您可以使用 ldapsearch 和 ldapmodify 实用程序联机查看和修改模式。但是,您只能修改 X-ORIGIN 字段值为 'user defined' 的模式元素。服务器将拒绝对其他定义所做的任何修改。
新的元素定义以及您对用户定义元素所做的更改都保存在 99user.ldif 文件中。
您可以使用 DSCC 执行此任务。有关信息,请参见目录服务控制中心界面和 DSCC 联机帮助。
从命令行修改模式定义容易出错,因为必须准确键入较长的值。但是,您可以在需要更新目录模式的脚本中使用此功能。
使用 ldapmodify(1) 命令添加或删除单个的 attributeTypes 属性值。
使用 ldapmodify(1) 命令添加或删除单个的 objectClasses 属性值。
要修改其中某个值,您必须先删除特定的值,然后将此值作为新值进行添加。由于属性为多值属性,因此必须执行此过程。有关详细信息,请参见修改多值属性的一个值。
有关自定义模式文件的信息,请参见使用自定义模式文件扩展模式。以下过程介绍如何使用复制机制将模式扩展传播到拓扑中的所有服务器。
对于此过程的某些部分,可以使用 DSCC 执行此任务。有关信息,请参见目录服务控制中心界面和 DSCC 联机帮助。此过程的其他部分只能使用命令行完成。
使用以下任一方法准备您的模式扩展:
RFC 4517 中介绍了模式文件中的定义所使用的语法。
在放置模式定义文件的主服务器上运行 schema_push 命令。
此脚本不会实际将模式发送到副本,而是将特殊属性写入模式文件,以使这些模式文件在装入后立即被复制。有关详细信息,请参见 schema_push(1M) 手册页。
重新启动放置模式定义文件的主服务器。
复制机制无法检测到您直接对包含模式的 LDIF 文件所做的任何更改。但是,在运行 schema_push 后重新启动服务器时,该服务器将装入所有模式文件,然后复制机制会将新的模式复制到使用方。
在两个服务器之间配置一个或多个后缀的复制时,也会自动复制模式定义。模式定义的自动复制可确保所有副本都具有完整、相同的模式,此模式用于定义可以复制到使用方的所有对象类和属性。因此,主服务器也将包含主服务器模式。
但模式复制不是即时完成的,即使通过 LDAP 修改模式时也是如此。模式复制会在更新目录数据时触发,或者在修改模式后启动第一个复制会话时触发。
要在所有副本上执行模式,至少要在所有服务器上启用模式检查。由于在执行 LDAP 操作的主服务器上执行模式检查,因此更新使用方时不需要检查模式。为了提高性能,复制机制将避开使用方副本上的模式检查。
不要在集线器和专用使用方上关闭模式检查。模式检查不会影响使用方的性能。应始终打开模式检查,以表明副本内容符合其模式。
在使用方初始化期间,主服务器自动将模式复制到其使用方。只要通过 DSCC 或者命令行工具修改模式,主服务器还会自动复制此模式。默认情况下将复制整个模式。将在使用方上创建其尚不存在的所有其他模式元素,并将这些元素存储在 99user.ldif 文件中。
例如,假定在启动主服务器时,该服务器包含 98mySchema.ldif 文件中的模式定义。此外,还假定您接下来将定义与其他服务器(主服务器、集线器或专用使用方)之间的复制协议。当您随后从此主服务器初始化副本时,复制的模式将包含 98mySchema.ldif 中的定义,但这些定义将存储在副本服务器上的 99user.ldif 中。
在使用方初始化期间复制模式之后,修改主服务器 cn=schema 中的模式还会将整个模式复制到使用方。因此,通过命令行实用程序或 DSCC 对主服务器模式所做的任何修改都将复制到使用方。这些修改存储在主服务器上的 99user.ldif 中,并且通过上述机制,这些修改还会存储在使用方上的 99user.ldif 中。
请考虑以下有关在复制环境中维护模式一致性的准则:
不要修改使用方服务器上的模式。
对使用方服务器上的模式所做的修改可能会导致复制错误。这是因为使用方上的模式差异可能会导致来自提供方的更新不符合使用方上的模式。
在多主复制环境中,请修改单个主服务器上的模式。
修改两个主服务器上的模式时,最近更新的主服务器会将其模式版本传播到使用方。这样,使用方上的模式可能与其他主服务器上的模式不一致。
配置部分复制时,还应考虑以下准则:
由于在部分复制配置中由提供方发送模式,因此部分使用方副本上的模式是主副本模式的副本。因此,模式与所应用的部分复制配置可能不相符。
通常,目录服务器会按照模式中的定义复制每个条目的所有必需属性,以免发生模式违规错误。将部分复制配置为过滤掉必需属性时,必须禁用模式检查。
如果对部分复制启用模式检查,可能无法以脱机方式初始化副本。如果过滤掉必需属性,目录服务器将不允许您从 LDIF 装入数据。
如果在部分使用方副本上禁用了模式检查,则部分使用方副本所在的整个服务器实例都不会执行模式检查。因此,应避免将同一服务器实例上的提供方副本配置为部分使用方。
默认情况下,只要复制机制复制模式,它都会将整个模式发送到其使用方。在以下两种情况下不希望将整个模式发送到使用方:
使用 DSCC 或从命令行对 cn=schema 所做的修改仅限于用户定义的模式元素,所有标准模式都不会更改。如果您经常修改模式,则每次发送大量未更改的模式元素时都会对性能造成影响。您可以只复制用户定义的模式元素,以提高复制和服务器性能。
当目录服务器上的主服务器复制到 Directory Server 5.1 上的使用方时,这些版本的配置属性模式将有所不同,因而会产生冲突。在这种情况下,您只能复制用户定义的模式元素。
目录服务器使用 11rfc2307.ldif 模式文件。此模式文件符合 RFC 2307。
DirectoryServer 5.2 以前的目录服务器版本使用 10rfc2307.ldif 模式文件。
无法使用 DSCC 执行此任务。请使用命令行,如以下过程所述。