schema.sdf

OpenLdap是LDAP的开源项目

> 

!block table; align=Center; coltags="EX,N"; \
	title="Table 8.4: Commonly Used Matching Rules"
Name					Type		Description
booleanMatch				equality	boolean
caseIgnoreMatch				equality	case insensitive, space insensitive
caseIgnoreOrderingMatch			ordering	case insensitive, space insensitive
caseIgnoreSubstringsMatch		substrings	case insensitive, space insensitive
caseExactMatch				equality	case sensitive, space insensitive
caseExactOrderingMatch			ordering	case sensitive, space insensitive
caseExactSubstringsMatch		substrings	case sensitive, space insensitive
distinguishedNameMatch			equality	distinguished name
integerMatch				equality	integer
integerOrderingMatch			ordering	integer
numericStringMatch			equality	numerical
numericStringOrderingMatch		ordering	numerical
numericStringSubstringsMatch		substrings	numerical
octetStringMatch			equality	octet string
octetStringOrderingStringMatch		ordering	octet string
octetStringSubstringsStringMatch	ordering	octet string
objectIdentiferMatch			equality	object identifier
!endblock

The second attribute, {{EX:cn}}, is a subtype of {{EX:name}} hence
it inherits the syntax, matching rules, and usage of {{EX:name}}.
{{EX:commonName}} is an alternative name.

Neither attribute is restricted to a single value.  Both are meant
for usage by user applications.  Neither is obsolete nor collective.

The following subsections provide a couple of examples.


H4: myUniqueName

Many organizations maintain a single unique name for each user.
Though one could use {{EX:displayName}} ({{REF:RFC2798}}), this
attribute is really meant to be controlled by the user, not the
organization.  We could just copy the definition of {{EX:displayName}}
from {{F:inetorgperson.schema}} and replace the OID, name, and
description, e.g:

>	attributetype ( 1.1.2.1.1 NAME 'myUniqueName'
>		DESC 'unique name with my organization' 
>		EQUALITY caseIgnoreMatch
>		SUBSTR caseIgnoreSubstringsMatch
>		SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>		SINGLE-VALUE )

However, if we want this name to be included in
{{EX:name}} assertions [e.g. {{EX:(name=*Jane*)}}], the attribute
could alternatively be defined as a subtype of {{EX:name}}, e.g.:

>	attributetype ( 1.1.2.1.1 NAME 'myUniqueName'
>		DESC 'unique name with my organization' 
>		SUP name )


H4: myPhoto

Many organizations maintain a photo of each each user.  A
{{EX:myPhoto}} attribute type could be defined to hold a photo.
Of course, one could use just use {{EX:jpegPhoto}} ({{REF:RFC2798}})
(or a subtype) to hold the photo.  However, you can only do
this if the photo is in {{JPEG File Interchange Format}}.
Alternatively, an attribute type which uses the {{Octet String}}
syntax can be defined, e.g.:

>	attributetype ( 1.1.2.1.2 NAME 'myPhoto'
>		DESC 'a photo (application defined format)' 
>		SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
>		SINGLE-VALUE )

In this case, the syntax doesn't specify the format of the photo.
It's assumed (maybe incorrectly) that all applications accessing
this attribute agree on the handling of values.

If you wanted to support multiple photo formats, you could define
a separate attribute type for each format, prefix the photo
with some typing information, or describe the value using
{{TERM:ASN.1}} and use the {{EX:;binary}} transfer option.

Another alternative is for the attribute to hold a {{TERM:URI}}
pointing to the photo.  You can model such an attribute after
{{EX:labeledURI}} ({{REF:RFC2079}}) or simply create a subtype,
e.g.:

>	attributetype ( 1.1.2.1.3 NAME 'myPhotoURI'
>		DESC 'URI and optional label referring to a photo' 
>		SUP labeledURI )


H3: Object Class Specification

The {{objectclasses}} directive is used to define a new object
class.  The directive uses the same Object Class Description
(as defined in {{REF:RFC2252}}) used by the objectClasses
attribute found in the subschema subentry, e.g.:

E:	objectclass <{{REF:RFC2252}} Object Class Description>

where Object Class Description is defined by the following
{{TERM:BNF}}:

