cancel
Showing results for 
Search instead for 
Did you mean: 

Managing Server Schema

UnboundID NeilW

 

A server's schema describes the kinds of information that it can hold. Attribute syntaxes (which define the data types for attribute values) and matching rules (which are used in the course of comparing attribute values) must be implemented in code and, and at present it is not possible for third-party developers to create custom attribute syntaxes or matching rules. However, all other types of schema elements (attribute types, object classes, name forms, DIT content rules, DIT structure rules, and matching rule uses) do not require any special logic, and new elements of these types can be easily defined in the server.

 

Schema Initialization Order

The server schema definitions are held in LDIF files contained in the server's config/schema directory, using the encoding described in RFC 4512 section 4.1. Each of these files must have a name that starts with a two-digit number and a dash, and must end with a ".ldif" extension. There should be some brief, descriptive name between the dash and the extension to help identify the types of schema elements defined in that file. For example, the "00-core.ldif" file contains a number of schema elements defined in core LDAP specifications and other key sources, the "01-pwpolicy.ldif" contains elements related to maintaining password policy state, and so on.

 

Whenever the server is started, schema elements are loaded in the following order:

 

  1. A schema file whose name begins with a lower two-digit number will be loaded before a schema file whose name begins with a higher two-digit number. For example, 00-core.ldif will be loaded before 01-pwpolicy.ldif because 00 is less than 01.

  2. If two or more schema files start with the same two-digit number, then the order in which those files will be loaded is determined by the lexicographical order of their filenames. For example, 03-changelog.ldif will be loaded before 03-rfc2713.ldif, which will be loaded before 03-rfc2714.ldif, and so on.

  3. Within the same LDIF file, different types of elements are loaded in the following order:
    1. Attribute types (defined in the attributeTypes attribute)
    2. Object classes (defined in the objectClasses attribute)
    3. Name forms (defined in the nameForms attribute)
    4. DIT content rules (defined in the dITContentRules attribute)
    5. DIT structure rules (defined in the dITStructureRules attribute)
    6. Matching rule uses (defined in the matchingRuleUse attribute)

  4. Within the same attribute in the same LDIF file, elements are loaded in the order in which they appear in the file.

 

One schema element may reference another schema element only if the referenced element is loaded first. For example, if an object class requires a particular attribute type, then that attribute type must have been defined either in the schema file that also defines the object class (since attribute types are loaded before object classes), or in a schema file that will be loaded before the one containing the object class definition. If any schema element references another schema element that has not yet been defined, then the server will report an error and the schema element with the unresolved reference will not be available for use.

 

Assigning Object Identifiers (OIDs)

Each attribute type and object class defined in the schema needs to have a unique object identifier (OID). An OID is formatted as a sequence of numbers separated by periods. For example, the OID for the cn attribute is 2.5.4.3. If you're going to create custom attribute types and object classes, then you'll need to assign them OIDs.

 

If your organization doesn't already have one, you will need to get a private enterprise number from IANA, the Internet Assigned Numbers Authority. This can be freely obtained using the request form at http://pen.iana.org/pen/PenApplication.page, and you will be allocated a number that you can use as the base for any custom OIDs that you may require. For example, the value "1.3.6.1.4.1.32473" is reserved for documentation examples, and we will use that value for all examples here.

 

You should then come up with some scheme for allocating OIDs below this base. To avoid conflicts with other applications that may need their own OIDs, then you may want to use a separate number immediately beneath the base to indicate the application with which the OID is associated. For example, "1.3.6.1.4.1.32473.1" might be the base for OIDs associated with the first application, "1.3.6.1.4.1.32473.2" for the second application, etc.

 

Next, it's probably a good idea to use another number to indicate the intended usage for the OID. For example, "1.3.6.1.4.1.32473.1.1" for LDAP attribute types, and "1.3.6.1.4.1.32473.1.2" for LDAP object classes.

 

Finally, use a sequential counter for each new attribute type or object class that you want to create. For example, if you need to define five attribute types, then they could have OIDs of "1.3.6.1.4.1.32473.1.1.1" through "1.3.6.1.4.1.32473.1.1.5".

 

Note that the server does allow you to define custom attribute types and object classes without proper numeric OIDs by using fake OIDs that match the name of the associated attribute or object class with "-oid" appended to it. So if you have an attribute named "example-attribute-name", then the server will allow "example-attribute-name-oid" as its object identifier. However, this is not recommended because it may cause interoperability problems with other applications that expect schema definitions to be standards compliant and include well-formed numeric OIDs.

 

