HP-UX Directory Server Administrator Guide HP-UX Directory Server Version 8.1 (5900-3098, May 2013)

Server itself does not manage OIDs, but there are some best practices described in “Managing
object identifiers” (page 430).
2. Create the new attributes. Attribute definitions require a name, a syntax (the allowed format
of the values), an OID, and a description of whether the attribute can only be used once per
entry or multiple times.
3. Create an object class to contain the new attributes. An object class lists the required attributes
for that entry type and the allowed (permissible) attributes. Because the default schema should
never be altered, if any new attributes are created, then they should be added to a custom
object class.
The schema elements should be planned in advance; do not use multiple attributes for the same
information. Whenever possible, use the standard Directory Server schema. Directory Server has
hundreds of attributes and dozens of object classes defined in the default schema files. The HP-UX
Directory Server schema reference lists and describes the standard attributes and object classes;
all the schema can be viewed in the Directory Server Console or read in the schema files in
/etc/opt/dirsrv/slapd-instance_name/schema. Become familiar with the available
schema; then plan what information attributes are missing and how best to fill those gaps with
custom attributes. Planning the schema is covered in the HP-UX Directory Server deployment guide.
CAUTION:
The default object classes and attributes in Directory Server are based on LDAP and X.500 standards
and RFCs. Using standard schema makes the Directory Server more easily integrated with other
applications and servers and allows interoperability with LDAP clients, legacy Directory Server
instances, and future release. It is unadvisable for you to edit the standard attributes or change the
object classes.
Keep the following rules in mind when customizing the Directory Server schema:
• Keep the schema as simple as possible.
• Reuse existing schema elements whenever possible.
• Minimize the number of mandatory attributes defined for each object class.
• Do not define more than one object class or attribute for the same purpose.
• Do not modify any existing definitions of attributes or object classes.
NOTE:
Never delete or replace the standard schema. Doing so can lead to compatibility problems with
other directories or other LDAP client applications.
The schema is loaded into the Directory Server instance when the instance is started; any new
schema files are not loaded until the Directory Server is restarted or unless a reload task is initiated.
Always, any custom schema is loaded before the standard schema.
10.1.5 Schema replication
Schema elements are replicated by default whenever the schema is changed in the Directory Server
Console or through ldapmodify because the changes are logged in the server change log.
However, replicated schema elements are all copied to 99user.ldif regardless of what schema
file held the schema on the supplier server, so replication can lead to multiple files defining the
same schema.
To keep from having duplicate schema definitions in multiple files, and for the easiest maintenance
of the schema, keep all custom schema in the default custom schema file, 99user.ldif in
/etc/opt/dirsrv/slapd-instance_name/schema.
When new schema files are added to the server and loaded dynamically into the Directory Server,
the schema is only loaded locally because the schema reload operation is a local task. Because
10.1 Overview of schema 429