HP-UX Directory Server 8.1 administrator guide

Server itself does not manage OIDs, but there are some best practices described in “Managing
object identifiers”.
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
the changes do not show up in the changelog, these newly-loaded schema files are not replicated.
10.1 Overview of schema 433