Naming Schema Elements

Although you can create an attribute type or object class with just a numeric OID, it is strongly recommended that you also assign user-friendly names to custom schema elements. These names are much easier to work with and remember, and will be much more meaningful if you see them in entries, filters, DNs, and other places that such names may appear.

 

As per RFC 4512, schema element names must start with an ASCII letter, and may contain only ASCII letters, ASCII numeric digits, and the ASCII hyphen character. Other special characters like periods, slashes, and underscores are not allowed. If you want to create a schema element name that combines multiple words, the general practice is to either separate those words with hyphens (e.g., example-attribute-name) or to capitalize the first letter of all but the first word (e.g., exampleAttributeName).

 

Schema element names must be unique within a given element type (e.g., you can't have two attribute types with the same name, and you can't have two object classes with the same name), but it is acceptable to have overlap between different types of schema elements (so you can use the same name for both an attribute type and an object class).

 

One of the most common pitfalls encountered when naming schema elements is making the names too generic. This may lead to conflicts with other applications that have also chosen names that are too generic. Such conflicts are most likely to occur if you use off-the-shelf software to interact with your server, but may also occur even across multiple custom applications. To avoid this, it is recommended that you use prefixes to ensure that your custom attribute type or object class does not conflict with someone else's. We recommend prefixing custom schema element names with the full or abbreviated name of your organization (for example, at UnboundID we often use a prefix of "ubid", like in  "ubidMiddleName"). If you are concerned about naming conflicts between different applications within the same organization, it may even be desirable to include the full or abbreviated application name in addition to the organization name.

 

Creating Custom Attribute Type Definitions

Unless you're storing only the most basic types of information in your server, you will need to define custom attribute types to hold the data that is specific to your deployment. Attribute type definitions use the format described in RFC 4512 section 4.1.2, but the following example provides a sample of such a definition:

 

( 1.3.6.1.4.1.32473.1.1.1
NAME 'exampleAttributeName'
DESC 'An example attribute type definition'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
X-ORIGIN 'Managing Schema Document' )

 

Technically, only the numeric OID is required, but we also recommend providing a user-friendly name, and also explicitly specifying the matching rules and syntax. The SINGLE-VALUE element indicates that the attribute is only allowed to have a single value per entry; if an attribute should allow multiple values in the same entry, then the SINGLE-VALUE element should be omitted. The DESC and X-ORIGIN components are purely informational and are not used by the server in any way.

 

Commonly-Used Attribute Syntaxes

When present, the attribute syntax should be specified as a numeric OID. The following are the OIDs for some of the most commonly-used attribute syntaxes. See RFC 4517 section 3.3 for a more complete description of these syntaxes.

 

  • 1.3.6.1.4.1.1466.115.121.1.7 — The Boolean syntax. In strict compliance with the specification, values should be either "TRUE" or "FALSE" in all capital letters, but many servers will permit the values in any capitalization.

 

  • 1.3.6.1.4.1.1466.115.121.1.12 — The DN syntax, which requires values to be valid distinguished names.

 

  • 1.3.6.1.4.1.1466.115.121.1.15 — The directory string syntax, which allows for any sequence of one or more UTF-8 characters.

 

  • 1.3.6.1.4.1.1466.115.121.1.24 — The generalized time syntax, which is used for timestamps in the standard generalized time format (e.g., "20160102030405.678Z").

 

  • 1.3.6.1.4.1.1466.115.121.1.26 — The IA5 string syntax, which allows for any sequence of zero or more characters from the IA5 character set, which is better known as the ASCII character set.

 

  • 1.3.6.1.4.1.1466.115.121.1.27 — The integer syntax, which allows for any valid positive, negative, or zero integer value.

 

  • 1.3.6.1.4.1.1466.115.121.1.36 — The numeric string syntax, which allows for any combination of one or more ASCII numeric digits and spaces.

 

  • 1.3.6.1.4.1.1466.115.121.1.40 — The octet string syntax, which allows for any sequence of zero or more bytes. This syntax is recommended for binary data.

 

  • 1.3.6.1.4.1.1466.115.121.1.44 — The printable string syntax, which allows for any sequence of one or more characters from the following set of ASCII characters: alphabetic letters, numeric digits, the single quotation mark, the open and close parentheses, the plus sign, the comma, the hyphen, the period, the equal sign, the forward slash, the colon, the question mark, and the space.

 

  • 1.3.6.1.4.1.1466.115.121.1.50 — The telephone number syntax, which is used to hold telephone number values. Technically, values should be compliant with the ITU-T E.123 specification, although servers often allow other characters like hyphens and/or parentheses.

 

