schema.sdf 19.1 KB
Newer Older
1
# $OpenLDAP$
Kurt Zeilenga's avatar
Kurt Zeilenga committed
2
# Copyright 1999-2008 The OpenLDAP Foundation, All Rights Reserved.
3
4
5
6
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.

H1: Schema Specification

Kurt Zeilenga's avatar
Kurt Zeilenga committed
7
This chapter describes how to extend the user schema used by
8
{{slapd}}(8).  The chapter assumes the reader is familiar with the
Kurt Zeilenga's avatar
Kurt Zeilenga committed
9
10
{{TERM:LDAP}}/{{TERM:X.500}} information model.

11
The first section, {{SECT:Distributed Schema Files}} details optional
12
13
14
15
16
17
18
19
20
schema definitions provided in the distribution and where to obtain
other definitions.
The second section, {{SECT:Extending Schema}}, details how to define
new schema items.
!if 0
The third section, {{SECT:Transferring Schema}} details how you can
export schema definitions from an LDAPv3 server and transform it
to {{slapd.conf}}(5) format.
!endif
21

Kurt Zeilenga's avatar
Kurt Zeilenga committed
22
This chapter does not discuss how to extend system schema used by
23
24
25
26
27
28
{{slapd}}(8) as this requires source code modification.  System
schema includes all operational attribute types or any object class
which allows or requires an operational attribute (directly or
indirectly).


29
30
H2: Distributed Schema Files

Kurt Zeilenga's avatar
Kurt Zeilenga committed
31
OpenLDAP Software is distributed with a set of schema specifications for
32
33
34
35
36
your use.  Each set is defined in a file suitable for inclusion
(using the {{EX:include}} directive) in your {{slapd.conf}}(5)
file.  These schema files are normally installed in the
{{F:/usr/local/etc/openldap/schema}} directory.

37
!block table; colaligns="LR"; coltags="F,N"; align=Center; \
38
	title="Table 8.1: Provided Schema Specifications"
39
40
41
42
43
44
45
File			Description
core.schema		OpenLDAP {{core}} (required)
cosine.schema		Cosine and Internet X.500 (useful)
inetorgperson.schema	InetOrgPerson (useful)
misc.schema		Assorted (experimental)
nis.schema		Network Information Services (FYI)
openldap.schema		OpenLDAP Project (experimental)
46
47
48
!endblock

To use any of these schema files, you only need to include the
49
desired file in the global definitions portion of your
50
51
52
53
54
55
56
57
{{slapd.conf}}(5) file.  For example:

>	# include schema
>	include /usr/local/etc/openldap/schema/core.schema
>	include /usr/local/etc/openldap/schema/cosine.schema
>	include /usr/local/etc/openldap/schema/inetorgperson.schema

