mirror of
https://git.openldap.org/openldap/openldap.git
synced 2025-01-30 13:30:57 +08:00
Split out schema from slapdconfig.sdf and flush it out a bit (more work needed).
Need separate "Advanced Access Control" chapter as well (but leaving 'basic' in slapdconfig.sdf.
This commit is contained in:
parent
b61cd98fb5
commit
b0c3355fa2
@ -48,6 +48,9 @@ PB:
|
|||||||
!include "dbtools.sdf"; chapter
|
!include "dbtools.sdf"; chapter
|
||||||
PB:
|
PB:
|
||||||
|
|
||||||
|
!include "schema.sdf"; chapter
|
||||||
|
PB:
|
||||||
|
|
||||||
#!include "tuning.sdf"; chapter
|
#!include "tuning.sdf"; chapter
|
||||||
#PB:
|
#PB:
|
||||||
|
|
||||||
|
161
doc/guide/admin/schema.sdf
Normal file
161
doc/guide/admin/schema.sdf
Normal file
@ -0,0 +1,161 @@
|
|||||||
|
# $OpenLDAP$
|
||||||
|
# Copyright 1999-2000, The OpenLDAP Foundation, All Rights Reserved.
|
||||||
|
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
|
||||||
|
|
||||||
|
H1: Schema Specification
|
||||||
|
|
||||||
|
This chapter describes how to extend slapd(8) schema. The
|
||||||
|
first section details how to extend schema using provided
|
||||||
|
schema files. The second section details how to define
|
||||||
|
new schema items.
|
||||||
|
|
||||||
|
H2: Distributed Schema Files
|
||||||
|
|
||||||
|
OpenLDAP is distributed with a set of schema specifications for
|
||||||
|
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.
|
||||||
|
|
||||||
|
!block table; colaligns="LR"; align=Center; \
|
||||||
|
title="Table 6.1: Provided Schema Specifications"
|
||||||
|
File Description
|
||||||
|
{{F:core.schema}} OpenLDAP {{core}} (required)
|
||||||
|
{{F:cosine.schema}} Cosine and Internet X.500 (useful)
|
||||||
|
{{F:inetorgperson.schema}} InetOrgPerson (useful)
|
||||||
|
{{F:misc.schema}} Assorted (experimental)
|
||||||
|
{{F:nadf.schema}} North American Directory Forum (FYI)
|
||||||
|
{{F:nis.schema}} Network Information Services (FYI)
|
||||||
|
{{F:openldap.schema}} OpenLDAP Project (experimental)
|
||||||
|
{{F:pilot.schema}} Cosine Pilot (obsolete)
|
||||||
|
!endblock
|
||||||
|
|
||||||
|
To use any of these schema files, you only need to include the
|
||||||
|
the desired file in the global definitions portion of your
|
||||||
|
{{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
|
||||||
|
FAQ ({{URL:http://www.openldap.org/faq/}}).
|
||||||
|
|
||||||
|
Note: You should not modify any of the schema items defined
|
||||||
|
in provided files.
|
||||||
|
|
||||||
|
H2: Extending Schema
|
||||||
|
|
||||||
|
Schema used by {{slapd}}(8) can be extended to support additional
|
||||||
|
syntaxes, matching rules, attribute types, and object classes.
|
||||||
|
This chapter details how to add attribute types and object classes
|
||||||
|
using the syntaxes and matching rules already support by slapd.
|
||||||
|
slapd(8) can also be extended to support additional syntaxes
|
||||||
|
and matching rules, but this requires some programming and hence
|
||||||
|
is not discussed here.
|
||||||
|
|
||||||
|
There are four steps to defining new schema:
|
||||||
|
^ obtain Object Identifer
|
||||||
|
+ create local schema file
|
||||||
|
+ define custom attribute types (if necessary)
|
||||||
|
+ define custom object classes
|
||||||
|
|
||||||
|
H2: Object Identifiers
|
||||||
|
|
||||||
|
Each schema element is identified by a globally unique
|
||||||
|
{{TERM[expand]OID}} ({{TERM:OID}}). OIDs are also used to identify
|
||||||
|
other objects.
|
||||||
|
They are commonly found in protocols described by {{TERM:ASN.1}}. In
|
||||||
|
particular, they are heavy used by Simple Network Management
|
||||||
|
Protocol (SNMP). 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:
|
||||||
|
|
||||||
|
!block table; colaligns="LR"; align=Center; \
|
||||||
|
title="Table 6.2: Example OID hierarchy"
|
||||||
|
OID Assignment
|
||||||
|
{{EX:1.1}} Organization's OID
|
||||||
|
{{EX:1.1.1}} SNMP Elements
|
||||||
|
{{EX:1.1.2}} LDAP Elements
|
||||||
|
{{EX:1.1.2.1}} AttributeTypes
|
||||||
|
{{EX:1.1.2.1.1}} myAttribute
|
||||||
|
{{EX:1.1.2.2}} ObjectClasses
|
||||||
|
{{EX:1.1.2.2.1}} myObjectClass
|
||||||
|
!endblock
|
||||||
|
|
||||||
|
You are, of course, free to design a hierarchy suitable to your
|
||||||
|
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 a
|
||||||
|
something more sophisticated such as the OpenLDAP OID Registry
|
||||||
|
{{URL:http://www.openldap.org/faq/index.cgi?file=197}}.
|
||||||
|
|
||||||
|
For more information about Object Identifers (and a listing
|
||||||
|
service) see {{URL:http://www.alvestrand.no/harald/objectid/}}.
|
||||||
|
|
||||||
|
.{{Under no circumstances should you use a fictious OID!}}
|
||||||
|
|
||||||
|
To obtain a fully registered OID at {{no cost}}, apply for
|
||||||
|
a OID under {{ORG[expand]IANA}} maintained
|
||||||
|
{{Private Enterprise}} arch. Any private enterprise (organization)
|
||||||
|
may request an OID to be assigned under this arch. Just fill
|
||||||
|
out the form at {{URL: http://www.iana.org/cgi-bin/enterprise.pl}}
|
||||||
|
and your official OID 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}} were {{EX:X}}
|
||||||
|
is an integer.
|
||||||
|
|
||||||
|
Note: Don't let the "MIB/SNMP" statement on the IANA page confuse you.
|
||||||
|
OIDs obtained using this form may be used for any purpose including
|
||||||
|
identifying LDAP schema elements.
|
||||||
|
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
|
||||||
|
H2: AttributeType Specification
|
||||||
|
|
||||||
|
{{B:To be specified.}}
|
||||||
|
|
||||||
|
E: attributetype <{{REF:RFC2252}} Attribute Type Description>
|
||||||
|
|
||||||
|
H2: ObjectClass Specification
|
||||||
|
|
||||||
|
The schema rules are defined by one or more
|
||||||
|
objectclass lines, and enforcement is turned on or off via the
|
||||||
|
schemacheck directives. The format of an {{EX:objectclass}} line is:
|
||||||
|
|
||||||
|
E: objectclass <{{REF:RFC2252}} Object Class Description>
|
||||||
|
|
||||||
|
This directive defines the schema rules for the object class
|
||||||
|
given by {{EX:<name>}}. Schema rules consist of the attributes the
|
||||||
|
entry is required to have (given by the requires {{EX:<attrs>}}
|
||||||
|
clause) and those attributes that it may optionally have (given
|
||||||
|
by the allows {{EX:<attrs>}} clause). In both clauses, {{EX:<attrs>}}
|
||||||
|
is a comma-separated list of attribute names.
|
||||||
|
|
||||||
|
For example, to define an object class called {{myPerson}}, you
|
||||||
|
might include a definition like this:
|
||||||
|
|
||||||
|
> objectclass ( 1.2.3 NAME 'myPerson'
|
||||||
|
> DESC 'my person'
|
||||||
|
> MUST ( cn $ sn )
|
||||||
|
> MAY ( mail $ phone $ fax ) )
|
||||||
|
|
||||||
|
|
@ -100,8 +100,8 @@ More details discussion of this directive can be found in the
|
|||||||
H4: attributetype <{{REF:RFC2252}} Attribute Type Description>
|
H4: attributetype <{{REF:RFC2252}} Attribute Type Description>
|
||||||
|
|
||||||
This directive defines an attribute type.
|
This directive defines an attribute type.
|
||||||
Please see the {{SECT:Schema Specification}} section of this
|
Please see the {{SECT:Schema Specification}} chapter
|
||||||
chapter for information regarding how to use this directive.
|
for information regarding how to use this directive.
|
||||||
|
|
||||||
|
|
||||||
H4: defaultaccess { none | compare | search | read | write }
|
H4: defaultaccess { none | compare | search | read | write }
|
||||||
@ -179,8 +179,8 @@ E: loglevel 256
|
|||||||
H4: objectclass <{{REF:RFC2252}} Object Class Description>
|
H4: objectclass <{{REF:RFC2252}} Object Class Description>
|
||||||
|
|
||||||
This directive defines an object class.
|
This directive defines an object class.
|
||||||
Please see the {{SECT:Schema Specification}} section of this
|
Please see the {{SECT:Schema Specification}} chapter for
|
||||||
chapter for information regarding how to use this directive.
|
information regarding how to use this directive.
|
||||||
|
|
||||||
|
|
||||||
H4: referral <URI>
|
H4: referral <URI>
|
||||||
@ -800,92 +800,6 @@ For more details on how to use the {{EX:access}} directive,
|
|||||||
consult the {{Advanced Access Control}} chapter.
|
consult the {{Advanced Access Control}} chapter.
|
||||||
!endif
|
!endif
|
||||||
|
|
||||||
H2: Schema Specification
|
|
||||||
|
|
||||||
The {{EX:objectclass}} and {{EX:attributeTypes}} configuration file
|
|
||||||
directives can be used to define schema rules on entries in the
|
|
||||||
directory.
|
|
||||||
|
|
||||||
H3: Object Identifiers
|
|
||||||
|
|
||||||
Each schema element is identified by a globally unique
|
|
||||||
{{TERM[expand]OID}} ({{TERM:OID}}). OIDs are also used to identify
|
|
||||||
other objects.
|
|
||||||
They are commonly found in protocols described by {{TERM:ASN.1}}. In
|
|
||||||
particular, they are heavy used by Simple Network Management
|
|
||||||
Protocol (SNMP). 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:
|
|
||||||
|
|
||||||
!block table; colaligns="LR"; coltags="EX,N"; align=Center; \
|
|
||||||
title="Table 5.4: Example OID hierarchy"
|
|
||||||
OID Assignment
|
|
||||||
1.1 Organization's OID
|
|
||||||
1.1.1 SNMP Elements
|
|
||||||
1.1.2 LDAP Elements
|
|
||||||
1.1.2.1 AttributeTypes
|
|
||||||
1.1.2.1.1 myAttribute
|
|
||||||
1.1.2.2 ObjectClasses
|
|
||||||
1.1.2.2.1 myObjectClass
|
|
||||||
!endblock
|
|
||||||
|
|
||||||
You are, of course, free to design a hierarchy suitable to your
|
|
||||||
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 a
|
|
||||||
something more sophisticated such as the OpenLDAP OID Registry
|
|
||||||
{{URL:http://www.openldap.org/faq/index.cgi?file=197}}.
|
|
||||||
|
|
||||||
For more information about Object Identifers (and a listing
|
|
||||||
service) see {{URL:http://www.alvestrand.no/harald/objectid/}}.
|
|
||||||
|
|
||||||
.{{Under no circumstances should you use a fictious OID!}}
|
|
||||||
|
|
||||||
To obtain a fully registered OID at {{no cost}}, apply for
|
|
||||||
a OID under {{ORG[expand]IANA}} maintained
|
|
||||||
{{Private Enterprise}} arch. Any private enterprise (organization)
|
|
||||||
may request an OID to be assigned under this arch. Just fill
|
|
||||||
out the form at {{URL: http://www.iana.org/cgi-bin/enterprise.pl}}
|
|
||||||
and your official OID 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}} were {{EX:X}}
|
|
||||||
is an integer.
|
|
||||||
|
|
||||||
Note: Don't let the "MIB/SNMP" statement on the IANA page confuse you.
|
|
||||||
OIDs obtained using this form may be used for any purpose including
|
|
||||||
identifying LDAP schema elements.
|
|
||||||
|
|
||||||
|
|
||||||
H3: AttributeType Specification
|
|
||||||
|
|
||||||
{{B:To be specified.}}
|
|
||||||
|
|
||||||
> attributetype <{{REF:RFC2252}} Attribute Type Description>
|
|
||||||
|
|
||||||
H3: ObjectClass Specification
|
|
||||||
|
|
||||||
The schema rules are defined by one or more
|
|
||||||
objectclass lines, and enforcement is turned on or off via the
|
|
||||||
schemacheck directives. The format of an {{EX:objectclass}} line is:
|
|
||||||
|
|
||||||
> objectclass <{{REF:RFC2252}} Object Class Description>
|
|
||||||
|
|
||||||
This directive defines the schema rules for the object class
|
|
||||||
given by {{EX:<name>}}. Schema rules consist of the attributes the
|
|
||||||
entry is required to have (given by the requires {{EX:<attrs>}}
|
|
||||||
clause) and those attributes that it may optionally have (given
|
|
||||||
by the allows {{EX:<attrs>}} clause). In both clauses, {{EX:<attrs>}}
|
|
||||||
is a comma-separated list of attribute names.
|
|
||||||
|
|
||||||
For example, to define an object class called {{myPerson}}, you
|
|
||||||
might include a definition like this:
|
|
||||||
|
|
||||||
> objectclass ( 1.2.3 NAME 'myPerson'
|
|
||||||
> DESC 'my person'
|
|
||||||
> MUST ( cn $ sn )
|
|
||||||
> MAY ( mail $ phone $ fax ) )
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
H2: Configuration File Example
|
H2: Configuration File Example
|
||||||
|
|
||||||
@ -896,9 +810,9 @@ database instances. The line numbers shown are provided for
|
|||||||
reference only and are not included in the actual file. First, the
|
reference only and are not included in the actual file. First, the
|
||||||
global configuration section:
|
global configuration section:
|
||||||
|
|
||||||
E: 1. # example config file - global configuration section
|
E: 1. # example config file - global configuration section
|
||||||
E: 2. include /usr/local/etc/schema/core.schema
|
E: 2. include /usr/local/etc/schema/core.schema
|
||||||
E: 3. referral ldap://root.openldap.org
|
E: 3. referral ldap://root.openldap.org
|
||||||
|
|
||||||
Line 1 is a comment. Lines 2 include another config file
|
Line 1 is a comment. Lines 2 include another config file
|
||||||
which containing {{core}} schema definitions.
|
which containing {{core}} schema definitions.
|
||||||
|
Loading…
Reference in New Issue
Block a user