Commonly-Used Matching Rules

Matching rules can also be specified by OID, but are often referenced by name simply because it is more convenient and more meaningful. Some of the most commonly-used matching rules are listed below. Most of the names are self-descriptive, but see RFC 4517 section 4.2 for a complete description of each of the matching rules.

 

  • booleanMatch
  • caseExactIA5Match
  • caseExactMatch
  • caseExactOrderingMatch
  • caseExactSubstringsMatch
  • caseIgnoreIA5Match
  • caseIgnoreIA5SubstringsMatch
  • caseIgnoreMatch
  • caseIgnoreOrderingMatch
  • caseIgnoreSubstringsMatch
  • distinguishedNameMatch
  • generalizedTimeMatch
  • generalizedTimeOrderingMatch
  • integerMatch
  • integerOrderingMatch
  • numericStringMatch
  • numericStringOrderingMatch
  • numericStringSubstringsMatch
  • octetStringMatch
  • octetStringOrderingMatch
  • telephoneNumberMatch
  • telephoneNumberSubstringsMatch

 

UnboundID-Specific Attribute Type Extensions for Constraining Values

An attribute type's syntax will enforce some basic requirements on the set of acceptable values for that attribute, and the SINGLE-VALUE constraint can be used to indicate whether to allow an entry to have multiple values for an attribute. But in some cases, you may want to impose additional constraints on the types of values that a particular attribute may have. To address this, UnboundID has defined a number of extensions that may be included in an attribute type definition. They include:

 

  • X-ALLOWED-VALUE — Provides an explicit set of values that are the only values that will be allowed for the associated attribute.

 

  • X-VALUE-REGEX — Provides one or more regular expressions that describe acceptable values for the associated attribute. Values will only be allowed if they match at least one of the regular expressions.

 

  • X-MIN-VALUE-LENGTH — Specifies the minimum number of characters that values of the associated attribute are permitted to have.

 

  • X-MAX-VALUE-LENGTH — Specifies the maximum number of characters that values of the associated attribute are permitted to have.

 

  • X-MIN-INT-VALUE — Specifies the minimum integer value that may be assigned to the associated attribute.

 

  • X-MAX-INT-VALUE — Specifies the maximum integer value that may be assigned to the associated attribute.

 

  • X-MIN-VALUE-COUNT — Specifies the minimum number of values that the attribute is allowed to have in any entry.

 

  • X-MAX-VALUE-COUNT — Specifies the maximum number of values that the attribute is allowed to have in any entry.

 

Creating Custom Object Class Definitions

Object class definitions use the format described in RFC 4512 section 4.1.1. The following example provides a sample of an object class definition:

 

 

( 1.3.6.1.4.1.32473.1.2.1
NAME 'exampleObjectClassName'
DESC 'An example object class definition'
SUP top
STRUCTURAL
MUST cn
MAY ( description $ givenName $ sn )
X-ORIGIN 'Managing Schema Document' )

 

As is the case for an attribute type definition, technically only the OID is required, but a user-friendly name is also recommended. Object class definitions will also typically include one or both of the MUST and MAY elements, which are used to list the names or OIDs of the required and optional attribute types for entries containing this object class.

 

The SUP element specifies the name of the superior object class from which the class being defined inherits. All of the required attributes of the superclass will also be required by the subclass. All of the optional attributes of the superclass will also be permitted by the subclass, although an attribute type that is optional in the superclass may be made required by a subclass.

 

Each object class has a "kind", which is one of the following values:

 

  • STRUCTURAL — A structural class defines the base type of object that an entry represents (e.g., a person, a group, a device, an application, etc.). Every entry must have exactly one structural object class, although if that structural class inherits from one or more other structural classes, then those superior classes will also be present in the entry. If a structural object class has a superior object class, then that superclass must be either abstract or structural.

 

  • AUXILIARY — An auxiliary class is typically used to provide information related to a particular trait that an entry may have. For example, a user account may have a structural class of inetOrgPerson, but if their password should be stored in the authPassword attribute (using the authentication password syntax described in RFC 3112), that user's entry should also include the authPasswordObject auxiliary class. An entry may have zero, one, or multiple auxiliary classes. If an auxiliary class has a superior object class, then that superclass must be either abstract or auxiliary.

 

  • ABSTRACT — An abstract class is primarily meant to be extended by other classes. An abstract class must not be present in an entry unless it also contains at least one non-abstract subclass of that class. If an abstract class has a superior object class, that superclass must also be abstract.

 