Additional files may be available.  Please consult the OpenLDAP
Kurt Zeilenga's avatar
Kurt Zeilenga committed
58
{{TERM:FAQ}} ({{URL:http://www.openldap.org/faq/}}).
59
60
61
62

Note: You should not modify any of the schema items defined
in provided files.

Kurt Zeilenga's avatar
Kurt Zeilenga committed
63

64
65
H2: Extending Schema

Kurt Zeilenga's avatar
Kurt Zeilenga committed
66
Schema used by {{slapd}}(8) may be extended to support additional
Kurt Zeilenga's avatar
Kurt Zeilenga committed
67
68
69
70
71
72
syntaxes, matching rules, attribute types, and object classes.  This
chapter details how to add user application attribute types and
object classes using the syntaxes and matching rules already supported
by slapd.  slapd can also be extended to support additional syntaxes,
matching rules and system schema, but this requires some programming
and hence is not discussed here.
73

74
There are five steps to defining new schema:
75
^	obtain Object Identifier
76
+	choose a name prefix
77
78
79
80
+	create local schema file
+	define custom attribute types (if necessary)
+	define custom object classes

Kurt Zeilenga's avatar
Kurt Zeilenga committed
81

82
H3: Object Identifiers
83

84
85
86
Each schema element is identified by a globally unique {{TERM[expand]OID}}
(OID).  OIDs are also used to identify other objects.  They are
commonly found in protocols described by {{TERM:ASN.1}}.  In
87
particular, they are heavily used by the {{TERM[expand]SNMP}} (SNMP).
88
89
90
As OIDs are hierarchical, your organization can obtain one OID and
branch it as needed.  For example, if your organization were assigned
OID {{EX:1.1}}, you could branch the tree as follows:
91

92
!block table; colaligns="LR"; coltags="EX,N"; align=Center; \
93
	title="Table 8.2: Example OID hierarchy"
94
95
96
97
98
OID		Assignment
1.1		Organization's OID
1.1.1		SNMP Elements
1.1.2		LDAP Elements
1.1.2.1		AttributeTypes
Kurt Zeilenga's avatar
Kurt Zeilenga committed
99
1.1.2.1.1	x-my-Attribute
100
1.1.2.2		ObjectClasses
Kurt Zeilenga's avatar
Kurt Zeilenga committed
101
1.1.2.2.1	x-my-ObjectClass
102
103
104
!endblock

You are, of course, free to design a hierarchy suitable to your
105
organizational needs under your organization's OID. No matter what hierarchy you choose, you should maintain a registry of assignments you make.  This can be a simple flat file or something more sophisticated such as the {{OpenLDAP OID Registry}} ({{URL:http://www.openldap.org/faq/index.cgi?file=197}}).
106

107
For more information about Object Identifiers (and a listing service)
Kurt Zeilenga's avatar
Kurt Zeilenga committed
108
see {{URL:http://www.alvestrand.no/harald/objectid/}}.
109

Kurt Zeilenga's avatar
Kurt Zeilenga committed
110
.{{Under no circumstances should you hijack OID namespace!}}
Kurt Zeilenga's avatar
Kurt Zeilenga committed
111

112
113
114
115
116
To obtain a registered OID at {{no cost}}, apply for a OID
under the {{ORG[expand]IANA}} (ORG:IANA) maintained {{Private Enterprise}} arc.  
Any private enterprise (organization) may request a {{TERM[expand]PEN}} (PEN) to be assigned under this arc. Just fill out the IANA form at {{URL: http://pen.iana.org/pen/PenApplication.page}} and your official PEN will be sent to you usually within a few days. Your base OID will be something like {{EX:1.3.6.1.4.1.X}} where {{EX:X}} is an integer.

Note: PENs obtained using this form may be used for any purpose
Kurt Zeilenga's avatar
Kurt Zeilenga committed
117
including identifying LDAP schema elements.
118

Kurt Zeilenga's avatar
Kurt Zeilenga committed
119
Alternatively, OID name space may be available from a national
120
authority (e.g., {{ORG:ANSI}}, {{ORG:BSI}}).
Kurt Zeilenga's avatar
Kurt Zeilenga committed
121

122

Kurt Zeilenga's avatar
Kurt Zeilenga committed
123
H3: Naming Elements
124

125
In addition to assigning a unique object identifier to each schema
Quanah Gibson-Mount's avatar
Quanah Gibson-Mount committed
126
element, you should provide at least one textual name for each
Kurt Zeilenga's avatar
Kurt Zeilenga committed
127
128
element.  Names should be registered with the {{ORG:IANA}} or
prefixed with "x-" to place in the "private use" name space.
129

Kurt Zeilenga's avatar
Kurt Zeilenga committed
130
131
132
The name should be both descriptive and not likely to clash with
names of other schema elements.  In particular, any name you choose
should not clash with present or future Standard Track names (this
133
is assured if you registered names or use names beginning with "x-").
134

Kurt Zeilenga's avatar
Kurt Zeilenga committed
135
136
137
138
139
140
141
142
143
It is noted that you can obtain your own registered name
prefix so as to avoid having to register your names individually.
See {{REF:RFC4520}} for details.

In the examples below, we have used a short prefix '{{EX:x-my-}}'.
Such a short prefix would only be suitable for a very large, global
organization.  In general, we recommend something like '{{EX:x-de-Firm-}}'
(German company) or '{{EX:x-com-Example}}' (elements associated with
organization associated with {{EX:example.com}}).
144
145


146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
H3: Local schema file

The {{EX:objectclass}} and {{EX:attributeTypes}} configuration file
directives can be used to define schema rules on entries in the
directory.  It is customary to create a file to contain definitions
of your custom schema items.  We recommend you create a file
{{F:local.schema}} in {{F:/usr/local/etc/openldap/schema/local.schema}}
and then include this file in your {{slapd.conf}}(5) file immediately
after other schema {{EX:include}} directives.

>	# include schema
>	include /usr/local/etc/openldap/schema/core.schema
>	include /usr/local/etc/openldap/schema/cosine.schema
>	include /usr/local/etc/openldap/schema/inetorgperson.schema
>	# include local schema
>	include /usr/local/etc/openldap/schema/local.schema


164
H3: Attribute Type Specification
165

166
167
The {{attributetype}} directive is used to define a new attribute
type.  The directive uses the same Attribute Type Description
Kurt Zeilenga's avatar
Kurt Zeilenga committed
168
(as defined in {{REF:RFC4512}}) used by the attributeTypes
169
attribute found in the subschema subentry, e.g.:
170

Kurt Zeilenga's avatar
Kurt Zeilenga committed
171
E:	attributetype <{{REF:RFC4512}} Attribute Type Description>
172

173
where Attribute Type Description is defined by the following
Kurt Zeilenga's avatar
Kurt Zeilenga committed
174
{{TERM:ABNF}}:
175
176
177
178
179
180
181
182
183
184
185

>      AttributeTypeDescription = "(" whsp
>            numericoid whsp              ; AttributeType identifier
>          [ "NAME" qdescrs ]             ; name used in AttributeType
>          [ "DESC" qdstring ]            ; description
>          [ "OBSOLETE" whsp ]
>          [ "SUP" woid ]                 ; derived from this other
>                                         ; AttributeType
>          [ "EQUALITY" woid              ; Matching Rule name
>          [ "ORDERING" woid              ; Matching Rule name
>          [ "SUBSTR" woid ]              ; Matching Rule name
Kurt Zeilenga's avatar
Kurt Zeilenga committed
186
>          [ "SYNTAX" whsp noidlen whsp ] ; Syntax OID
187
188
189
190
191
192
193
194
195
196
197
198
199
200
>          [ "SINGLE-VALUE" whsp ]        ; default multi-valued
>          [ "COLLECTIVE" whsp ]          ; default not collective
>          [ "NO-USER-MODIFICATION" whsp ]; default user modifiable
>          [ "USAGE" whsp AttributeUsage ]; default userApplications
>          whsp ")"
>
>      AttributeUsage =
>          "userApplications"     /
>          "directoryOperation"   /
>          "distributedOperation" / ; DSA-shared
>          "dSAOperation"          ; DSA-specific, value depends on server
>

where whsp is a space ('{{EX: }}'), numericoid is a globally unique
Kurt Zeilenga's avatar
Kurt Zeilenga committed
201
OID in dotted-decimal form (e.g. {{EX:1.1.0}}), qdescrs is one or
Kurt Zeilenga's avatar
Kurt Zeilenga committed
202
more names, woid is either the name or OID optionally followed
Howard Chu's avatar
Howard Chu committed
203
by a length specifier (e.g {{EX:{10}}}).
204
205
206
207

For example, the attribute types {{EX:name}} and {{EX:cn}} are defined
in {{F:core.schema}} as:

Kurt Zeilenga's avatar
Kurt Zeilenga committed
208
>	attributeType ( 2.5.4.41 NAME 'name'
Kurt Zeilenga's avatar
Kurt Zeilenga committed
209
>		DESC 'name(s) associated with the object'
210
211
212
>		EQUALITY caseIgnoreMatch
>		SUBSTR caseIgnoreSubstringsMatch
>		SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
Kurt Zeilenga's avatar
Kurt Zeilenga committed
213
>	attributeType ( 2.5.4.3 NAME ( 'cn' 'commonName' )
Kurt Zeilenga's avatar
Kurt Zeilenga committed
214
215
216
217
218
219
220
221
>		DESC 'common name(s) assciated with the object'
>		SUP name )

Notice that each defines the attribute's OID, provides a short name,
and a brief description.  Each name is an alias for the OID.
{{slapd}}(8) returns the first listed name when returning results.

The first attribute, {{EX:name}}, holds values of {{EX:directoryString}}
Kurt Zeilenga's avatar
Kurt Zeilenga committed
222
223
224
225
({{TERM:UTF-8}} encoded Unicode) syntax.  The syntax is
specified by OID (1.3.6.1.4.1.1466.115.121.1.15 identifies the
directoryString syntax).  A length recommendation of 32768 is
specified.  Servers should support values of this length, but may
Quanah Gibson-Mount's avatar
Quanah Gibson-Mount committed
226
support longer values. The field does NOT specify a size constraint,
Kurt Zeilenga's avatar
Kurt Zeilenga committed
227
228
229
230
so is ignored on servers (such as slapd) which don't impose such
size limits.  In addition, the equality and substring matching uses
case ignore rules.  Below are tables listing commonly used syntax
and matching rules ({{slapd}}(8) supports these and many more).
231

232
!block table; align=Center; coltags="EX,EX,N"; \
233
	title="Table 8.3: Commonly Used Syntaxes"
Kurt Zeilenga's avatar
Kurt Zeilenga committed
234
235
Name			OID				Description
boolean			1.3.6.1.4.1.1466.115.121.1.7	boolean value
236
directoryString		1.3.6.1.4.1.1466.115.121.1.15	Unicode (UTF-8) string
Kurt Zeilenga's avatar
Kurt Zeilenga committed
237
distinguishedName	1.3.6.1.4.1.1466.115.121.1.12	LDAP {{TERM:DN}}
238
239
integer			1.3.6.1.4.1.1466.115.121.1.27	integer
numericString		1.3.6.1.4.1.1466.115.121.1.36	numeric string
Kurt Zeilenga's avatar
Kurt Zeilenga committed
240
OID			1.3.6.1.4.1.1466.115.121.1.38	object identifier
241
octetString		1.3.6.1.4.1.1466.115.121.1.40	arbitrary octets
242
243
!endblock

Kurt Zeilenga's avatar
Kurt Zeilenga committed
244
> 
Kurt Zeilenga's avatar
Kurt Zeilenga committed
245

246
!block table; align=Center; coltags="EX,N"; \
247
	title="Table 8.4: Commonly Used Matching Rules"
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
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
Quanah Gibson-Mount's avatar
Quanah Gibson-Mount committed
263
264
octetStringOrderingMatch		ordering	octet string
octetStringSubstringsMatch	ordering	octet string
265
objectIdentiferMatch			equality	object identifier
266
267
!endblock

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

Kurt Zeilenga's avatar
Kurt Zeilenga committed
272
273
Neither attribute is restricted to a single value.  Both are meant
for usage by user applications.  Neither is obsolete nor collective.
274
275
276
277

The following subsections provide a couple of examples.


Kurt Zeilenga's avatar
Kurt Zeilenga committed
278
H4: x-my-UniqueName
279
280

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

Kurt Zeilenga's avatar
Kurt Zeilenga committed
287
>	attributetype ( 1.1.2.1.1 NAME 'x-my-UniqueName'
288
289
290
291
292
293
>		DESC 'unique name with my organization' 
>		EQUALITY caseIgnoreMatch
>		SUBSTR caseIgnoreSubstringsMatch
>		SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>		SINGLE-VALUE )

Kurt Zeilenga's avatar
Kurt Zeilenga committed
294
295
296
However, if we want this name to be used in {{EX:name}} assertions,
e.g. {{EX:(name=*Jane*)}}, the attribute could alternatively be
defined as a subtype of {{EX:name}}, e.g.:
297

Kurt Zeilenga's avatar
Kurt Zeilenga committed
298
>	attributetype ( 1.1.2.1.1 NAME 'x-my-UniqueName'
299
300
301
302
>		DESC 'unique name with my organization' 
>		SUP name )


Kurt Zeilenga's avatar
Kurt Zeilenga committed
303
H4: x-my-Photo
304
305

Many organizations maintain a photo of each each user.  A
Kurt Zeilenga's avatar
Kurt Zeilenga committed
306
{{EX:x-my-Photo}} attribute type could be defined to hold a photo.
307
308
309
310
311
312
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.:

Kurt Zeilenga's avatar
Kurt Zeilenga committed
313
>	attributetype ( 1.1.2.1.2 NAME 'x-my-Photo'
314
315
316
317
>		DESC 'a photo (application defined format)' 
>		SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
>		SINGLE-VALUE )

Kurt Zeilenga's avatar
Kurt Zeilenga committed
318
319
320
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.
321

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

Kurt Zeilenga's avatar
Kurt Zeilenga committed
327
Another alternative is for the attribute to hold a {{TERM:URI}}
328
pointing to the photo.  You can model such an attribute after
Kurt Zeilenga's avatar
Kurt Zeilenga committed
329
330
331
{{EX:labeledURI}} ({{REF:RFC2079}}) or simply create a subtype,
e.g.:

Kurt Zeilenga's avatar
Kurt Zeilenga committed
332
>	attributetype ( 1.1.2.1.3 NAME 'x-my-PhotoURI'
Kurt Zeilenga's avatar
Kurt Zeilenga committed
333
334
>		DESC 'URI and optional label referring to a photo' 
>		SUP labeledURI )
335
336
337
338
339
340


H3: Object Class Specification

The {{objectclasses}} directive is used to define a new object
class.  The directive uses the same Object Class Description
Kurt Zeilenga's avatar
Kurt Zeilenga committed
341
(as defined in {{REF:RFC4512}}) used by the objectClasses
342
attribute found in the subschema subentry, e.g.:
343

Kurt Zeilenga's avatar
Kurt Zeilenga committed
344
E:	objectclass <{{REF:RFC4512}} Object Class Description>
345

346
where Object Class Description is defined by the following
Kurt Zeilenga's avatar
Kurt Zeilenga committed
347
{{TERM:ABNF}}:
348

349
350
351
352
353
354
355
356
357
358
359
360
361
>	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
Kurt Zeilenga's avatar
Kurt Zeilenga committed
362
OID in dotted-decimal form (e.g. {{EX:1.1.0}}), qdescrs is one or more
363
names, and oids is one or more names and/or OIDs.
364
365


Kurt Zeilenga's avatar
Kurt Zeilenga committed
366
H4: x-my-PhotoObject
367

Kurt Zeilenga's avatar
Kurt Zeilenga committed
368
To define an {{auxiliary}} object class which allows
Kurt Zeilenga's avatar
Kurt Zeilenga committed
369
x-my-Photo to be added to any existing entry.
370

Kurt Zeilenga's avatar
Kurt Zeilenga committed
371
372
>	objectclass ( 1.1.2.2.1 NAME 'x-my-PhotoObject'
>		DESC 'mixin x-my-Photo'
373
>		AUXILIARY
Kurt Zeilenga's avatar
Kurt Zeilenga committed
374
>		MAY x-my-Photo )
375
376


Kurt Zeilenga's avatar
Kurt Zeilenga committed
377
H4: x-my-Person
378

Kurt Zeilenga's avatar
Kurt Zeilenga committed
379
If your organization would like have a private {{structural}}
380
381
object class to instantiate users, you can subclass one of
the existing person classes, such as {{EX:inetOrgPerson}}
Kurt Zeilenga's avatar
Kurt Zeilenga committed
382
({{REF:RFC2798}}), and add any additional attributes which
383
384
you desire.

Kurt Zeilenga's avatar
Kurt Zeilenga committed
385
>	objectclass ( 1.1.2.2.2 NAME 'x-my-Person'
386
387
>		DESC 'my person'
>		SUP inetOrgPerson
Kurt Zeilenga's avatar
Kurt Zeilenga committed
388
389
>		MUST ( x-my-UniqueName $ givenName )
>		MAY x-my-Photo )
390

391
The object class inherits the required/allowed attribute
Kurt Zeilenga's avatar
Kurt Zeilenga committed
392
393
types of {{EX:inetOrgPerson}} but requires {{EX:x-my-UniqueName}}
and {{EX:givenName}} and allows {{EX:x-my-Photo}}.
394
395
396
397

!if 0
H2: Transferring Schema

Kurt Zeilenga's avatar
Kurt Zeilenga committed
398
Since the {{slapd.conf}}(5) schema directives use {{REF:RFC4512}}
Kurt Zeilenga's avatar
Kurt Zeilenga committed
399
400
format values, you can extract schema elements published by any
{{TERM:LDAPv3}} server and easily construct directives for use with
401
402
403
{{slapd}}(8).

LDAPv3 servers publish schema elements in special {{subschema}}
Kurt Zeilenga's avatar
Kurt Zeilenga committed
404
405
406
407
408
409
410
411
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
412
413
414
415
416
417

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

Kurt Zeilenga's avatar
Kurt Zeilenga committed
418
419
420
where "cn=Subschema" is the value of subschemaSubentry returned in
the prior search.

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

>	dn: cn=Subschema
Kurt Zeilenga's avatar
Kurt Zeilenga committed
425
426
427
428
429
430
>	objectClasses: ( 1.1.2.2.2 NAME 'x-my-Person' DESC 'my person' SUP inet
>	 OrgPerson MUST ( x-my-UniqueName $ givenName ) MAY x-my-Photo )
>	attributeTypes: ( 1.1.2.1.1 NAME 'x-my-UniqueName' DESC 'unique name wi
>	 th my organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstrin
>	 gsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
>	attributeTypes: ( 1.1.2.1.2 NAME 'x-my-Photo' DESC 'a photo (applicatio
431
432
433
434
435
436
437
>	 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
Kurt Zeilenga's avatar
Kurt Zeilenga committed
438
439
440
(e.g. {{EX:s/attributeTypes:/attributeType /}} and
{{EX:s/objectClasses:/objectClass /}}).
^ reorder lines so each element is defined before first use
441
442
443
444
445
^ 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:

Kurt Zeilenga's avatar
Kurt Zeilenga committed
446
>	attributetype ( 1.1.2.1.1 NAME 'x-my-UniqueName'
447
448
449
450
451
>		DESC 'unique name with my organization' 
>		EQUALITY caseIgnoreMatch
>		SUBSTR caseIgnoreSubstringsMatch
>		SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>		SINGLE-VALUE )
Kurt Zeilenga's avatar
Kurt Zeilenga committed
452
>	attributeType ( 1.1.2.1.2 NAME 'x-my-Photo'
453
454
>		DESC 'a photo (application defined format)'
>		SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
Kurt Zeilenga's avatar
Kurt Zeilenga committed
455
>	objectClass ( 1.1.2.2.2 NAME 'x-my-Person'
456
457
>		DESC 'my person'
>		SUP inetOrgPerson
Kurt Zeilenga's avatar
Kurt Zeilenga committed
458
459
>		MUST ( x-my-UniqueName $ givenName )
>		MAY x-my-Photo )
460

Kurt Zeilenga's avatar
Kurt Zeilenga committed
461
Save in an appropriately named file (e.g. {{F:local.schema}}).
Kurt Zeilenga's avatar
Kurt Zeilenga committed
462
You may now include this file in your {{slapd.conf}}(5) file.
463
!endif
Kurt Zeilenga's avatar
Kurt Zeilenga committed
464
465
466
467
468


H3: OID Macros

To ease the management and use of OIDs, {{slapd}}(8) supports
Kurt Zeilenga's avatar
Kurt Zeilenga committed
469
470
471
472
{{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:
Kurt Zeilenga's avatar
Kurt Zeilenga committed
473
474
475
476
477
478

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

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

Kurt Zeilenga's avatar
Kurt Zeilenga committed
479
>	objectIdentifier myOID	1.1
Howard Chu's avatar
Howard Chu committed
480
481
482
483
>	objectIdentifier mySNMP	myOID:1
>	objectIdentifier myLDAP	myOID:2
>	objectIdentifier myAttributeType	myLDAP:1
>	objectIdentifier myObjectClass	myLDAP:2
Kurt Zeilenga's avatar
Kurt Zeilenga committed
484
>	attributetype ( myAttributeType:3 NAME 'x-my-PhotoURI'
Kurt Zeilenga's avatar
Kurt Zeilenga committed
485
486
>		DESC 'URI and optional label referring to a photo' 
>		SUP labeledURI )
Kurt Zeilenga's avatar
Kurt Zeilenga committed
487
488
>	objectclass ( myObjectClass:1 NAME 'x-my-PhotoObject'
>		DESC 'mixin x-my-Photo'
Kurt Zeilenga's avatar
Kurt Zeilenga committed
489
>		AUXILIARY
Kurt Zeilenga's avatar
Kurt Zeilenga committed
490
>		MAY x-my-Photo )
Kurt Zeilenga's avatar
Kurt Zeilenga committed
491