H3: The {{EX:slapcat}} program
-The {{EX:slapcat}} program is dump the database to a {{TERM:LDIF}}
+The {{EX:slapcat}} program is used to 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:
> ldif [-b] <attrdesc>
-where {{EX:<attrdesc>}} is an attribute description. Without the
--b option, ldif considers each line of standard input to be a
-separate value of the attribute.
+where {{EX:<attrdesc>}} is an attribute description. Without the -b
+option, ldif considers each line of standard input to be a separate
+value of the attribute.
> ldif description << EOF
> leading space
> [[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.
+As an example, let's 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.
Additionally, we've installed the BerkeleyDB database package.
{{EX:configure}} is smart enough to use BerkeleyDB automatically
consists of two distinct parts: a front end that handles protocol
communication with LDAP clients; and modules which handles specific
tasks such as database operations. Because these two pieces communicate
-via a well-defined C API, you can write your own customized modules
+via a well-defined {{TERM:C}} {{TERM:API}}, you can write your own
+customized modules
which extend {{slapd}} in numerous ways. Also, a number of
{{programmable database}} modules are provided. These allowing you
to expose external data sources to {{slapd}} using popular programming
In addition to assign a unique object identifier to each schema
element, you should provide a least one textual name for each
-element. The name should be both descriptive and no likely
+element. The name should be both descriptive and not likely
to clash with names of other schema elements. In particular,
any name you choose should not clash with present or future
Standard Track names.
be.
In the examples below, we have choosen a short prefix '{{EX:my}}'
-(to save space). Such a short would only be suitable for a
-very large, global organization. For a small, local
-organization, we recommend something like '{{EX:deFirm}}'
-(German company) or '{{EX:comExample}}' (elements associated
-with organization associated with {{EX:example.com}}).
+(to save space). Such a short prefix would only be suitable for
+a very large, global organization. For a small, local organization,
+we recommend something like '{{EX:deFirm}}' (German company) or
+'{{EX:comExample}}' (elements associated with organization associated
+with {{EX:example.com}}).
H3: Local schema file
> access to dn=".*,dc=com"
> by * read
-Read access is granted to entries under the {{EX:dc=com}}.
+Read access is granted to entries under the {{EX:dc=com}}
subtree, except for those entries under the {{EX:dc=example,dc=com}}
-subtree, to which search access is granted. No access to
-{{EX:dc=com}} as the neither access directive matches this DN.
+subtree, to which search access is granted. No access is granted to
+{{EX:dc=com}} as neither access directive matches this DN.
If the 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.
Sometimes it is useful to permit a particular DN to add or
remove itself from an attribute. For example, if you would like to
-create a group and allow people too add and remove only
+create a group and allow people to add and remove only
their own DN from the member attribute, you could accomplish
it with an access directive like this:
Line 5 is a comment. The start of the database definition is
marked by the database keyword on line 6. Line 7 specifies
the DN suffix for queries to pass to this database. Line 8
-specifies the directory in which the database files will live
+specifies the directory in which the database files will live.
Lines 9 and 10 identify the database "super user" entry and
associated password. This entry is not subject to access
# Internet and X.500 terms
!block terms; data
Term Definition
+API Application Programming Interface
ASN Abstract Syntax Notation
ASN.1 Abstract Syntax Notation 1
BCP Best Common Practice
BER Basic Encoding Rules
BNF BNF
+C The C Programming Language
CLDAP Connection-less LDAP
DAP Directory Access Protocol
DER Distinguished Encoding Rules
RDN Relative Distinguished Name
RFC Request for Comments
TCP Transmission Control Protocol
-TLS Transport Security Layer
+TLS Transport Layer Security
SASL Simple Authentication and Security Layer
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
projects / openldap / commitdiff