If an object class definition doesn't explicitly specify a kind, then it will inherit the kind of its superclass. If none of the classes in the inheritance chain specify a kind, then a default of STRUCTURAL will be assumed.

 

Retrieving the Schema from the Server

As previously mentioned, the server schema is defined in LDIF files contained in the config/schema directory beneath the server root. An application that resides on the same system as the server and has the necessary permissions to access those files could use them to discover the schema elements that the server offers, but that is not recommended because it's only an option for a very limited set of clients, and it's also not portable because not all types of directory servers store their schema in this way.

 

The standard way for LDAP clients to access a directory server's schema is by issuing LDAP requests. As per RFC 4512 section 4.2, all LDAPv3-compliant servers should make their schema available to clients in the form of a subschema subentry.

 

Although UnboundID servers currently have a single schema that governs all entries defined in the server, it is possible for an LDAP server to have different schemas for different portions of the DIT. Therefore, the process for retrieving information about the schema available for a particular operation should be done in two steps:

 

  1. Determine the location of the schema subentry that governs a specified entry. To do this, retrieve the subschemaSubentry operational attribute from the entry you want to target. To retrieve the general schema information from a server, use the subschemaSubentry operational attribute in the server's root DSE (the entry whose DN is the empty string).

  2. Once you know the DN of the subschema subentry, issue a search with that DN as the search base, a baseObject scope, and a filter of "(objectClass=subschema)". Because the attributes that hold the different types of schema elements are defined as operational, you should also specifically request the attributes holding the schema element types that you want to retrieve (which may include any or all of ldapSyntaxes, matchingRules, attributeTypes, objectClasses, nameForms, dITContentRules, dITStructureRules, and matchingRuleUse).

 

For example, to accomplish this using the ldapsearch command-line tool, use the following pair of commands:

 

$ bin/ldapsearch --hostname ds.example.com --port 389 \
      --baseDN "" --searchScope base \
      "(objectClass=*)" subschemaSubentry
dn:
subschemaSubentry: cn=schema
 

$ bin/ldapsearch --hostname ds.example.com --port 389 \
      --baseDN "cn=schema" --searchScope base \
      "(objectClass=subschema)" ldapSyntaxes matchingRules \
      attributeTypes objectClasses dITContentRules \
      dITStructureRules matchingRuleUse
dn: cn=schema
attributeTypes: ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch SUBSTR caseIgnor
eSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} X-ORIGIN 'RFC 4519
' )
attributeTypes: ( 2.5.4.49 NAME 'distinguishedName' EQUALITY distinguishedNameMa
tch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'RFC 4519' )
attributeTypes: ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch SYNT
AX 1.3.6.1.4.1.1466.115.121.1.38 X-ORIGIN 'RFC 4512' )
attributeTypes: ( 2.5.4.1 NAME 'aliasedObjectName' EQUALITY distinguishedNameMat
ch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'RFC 4512' )
attributeTypes: ( 2.5.4.2 NAME 'knowledgeInformation' EQUALITY caseIgnoreMatch S
YNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} X-ORIGIN 'RFC 2256' )
… many more lines of output omitted …

 

Note that in the above example, the text in bold represents the command to be invoked, while non-bold text provides command output. Further, text in red shows the output of the first command that is needed as input to the second command.

 

Installing Custom Schema Definitions in the Server

There are multiple ways to add new elements to the server schema, but they fall into two basic categories: modify the server's subschema subentry via LDAP, and define the schema elements in an LDIF file.

 

Note that regardless of the mechanism used, altering the schema on one Directory Server instance will cause the changes to be applied to all Directory Server instances in the replication topology. Changes made with the server online will cause the changes to be replicated immediately. Changes made with the server offline will be identified and replicated when the server is started. However, schema definitions are currently not replicated to Directory Proxy Server instances, so any schema changes made in the Directory Server should also be applied to Directory Proxy Server instances.

 

Updating Schema Definitions over LDAP

