mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-27 03:20:22 +08:00
Change formating... major updates to slapdconfig.sdf
This commit is contained in:
Kurt Zeilenga
parent
27ebe8534a
commit
63fffb0a7d
@ -11,7 +11,7 @@ you can create the database on-line using LDAP. With this
|
||||
method, you simply start up slapd and add entries using the
|
||||
LDAP client of your choice. This method is fine for relatively
|
||||
small databases (a few hundred or thousand entries,
|
||||
depending on your requirements). This method works for database
|
||||
depending on your requirements). This method works for database
|
||||
types which support updates.
|
||||
|
||||
The second method of database creation is to do it off-line
|
||||
@ -19,7 +19,7 @@ using special utilities provided with slapd. This method is
|
||||
best if you have many thousands of entries to create, which
|
||||
would take an unacceptably long time using the LDAP method,
|
||||
or if you want to ensure the database is not accessed while
|
||||
it is being created. Note that not all database types support
|
||||
it is being created. Note that not all database types support
|
||||
these utilitites.
|
||||
|
||||
|
||||
@ -30,44 +30,44 @@ With this method, you use the LDAP client of your choice
|
||||
once the database is created. You should be sure to set the
|
||||
following configuration options before starting slapd:
|
||||
|
||||
E: suffix <dn>
|
||||
> suffix <dn>
|
||||
|
||||
As described in the preceding section, this option says what
|
||||
entries are to be held by this database. You should set this
|
||||
to the DN of the root of the subtree you are trying to create.
|
||||
For example
|
||||
|
||||
E: suffix "dc=example, dc=com"
|
||||
> suffix "dc=example, dc=com"
|
||||
|
||||
You should be sure to specify a directory where the index
|
||||
files should be created:
|
||||
|
||||
E: directory <directory>
|
||||
> directory <directory>
|
||||
|
||||
For example:
|
||||
|
||||
E: directory /usr/local/var/openldap-ldbm
|
||||
> directory /usr/local/var/openldap-ldbm
|
||||
|
||||
You need to create this directory with appropriate permissions
|
||||
such that slapd can write to it.
|
||||
|
||||
You need to make it so you can connect to slapd as directory user
|
||||
with permission to add entries. You can configure the directory
|
||||
with permission to add entries. You can configure the directory
|
||||
to support a special {{super-user}} or {{root}} user just for
|
||||
this purpose. This is done through the following two options
|
||||
this purpose. This is done through the following two options
|
||||
in the database definition:
|
||||
|
||||
E: rootdn <dn>
|
||||
E: rootpw <passwd>
|
||||
> rootdn <dn>
|
||||
> rootpw <passwd>
|
||||
|
||||
For example:
|
||||
|
||||
E: rootdn "cn=Manager, dc=example, dc=com"
|
||||
E: rootpw secret
|
||||
> rootdn "cn=Manager, dc=example, dc=com"
|
||||
> rootpw secret
|
||||
|
||||
These options specify a DN and password that can be used
|
||||
to authenticate as the {{super-user}} entry of the database (i.e.,
|
||||
the entry allowed to do anything). The DN and password
|
||||
the entry allowed to do anything). The DN and password
|
||||
specified here will always work, regardless of whether the
|
||||
entry named actually exists or has the password given. This
|
||||
solves the chicken-and-egg problem of how to authenticate
|
||||
@ -76,14 +76,14 @@ and add entries before any entries yet exist.
|
||||
Finally, you should make sure that the database definition
|
||||
contains the index definitions you want:
|
||||
|
||||
E: index {<attrlist> | default} [pres,eq,approx,sub,none]
|
||||
> index {<attrlist> | default} [pres,eq,approx,sub,none]
|
||||
|
||||
For example, to index the cn, sn, uid and objectclass
|
||||
attributes the following index configuration lines could be
|
||||
used.
|
||||
|
||||
E: index cn,sn,uid
|
||||
E: index objectclass pres,eq
|
||||
> index cn,sn,uid
|
||||
> index objectclass pres,eq
|
||||
|
||||
See Section 4 on the configuration file for more details on
|
||||
this option. Once you have configured things to your liking,
|
||||
@ -93,22 +93,22 @@ followed by a Postmaster entry using the {{I:ldapadd}} tool, you
|
||||
could create an {{TERM:LDIF}} file called {{EX:entries.ldif}} with the
|
||||
contents:
|
||||
|
||||
E: dc=example, dc=com
|
||||
E: objectClass=dcObject
|
||||
E: objectClass=organization
|
||||
E: dc=example
|
||||
E: o=Example Corporation
|
||||
E: description=The Example Corporation
|
||||
E:
|
||||
E: cn=Postmaster, dc=example, dc=com
|
||||
E: objectClass=organizationalRole
|
||||
E: cn=Postmaster
|
||||
E: description=OpenLDAP Postmaster <Postmaster@example.com>
|
||||
> dc=example, dc=com
|
||||
> objectClass=dcObject
|
||||
> objectClass=organization
|
||||
> dc=example
|
||||
> o=Example Corporation
|
||||
> description=The Example Corporation
|
||||
>
|
||||
> cn=Postmaster, dc=example, dc=com
|
||||
> objectClass=organizationalRole
|
||||
> cn=Postmaster
|
||||
> description=OpenLDAP Postmaster <Postmaster@example.com>
|
||||
|
||||
and then use a command like this to actually create the
|
||||
entry:
|
||||
|
||||
E: ldapadd -f entries.ldif -x -D "cn=Manager, dc=example, dc=com" -w secret
|
||||
> ldapadd -f entries.ldif -x -D "cn=Manager,dc=example,dc=com" -w secret
|
||||
|
||||
The above command assumes settings provided in the above
|
||||
examples.
|
||||
@ -122,206 +122,216 @@ best if you have many thousands of entries to create, which
|
||||
would take an unacceptably long time using
|
||||
the LDAP method described above. These tools read the
|
||||
slapd configuration file and an input file containing a text
|
||||
representation of the entries to add. For database types which
|
||||
representation of the entries to add. For database types which
|
||||
support the tools, they produce the database files directly (otherwise
|
||||
you must use the on-line method above). There are several important
|
||||
configuration options you will want to be sure and set in the config
|
||||
file database definition first:
|
||||
|
||||
E: suffix <dn>
|
||||
> suffix <dn>
|
||||
|
||||
As described in the preceding section, this option says what
|
||||
entries are to be held by this database. You should set this
|
||||
to the DN of the root of the subtree you are trying to create.
|
||||
For example
|
||||
|
||||
E: suffix "dc=example, dc=com"
|
||||
> suffix "dc=example, dc=com"
|
||||
|
||||
You should be sure to specify a directory where the index
|
||||
files should be created:
|
||||
|
||||
E: directory <directory>
|
||||
> directory <directory>
|
||||
|
||||
For example:
|
||||
|
||||
E: directory /usr/local/var/openldap-ldbm
|
||||
> directory /usr/local/var/openldap-ldbm
|
||||
|
||||
Finally, you need to specify which indexes you want to build.
|
||||
This is done by one or more index options.
|
||||
|
||||
E: index {<attrlist> | default} [pres,eq,approx,sub,none]
|
||||
> index {<attrlist> | default} [pres,eq,approx,sub,none]
|
||||
|
||||
For example:
|
||||
|
||||
E: index cn,sn,uid pres,eq,approx
|
||||
E: index objectClass eq
|
||||
> index cn,sn,uid pres,eq,approx
|
||||
> index objectClass eq
|
||||
|
||||
This would create presence, equality and approximate
|
||||
indexes for the cn, sn, and uid attributes and an equality
|
||||
index for the objectClass attribute. See the configuration
|
||||
index for the objectClass attribute. See the configuration
|
||||
file section for more information on this option.
|
||||
|
||||
H3: The {{EX: slapadd}} program
|
||||
H3: The {{EX:slapadd}} program
|
||||
|
||||
Once you've configured things to your liking, you create the
|
||||
primary database and associated indexes by running the
|
||||
{{slapadd}}(8) program:
|
||||
|
||||
E: slapadd -l <inputfile> -f <slapdconfigfile>
|
||||
E: [-d <debuglevel>] [-n <integer>|-b <suffix>]
|
||||
> slapadd -l <inputfile> -f <slapdconfigfile>
|
||||
> [-d <debuglevel>] [-n <integer>|-b <suffix>]
|
||||
|
||||
The arguments have the following meanings:
|
||||
|
||||
E: -l <inputfile>
|
||||
> -l <inputfile>
|
||||
|
||||
Specifies the LDIF input file containing the entries to add in
|
||||
text form (described below in Section 8.3).
|
||||
|
||||
E: -f <slapdconfigfile>
|
||||
> -f <slapdconfigfile>
|
||||
|
||||
Specifies the slapd configuration file that tells where to
|
||||
create the indexes, what indexes to create, etc.
|
||||
|
||||
E: -d <debuglevel>
|
||||
> -d <debuglevel>
|
||||
|
||||
Turn on debugging, as specified by {{EX: <debuglevel>}}. The
|
||||
Turn on debugging, as specified by {{EX:<debuglevel>}}. The
|
||||
debug levels are the same as for slapd (see Section 6.1).
|
||||
|
||||
E: -n <databasenumber>
|
||||
> -n <databasenumber>
|
||||
|
||||
An optional argument that specifies the configuration file
|
||||
database for which to build. The first database listed
|
||||
is "1", the second "2", etc. By default, the first ldbm database
|
||||
in the configuration file is used. Should not be used in
|
||||
in the configuration file is used. Should not be used in
|
||||
conjunction with {{EX:-b}}.
|
||||
|
||||
E: -b <suffix>
|
||||
> -b <suffix>
|
||||
|
||||
An optional argument that specifies the configuration file
|
||||
database for which to build. The provided suffix is matched
|
||||
database for which to build. The provided suffix is matched
|
||||
against database {{EX:suffix}} to determine the database
|
||||
number. Should not be used in conjunction with {{EX:-n}}.
|
||||
number. Should not be used in conjunction with {{EX:-n}}.
|
||||
|
||||
|
||||
H3: The {{EX: ldif2index}} program
|
||||
H3: The {{EX:slapindex}} program
|
||||
|
||||
Sometimes it may be necessary to regenerate indices (such
|
||||
as after modifying {{slapd.conf}}(5)). This is possible using
|
||||
the {{slapindex}}(8) program. {{EX: slapindex}} is invoked
|
||||
as after modifying {{slapd.conf}}(5)). This is possible using
|
||||
the {{slapindex}}(8) program. {{EX:slapindex}} is invoked
|
||||
like this
|
||||
|
||||
E: slapindex -f <slapdconfigfile>
|
||||
E: [-d <debuglevel>] [-n <databasenumber>|-b <suffix>]
|
||||
> slapindex -f <slapdconfigfile>
|
||||
> [-d <debuglevel>] [-n <databasenumber>|-b <suffix>]
|
||||
|
||||
Where the -f, -d, -n and -b options are the same as for the
|
||||
{{slapadd}}(1) program. slapindex rebuilds all indices based
|
||||
{{slapadd}}(1) program. slapindex rebuilds all indices based
|
||||
upon the current database contents.
|
||||
|
||||
|
||||
H3: The {{EX: slapcat}} program
|
||||
H3: The {{EX:slapcat}} program
|
||||
|
||||
The {{EX: slapcat}} program is dump the database to a {{TERM:LDIF}}
|
||||
file. This can be useful when you want to make a human-readable
|
||||
The {{EX:slapcat}} program is dump the database to a {{TERM:LDIF}}
|
||||
file. This can be useful when you want to make a human-readable
|
||||
backup of your database or for editing your database off-line.
|
||||
The program is invoked like this:
|
||||
|
||||
E: slapcat -l <filename> -f <slapdconfigfile>
|
||||
E: [-d <debuglevel>] [-n <databasenumber>|-b <suffix>]
|
||||
> slapcat -l <filename> -f <slapdconfigfile>
|
||||
> [-d <debuglevel>] [-n <databasenumber>|-b <suffix>]
|
||||
|
||||
where -n or -b is used to select the database in the slapd.conf(5)
|
||||
specified using -f. The corresponding LDIF output is written to
|
||||
specified using -f. The corresponding LDIF output is written to
|
||||
standard output or to the file specified using the -l option.
|
||||
|
||||
|
||||
H3: The {{EX: ldif}} program
|
||||
H3: The {{EX:ldif}} program
|
||||
|
||||
The ldif program is used to convert arbitrary data values to
|
||||
LDIF format. This can be useful when writing a program or
|
||||
script to create the LDIF file you will feed into the ldif2ldbm
|
||||
program, or when writing a SHELL backend. ldif takes an
|
||||
The {{ldif}}(1) program is used to convert arbitrary data values to
|
||||
{{TERM:LDIF}} format. This can be useful when writing a program or
|
||||
script to create the LDIF file you will feed into the {{slapadd}}(8)
|
||||
or {{ldapadd}}(1) program, or when writing a SHELL backend. ldif takes an
|
||||
attribute name as an argument, and reads the attribute
|
||||
value(s) from standard input. It produces the LDIF formatted
|
||||
attribute line(s) on standard output. The usage is:
|
||||
|
||||
E: ldif [-b] <attrname>
|
||||
> ldif [-b] <attrname>
|
||||
|
||||
where {{EX: <attrname>}} is the name of the attribute. Without the
|
||||
where {{EX:<attrname>}} is the name of the attribute. Without the
|
||||
-b option, ldif considers each line of standard input to be a
|
||||
separate value of the attribute.
|
||||
|
||||
The -b option can be used to force ldif to interpret its input
|
||||
as a single raw binary value. This option is useful when
|
||||
converting binary data such as a {{EX: jpegPhoto}} or {{EX: audio}}
|
||||
converting binary data such as a {{EX:jpegPhoto}} or {{EX:audio}}
|
||||
attribute.
|
||||
|
||||
|
||||
H2: The LDIF text entry format
|
||||
|
||||
The LDAP Data Interchange Format (LDIF) is used to
|
||||
represent LDAP entries in a simple text format. The basic
|
||||
form of an entry is:
|
||||
The LDAP Data Interchange Format (LDIF) is used to represent LDAP
|
||||
entries in a simple text format. The basic form of an entry is:
|
||||
|
||||
E: [<id>]
|
||||
E: dn: <distinguished name>
|
||||
E: <attrtype>: <attrvalue>
|
||||
E: <attrtype>: <attrvalue>
|
||||
E:
|
||||
E: ...
|
||||
> # comment
|
||||
> dn: <distinguished name>
|
||||
> <attrdesc>: <attrvalue>
|
||||
> <attrdesc>: <attrvalue>
|
||||
>
|
||||
> ...
|
||||
|
||||
where {{EX: <id>}} is the optional entry ID (a positive decimal
|
||||
number). Normally, you would not supply the {{EX: <id>}}, allowing
|
||||
the database creation tools to do that for you. The ldbmcat
|
||||
program, however, produces an LDIF format that includes
|
||||
{{EX: <id>}} so that new indexes created will be consistent.
|
||||
Lines starting with '{{EX:#}}' character are
|
||||
comments. An attribute description may be a simple attribute
|
||||
type like {{EX:cn}} or {{objectClass}} or {{1.2.3}} (an {{TERM:OID}}
|
||||
associated with an attribute type) or may include options such
|
||||
as {{EX:cn;lang_en_US}} or {{EX:userCertificate;binary}}.
|
||||
|
||||
A line may be continued by starting the next line with a
|
||||
single space or tab character. e.g.,
|
||||
{{single}} space or tab character. e.g.,
|
||||
|
||||
E: dn: cn=Barbara J Jensen, dc=example, dc=com
|
||||
> dn: cn=Barbara J Jensen, dc=example, dc=
|
||||
> com
|
||||
> cn: Barbara J
|
||||
> Jensen
|
||||
|
||||
which is equivalent to:
|
||||
> dn: cn=Barbara J Jensen, dc=example, dc=com
|
||||
> cn: Barbara J Jensen
|
||||
|
||||
Multiple attribute values are specified on separate lines. e.g.,
|
||||
|
||||
E: cn: Barbara J Jensen
|
||||
E: cn: Babs Jensen
|
||||
> cn: Barbara J Jensen
|
||||
> cn: Babs Jensen
|
||||
|
||||
If an {{EX: <attrvalue>}} contains a non-printing character, or
|
||||
begins with a space or a colon `:', the {{EX: <attrtype>}} is followed
|
||||
If an {{EX:<attrvalue>}} contains a non-printing character, or
|
||||
begins with a space or a colon '{{EX::}}', the {{EX:<attrdesc>}} is followed
|
||||
by a double colon and the value is encoded in base 64
|
||||
notation. e.g., the value " begins with a space" would be
|
||||
notation. e.g., the value {{EX:" begins with a space"}} would be
|
||||
encoded like this:
|
||||
|
||||
E: cn:: IGJlZ2lucyB3aXRoIGEgc3BhY2U=
|
||||
> cn:: IGJlZ2lucyB3aXRoIGEgc3BhY2U=
|
||||
|
||||
Multiple entries within the same LDIF file are separated by
|
||||
blank lines. Here's an example of an LDIF file containing
|
||||
three entries.
|
||||
|
||||
E: dn: cn=Barbara J Jensen, dc=example, dc=com
|
||||
E: cn: Barbara J Jensen
|
||||
E: cn: Babs Jensen
|
||||
E: objectclass: person
|
||||
E: sn: Jensen
|
||||
E:
|
||||
E: dn: cn=Bjorn J Jensen, dc=example, dc=com
|
||||
E: cn: Bjorn J Jensen
|
||||
E: cn: Bjorn Jensen
|
||||
E: objectclass: person
|
||||
E: sn: Jensen
|
||||
E:
|
||||
E: dn: cn=Jennifer J Jensen, dc=example, dc=com
|
||||
E: cn: Jennifer J Jensen
|
||||
E: cn: Jennifer Jensen
|
||||
E: objectclass: person
|
||||
E: sn: Jensen
|
||||
E: jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD
|
||||
E: A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ
|
||||
E: ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG
|
||||
E:
|
||||
E: ...
|
||||
> # First Entry
|
||||
> dn: cn=Barbara J Jensen, dc=example, dc=com
|
||||
> cn: Barbara J Jensen
|
||||
> cn: Babs Jensen
|
||||
> objectclass: person
|
||||
> sn: Jensen
|
||||
>
|
||||
> # Second Entry
|
||||
> dn: cn=Bjorn J Jensen, dc=example, dc=com
|
||||
> cn: Bjorn J Jensen
|
||||
> cn: Bjorn Jensen
|
||||
> objectclass: person
|
||||
> sn: Jensen
|
||||
>
|
||||
> # Third Entry
|
||||
> dn: cn=Jennifer J Jensen, dc=example, dc=com
|
||||
> cn: Jennifer J Jensen
|
||||
> cn: Jennifer Jensen
|
||||
> objectclass: person
|
||||
> sn: Jensen
|
||||
> # Base64 encoded JPEG photo
|
||||
> jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD
|
||||
> A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ
|
||||
> ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG
|
||||
|
||||
Notice that the {{EX: jpegPhoto}} in Jennifer Jensen's entry is
|
||||
encoded using base 64. The {{EX: ldif}} program (described in
|
||||
Section 8.2.6) can be used to produce the LDIF format.
|
||||
Notice that the {{EX:jpegPhoto}} in Jennifer Jensen's entry is
|
||||
encoded using base 64. The {{ldif}}(1) program (described in
|
||||
Section 8.2.6) can be used to produce an attribute
|
||||
description/base64-value pair suitable for inclusion in an
|
||||
LDIF file.
|
||||
|
||||
Note: Trailing spaces are not trimmed from values in an
|
||||
LDIF file. Nor are multiple internal spaces compressed. If
|
||||
|
||||
@ -160,7 +160,7 @@ LIBS Specify additional libraries
|
||||
Now run the configure script with any desired configure options or
|
||||
environment variables.
|
||||
|
||||
.{{EX: [[env] settings] ./configure [options]}}
|
||||
> [[env] settings] ./configure [options]
|
||||
|
||||
As an example, lets assume that we want a copy of OpenLDAP configured to use the
|
||||
LDBM backend, and the shell backend. The LDBM backend is turned on by default, so we don't need to do anything special to enable it.
|
||||
@ -176,9 +176,9 @@ The following example shows how to run {{EX:configure}} and specify where to
|
||||
find BerkeleyDB and turn on the DNSSRV backend. The example should be
|
||||
entered on a single line (it has been split onto seperate lines for clarity.)
|
||||
|
||||
.{{EX: env CPPFLAGS="-I/usr/local/BerkeleyDB.3.1/include" \ }}
|
||||
..{{EX: LDFLAGS="-L/usr/local/BerkeleyDB.3.1/lib" \ }}
|
||||
..{{EX: ./configure --enable-dnssrv}}
|
||||
> env CPPFLAGS="-I/usr/local/BerkeleyDB.3.1/include" \
|
||||
> LDFLAGS="-L/usr/local/BerkeleyDB.3.1/lib" \
|
||||
> ./configure --enable-dnssrv
|
||||
|
||||
Note: Some shells, such as those derived from the Bourne {{sh}}(1),
|
||||
do not require use of the {{env}}(1) command. In some cases, environmental
|
||||
@ -194,16 +194,16 @@ H2: Building the Software
|
||||
|
||||
Once you have run the {{EX:configure}} script the last line of output
|
||||
should be:
|
||||
.{{EX:Please "make depend" to build dependencies}}
|
||||
> Please "make depend" to build dependencies
|
||||
|
||||
If the last line of output does not match, {{EX:configure}} has failed.
|
||||
You should not proceed until {{EX:configure}} completes sucessfuly.
|
||||
|
||||
To build dependencies, run:
|
||||
.{{EX: make depend}}
|
||||
> make depend
|
||||
|
||||
Now build the software, this step will actually compile OpenLDAP.
|
||||
.{{EX: make}}
|
||||
> make
|
||||
|
||||
You should examine the output of this command carefully to make sure
|
||||
everything is built correctly. Note that this command builds the LDAP
|
||||
@ -214,7 +214,7 @@ H2: Testing the Software
|
||||
Once the software has been properly configured and successfully
|
||||
made, you should run the test suite to verify the build.
|
||||
|
||||
.{{EX: make test}}
|
||||
> make test
|
||||
|
||||
The test will run a number of tests.
|
||||
|
||||
@ -230,7 +230,7 @@ in the location you provided.
|
||||
Typically, the installation is done as {{root}}. From the top level OpenLDAP
|
||||
source directory, type:
|
||||
|
||||
.{{EX: make install}}
|
||||
> make install
|
||||
|
||||
You should examine the output of this command carefully to make sure
|
||||
everything is installed correctly. You will find the configuration files
|
||||
|
||||
@ -61,7 +61,7 @@ entry's attributes has a {{type}} and one or more {{values}}.
|
||||
The types are typically mnemonic strings, like "{{EX:cn}}" for common
|
||||
name, or "{{EX:mail}}" for email address. The syntax of values depend
|
||||
on the attribute type is. For example, {{EX:cn}} attribute might
|
||||
be the value {{EX: Babs Jensen}}. A {{EX:mail}} attribute might
|
||||
be the value {{EX:Babs Jensen}}. A {{EX:mail}} attribute might
|
||||
contain the value "{{EX:babs@example.com}}". A {{EX:jpegPhoto}}
|
||||
attribute would contain a photograph in the JPEG (binary) format.
|
||||
|
||||
|
||||
@ -9,9 +9,9 @@ P1: Preface
|
||||
# document's copyright
|
||||
P2[notoc] Copyright
|
||||
|
||||
Copyright 1998-2000, The {{ORG[expand]OLF}}, All Rights Reserved.
|
||||
Copyright 1998-2000, The {{ORG[expand]OLF}}, {{All Rights Reserved}}.
|
||||
|
||||
Copyright 1992-1996, Regents of the {{ORG[expand]UM}}, All Rights Reserved.
|
||||
Copyright 1992-1996, Regents of the {{ORG[expand]UM}}, {{All Rights Reserved}}.
|
||||
|
||||
|
||||
P2[notoc] Acknowledgements
|
||||
@ -21,5 +21,18 @@ would not be possible without their contribution of time and energy.
|
||||
|
||||
The OpenLDAP Project would also like to thank the {{ORG[expand]UMLDAP}}
|
||||
for building the foundation of LDAP software and information
|
||||
to which we build upon.
|
||||
to which OpenLDAP Software is built upon.
|
||||
|
||||
|
||||
P2[notoc] Amendments
|
||||
|
||||
Suggested enhancements and corrections to this document should
|
||||
be submitted using the {{ORG:OpenLDAP}}
|
||||
{{TERM[expand]ITS}} ({{URL: http://www.openldap.org/its/}}.
|
||||
|
||||
|
||||
P2[notoc] About this document
|
||||
|
||||
This document was produced using the
|
||||
{{Simple Document Format}} ({{URL:http://www.mincom.com/mtr/sdf/}})
|
||||
documentation system developed by {{Ian Clatworthy}}.
|
||||
|
||||
@ -40,11 +40,11 @@ and wished to delegate the subtree {{EX:ou=subtree,dc=example,dc=net}}
|
||||
to another server {{EX:b.example.net}}, the following named referral
|
||||
object would be added to {{a.example.net}}:
|
||||
|
||||
E: dn: dc=subtree, dc=example, dc=net
|
||||
E: objectClass: referral
|
||||
E: objectClass: extensibleObject
|
||||
E: dc: subtree
|
||||
E: ref: ldap://b.example.net/dc=subtree,dc=example,dc=net/
|
||||
> dn: dc=subtree, dc=example, dc=net
|
||||
> objectClass: referral
|
||||
> objectClass: extensibleObject
|
||||
> dc: subtree
|
||||
> ref: ldap://b.example.net/dc=subtree,dc=example,dc=net/
|
||||
|
||||
The server uses this information to generate referrals and
|
||||
search continuations to subordinate servers.
|
||||
@ -64,10 +64,10 @@ Extending the example above, a {{ref}} attribute can be added
|
||||
to the entry {{EX:dc=subtree,dc=example,dc=net}} in server B indicating
|
||||
that A holds the immediate superior naming context.
|
||||
|
||||
E: dn: dc=subtree, dc=example, dc=net
|
||||
E: changetype: modify
|
||||
E: add: ref
|
||||
E: ref: ldap://a.example.net/
|
||||
> dn: dc=subtree, dc=example, dc=net
|
||||
> changetype: modify
|
||||
> add: ref
|
||||
> ref: ldap://a.example.net/
|
||||
|
||||
The server uses this information to generate referrals to
|
||||
management operations.
|
||||
@ -88,13 +88,13 @@ above, the server can be configured to use directory service with
|
||||
{{global knowledge}}, such as the {{OpenLDAP Root Service}}
|
||||
(http://www.openldap.org/faq/index.cgi?file=393).
|
||||
|
||||
E: referral ldap://root.openldap.org/
|
||||
> referral ldap://root.openldap.org/
|
||||
|
||||
However, as {{EX:a.example.net}} is the {{immediate superior}}
|
||||
to {{EX:b.example.net}}, {{a.example.net}} would be configured
|
||||
as follows:
|
||||
|
||||
E: referral ldap://a.example.net/
|
||||
> referral ldap://a.example.net/
|
||||
|
||||
The server uses this information to generate referrals to
|
||||
operations acting upon operations not within or subordinate
|
||||
@ -115,11 +115,11 @@ for requests to introgating or updating referral objects.
|
||||
The -M option of {{ldapmodify}}(1) (and other tools) enables
|
||||
ManageDsaIT. For example:
|
||||
|
||||
E: ldapmodify -M -f referral.ldif -x -D "cn=Manager,dc=example,dc=net" -W
|
||||
> ldapmodify -M -f referral.ldif -x -D "cn=Manager,dc=example,dc=net" -W
|
||||
|
||||
or with ldapsearch:
|
||||
or with {{ldapsearch}}(1):
|
||||
|
||||
E: ldapsearch -M -b "dc=example,dc=net" -x "(objectclass=referral)" '*' ref
|
||||
> ldapsearch -M -b "dc=example,dc=net" -x "(objectclass=referral)" '*' ref
|
||||
|
||||
Note: the {{EX:ref}} attribute is operational and must be explicitly
|
||||
requested when desired in search results.
|
||||
|
||||
@ -71,19 +71,19 @@ Changes to various operational attributes, such as {{EX:modifiersName}}
|
||||
and {{EX:modifyTimestamp}}, are included in the change record and
|
||||
will be propagated to the slave slapd.
|
||||
|
||||
E: replica: slave.example.com:389
|
||||
E: time: 809618633
|
||||
E: dn: uid=bjensen, dc=example, dc=com
|
||||
E: changetype: modify
|
||||
E: replace: multiLineDescription
|
||||
E: description: A dreamer...
|
||||
E: -
|
||||
E: replace: modifiersName
|
||||
E: modifiersName: uid=bjensen, dc=example, dc=com
|
||||
E: -
|
||||
E: replace: modifyTimestamp
|
||||
E: modifyTimestamp: 20000805073308Z
|
||||
E: -
|
||||
> replica: slave.example.com:389
|
||||
> time: 809618633
|
||||
> dn: uid=bjensen, dc=example, dc=com
|
||||
> changetype: modify
|
||||
> replace: multiLineDescription
|
||||
> description: A dreamer...
|
||||
> -
|
||||
> replace: modifiersName
|
||||
> modifiersName: uid=bjensen, dc=example, dc=com
|
||||
> -
|
||||
> replace: modifyTimestamp
|
||||
> modifyTimestamp: 20000805073308Z
|
||||
> -
|
||||
|
||||
The modifications to {{EX:modifiersName}} and {{EX:modifyTimestamp}}
|
||||
operational attributes were added by the master {{slapd}}.
|
||||
@ -94,7 +94,7 @@ H2: Command-Line Options
|
||||
|
||||
{{slurpd}}(8) supports the following command-line options.
|
||||
|
||||
E: -d <level> | ?
|
||||
> -d <level> | ?
|
||||
|
||||
This option sets the slurpd debug level to {{EX: <level>}}. When
|
||||
level is a `?' character, the various debugging levels are
|
||||
@ -102,24 +102,23 @@ printed and slapd exits, regardless of any other options
|
||||
you give it. Current debugging levels (a subset of slapd's
|
||||
debugging levels) are
|
||||
|
||||
|
||||
E: 4 heavy trace debugging
|
||||
E: 64 configuration file processing
|
||||
E: 65535 enable all debugging
|
||||
> 4 heavy trace debugging
|
||||
> 64 configuration file processing
|
||||
> 65535 enable all debugging
|
||||
|
||||
Debugging levels are additive. That is, if you want heavy
|
||||
trace debugging and want to watch the config file being
|
||||
processed, you would set level to the sum of those two
|
||||
levels (in this case, 68).
|
||||
|
||||
E: -f <filename>
|
||||
> -f <filename>
|
||||
|
||||
This option specifies an alternate slapd configuration file.
|
||||
Slurpd does not have its own configuration file. Instead, all
|
||||
configuration information is read from the slapd
|
||||
configuration file.
|
||||
|
||||
E: -r <filename>
|
||||
> -r <filename>
|
||||
|
||||
This option specifies an alternate slapd replication log file.
|
||||
Under normal circumstances, slurpd reads the name of
|
||||
@ -129,7 +128,7 @@ cause slurpd to process a different replication log file. See
|
||||
section 10.5, Advanced slurpd Operation, for a discussion
|
||||
of how you might use this option.
|
||||
|
||||
E: -o
|
||||
> -o
|
||||
|
||||
Operate in "one-shot" mode. Under normal
|
||||
circumstances, when slurpd finishes processing a
|
||||
@ -140,12 +139,12 @@ replication log and exits immediately. If the -o option is
|
||||
given, the replication log file must be explicitly specified
|
||||
with the -r option
|
||||
|
||||
E: -t <directory>
|
||||
> -t <directory>
|
||||
|
||||
Specify an alternate directory for slurpd's temporary
|
||||
copies of replication logs. The default location is /usr/tmp.
|
||||
|
||||
E: -k <filename>
|
||||
> -k <filename>
|
||||
|
||||
When slurpd uses kerberos to authenticate to slave slapd
|
||||
instances, it needs to have an appropriate srvtab file for
|
||||
@ -159,7 +158,6 @@ more complete discussion of using kerberos with slapd
|
||||
and slurpd may be found in Appendix D.
|
||||
|
||||
|
||||
|
||||
H2: Configuring slurpd and a slave slapd instance
|
||||
|
||||
To bring up a replica slapd instance, you must configure
|
||||
@ -228,7 +226,6 @@ time, the master slapd will return an "unwilling to perform"
|
||||
error to clients that attempt to modify data.
|
||||
|
||||
|
||||
|
||||
H3: Copy the master slapd's database to the slave
|
||||
|
||||
Copy the master's database(s) to the slave. For an
|
||||
@ -254,9 +251,9 @@ config file. For example, if we wish to propagate changes
|
||||
to the slapd instance running on host
|
||||
slave.example.com:
|
||||
|
||||
E: replica host=slave.example.com:389
|
||||
E: binddn="cn=Replicator,dc=example,dc=com"
|
||||
E: bindmethod=simple credentials=secret
|
||||
> replica host=slave.example.com:389
|
||||
> binddn="cn=Replicator,dc=example,dc=com"
|
||||
> bindmethod=simple credentials=secret
|
||||
|
||||
In this example, changes will be sent to port 389 (the
|
||||
standard LDAP port) on host slave.example.com. The slurpd
|
||||
@ -281,7 +278,6 @@ entry in the database, and check that data has been
|
||||
written to the log file.
|
||||
|
||||
|
||||
|
||||
H3: Start slurpd
|
||||
|
||||
Start the slurpd process. Slurpd should immediately send
|
||||
@ -289,7 +285,7 @@ the test modification you made to the slave slapd. Watch
|
||||
the slave slapd's logfile to be sure that the modification
|
||||
was sent.
|
||||
|
||||
{{EX: slurpd -f <masterslapdconfigfile>}}
|
||||
> slurpd -f <masterslapdconfigfile>
|
||||
|
||||
|
||||
|
||||
@ -306,24 +302,24 @@ string ".rej" appended. For example, for a replica running
|
||||
on host slave.example.com, port 389, the reject file, if it
|
||||
exists, will be named
|
||||
|
||||
E: /usr/local/var/openldap/replog.slave.example.com:389.
|
||||
> /usr/local/var/openldap/replog.slave.example.com:389.
|
||||
|
||||
A sample rejection log entry follows:
|
||||
|
||||
E: ERROR: No such attribute
|
||||
E: replica: slave.example.com:389
|
||||
E: time: 809618633
|
||||
E: dn: uid=bjensen, dc=example, dc=com
|
||||
E: changetype: modify
|
||||
E: replace: description
|
||||
E: description: A dreamer...
|
||||
E: -
|
||||
E: replace: modifiersName
|
||||
E: modifiersName: uid=bjensen, dc=example, dc=com
|
||||
E: -
|
||||
E: replace: modifyTimestamp
|
||||
E: modifyTimestamp: 20000805073308Z
|
||||
E: -
|
||||
> ERROR: No such attribute
|
||||
> replica: slave.example.com:389
|
||||
> time: 809618633
|
||||
> dn: uid=bjensen, dc=example, dc=com
|
||||
> changetype: modify
|
||||
> replace: description
|
||||
> description: A dreamer...
|
||||
> -
|
||||
> replace: modifiersName
|
||||
> modifiersName: uid=bjensen, dc=example, dc=com
|
||||
> -
|
||||
> replace: modifyTimestamp
|
||||
> modifyTimestamp: 20000805073308Z
|
||||
> -
|
||||
|
||||
Note that this is precisely the same format as the original
|
||||
replication log entry, but with an ERROR line prepended to
|
||||
@ -349,7 +345,7 @@ to process the rejection log file
|
||||
{{F:/usr/local/var/openldap/replog.slave.example.com:389}}
|
||||
and exit, use the command
|
||||
|
||||
E: slurpd -r /usr/tmp/replog.slave.example.com:389 -o
|
||||
> slurpd -r /usr/tmp/replog.slave.example.com:389 -o
|
||||
|
||||
|
||||
H2: Replication from a slapd directory server to an X.500 DSA
|
||||
@ -365,7 +361,8 @@ X.500 DSA, slurpd runs on the master slapd host, and
|
||||
sends changes to an ldapd which acts as a gateway to
|
||||
the X.500 DSA:
|
||||
|
||||
!import "replication.gif"; align="center"; title="Replication from slapd to an X.500 DSA"
|
||||
!import "replication.gif"; align="center"; \
|
||||
title="Replication from slapd to an X.500 DSA"
|
||||
FT: Figure 6: Replication from slapd to an X.500 DSA
|
||||
|
||||
Note that the X.500 DSA must be a read-only copy. Since
|
||||
|
||||
@ -14,20 +14,21 @@ H2: Command-Line Options
|
||||
{{slapd}}(8) supports a number of command-line options as detailed
|
||||
in manual page. This section details a few commonly used options.
|
||||
|
||||
E: -f <filename>
|
||||
> -f <filename>
|
||||
|
||||
This option specifies an alternate configuration file for slapd.
|
||||
The default is normally {{F:/usr/local/etc/openldap/slapd.conf}}.
|
||||
|
||||
|
||||
E: -d <level> | ?
|
||||
> -d <level> | ?
|
||||
|
||||
This option sets the slapd debug level to <level>. When level is a
|
||||
`?' character, the various debugging levels are printed and slapd
|
||||
exits, regardless of any other options you give it. Current
|
||||
debugging levels are
|
||||
|
||||
!block table; colaligns="RL"; align=Center; title="Table 6.1: Debugging Levels"
|
||||
!block table; colaligns="RL"; align=Center; \
|
||||
title="Table 6.1: Debugging Levels"
|
||||
Level Description
|
||||
-1 enable all debugging
|
||||
0 no debugging
|
||||
@ -63,7 +64,7 @@ H2: Starting slapd
|
||||
|
||||
In general, slapd is run like this:
|
||||
|
||||
E: /usr/local/etc/libexec/slapd [<option>]*
|
||||
> /usr/local/etc/libexec/slapd [<option>]*
|
||||
|
||||
where {{F:/usr/local/etc/libexec}} is determined by {{EX:configure}}.
|
||||
and <option> is one of the options described above (or in {{slapd}}(8)).
|
||||
@ -75,7 +76,7 @@ H2: Stopping slapd
|
||||
|
||||
To kill off slapd safely, you should give a command like this
|
||||
|
||||
E: kill -TERM `cat /usr/local/var/slapd.pid`
|
||||
> kill -INT `cat /usr/local/var/slapd.pid`
|
||||
|
||||
where {{F:/usr/local/var}} is determined by {{EX:configure}}.
|
||||
|
||||
|
||||
@ -31,33 +31,33 @@ are ignored. If a line begins with white space, it is considered a
|
||||
continuation of the previous line. The general format of slapd.conf is
|
||||
as follows:
|
||||
|
||||
E: # global configuration directives
|
||||
E: <global config directives>
|
||||
E:
|
||||
E: # backend definition
|
||||
E: backend <typeA>
|
||||
E: <backend-specific directives>
|
||||
E:
|
||||
E: # first database definition & config directives
|
||||
E: database <typeA>
|
||||
E: <database-specific directives>
|
||||
E:
|
||||
E: # second database definition & config directives
|
||||
E: database <typeB>
|
||||
E: <database-specific directives>
|
||||
E:
|
||||
E: # second database definition & config directives
|
||||
E: database <typeA>
|
||||
E: <database-specific directives>
|
||||
E:
|
||||
E: # subsequent backend & database definitions & config directives
|
||||
E: ...
|
||||
> # global configuration directives
|
||||
> <global config directives>
|
||||
>
|
||||
> # backend definition
|
||||
> backend <typeA>
|
||||
> <backend-specific directives>
|
||||
>
|
||||
> # first database definition & config directives
|
||||
> database <typeA>
|
||||
> <database-specific directives>
|
||||
>
|
||||
> # second database definition & config directives
|
||||
> database <typeB>
|
||||
> <database-specific directives>
|
||||
>
|
||||
> # second database definition & config directives
|
||||
> database <typeA>
|
||||
> <database-specific directives>
|
||||
>
|
||||
> # subsequent backend & database definitions & config directives
|
||||
> ...
|
||||
|
||||
A configuration directive may take arguments. If so, they are
|
||||
separated by white space. If an argument contains white space,
|
||||
the argument should be enclosed in double quotes "like this". If
|
||||
an argument contains a double quote or a backslash character `\',
|
||||
the character should be preceded by a backslash character `\'.
|
||||
the argument should be enclosed in double quotes {{EX:"like this"}}. If
|
||||
an argument contains a double quote or a backslash character `{{EX:\}}',
|
||||
the character should be preceded by a backslash character `{{EX:\}}'.
|
||||
|
||||
The distribution contains an example configuration file that will
|
||||
be installed in the {{F: /usr/local/etc/openldap}} directory.
|
||||
@ -123,8 +123,8 @@ H4: loglevel <integer>
|
||||
|
||||
This directive specifies the level at which debugging statements
|
||||
and operation statistics should be syslogged (currently
|
||||
logged to the syslogd(8) LOG_LOCAL4 facility). You must
|
||||
have compiled slapd with DLDAP_DEBUG for this to work
|
||||
logged to the {{syslogd}}(8) LOG_LOCAL4 facility). You must
|
||||
have compiled slapd with -DLDAP_DEBUG for this to work
|
||||
(except for the two stats levels, which are always enabled).
|
||||
Log levels are additive. To display what numbers correspond
|
||||
to what kind of debugging, invoke slapd with the ? flag or
|
||||
@ -165,7 +165,7 @@ cannot find a local database to handle a request.
|
||||
|
||||
\Example:
|
||||
|
||||
E: referral ldap://root.openldap.org
|
||||
> referral ldap://root.openldap.org
|
||||
|
||||
This will refer non-local queries to the global root LDAP server
|
||||
at the OpenLDAP Project. Smart LDAP clients can re-ask their
|
||||
@ -183,7 +183,7 @@ directive(s). If schema checking is off this check is not done.
|
||||
|
||||
\Default:
|
||||
|
||||
E: schemacheck on
|
||||
> schemacheck on
|
||||
|
||||
H4: sizelimit <integer>
|
||||
|
||||
@ -192,7 +192,7 @@ from a search operation.
|
||||
|
||||
\Default:
|
||||
|
||||
E: sizelimit 500
|
||||
> sizelimit 500
|
||||
|
||||
|
||||
H4: srvtab <filename>
|
||||
@ -202,11 +202,11 @@ kerberos keys necessary for authenticating clients using
|
||||
kerberos. This directive is only meaningful if you are using
|
||||
kerberos authentication, which must be enabled at compile
|
||||
time by including the appropriate definitions in the
|
||||
{{EX: Make-common}} file.
|
||||
{{EX:Make-common}} file.
|
||||
|
||||
\Default:
|
||||
|
||||
E: srvtab /etc/srvtab
|
||||
> srvtab /etc/srvtab
|
||||
|
||||
H4: timelimit <integer>
|
||||
|
||||
@ -217,7 +217,7 @@ exceeded timelimit will be returned.
|
||||
|
||||
\Default:
|
||||
|
||||
E: timelimit 3600
|
||||
> timelimit 3600
|
||||
|
||||
|
||||
H3: General Backend Directives
|
||||
@ -236,7 +236,7 @@ database.
|
||||
|
||||
\Example:
|
||||
|
||||
E: database ldbm
|
||||
> database ldbm
|
||||
|
||||
This marks the beginning of a new LDBM backend database
|
||||
instance definition.
|
||||
@ -249,7 +249,7 @@ createTimestamp attributes for entries.
|
||||
|
||||
\Default:
|
||||
|
||||
E: lastmod on
|
||||
> lastmod on
|
||||
|
||||
H4: readonly { on | off }
|
||||
|
||||
@ -259,43 +259,43 @@ perform" error.
|
||||
|
||||
\Default:
|
||||
|
||||
E: readonly off
|
||||
> readonly off
|
||||
|
||||
H4: replica
|
||||
|
||||
.{{EX:replica host=<hostname>[:<port>]}}
|
||||
..{{EX:"binddn=<DN>"}}
|
||||
..{{EX:bindmethod={ simple | kerberos }}}
|
||||
..{{EX:[credentials=<password>]}}
|
||||
..{{EX:[srvtab=<filename>]}}
|
||||
> replica host=<hostname>[:<port>]
|
||||
> "binddn=<DN>"
|
||||
> [bindmethod={ simple | kerberos }]
|
||||
> [credentials=<password>]
|
||||
> [srvtab=<filename>]
|
||||
|
||||
This directive specifies a replication site for this database. The
|
||||
{{EX: host=}} parameter specifies a host and optionally a port where
|
||||
{{EX:host=}} parameter specifies a host and optionally a port where
|
||||
the slave slapd instance can be found. Either a domain name
|
||||
or IP address may be used for <hostname>. If <port> is not
|
||||
given, the standard LDAP port number (389) is used.
|
||||
|
||||
The {{EX: binddn=}} parameter gives the DN to bind as for updates to
|
||||
The {{EX:binddn=}} parameter gives the DN to bind as for updates to
|
||||
the slave slapd. It should be a DN which has read/write
|
||||
access to the slave slapd's database, typically given as a
|
||||
"rootdn" in the slave's config file. It must also match the
|
||||
{{EX:rootdn}} in the slave's config file. It must also match the
|
||||
updatedn directive in the slave slapd's config file. Since DNs are
|
||||
likely to contain embedded spaces, the entire "{{EX: binddn=<DN>}}"
|
||||
string should be enclosed in quotes.
|
||||
likely to contain embedded spaces, the entire {{EX:"binddn=<DN>"}}
|
||||
string should be enclosed in double quotes.
|
||||
|
||||
{{EX: bindmethod}} is either simple or kerberos, depending on
|
||||
The {{EX:bindmethod}} is either simple or kerberos, depending on
|
||||
whether simple password-based authentication or kerberos
|
||||
authentication is to be used when connecting to the slave
|
||||
slapd. Simple authentication requires a valid password be
|
||||
given. Kerberos authentication requires a valid srvtab file.
|
||||
|
||||
The {{EX: credentials=}} parameter, which is only required if using
|
||||
simple authentication, gives the password for binddn on the
|
||||
The {{EX:credentials=}} parameter, which is only required if using
|
||||
simple authentication, gives the password for {{EX:binddn}} on the
|
||||
slave slapd.
|
||||
|
||||
The {{EX: srvtab=}} parameter, which is only required if using
|
||||
The {{EX:srvtab=}} parameter, which is only required if using
|
||||
kerberos, specifies the filename which holds the kerberos key
|
||||
for the slave slapd. If omitted, {{EX: /etc/srvtab}} is used.
|
||||
for the slave slapd. If omitted, {{F:/etc/srvtab}} is used.
|
||||
|
||||
See Section 10 for more details on replication.
|
||||
|
||||
@ -319,19 +319,19 @@ operations on this database.
|
||||
|
||||
\Example:
|
||||
|
||||
E: rootdn "cn=Manager, dc=example, dc=com"
|
||||
> rootdn "cn=Manager, dc=example, dc=com"
|
||||
|
||||
H4: rootkrbname <kerberosname>
|
||||
|
||||
This directive specifies a kerberos name for the DN given above
|
||||
that will always work, regardless of whether an entry with the
|
||||
given DN exists or has a {{EX: krbName}} attribute. This directive is
|
||||
given DN exists or has a {{EX:krbName}} attribute. This directive is
|
||||
useful when creating a database and also when using slurpd
|
||||
to provide replication service (see Section 10).
|
||||
|
||||
\Example:
|
||||
|
||||
E: rootkrbname admin@openldap.org
|
||||
> rootkrbname admin@openldap.org
|
||||
|
||||
H4: rootpw <password>
|
||||
|
||||
@ -343,7 +343,7 @@ replication service (see Section 10).
|
||||
|
||||
\Example:
|
||||
|
||||
E: rootpw secret
|
||||
> rootpw secret
|
||||
|
||||
H4: suffix <dn suffix>
|
||||
|
||||
@ -354,7 +354,7 @@ definition.
|
||||
|
||||
\Example:
|
||||
|
||||
E: suffix "dc=example, dc=com"
|
||||
> suffix "dc=example, dc=com"
|
||||
|
||||
Queries with a DN ending in "dc=example, dc=com"
|
||||
will be passed to this backend.
|
||||
@ -385,7 +385,7 @@ cache maintained by the LDBM backend database instance.
|
||||
|
||||
\Default:
|
||||
|
||||
E: cachesize 1000
|
||||
> cachesize 1000
|
||||
|
||||
|
||||
H4: dbcachesize <integer>
|
||||
@ -399,7 +399,7 @@ modifies or when building indexes.
|
||||
|
||||
\Default:
|
||||
|
||||
E: dbcachesize 100000
|
||||
> dbcachesize 100000
|
||||
|
||||
|
||||
H4: directory <directory>
|
||||
@ -409,7 +409,7 @@ containing the database and associated indexes live.
|
||||
|
||||
\Default:
|
||||
|
||||
E: directory /usr/local/var/openldap-ldbm
|
||||
> directory /usr/local/var/openldap-ldbm
|
||||
|
||||
|
||||
H4: index {<attrlist> | default} [pres,eq,approx,sub,none]
|
||||
@ -420,9 +420,9 @@ maintained.
|
||||
|
||||
\Example:
|
||||
|
||||
E: index default pres,eq
|
||||
E: index objectclass,uid
|
||||
E: index cn,sn eq,sub,approx
|
||||
> index default pres,eq
|
||||
> index objectclass,uid
|
||||
> index cn,sn eq,sub,approx
|
||||
|
||||
The first line sets the default to indices to maintain to present
|
||||
and equality. The second line causes the default (pres,eq) set
|
||||
@ -437,29 +437,21 @@ created database index files should have.
|
||||
|
||||
\Default:
|
||||
|
||||
E: mode 0600
|
||||
> mode 0600
|
||||
|
||||
|
||||
|
||||
H3: Shell Backend-Specific Directives
|
||||
|
||||
E: bind <pathname>
|
||||
|
||||
E: unbind <pathname>
|
||||
|
||||
E: search <pathname>
|
||||
|
||||
E: compare <pathname>
|
||||
|
||||
E: modify <pathname>
|
||||
|
||||
E: modrdn <pathname>
|
||||
|
||||
E: add <pathname>
|
||||
|
||||
E: delete <pathname>
|
||||
|
||||
E: abandon <pathname>
|
||||
> bind <pathname>
|
||||
> unbind <pathname>
|
||||
> search <pathname>
|
||||
> compare <pathname>
|
||||
> modify <pathname>
|
||||
> modrdn <pathname>
|
||||
> add <pathname>
|
||||
> delete <pathname>
|
||||
> abandon <pathname>
|
||||
|
||||
These directives specify the pathname of the command to
|
||||
execute in response to the given LDAP operation. The
|
||||
@ -468,7 +460,7 @@ conventions described in Appendix B.
|
||||
|
||||
\Example:
|
||||
|
||||
E: search /usr/local/bin/search.sh
|
||||
> search /usr/local/bin/search.sh
|
||||
|
||||
Note that you need only supply those commands you want the
|
||||
backend to handle. Operations for which a command is not
|
||||
@ -488,56 +480,48 @@ This directive specifies an alternate passwd file to use.
|
||||
|
||||
\Default:
|
||||
|
||||
E: file /etc/passwd
|
||||
> file /etc/passwd
|
||||
|
||||
|
||||
|
||||
H3: Tcl Backend-Specific Directives
|
||||
H3: TCL Backend-Specific Directives
|
||||
|
||||
H4: scriptpath <pathname>
|
||||
|
||||
This is the full path to a file containing the tcl command(s) to handle
|
||||
This is the full path to a file containing the TCL command(s) to handle
|
||||
the LDAP operations.
|
||||
|
||||
H4: Proc specifiers
|
||||
|
||||
E: bind <proc>
|
||||
> bind <proc>
|
||||
> unbind <proc>
|
||||
> search <proc>
|
||||
> compare <proc>
|
||||
> modify <proc>
|
||||
> modrdn <proc>
|
||||
> add <proc>
|
||||
> delete <proc>
|
||||
> abandon <proc>
|
||||
|
||||
E: unbind <proc>
|
||||
|
||||
E: search <proc>
|
||||
|
||||
E: compare <proc>
|
||||
|
||||
E: modify <proc>
|
||||
|
||||
E: modrdn <proc>
|
||||
|
||||
E: add <proc>
|
||||
|
||||
E: delete <proc>
|
||||
|
||||
E: abandon <proc>
|
||||
|
||||
These directives specify the name of the proc (function) in the tcl script
|
||||
specified in 'scriptpath' to execute in response to the given LDAP
|
||||
operation.
|
||||
These directives specify the name of the proc (function) in the
|
||||
TCL script specified in {{EX:scriptpath}} to execute in response to
|
||||
the given LDAP operation.
|
||||
|
||||
\Example:
|
||||
|
||||
E: search proc_search
|
||||
> search proc_search
|
||||
|
||||
Note that you need only supply those commands you want the
|
||||
tcl backend to handle. Operations for which a command is not
|
||||
TCL backend to handle. Operations for which a command is not
|
||||
supplied will be refused with an "unwilling to perform" error.
|
||||
|
||||
H4: tclrealm <name>
|
||||
|
||||
This is one of the biggest pluses of using the tcl backend.
|
||||
This is one of the biggest pluses of using the TCL backend.
|
||||
The realm let's you group several databases to the same interpretor.
|
||||
This basically means they share the same global variables and proc
|
||||
space. So global variables, as well as all the procs are callable
|
||||
between databases. If no tclrealm is specified, it is put into the
|
||||
between databases. If no {{EX:tclrealm}} is specified, it is put into the
|
||||
"default" realm.
|
||||
|
||||
|
||||
@ -548,32 +532,35 @@ Access to slapd entries and attributes is controlled by the
|
||||
access configuration file directive. The general form of an
|
||||
access line is:
|
||||
|
||||
E: <access directive> ::= access to <what>
|
||||
E: [ by <who> <access> <control> ]+
|
||||
E: <what> ::= * | [ dn[.<target style>]=<regex> ] [ filter=<ldapfilter> ]
|
||||
E: [ attrs=<attrlist> ]
|
||||
E: <target style> ::= regex | base | one | subtree | children
|
||||
E: <attrlist> ::= <attr> | <attr> , <attrlist>
|
||||
E: <attr> ::= <attrname> | entry | children
|
||||
E: <who> ::= [ * | anonymous | users | self | dn[.<subject style>]=<regex> ]
|
||||
E: [ dnattr=<attrname> ]
|
||||
E: [ group[/<objectclass>[/<attrname>][.<basic style>]]=<regex> ]
|
||||
E: [ peername[.<basic style>]=<regex> ] [ sockname[.<basic style>]=<regex> ]
|
||||
E: [ domain[.<basic style>]=<regex> ] [ sockurl[.<basic style>]=<regex> ]
|
||||
E: [ set=<setspec> ]
|
||||
E: [ aci=<attrname> ]
|
||||
E: <subject style> ::= regex | exact | base | one | subtree | children
|
||||
E: <basic style> ::= regex | exact
|
||||
E: <access> ::= [self]{<level>|<priv>}
|
||||
E: <level> ::= none | auth | compare | search | read | write
|
||||
E: <priv> ::= {=|+|-}{w|r|s|c|x}+
|
||||
E: <control> ::= [ stop | continue | break ]
|
||||
> <access directive> ::= access to <what>
|
||||
> [by <who> <access> <control>]+
|
||||
> <what> ::= * | [ dn[.<target style>]=<regex>]
|
||||
> [filter=<ldapfilter>] [attrs=<attrlist>]
|
||||
> <target style> ::= regex | base | one | subtree | children
|
||||
> <attrlist> ::= <attr> | <attr> , <attrlist>
|
||||
> <attr> ::= <attrname> | entry | children
|
||||
> <who> ::= [* | anonymous | users | self |
|
||||
> dn[.<subject style>]=<regex>]
|
||||
> [dnattr=<attrname> ]
|
||||
> [group[/<objectclass>[/<attrname>][.<basic style>]]=<regex> ]
|
||||
> [peername[.<basic style>]=<regex>]
|
||||
> [sockname[.<basic style>]=<regex>]
|
||||
> [domain[.<basic style>]=<regex>]
|
||||
> [sockurl[.<basic style>]=<regex>]
|
||||
> [set=<setspec>]
|
||||
> [aci=<attrname>]
|
||||
> <subject style> ::= regex | exact | base | one | subtree | children
|
||||
> <basic style> ::= regex | exact
|
||||
> <access> ::= [self]{<level>|<priv>}
|
||||
> <level> ::= none | auth | compare | search | read | write
|
||||
> <priv> ::= {=|+|-}{w|r|s|c|x}+
|
||||
> <control> ::= [stop | continue | break]
|
||||
|
||||
where the <what> part selects the entries and/or attributes to
|
||||
which the access applies, the <who> part specifies which
|
||||
entities are granted access, and the <access> part specifies
|
||||
the access granted. Multiple <who> <access> <control> triplets are
|
||||
supported, allowing many entities to be granted different
|
||||
which the access applies, the {{EX:<who>}} part specifies which
|
||||
entities are granted access, and the {{EX:<access>}} part specifies
|
||||
the access granted. Multiple {{EX:<who> <access> <control>}} triplets
|
||||
are supported, allowing many entities to be granted different
|
||||
access to the same set of entries and attributes.
|
||||
|
||||
|
||||
@ -584,7 +571,7 @@ entries and attributes to which the access control applies.
|
||||
Entries can be selected in two ways: by a regular expression
|
||||
matching the entry's distinguished name:
|
||||
|
||||
E: dn=<regular expression>
|
||||
> dn=<regular expression>
|
||||
|
||||
Note: The DN pattern specified should be "normalized",
|
||||
meaning that there should be no extra spaces, and commas
|
||||
@ -596,7 +583,7 @@ An example of a non-normalized DN is
|
||||
Or, entries may be selected by a filter matching some
|
||||
attribute(s) in the entry:
|
||||
|
||||
E: filter=<ldap filter>
|
||||
> filter=<ldap filter>
|
||||
|
||||
where <ldap filter> is a string representation of an LDAP
|
||||
search filter, as described in RFC 2254.
|
||||
@ -608,7 +595,7 @@ Attributes within an entry are selected by including a
|
||||
comma-separated list of attribute names in the <what>
|
||||
selector:
|
||||
|
||||
E: attrs=<attribute list>
|
||||
> attrs=<attribute list>
|
||||
|
||||
Access to the entry itself must be granted or denied using the
|
||||
special attribute name "{{EX:entry}}". Note that giving access to an
|
||||
@ -627,7 +614,7 @@ any entry, the keyword "self" matching the entry protected by
|
||||
the access, or by a regular expression matching an entry's
|
||||
distinguished name:
|
||||
|
||||
E: dn=<regular expression>
|
||||
> dn=<regular expression>
|
||||
|
||||
Note: The DN pattern specified should be "normalized",
|
||||
meaning that there should be no extra spaces, and commas
|
||||
@ -636,13 +623,13 @@ should be used to separate components.
|
||||
Or entities can be specified by a regular expression matching
|
||||
the client's IP address or domain name:
|
||||
|
||||
E: addr=<regular expression>
|
||||
E: domain=<regular expression>
|
||||
> addr=<regular expression>
|
||||
> domain=<regular expression>
|
||||
|
||||
or by an entry listed in a DN-valued attribute in the entry to
|
||||
which the access applies:
|
||||
|
||||
E: dnattr=<dn-valued attribute name>
|
||||
> dnattr=<dn-valued attribute name>
|
||||
|
||||
The dnattr specification is used to give access to an entry
|
||||
whose DN is listed in an attribute of the entry (e.g., give
|
||||
@ -656,36 +643,35 @@ H3: The access to grant
|
||||
|
||||
The kind of <access> granted can be one of the following:
|
||||
|
||||
E: none | compare | search | read | write
|
||||
> none | auth | compare | search | read | write
|
||||
|
||||
Note that each level implies all lower levels of access. So, for
|
||||
example, granting someone write access to an entry also
|
||||
grants them read, search, and compare access.
|
||||
|
||||
grants them read, search, compare, and auth access.
|
||||
|
||||
|
||||
H3: Access Control Evaluation
|
||||
|
||||
When evaluating whether some requester should be given
|
||||
access to an entry and/or attribute, slapd compares the entry
|
||||
and/or attribute to the {{EX: <what>}} selectors given in the
|
||||
and/or attribute to the {{EX:<what>}} selectors given in the
|
||||
configuration file. Access directives local to the current
|
||||
database are examined first, followed by global access
|
||||
directives. Within this priority, access directives are
|
||||
examined in the order in which they appear in the config file.
|
||||
Slapd stops with the first {{EX: <what>}} selector that matches the
|
||||
Slapd stops with the first {{EX:<what>}} selector that matches the
|
||||
entry and/or attribute. The corresponding access directive is
|
||||
the one slapd will use to evaluate access.
|
||||
|
||||
Next, slapd compares the entity requesting access to the
|
||||
{{EX: <who>}} selectors within the access directive selected above,
|
||||
in the order in which they appear. It stops with the first {{EX: <who>}}
|
||||
{{EX:<who>}} selectors within the access directive selected above,
|
||||
in the order in which they appear. It stops with the first {{EX:<who>}}
|
||||
selector that matches the requester. This determines the
|
||||
access the entity requesting access has to the entry and/or
|
||||
attribute.
|
||||
|
||||
Finally, slapd compares the access granted in the selected
|
||||
{{EX: <access>}} clause to the access requested by the client. If it
|
||||
{{EX:<access>}} clause to the access requested by the client. If it
|
||||
allows greater or equal access, access is granted. Otherwise,
|
||||
access is denied.
|
||||
|
||||
@ -693,7 +679,7 @@ The order of evaluation of access directives makes their
|
||||
placement in the configuration file important. If one access
|
||||
directive is more specific than another in terms of the entries
|
||||
it selects, it should appear first in the config file. Similarly, if
|
||||
one {{EX: <who>}} selector is more specific than another it should
|
||||
one {{EX:<who>}} selector is more specific than another it should
|
||||
come first in the access directive. The access control
|
||||
examples given below should help make this clear.
|
||||
|
||||
@ -707,22 +693,28 @@ The access control facility described above is quite powerful.
|
||||
This section shows some examples of its use. First, some
|
||||
simple examples:
|
||||
|
||||
E: access to * by * read
|
||||
> access to * by * read
|
||||
|
||||
This access directive grants read access to everyone. If it
|
||||
appears alone it is the same as the following defaultaccess
|
||||
line.
|
||||
This access directive grants read access to everyone.
|
||||
|
||||
E: defaultaccess read
|
||||
> access to *
|
||||
> by self write
|
||||
> by anonymous auth
|
||||
> by * read
|
||||
|
||||
This directive allows users to modify their own entries,
|
||||
allows authenticate, and allows authenticated users to read.
|
||||
Note that only the first {{EX:by <who>}} clause which matches applies.
|
||||
Hence, the anonymous users are granted {{EX:auth}}, not {{EX:read}}.
|
||||
|
||||
The following example shows the use of a regular expression
|
||||
to select the entries by DN in two access directives where
|
||||
ordering is significant.
|
||||
|
||||
E: access to dn=".*,dc=example,dc=com"
|
||||
E: by * search
|
||||
E: access to dn=".*,dc=com"
|
||||
E: by * read
|
||||
> access to dn=".*,dc=example,dc=com"
|
||||
> by * search
|
||||
> access to dn=".*,dc=com"
|
||||
> by * read
|
||||
|
||||
Read access is granted to entries under the {{EX:dc=com}}
|
||||
subtree, except for those entries under the {{EX:dc=example,dc=com}} subtree,
|
||||
@ -731,28 +723,37 @@ order of these access directives was reversed, the
|
||||
trailing directive would never be reached, since all
|
||||
{{EX:dc=example,dc=com}} entries are also {{EX:dc=com}} entries.
|
||||
|
||||
The next example again shows the importance of ordering,
|
||||
both of the access directives and the "by" clauses. It also
|
||||
shows the use of an attribute selector to grant access to a
|
||||
specific attribute and various <who> selectors.
|
||||
Also note that if no {{EX:access to}} directive matches or
|
||||
no {{EX:by <who>}} clause, {{B:access is denied}}. That is, every
|
||||
{{EX:access to}} directive ends with a implicit {{EX:by * none}}
|
||||
clause and access list itself ends with {{EX:access to * by * none}}
|
||||
directive. Only if no access controls are specified, is the
|
||||
defaultaccess granted.
|
||||
|
||||
E:access to dn=".*, dc=example, dc=com" attr=homePhone
|
||||
E: by self write
|
||||
E: by dn=".*,dc=example,dc=com" search
|
||||
E: by domain=.*\.example\.com read
|
||||
E: by * compare
|
||||
E:access to dn=".*,dc=example,dc=com"
|
||||
E: by self write
|
||||
E: by dn=".*,dc=example,dc=com" search
|
||||
E: by * none
|
||||
The next example again shows the importance of ordering,
|
||||
both of the access directives and the {{EX:by <who>}} clauses.
|
||||
It also shows the use of an attribute selector to grant access
|
||||
to a specific attribute and various <who> selectors.
|
||||
|
||||
> access to dn="(.*,)?dc=example,dc=com" attr=homePhone
|
||||
> by self write
|
||||
> by dn="(.*,)?dc=example,dc=com" search
|
||||
> by domain=.*\.example\.com read
|
||||
> access to dn="(.*,)?dc=example,dc=com"
|
||||
> by self write
|
||||
> by dn=".*,dc=example,dc=com" search
|
||||
> by anonymous auth
|
||||
|
||||
This example applies to entries in the "dc=example, dc=com"
|
||||
subtree. To all attributes except homePhone, the entry itself
|
||||
can write them, other Example.com entries can search by them,
|
||||
anybody else has no access. The homePhone attribute is
|
||||
writable by the entry, searchable by other Example.com entries,
|
||||
readable by clients connecting from somewhere in the
|
||||
example.com domain, and comparable by everybody else.
|
||||
anybody else has no access ((implicit {{EX:by * none}}) excepting for
|
||||
authentication/authorization (which is always done anonymously).
|
||||
The homePhone attribute is writable by the entry, searchable
|
||||
by other Example.com entries, readable by clients connecting
|
||||
from somewhere in the example.com domain, and otherwise not
|
||||
readable (implicit {{EX:by * none}}). All other access
|
||||
is denied by the implicit {{EX:access to * by * none}}.
|
||||
|
||||
Sometimes it is useful to permit a particular DN to add or
|
||||
remove itself from an attribute. For example, if you would like to
|
||||
@ -760,18 +761,18 @@ create a group and allow people too add and remove only
|
||||
their own DN from the member attribute, you could accomplish
|
||||
it with an access directive like this:
|
||||
|
||||
E: access to attr=member,entry
|
||||
E: by dnattr=member selfwrite
|
||||
> access to attr=member,entry
|
||||
> by dnattr=member selfwrite
|
||||
|
||||
The dnattr {{EX: <who>}} selector says that the access applies to
|
||||
The dnattr {{EX:<who>}} selector says that the access applies to
|
||||
entries listed in the member attribute. The selfwrite access
|
||||
selector says that such members can only add or delete their
|
||||
own DN from the attribute, not other values. The addition of
|
||||
the entry attribute is required because access to the entry is
|
||||
required to access any of the entry's attributes.
|
||||
|
||||
Note that the attr=member construct in the {{EX: <what>}} clause is a
|
||||
shorthand for the clause "dn=* attr=member" (i.e., it matches
|
||||
Note that the attr=member construct in the {{EX:<what>}} clause is a
|
||||
shorthand for the clause "{{EX:dn=.* attr=member}}" (i.e., it matches
|
||||
the member attribute in all entries).
|
||||
|
||||
|
||||
@ -780,19 +781,19 @@ H2: Schema Enforcement
|
||||
|
||||
|
||||
|
||||
The {{EX: objectclass}} and schemacheck configuration file directives
|
||||
The {{EX:objectclass}} and schemacheck configuration file directives
|
||||
can be used to enforce schema rules on entries in the
|
||||
directory. 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:
|
||||
schemacheck directives. The format of an {{EX:objectclass}} line is:
|
||||
|
||||
E: objectclass <RFC2252 Object Class Description>
|
||||
> objectclass <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>}}
|
||||
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
|
||||
by the allows {{EX:<attrs>}} clause). In both clauses, {{EX:<attrs>}} is a
|
||||
comma-separated list of attribute names.
|
||||
|
||||
Note that object class inheritance (that is, defining one object
|
||||
@ -803,9 +804,9 @@ in the objectclass definition.
|
||||
For example, to define an objectclass called myPerson, you
|
||||
might include a definition like this:
|
||||
|
||||
E: objectclass myperson
|
||||
E: requires cn, sn, objectclass
|
||||
E: allows mail, phone, fax
|
||||
> objectclass myperson
|
||||
> requires cn, sn, objectclass
|
||||
> allows mail, phone, fax
|
||||
|
||||
To then enforce this rule (i.e., to make sure an entry with an
|
||||
objectclass of myperson contains the cn, sn and objectclass
|
||||
@ -813,7 +814,7 @@ attributes, and that it contains no other attributes besides
|
||||
mail, phone, and fax), turn on schema checking with a line like
|
||||
this:
|
||||
|
||||
E: schemacheck on
|
||||
> schemacheck on
|
||||
|
||||
|
||||
|
||||
@ -834,17 +835,17 @@ E: 3. referral ldap://root.openldap.org
|
||||
|
||||
Line 1 is a comment. Lines 2 include another config file
|
||||
which containing {{core}} schema definitions.
|
||||
The {{EX: referral}} directive on line 3
|
||||
The {{EX:referral}} directive on line 3
|
||||
means that queries not local to one of the databases defined
|
||||
below will be referred to the LDAP server running on the
|
||||
standard port (389) at the host {{EX: root.openldap.org}}.
|
||||
standard port (389) at the host {{EX:root.openldap.org}}.
|
||||
|
||||
The next section of the configuration file defines an LDBM
|
||||
backend that will handle queries for things in the
|
||||
"dc=example,dc=com" portion of the tree. The
|
||||
database is to be replicated to two slave slapds, one on
|
||||
truelies, the other on judgmentday. Indexes are to be
|
||||
maintained for several attributes, and the {{EX: userPassword}}
|
||||
maintained for several attributes, and the {{EX:userPassword}}
|
||||
attribute is to be protected from unauthorized access.
|
||||
|
||||
E: 1. # ldbm definition for the U-M database
|
||||
@ -901,7 +902,7 @@ various attributes. The default is not to maintain any indexes
|
||||
(line 19).
|
||||
|
||||
Lines 20 through 30 specify access control for entries in the
|
||||
database. For all entries, the {{EX: userPassword}} attribute is
|
||||
database. For all entries, the {{EX:userPassword}} attribute is
|
||||
writable by the entry and the "admin" entry, may be used for
|
||||
authentication/authorization purposes, but is otherwise not
|
||||
readable. All other attributes by writable by the entry and
|
||||
|
||||
@ -90,6 +90,7 @@ LBER Lightweight BER
|
||||
LDAP Lightweight Directory Access Protocol
|
||||
LDIF LDAP Directory Interchange Format
|
||||
LDBM LDAP Database Manager
|
||||
OID Object Identifier
|
||||
OSI OSI
|
||||
PS Proposed Standard
|
||||
RDN Relative Distinguished Name
|
||||
|
||||
Loading…
Reference in New Issue
Block a user