Starting and Stopping Your Server Instance
Configuring the Server Instance
Configuring the Proxy Components
Configuring Security Between Clients and Servers
Configuring Security Between the Proxy and the Data Source
Configuring Servers With the Control Panel
Monitoring Sun OpenDS Standard Edition
Running the Server as a Non-Root User
Working With Object Identifiers (OIDs)
Extending the Directory Schema
Extending the Schema With a Custom Schema File
You can add new attribute types to the schema by using the ldapmodify command. The attribute types syntax requires that you provide at least a valid OID to define a new element. In typical applications, you can optionally include the following identifiers for the attribute type. To see the full set of attribute type elements, see Understanding Attribute Types in Sun OpenDS Standard Edition 2.2 Architectural Reference.
Required. Specifies the OID that uniquely identifies the attribute type in the directory server. The LDAP v3 specification requires the OID to be a numeric number, but the directory server supports the use of non-numeric OIDs for easy identification as long as the schema is used internally within the organization. The format is attributename-oid, for example, telephoneNumber-oid. Each non-numeric OID must have its corresponding numeric OID defined in the schema.
Optional. Specifies the set of human-readable names that are used to refer to the attribute type. If there is a single name, enclose it in single quotes, for example, 'blogURL'. If there are multiple names, enclose each name in single quotes separated by spaces, and then enclose the entire set of names within parentheses, for example, ( 'blog' 'blogURL' ). Ensure that there is a space between the left parenthesis and the name, and a space before the closing parenthesis.
Optional. Specifies the superior attribute type when you want one attribute type to inherit elements from another attribute type. The matching rule and attribute syntax specifications from the superior attribute type can be inherited by the subordinate type if it does not override the superior attribute type definition. The OID, any of the human-readable names associated with the superior attribute type or both can be used to collectively reference all of the subordinate attribute types.
Optional. Specifies a human-readable description of the attribute type.
Optional. Specifies the attribute syntax for use with the attribute type. If provided, it should be given as a numeric OID. The core syntaxes are defined in section 3.3. of RFC 4517 and in Appendix A of the same document.
Optional. Specifies whether the attributes of that type are allowed to have only a single value in any entry in which they appear. If SINGLE-VALUE is not present, the attributes are allowed to have multiple distinct values in the same entry.
Optional. Indicates that the values of the attributes of the given type cannot be modified by external clients (that is, the values can be modified only by internal processing within the directory server).
Optional. Indicates how the attribute is to be used. Possible values are as follows: userApplications. Used to store user data. directoryOperation. Used to store data required for internal processing within the directory server. distributeOperation. Used to store operational data that must be synchronized across directory servers in the topology. dSAOperation. Used to store operational data that is specific to a particular directory server and should not be synchronized across the topology.
Optional. Specifies the extensions available to the attribute type. The directory server provides the following extensions: X-ORIGIN. Provides information on where the attribute type is defined. The element is a non-standard tool that the user can use to locate the schema element. Examples could include the RFC number (RFC4517), Sun OpenDS SE Directory Server and others. X-SCHEMA-FILE. Indicates which schema file contains the attribute type definition. Used for internal purposes only and is not exposed to clients. You can use this extension to specify where the directory server should store your custom schema definitions. X-APPROX. Indicates which approximate matching rule should be used for the attribute type. If specified, the value should be the name of the OID of a registered approximate matching rule.
For example, you can specify the addition of a new attribute type, blogURL, in an LDIF file that will be added to the schema.
$ cat blogURL.ldif dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'OpenDS Directory Server' USAGE userApplications )
Note - Pay special attention to the spaces in an attribute type declaration. The LDAP specification requires that a space exist between the opening parenthesis and the OID, and the value of the USAGE element and the closing parenthesis. Further, the LDIF specification states that LDIF parsers should ignore exactly one space at the beginning of each line. Therefore, it is a good practice to add two (2) spaces at the beginning of the line that starts with an element keyword. For example, add two spaces before NAME, DESC, SYNTAX, SINGLE-VALUE, X-ORIGIN, and USAGE in the previous example.
The OIDs used in this example are for illustration purposes only and should not be implemented in your directory.
The cn=schema entry has a multivalued attribute, attributeTypes, that contains definitions of each attribute type in the directory schema. You can view the schema definitions by using the ldapsearch command.
Manipulation of the cn=schema suffix is regarded as an administrative action and, as such, it is recommended that you use the administration connector when accessing this suffix. See Managing Administration Traffic to the Server for more information.
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \ --baseDN cn=schema --searchScope base \ "(objectclass=*)" attributeTypes dn: cn=schema attributeTypes: ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch SUBSTR caseIgnore 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' ) ...(more output)...
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \ -b cn=schema -s base --dontWrap "(objectclass=*)" attributeTypes | grep "telexNumber" attributeTypes: ( 2.5.4.21 NAME 'telexNumber' SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 X-ORIGIN 'RFC 4519' )
The cn=schema entry has a multivalued attribute, attributeTypes, that contains definitions of each attribute type in the directory schema. You add custom schema definitions by using the ldapmodify command. This example adds an attribute named blog.
Manipulation of the cn=schema suffix is regarded as an administrative action and, as such, it is recommended that you use the administration connector when accessing this suffix. See Managing Administration Traffic to the Server for more information.
dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'OpenDS Directory Server' USAGE userApplications )
$ ldapmodify -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \ -a -f blogURL.ldif Processing MODIFY request for cn=schema MODIFY operation successful for DN cn=schema
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \ -b cn=schema -s base --dontWrap "(objectclass=*)" attributeTypes | grep 'blog' attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'OpenDS Directory Server' USAGE userApplications )
Note - The directory server automatically adds new attribute definitions to the 99user.ldif file.
The cn=schema entry has a multivalued attribute, attributeTypes, that contains definitions of each attribute type in the directory schema. You can delete definitions with X-ORIGIN 'user defined' by using the ldapmodify command. The directory server does not allow deletions to other definitions.
Caution - Be careful when deleting attribute types, because doing so can harm your directory. Do not delete an attribute type unless absolutely necessary. |
Manipulation of the cn=schema suffix is regarded as an administrative action and, as such, it is recommended that you use the administration connector when accessing this suffix. For more information, see Managing Administration Traffic to the Server.
dn: cn=schema changetype: modify delete: attributeTypes attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'OpenDS Directory Server' USAGE userApplications )
$ ldapmodify -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \ --defaultAdd --fileName "remove_blogURL.ldif" Processing MODIFY request for cn=schema MODIFY operation successful for DN cn=schema