If you're just going to make a couple of changes, then one of the easiest and most convenient ways to update the server schema is to use the Management Console. In the upper left corner of the page, click on the "Configuration" drop-down and choose "LDAP Schema" instead. This will allow you to view, edit, and the schema elements defined in the server through a simple web-based interface.

 

However, if you need to make more extensive changes to the schema, if you need to be able to update the schema programmatically, or if you'd prefer a command-line interface to a graphical one, then you can simply target the subschema subentry with an LDAP modify operation. Use the add modification type to define new schema elements, and also to replace existing schema elements with new versions (by adding the updated version of the element as if it didn't already exist). For example, to add a new attribute type and an auxiliary object class that allows it to be included in entries, use a modification like the following:

 

dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 1.3.6.1.4.1.32473.1.1.1
NAME 'exampleAttributeName'
DESC 'An example attribute type definition'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
X-ORIGIN 'Managing Schema Document' )
-
add: objectClasses
objectClasses: ( 1.3.6.1.4.1.32473.1.2.2
NAME 'exampleAuxiliaryClass'
DESC 'An example auxiliary object class definition'
SUP top
AUXILIARY
MAY exampleAttributeName
X-ORIGIN 'Managing Schema Document' )

 

Applying this modification will cause the new schema elements to appear in the config/schema/99-user.ldif file, which is the default location for new schema elements. If any of these schema elements had already been defined in the schema, then the modification would have updated the definition in whatever file held the previous definition. If you want to explicitly specify which file should hold the schema element (regardless of whether you're defining a new element or updating an existing element), can use the X-SCHEMA-FILE extension to specify the name (without any path information), like:

 

dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 1.3.6.1.4.1.32473.1.1.1
NAME 'exampleAttributeName'
DESC 'An example attribute type definition'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
X-ORIGIN 'Managing Schema Document'
X-SCHEMA-FILE '90-test.ldif' )

 

Note that while you can add new schema elements over LDAP, and you can update custom schema elements with new versions, you cannot alter any schema elements shipped with the server. Since the schema elements included with the server are primarily either defined in LDAP specifications or are used by the server itself, we strongly discourage any attempt to alter those definitions. However, if it is absolutely necessary to replace a schema element shipped with the server, then you may do so by redefining the schema element with the X-SCHEMA-FILE extension to specify a schema file that is loaded after the one containing the original definition of that element. In the event that the same schema element is defined in multiple schema configuration files, the version that is loaded last is the one that will be used by the server.

 

Also note that the server will only permit users with the update-schema privilege to make changes to the server schema. You must also have access control permission to write to the cn=schema entry, or the bypass-acl privilege, which grants all access control rights.

 

Adding Schema via LDIF Files

Since the server maintains the schema definitions in LDIF files contained in the config/schema directory, you can add custom schema elements to the server by simply defining the schema in a properly-named file (starting with a two-digit number followed by a dash, and ending with ".ldif") in that directory. However, the new file will not automatically be loaded into the running server's schema, so the server will need to be restarted for the changes to take effect, and if there are any problems with any of the schema elements defined in the file (e.g., a syntax error in a definition, or a reference to an undefined schema element), then you will need to edit the file to correct the error and restart the server for the new version to be loaded.

 

The load-ldap-schema-file tool provides a better alternative to the above process, with two clear advantages:

 

  • The tool will validate the definitions contained in the schema file to catch any potential problems with those definitions.

 

  • The tool will invoke an administrative task in the server that will cause it to load the contents of that schema file into the running schema without the need for a restart.

 

To run this tool, provide the normal arguments needed to connect and authenticate to the server, and provide the --schemaFile argument to specify the location of the file to load on the server filesystem. For example:

 

 

$ bin/load-ldap-schema-file --hostname ds.example.com --port 389 \
       --bindDN "cn=Directory Manager" --promptForBindPassword \
       --schemaFile /tmp/98-example-schema.ldif
Enter the bind password:
 
Successfully validated the schema file contents
Successfully copied the schema file into directory
/ds/UnboundID-DS/config/schema
Successfully scheduled task Add Schema File 98-example-schema.ldif 20160102030405.678Z.  Waiting for it to complete
Successfully loaded the contents of schema file /tmp/98-example-schema.ldif into the server schema

 

Migrating Schema from Another LDAP Server