>	ObjectClassDescription = "(" whsp
>		numericoid whsp      ; ObjectClass identifier
>		[ "NAME" qdescrs ]
>		[ "DESC" qdstring ]
>		[ "OBSOLETE" whsp ]
>		[ "SUP" oids ]       ; Superior ObjectClasses
>		[ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
>			; default structural
>		[ "MUST" oids ]      ; AttributeTypes
>		[ "MAY" oids ]       ; AttributeTypes
>		whsp ")"

where whsp is a space ('{{EX: }}'), numericoid is a globally unique
OID in numeric form (e.g. {{EX:1.1.0}}), qdescrs is one or more
names, and oids is one or more names and/or OIDs.


H4: myPhotoObject

To define an {{auxiliary}} object class which allows
myPhoto to be added to any existing entry.

>	objectclass ( 1.1.2.2.1 NAME 'myPhotoObject'
>		DESC 'mixin myPhoto'
>		AUXILIARY
>		MAY myPhoto )


H4: myPerson

If your organization would like have a private {{structural}}
object class to instantiate users, you can subclass one of
the existing person classes, such as {{EX:inetOrgPerson}}
({{REF:RFC2798}}), and add any additional attributes which
you desire.

>	objectclass ( 1.1.2.2.2 NAME 'myPerson'
>		DESC 'my person'
>		SUP inetOrgPerson
>		MUST ( myUniqueName $ givenName )
>		MAY myPhoto )

The object class inherits the required/allowed attribute
types of {{EX:inetOrgPerson}} but requires {{EX:myUniqueName}}
and {{EX:givenName}} and allows {{EX:myPhoto}}.

!if 0
H2: Transferring Schema

Since the {{slapd.conf}}(5) schema directives use {{REF:RFC2252}}
format values, you can extract schema elements published by
any LDAPv3 server and easily construct directives for use with
{{slapd}}(8).

LDAPv3 servers publish schema elements in special {{subschema}}
entries (or subentries).  While {{slapd}}(8) publishes a single
subschema subentry normally named {{EX:cn=Subschema}}, this behavior
cannot be expected from other servers.  The subschema subentry
controlling a particular entry can be obtained by examining the
{{EX:subschemaSubentry}} attribute contained in the entry at the
root of each administrative context.  For example,

>	ldapsearch -LLL -x -b "dc=example,dc=com" -s base "(objectclass=*)" subschemaSubentry

To obtain the schema from a subschema subentry, you can use
ldapsearch(1) as follows (replace the search base as needed):

>	ldapsearch -LLL -x -b "cn=Subschema" -s base "(objectclass=subschema)" attributeTypes objectClasses

where "cn=Subschema" is the value of subschemaSubentry returned in
the prior search.

This will return {{TERM:LDIF}} output containing many type/value
pairs.  The following is an abbreviated example:

>	dn: cn=Subschema
>	objectClasses: ( 1.1.2.2.2 NAME 'myPerson' DESC 'my person' SUP inet
>	 OrgPerson MUST ( myUniqueName $ givenName ) MAY myPhoto )
>	attributeTypes: ( 1.1.2.1.1 NAME 'myUniqueName' DESC 'unique name wi
>	 th my organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubst
>	 ringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
>	attributeTypes: ( 1.1.2.1.2 NAME 'myPhoto' DESC 'a photo (applicatio
>	 n defined format)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40

Capture the output of the search in a file and then edit the file:

+ to contain only desired type/value pairs
^ join LDIF continuation lines
^ replace attribute type with directive name
(e.g. {{EX:s/attributeTypes:/attributeType /}} and
{{EX:s/objectClasses:/objectClass /}}).
^ reorder lines so each element is defined before first use
^ continue long directives over multiple lines

For the three type/value pairs in our example, the edit should
result in a file with contains of:

>	attributetype ( 1.1.2.1.1 NAME 'myUniqueName'
>		DESC 'unique name with my organization' 
>		EQUALITY caseIgnoreMatch
>		SUBSTR caseIgnoreSubstringsMatch
>		SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>		SINGLE-VALUE )
>	attributeType ( 1.1.2.1.2 NAME 'myPhoto'
>		DESC 'a photo (application defined format)'
>		SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
>	objectClass ( 1.1.2.2.2 NAME 'myPerson'
>		DESC 'my person'
>		SUP inetOrgPerson
>		MUST ( myUniqueName $ givenName )
>		MAY myPhoto )

Save in an appropriately named file (e.g. {{F:local.schema}}).
You may now include this file in your {{slapd.conf}}(5) file.
!endif


H3: OID Macros

To ease the management and use of OIDs, {{slapd}}(8) supports
{{Object Identifier}} macros.  The {{EX:objectIdentifier}} directive
is used to equate a macro (name) with a OID.  The OID may possibly
be derived from a previously defined OID macro.   The {{slapd.conf}}(5)
syntax is:

E:	objectIdentifier <name> { <oid> | <name>[:<suffix>] }

The following demonstrates definition of a set of OID macros
and their use in defining schema elements:

>	objectIdentifier myOID	1.1
>	objectIdentifier mySNMP	myOID:1
>	objectIdentifier myLDAP	myOID:2
>	objectIdentifier myAttributeType	myLDAP:1
>	objectIdentifier myObjectClass	myLDAP:2
>	attributetype ( myAttributeType:3 NAME 'myPhotoURI'
>		DESC 'URI and optional label referring to a photo' 
>		SUP labeledURI )
>	objectclass ( myObjectClass:1 NAME 'myPhotoObject'
>		DESC 'mixin myPhoto'
>		AUXILIARY
>		MAY myPhoto )