Schema Maintenance and Evolution

Your schema needs will change over time as you bring up new applications and find new and interesting ways to use your directory service. So far in this chapter, we have generally assumed that one person or a small group of people will look after the schema for the directory service as a whole. This is a good model to follow initially, but when your directory service becomes popular and new applications are rapidly being proposed, it may be difficult to keep up with the demand for new schemas. A more decentralized approach to schema design would then be needed.

After you gain some deployment experience, you may also find yourself wishing you could change some of the schema rules that you defined when you initially deployed your directory service. Changing the existing schema is tricky, but it is possible in certain situations described later in this section. There are also some schema- related issues to be aware of when you're upgrading directory service software, which we discuss as well.

Establishing a Schema Review Board

One option is to allow people to define and submit schemas to a centralized review committee for approval before they are installed in the directory service. The main job of the review board (which can be just one or two people) is to check for inconsistencies in the schema, ensure that redundancy is not being introduced, and make sure that the schema is well defined and well documented. This same group can also perform clerical tasks such as assigning OIDs, and it can serve as a central point for schema advice and consent .

Granting Permission to Change the Schema Configuration

If your directory server software supports it, you may want to allow people installing new applications to perform online schema updates over LDAP. Be careful to limit the number of people who have the access rights necessary to do this; you do not want frivolous, inappropriate, or inconsistent schemas to be installed. Check with your directory server software vendor to see if online schema updates are allowed and to find out how to control access.

Changing Existing Schemas

As with all other aspects of design, it is difficult to produce a perfect, complete schema design the first time. Because the use of your directory service will change over time, so will your schema needs. It may be tempting to change your defined schemas to accommodate your changing service, but proceed with caution. It is probably OK to add optional attribute types to an object class you previously defined, but it is risky to try to remove any attribute types or add required attribute types. In practice, there is usually no reason to remove attributes or add mandatory ones.

If you defined an attribute type that has the wrong syntax or name , you need to define a new type but keep the old one around and transition away from it. The most important consideration when you're contemplating changes to an existing schema is to make sure that you have thought carefully about how those changes affect users, directory-enabled applications, and the directory itself.

Upgrading Directory Service Software

When the time comes to upgrade your directory service software, make sure that all your schema additions are preserved during the upgrade process. Well-designed software takes care of this for you, but otherwise you need to reconfigure the new version of the software to make it aware of your schema rules. Also, the potential trouble with software upgrades is the most compelling reason not to remove any of the schemas that come preconfigured with your directory service software.