If you're migrating from another directory server that already has all of the schema elements that you want to use, the migrate-ldap-schema tool can help with that. This tool will read the schema from your existing server, identify any schema elements that it contains that aren't already in the UnboundID server schema, and will either add those schema elements directly to the UnboundID server over LDAP or will write them to a schema file that you can edit if necessary and then install with the load-ldap-schema-file tool.

 

The migrate-ldap-schema tool provides two modes of operation. By default, if you run it without any arguments, it will use an interactive mode in which it will prompt for all of the information that it needs to run. But you can also provide all of the necessary information with command-line arguments to operate in a non-interactive mode.

 

The following output demonstrates using this tool in interactive mode, using bold text for any input and non-bold text for program output:

$ bin/migrate-ldap-schema 


>>>> UnboundID Schema Migration Tool

This tool may be used to assist in the process of migrating schema information from an LDAP server into an instance of the UnboundID Data Store. It provides the ability to migrate attribute type and object class definitions which are contained in the source LDAP server but are not included in the schema of the target UnboundID Data Store

Press RETURN to continue


>>>> Source Server Information

Provide information about the source LDAP server from which to read schema information. The account used to communicate with this server must have permission to read the attribute type and object class definitions contained in the server schema

Provide the address of the source server instance

Server address [localhost]: dsee.example.com

Provide the port of the source server instance

Server port [389]: 389

Specify the type of security that should be used when communicating with the source server

1) No security
2) SSL
3) StartTLS

Enter option [1]: 1
Provide information about the account to use when authenticating to the source server

Bind DN [cn=Directory Manager]: cn=Directory Manager
Password for 'cn=Directory Manager':


>>>> Target Server Information

Provide information about the target UnboundID Data Store instance whose schema should be compared with that of the source server. The account used to communicate with this server must have permission to read the attribute type and object class definitions contained in the server schema, and if changes are to be applied over LDAP then that account must have permission to update the server schema

Provide the address of the target server instance

Server address [localhost]: unboundid-ds.example.com

Provide the port of the target server instance

Server port [389]: 389

Specify the type of security that should be used when communicating with the target server

1) No security
2) SSL
3) StartTLS

Enter option [1]: 1
Provide information about the account to use when authenticating to the target server

Bind DN [cn=Directory Manager]: cn=Directory Manager
Password for 'cn=Directory Manager':


>>>> Identify Schema Differences

Reading schema from the source server ... Done
Reading schema from the target server ... Done

Identifying attribute types contained in the source server schema that are not in the target schema ... Found 950 missing attribute types

Identifying object classes contained in the source server schema that are not in the target schema ... Found 164 missing object classes

Please indicate how you would like to handle the missing schema elements
1) Add the schema elements to the UnboundID Data Store instance over LDAP
2) Write the schema elements to a file

q) quit

Enter option [2]: 2

Enter the filename to use [98-migrated-schema.ldif]: 98-migrated-schema.ldif
Wrote 950 attribute types and 164 object classes to schema file 98-migrated-schema.ldif

 

The same result can also be accomplished with the following non-interactive command:

 

$ bin/migrate-ldap-schema --sourceHost dsee.example.com \
      --sourcePort 389 \
      --sourceBindDN "cn=Directory Manager" \
      --sourceBindPasswordFile dsee-password.txt \
      --targetHost unboundid-ds.example.com \
      --targetPort 389 \
      --targetBindDN "cn=Directory Manager" \
      --targetBindPasswordFile unboundid-ds-password.txt \
      --schemaFileName 98-migrated-schema.ldif \
      --no-prompt

>>>> Identify Schema Differences
 

Reading schema from the source server ... Done
Reading schema from the target server ... Done
 

Identifying attribute types contained in the source server schema that are not in the target schema ... Found 950 missing attribute types
 

Identifying object classes contained in the source server schema that are not in the target schema ... Found 164 missing object classes

Wrote 950 attribute types and 164 object classes to schema file 98-migrated-schema.ldif

 

Although the tool provides an option to add the schema elements directly into the UnboundID server instance (by selecting the appropriate option in interactive mode, or using the --applyChanges argument instead of --schemaFileName in non-interactive mode), the source server's schema will likely include a large number of schema elements that are specific to the operation of that server and won't be needed by your applications when running against the UnboundID server. To avoid cluttering the UnboundID server schema with unnecessary definitions specific to your previous directory server, you may want to write the schema elements to a file and remove any elements that aren't specifically needed by your data.