3.4. Customizing the 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 (data).
- Do not modify any existing definitions of attributes or object classes.
99user.ldiffile. Each individual instance maintains its own
99user.ldiffile in the
/etc/dirsrv/slapd-instance_name/schemadirectory. It is also possible to create custom schema files and dynamically reload the schema into the server.
3.4.1. When to Extend the Schema
3.4.2. Getting and Assigning Object Identifiers
- Obtain an OID from the Internet Assigned Numbers Authority (IANA) or a national organization.In some countries, corporations already have OIDs assigned to them. If your organization does not already have an OID, one can be obtained from IANA. For more information, go to the IANA website at http://www.iana.org/cgi-bin/enterprise.pl.
- Create an OID registry to track OID assignments.An OID registry is a list of the OIDs and descriptions of the OIDs used in the directory schema. This ensures that no OID is ever used for more than one purpose. Then publish the OID registry with the schema.
- Create branches in the OID tree to accommodate schema elements.Create at least two branches under the OID branch or the directory schema, using OID
.1for attributes and OID
.2for object classes. To define custom matching rules or controls, add new branches as needed (OID
.3, for example).
3.4.3. Naming Attributes and Object Classes
examplebefore each of their custom schema elements. They might add a special object class called
examplePersonto identify Example Corp. employees in their directory.
3.4.4. Strategies for Defining New Object Classes
- Create many new object classes, one for each object class structure to which to add an attribute.
- Create a single object class that supports all of the custom attributes created for the directory. This kind of object class is created by defining it as an auxiliary object class.
exampleVicePresident. A simple solution is to create several object classes that allow some subset of these attributes.
- One object class,
examplePerson, is created and allows
examplePreferredOS. The parent of
- A second object class,
exampleVicePresident. The parent of
objectclasses: ( 2.16.840.1.117370.9126.96.36.199 NAME 'examplePerson' DESC 'Example Person Object Class' SUP inetorgPerson MAY (exampleDateOfBirth $ examplePreferredOS) ) objectclasses: ( 2.16.840.1.117370.9188.8.131.52 NAME 'exampleOrganization' DESC 'Organization Object Class' SUP organization MAY (exampleBuildingFloor $ exampleVicePresident) )
objectclasses: (2.16.840.1.117370.9184.108.40.206 NAME 'exampleEntry' DESC 'Standard Entry Object Class' SUP top AUXILIARY MAY (exampleDateOfBirth $ examplePreferredOS $ exampleBuildingFloor $ exampleVicePresident) )
exampleEntryobject class is marked
AUXILIARY, meaning that it can be used with any entry regardless of its structural object class.
2.16.840.1.117370) is based on the former Netscape OID prefix. To create custom object classes, obtain an OID as described in Section 3.4.2, “Getting and Assigning Object Identifiers”.
- Multiple object classes result in more schema elements to create and maintain.Generally, the number of elements remains small and needs little maintenance. However, it may be easier to use a single object class if there are more than two or three object classes added to the schema.
- Multiple object classes require a more careful and rigid data design.Rigid data design forces attention to the object class structure under which every piece of data is placed, which can be either helpful or cumbersome.
- Single object classes simplify data design when there is data that can be applied to more than one type of object class, such as both people and asset entries.For example, a custom
preferredOSattribute may be set on both a person and a group entry. A single object class can allow this attribute on both types of entries.
- Avoid required attributes for new object classes.Specifying
allowfor attributes in new object classes can make the schema inflexible. When creating a new object class, use
requireas much as possible.After defining a new object class, decide what attributes it allows and requires, and from what object classes it inherits attributes.
3.4.5. Strategies for Defining New Attributes
inetOrgPersonobject classes support by default. As an example, no attribute exists within the standard Directory Server schema to store birth dates. A new attribute,
dateOfBirth, can be created and set as an allowed attribute within a new auxiliary object class,
attributetypes: ( dateofbirth-oid NAME 'dateofbirth' DESC 'For employee birthdays' SYNTAX 220.127.116.11.4.1.1418.104.22.168.15 X-ORIGIN 'Example defined') objectclasses: ( 2.16.840.1.117370.922.214.171.124 NAME 'examplePerson' DESC 'Example Person Object Class' SUP inetorgPerson MAY (exampleDateOfBirth $ cn) X-ORIGIN 'Example defined')
3.4.6. Deleting Schema Elements
3.4.7. Creating Custom Schema Files
99user.ldiffile provided with Directory Server. These schema files hold new, custom attributes and object classes that are specific to the organization. The new schema files should be located in the schema directory,
99user.ldifor the server could experience problems.
- Manually copy these custom schema files to the instance's schema directory,
/etc/dirsrv/slapd-instance_name/schema. To load the schema, restart the server or reload the schema dynamically by running the
- Modify the schema on the server with an LDAP client such as the Directory Server Console or
- If the server is replicated, then allow the replication process to copy the schema information to each of the consumer servers.With replication, all of the replicated schema elements are copied into the consumer servers'
99user.ldiffile. To keep the schema in a custom schema file, like
90example_schema.ldif, the file has to be copied over to the consumer server manually. Replication does not copy schema files.
99user.ldiffile. The directory does not track where schema definitions are stored. Storing schema elements in the
99user.ldiffile of consumers does not create a problem as long as the schema is maintained on the supplier server only.
99user.ldiffile on the consumer. Having the changes in the
99user.ldiffile may make schema management difficult, as some attributes will appear in two separate schema files on a consumer, once in the original custom schema file copied from the supplier and again in the
99user.ldiffile after replication.
3.4.8. Custom Schema Best Practices
126.96.36.199. Naming Schema Files
99user.ldif. This lets Directory Server write to
99user.ldif, both through LDAP tools and the Directory Server Console.
99user.ldiffile contains attributes with an
'user defined'; however, the Directory Server writes all
'user defined'schema elements to the highest named file, numerically then alphabetically. If there is a schema file called
99zzz.ldif, the next time the schema is updated (either through LDAP command-line tools or the Directory Server Console) all of the attributes with an
'user defined'are written to
99zzz.ldif. The result is two LDIF files that contain duplicate information, and some information in the
99zzz.ldiffile might be erased.
188.8.131.52. Using 'user defined' as the Origin
'user defined'in the
X-ORIGINfield of custom schema files (such as
'user defined'is used internally by the Directory Server when a schema is added over LDAP. In custom schema files, use something more descriptive, such as
'Example Corp. defined'.
'user defined'as the value of
X-ORIGIN. If a different
X-ORIGINvalue is set, the server simply may overwrite it.
'user defined'ensures that schema definitions in the
99user.ldiffile are not removed from the file by the Directory Server. The Directory Server does not remove them because it relies on an
'user defined'to tell it what elements should reside in the
attributetypes: ( exampleContact-oid NAME 'exampleContact' DESC 'Example Corporate contact' SYNTAX 184.108.40.206.4.1.14220.127.116.11.15 X-ORIGIN 'Example defined')
attributetypes: ( exampleContact-oid NAME 'exampleContact' DESC 'Example Corporate contact' SYNTAX 18.104.22.168.4.1.1422.214.171.124.15 X-ORIGIN ('Example defined' 'user defined') )
126.96.36.199. Defining Attributes before Object Classes
188.8.131.52. Defining Schema in a Single File
- Be careful with what schema elements are included in each schema file.
- Be careful in naming and updating the schema files. When schema elements are edited through LDAP tools, the changes are automatically written to the last file (alphabetically). Most schema changes, then, write to the default file
99user.ldifand not to the custom schema file, such as
60example.ldif. Also, the schema elements in
99user.ldifoverride duplicate elements in other schema files.
- Add all the schema definitions to the
99user.ldiffile. This is useful if your are managing the schema through the Directory Server Console.