To extend schema, modifying schema files is not recommended as this method of extending schema is error-prone. To make any changes to the Directory Serverschema, use the ldapmodify command, which is more reliable way to extend schema.
Schema files are LDIF files that are located in instance-path/config/schema/. The instance-path corresponds to the file system directory where the Directory Server instance resides. For example, the instance might be located in /local/dsInst/. The files define standard schema that are used by Directory Server and all servers that rely on Directory Server. The files and the standard schema are described in Sun Directory Server Enterprise Edition 7.0 Reference and Sun Directory Server Enterprise Edition 7.0 Man Page Reference.
Schema files are read once only at startup by the server. The LDIF contents of the files are added to the in-memory LDAP view of the schema in cn=schema . Because the order of schema definitions is important, schema file names are prepended with a number and loaded in alphanumerical order. Schema files in this directory are writable only by the system user who is defined during installation.
When defining the schema directly in an LDIF file, do not use the value ’user defined’ for the X-ORIGIN field. This value is reserved for schema elements that are defined through the LDAP view of cn=schema and that appear in the file 99user.ldif.
The 99user.ldif file contains additional ACIs for the cn=schema entry and all schema definitions that have been added from the command-line or using DSCC. The 99user.ldif file is overwritten when new schema definitions are added. If you want to modify this file, you must restart the server immediately to ensure that your changes are current.
Do not modify the standard schema that is defined in the other schema files. You can, however, add new files to define new attributes and object classes. For example, to define new schema elements in many servers, you could define the elements in a file named 98mySchema.ldif and copy this file to the schema directory on all servers. You would then restart all servers to load your new schema file.
You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.
Create your own schema definition file, such as 98mySchema.ldif.
The syntax of definitions in the schema files is described in RFC 4517.
Read When Creating Custom Schema Files before creating custom schema files.
(Optional) If this server is a master replica that sends updates to other servers, copy your schema definition file to each server instance in the replication topology.
The replication mechanism cannot detect any changes that you make directly to the LDIF files that contain the schema. Therefore, your changes are not replicated to consumers even after restarting the master.
Restart each Directory Server instance to which you copied your schema definition file.
Your changes take effect when the servers restart and thus reload schema definitions.
Keep the following in mind when creating custom schema files, especially when you are using replication:
When adding new schema elements, all attributes must be defined before they can be used in an object class. You can define attributes and object classes in the same schema file.
Each custom attribute or object class that you create should be defined in only one schema file. This practice prevents the server from overriding any previous definitions when the server loads the most recently created schema. Directory Server loads the schema files in numerical order first, then in alphabetical order.
When defining new schema definitions manually, best practice is generally to add these definitions to the 99user.ldif file.
When you update schema elements using LDAP, the new elements are written automatically to the 99user.ldif file. As a result, any other schema definition changes that you made in custom schema files might be overwritten. Using only the 99user.ldif file prevents possible duplications of schema elements and the danger of schema changes being overwritten.
As Directory Server loads schema files in alphanumeric order with numbers loaded first, you should name custom schema files as follows:
The number is higher than any directory standard schema already defined.
If you name your schema file with a number that is lower than the standard schema files, the server might encounter errors when loading the schema. In addition, all standard attributes and object classes are loaded only after your custom schema elements have been loaded.
Make sure that custom schema file names are not numerically or alphabetically higher than 99user.ldif because Directory Server uses the highest sequenced file for its internal schema management.
For example, if you created a schema file and named it 99zzz.ldif, the next time you update the schema, all of the attributes with an X-ORIGIN value of 'user defined' would be written to 99zzz.ldif. The result would be two LDIF files that contain duplicate information, and some information in the 99zzz.ldif file might be erased.
As a general rule, identify the custom schema elements that you are adding with the following two items:
'user defined' in the X-ORIGIN field of custom schema files,
A more descriptive label such as 'Example.com Corporation defined' in the X-ORIGIN field, so that the custom schema element is easy for other administrators to understand. For example X-ORIGIN ('user defined' 'Example.com Corporation defined').
If you are adding schema elements manually and do not use 'user defined' in the X-ORIGIN field, the schema elements appear read-only in DSCC.
The 'user defined' value is added automatically by the server if you add custom schema definitions by using LDAP or DSCC. However, if you do not add a more descriptive value in the X-ORIGIN field, you might later have difficulty understanding what the schema relates to.
These changes are not replicated automatically. To replicate, you must propagate custom schema files manually to all your servers.
When you change the directory schema, the server keeps a timestamp of when the schema was changed. At the beginning of each replication session the server compares its timestamp with its consumer’s timestamp and, if necessary, pushes any schema changes. For custom schema files, the server maintains only one timestamp, which is associated with the 99user.ldif file. This means that any custom schema file changes or additions that you make to files other than 99user.ldif will not be replicated. Therefore, you must propagate custom schema files to all other servers to ensure that all schema information is present throughout the topology.