The schema of the LDAP

Schema is an important part of LDAP, similar to the schema definition of a database, the LDAP schema defines the structure and rules that the LDAP directory should follow, such as what attributes a objectclass will have, what structures these properties are, etc. The schema gives the LDAP server a way to identify the categories, attributes, and other information in the LDAP directory, which can be identified by the LDAP server.
In the LDAP schema, there are four important elements:
1. Objectclass
ObjectClass defines a category that is used by a different directory (in LDAP, which is a entry), which describes what attributes the directory should have, which attributes are required, and which are optional. A objectclass definition includes the name (name), description (DESC), the type (structural or auxilary, whether it is structural or auxiliary), the required property (must), optional attribute (May), and so on.
2. Attribute
attribute is a property that may be included in the above objectclass, including the name, data type, single-value or multi-value, and matching rules. The following is illustrated with specific examples.
3. Syntax
Syntax is the "syntax" in LDAP, which is actually the data type and data constraints that are used in LDAP, which is defined by the data constraints in the X.500. The definition requires an ID (follow X.500) and a description (DESP)
4. Matching Rules
is used to specify a matching rule for a property, which in effect defines a special syntax alias, which allows the LDAP server to recognize and match the defined attributes.
The main elements of the LDAP schema are these, which are listed below for some LDAP-defined or now more generic schemas, which should be recognized by the general LDAP server.
This is the definition of a objectclass named Subschema:
(2.5.20.1 NAME ' subschema ' auxiliary
May (Ditstructurerules $ nameforms $ ditcontentrules $
Objectclasses $ attributetypes $ matchingrules $ matchingruleuse))
The first is the ID, here is the 2.5.20.1, followed by the name,auxiliary description is auxiliary, then the definition of the optional attribute, Subschema does not define the must attribute, if need to define, should be same as may, the attribute is placed in the must () and separated by $

Then look at a property definition:
(2.5.4.3 name ' CN ' SUP name Equality caseignorematch)
You can see that the parent property of the CN property is name, which matches the equality of caseignorematch (the matching principle is equality, and the substr is a string match, ordering is a sequential match)

Syntax definitions are generally relatively simple, such as:
(1.3.6.1.4.1.1466.115.121.1.6 DESC ' String ')
This definition shows that this string of numbers 1.3.6.1.4.1.1466.115.121.1.5 the string in LDAP, and the definition of this string is related to X.500, including its storage, the amount of space it occupies, and so on.
Finally, take a look at the example of matching rule, which mentioned caseignorematch, just look at him.
(2.5.13.2 NAME ' Caseignorematch '
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15)
In fact, 1.3.6.1.4.1.1466.115.121.1.15 is the ID of the LDAP data type directory string, stating that the previous CN needs to be equal to this data type to be valid.
There are many common schema definitions in RFC2252, and LDAP servers should support these basic schemas. OK, now basically to the LDAP schema has a general description, there may be not in place or inappropriate, but also hope you correct.

Schema-like field descriptions for relational databases, including field names, data types, data lengths, and so on. The system has some default schema, my default schema file
Under the/usr/local/openldap/etc/openldap/schema, the most important thing is core.schema. It defines some of the most basic fields.
To adapt to our application, we create our own schema file. The Shema file I created is as follows: (file name: Kunmail.schema)
#
# KUNMAIL-LDAP V3 Directory Schema
#
# written by Msn:[email protected]
#
# Attribute Type Definitions
AttributeType (1.3.6.1.4.1.7914.1.2.1.1 NAME ' username '
DESC ' name of the user on the MailSystem '
Equality Caseignoreia5match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
Single-value)
AttributeType (1.3.6.1.4.1.7914.1.2.1.2 NAME ' Vuid '
DESC ' UID of the user on the MailSystem '
Equality Integermatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
Single-value)
AttributeType (1.3.6.1.4.1.7914.1.2.1.3 NAME ' Vgid '
DESC ' GID of the user on the MailSystem '
Equality Integermatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
Single-value)
AttributeType (1.3.6.1.4.1.7914.1.2.1.4 NAME ' Maildir '
DESC ' Path to the Maildir/mbox on the mail system '
Equality Caseexactmatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
Single-value)
AttributeType (1.3.6.1.4.1.7914.1.2.1.5 NAME ' forwardaddr '
SUBSTR Caseignoresubstringsmatch
DESC ' Forward mail address '
Equality Caseignoreia5match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26)
AttributeType (1.3.6.1.4.1.7914.1.2.1.6 NAME ' quota '
DESC ' The amount of space the user can use until all further messages get bounced. '
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
Single-value)
AttributeType (1.3.6.1.4.1.7914.1.2.1.7 NAME ' Storehost '
DESC ' on which Kunmail server the messagestore of this user is located. '
Equality Caseignoreia5match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
Single-value)
AttributeType (1.3.6.1.4.1.7914.1.2.1.8 NAME ' delivery '
DESC ' program-to-execute for all incoming mails. '
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
Single-value)
AttributeType (1.3.6.1.4.1.7914.1.2.1.9 NAME ' CLEARPW '
DESC ' name of the user on the MailSystem '
Equality Caseignoreia5match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
Single-value)
AttributeType (1.3.6.1.4.1.7914.1.2.1.10 NAME ' home '
DESC ' program-to-execute for all incoming mails. '
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
Single-value)
AttributeType (1.3.6.1.4.1.7914.1.2.1.11 NAME ' Mailreplytext '
DESC ' A reply text for every incoming message '
SUBSTR Caseignoresubstringsmatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{4096}
Single-value)
AttributeType (1.3.6.1.4.1.7914.1.2.1.12 NAME ' active '
DESC ' The status of a user account:active, Nopop, disabled '
Equality Integermatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
Single-value)
# Object Class Definitions
objectclass (1.3.6.1.4.1.7914.1.2.2.1 NAME ' Kunmailuser '
DESC ' Kunmail-ldap User ' SUP top STRUCTURAL
Must (Username $ CN $ VUID $ vgid)
May (Maildir $ home $ CLEARPW $
FORWARDADDR $ Quota $
Storehost $ Delivery $
Mailreplytext $ active))
Now, let's talk about this schema file.
The start section is the definition of attributetype, which is equivalent to the field definition. The final objectclass is to define the properties that the data contains.
Here Kunmailuser this data to include Maildir $ home $ CLEARPW $ FORWARDADDR $ quota $ storehost $ delivery $ Mailreplytext $ in active
You can also include the username $ CN $ VUID $ vgid required option. Options are included with May (), and the required options are included with must (). DESC is a description item. The SUP represents the parent class (
A bit like object-oriented programming AH) Top means no parent class, he is the top of his own. Structural is the way of storage, no matter what he (I don't know)
Next, explain the AttributeType's description.
The first number is the serial number, at least what I think, maybe wrong, but ... Tube him.
Name is the name that represents the property
Desc is a description
Here is the way of matching, substr is a string match, equality is an equality match, these are in OpenLDAP Admin guide, not ugly understand
Syntax is the data type that represents the field. This admin guide also contains instructions.
Single-value indicates that this property has only one value, and some properties can have multiple values, such as a contact address. By default, it is multi-valued.

After the schema is ready, we will include this schema in the configuration file, and let the schema take effect.
In the middle of the configuration file slapd.conf the beginning of the section to add such a sentence:
Include/usr/local/openldap/etc/openldap/schema/kunmail.schema
It should be noted that before this sentence should be ensured that there is a sentence:
Include/usr/local/openldap/etc/openldap/schema/core.schema
Because there are some things in kunmail.schema that depend on Core.schema.

The schema of the LDAP