# $OpenLDAP$
-# Copyright 1999-2000, The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 1999-2003, The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
H1: Introduction to OpenLDAP Directory Services
provided by {{slapd}}(8).
-
H2: What is a directory service?
-A directory is specialized database optimized for reading, browsing
+A directory is a specialized database optimized for reading, browsing
and searching. Directories tend to contain descriptive, attribute-based
information and support sophisticated filtering capabilities.
Directories generally do not support complicated transaction or
roll-back schemes found in database management systems designed
for handling high-volume complex updates. Directory updates are
typically simple all-or-nothing changes, if they are allowed at
-all. Directories are tuned to give quick-response to high-volume
+all. Directories are tuned to give quick response to high-volume
lookup or search operations. They may have the ability to replicate
information widely in order to increase availability and reliability,
while reducing response time. When directory information is
provide the directory service. Typically a global service defines
a uniform {{namespace}} which gives the same view of the data no
matter where you are in relation to the data itself. The Internet
-{{TERM[expand]DNS}} is an example of a globally distributed directory
-service.
+{{TERM[expand]DNS}} (DNS) is an example of a globally distributed
+directory service.
H2: What is LDAP?
specifically {{TERM:X.500}}-based directory services. LDAP runs
over {{TERM:TCP}}/{{TERM:IP}} or other connection oriented transfer
services. The nitty-gritty details of LDAP are defined in
-{{REF:RFC2251}} "The Lightweight Directory Access Protocol (v3)."
-This section gives an overview of LDAP from a user's perspective.
+{{REF:RFC2251}} "The Lightweight Directory Access Protocol (v3)"
+and other documents comprising the technical specification
+{{REF:RFC3377}}. This section gives an overview of LDAP from a
+user's perspective.
{{What kind of information can be stored in the directory?}} The
LDAP information model is based on {{entries}}. An entry is a
the 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}}
+values depend on the attribute type. For example, a {{EX:cn}}
+attribute might contain 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.
{{How is the information arranged?}} In LDAP, directory entries
are arranged in a hierarchical tree-like structure. Traditionally,
this structure reflected the geographic and/or organizational
-boundaries. Entries representing countries appeared at the top of
+boundaries. Entries representing countries appear at the top of
the tree. Below them are entries representing states and national
organizations. Below them might be entries representing organizational
units, people, printers, documents, or just about anything else
The tree may also be arranged based upon Internet domain names.
This naming approach is becoming increasing popular as it allows
-for directory services to be locating using the {{TERM[expand]DNS}}.
+for directory services to be located using the {{DNS}}.
Figure 1.2 shows an example LDAP directory tree using domain-based
naming.
Technically, {{TERM:LDAP}} is a directory access protocol to an
{{TERM:X.500}} directory service, the {{TERM:OSI}} directory service.
-Initially, LDAP clients accessed gateways to directory service.
-This gateway ran LDAP (between the client and gateway) and X.500's
-{{TERM[expand]DAP}} ({{TERM:DAP}}) (between the gateway and the
+Initially, LDAP clients accessed gateways to the X.500 directory service.
+This gateway ran LDAP between the client and gateway and X.500's
+{{TERM[expand]DAP}} ({{TERM:DAP}}) between the gateway and the
X.500 server. DAP is a heavyweight protocol that operates over a
full OSI protocol stack and requires a significant amount of
computing resources. LDAP is designed to operate over
H2: What is the difference between LDAPv2 and LDAPv3?
-LDAPv3 was developed in late 1990's to replace LDAPv2.
+LDAPv3 was developed in the late 1990's to replace LDAPv2.
LDAPv3 adds the following features to LDAP:
- Strong Authentication via {{TERM:SASL}}
- - Integrity and Confidential Protections via {{TERM:TLS}} (SSL)
+ - Integrity and Confidentiality Protection via {{TERM:TLS}} (SSL)
- Internationalization through the use of Unicode
- Referrals and Continuations
- - Extensibility (controls and extended operations)
- Schema Discovery
+ - Extensibility (controls, extended operations, and more)
-LDAPv2 is considered historical. As deploying both LDAPv2 and
-LDAPv3 simultaneously can be quite problematic, LDAPv2 should
-be avoided.
+LDAPv2 is historic ({{REF:RFC3494}}). As most implementations
+(including {{slapd}}(8)) of LDAPv2 do not conform to the LDAPv2
+technical specification, interoperatibility amongst implementations
+claiming LDAPv2 support will be limited. As LDAPv2 differs
+significantly from LDAPv3, deploying both LDAPv2 and LDAPv3
+simultaneously can be quite problematic. LDAPv2 should be avoided.
+LDAPv2 is disabled by default.
H2: What is slapd and what can it do?
{{B:Internationalization}}: {{slapd}} supports Unicode and language
tags.
-{{B:Choice of databases}}: {{slapd}} comes with a variety of
-different backend databases you can choose from. They include
-{{TERM:LDBM}}, a high-performance disk-based embedded database;
-SHELL, a database interface to arbitrary shell scripts; and PASSWD,
-a simple password file database. LDBM utilizes either {{PRD:BerkeleyDB}}
-or {{PRD:GDBM}}. There is also a new {{TERM:BDB}} backend database
-which uses BerkeleyDB directly, instead of the generic API that
-LDBM uses, and delivers even greater performance.
+{{B:Choice of database backends}}: {{slapd}} comes with a variety
+of different database backends you can choose from. They include
+{{TERM:BDB}}, a high-performance transactional database backend;
+{{TERM:LDBM}}, a lightweight DBM based backend; {{SHELL}}, a backend
+interface to arbitrary shell scripts; and PASSWD, a simple backend
+interface to the {{passwd}}(5) file. BDB utilizes {{ORG:Sleepycat}}
+{{PRD:Berkeley DB}}. LDBM utilizes either {{PRD:Berkeley DB}} or
+{{PRD:GDBM}}.
{{B:Multiple database instances}}: {{slapd}} can be configured to
serve multiple databases at the same time. This means that a single
{{slapd}} server can respond to requests for many logically different
-portions of the LDAP tree, using the same or different backend
-databases.
+portions of the LDAP tree, using the same or different database
+backends.
{{B:Generic modules API}}: If you require even more customization,
{{slapd}} lets you write your own modules easily. {{slapd}} consists
customized modules which extend {{slapd}} in numerous ways. Also,
a number of {{programmable database}} modules are provided. These
allow you to expose external data sources to {{slapd}} using popular
-programming languages ({{PRD:Perl}}, {{Shell}}, {{PRD:SQL}}, and
+programming languages ({{PRD:Perl}}, {{shell}}, {{PRD:SQL}}, and
{{PRD:TCL}}).
-{{B:Threads}}: {{slapd}} is threaded for high performance. A single
-multi-threaded {{slapd}} process handles all incoming requests,
-reducing the amount of system overhead required.
+{{B:Threads}}: {{slapd}} is threaded for high performance. A single
+multi-threaded {{slapd}} process handles all incoming requests
+using a pool of threads. This reduces the amount of system overhead
+required while providing high performance.
{{B:Replication}}: {{slapd}} can be configured to maintain replica
copies of its database. This {{single-master/multiple-slave}}
everything you'd ever want to change. Configuration options have
reasonable defaults, making your job much easier.
-{{slapd}} also has its limitations, of course. The main LDBM
-database backend does not handle range queries or negation queries
+{{slapd}} also has its limitations, of course. The main BDB
+backend does not handle range queries or negation queries
very well.
projects / openldap / blobdiff