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
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.
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>
+> rootdn <dn>
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
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,
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.
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:
-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: ...
-
-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.
+> # 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 {{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
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.
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
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
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.
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
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.
# 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
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}}.
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.
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.
{{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
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.
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}}.
{{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
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
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
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
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
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
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
written to the log file.
-
H3: Start slurpd
Start the slurpd process. Slurpd should immediately send
the slave slapd's logfile to be sure that the modification
was sent.
-{{EX: slurpd -f <masterslapdconfigfile>}}
+> slurpd -f <masterslapdconfigfile>
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
{{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
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
{{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
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)).
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}}.
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.
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
\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
\Default:
-E: schemacheck on
+> schemacheck on
H4: sizelimit <integer>
\Default:
-E: sizelimit 500
+> sizelimit 500
H4: srvtab <filename>
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>
\Default:
-E: timelimit 3600
+> timelimit 3600
H3: General Backend Directives
\Example:
-E: database ldbm
+> database ldbm
This marks the beginning of a new LDBM backend database
instance definition.
\Default:
-E: lastmod on
+> lastmod on
H4: readonly { on | off }
\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.
\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>
\Example:
-E: rootpw secret
+> rootpw secret
H4: suffix <dn suffix>
\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.
\Default:
-E: cachesize 1000
+> cachesize 1000
H4: dbcachesize <integer>
\Default:
-E: dbcachesize 100000
+> dbcachesize 100000
H4: directory <directory>
\Default:
-E: directory /usr/local/var/openldap-ldbm
+> directory /usr/local/var/openldap-ldbm
H4: index {<attrlist> | default} [pres,eq,approx,sub,none]
\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
\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
\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
\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>
-
-E: unbind <proc>
-
-E: search <proc>
+> bind <proc>
+> unbind <proc>
+> search <proc>
+> compare <proc>
+> modify <proc>
+> modrdn <proc>
+> add <proc>
+> delete <proc>
+> abandon <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.
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.
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
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.
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
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
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
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.
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.
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,
trailing directive would never be reached, since all
{{EX:dc=example,dc=com}} entries are also {{EX:dc=com}} entries.
+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.
+
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.
-
-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
+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
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).
-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
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
mail, phone, and fax), turn on schema checking with a line like
this:
-E: schemacheck on
+> schemacheck on
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
(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
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
projects / openldap / commitdiff