# $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
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 {{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?
interesting features and capabilities include:
{{B:LDAPv3}}: {{slapd}} implements version 3 of {{TERM[expand]LDAP}}.
-{{slapd}} supports LDAP over both IPv4 and IPv6.
+{{slapd}} supports LDAP over both IPv4 and IPv6 and Unix IPC.
{{B:{{TERM[expand]SASL}}}}: {{slapd}} supports strong authentication
services through the use of SASL. {{slapd}}'s SASL implementation
protections through the use of TLS (or SSL). {{slapd}}'s TLS
implementation utilizes {{PRD:OpenSSL}} software.
-{{B:Topology control}}: {{slapd}} allows one to restrict access to
-the server based upon network topology. This feature utilizes
-{{TCP wrappers}}.
+{{B:Topology control}}: {{slapd}} can be configured to restrict
+access at the socket layer based upon network topology information.
+This feature utilizes {{TCP wrappers}}.
{{B:Access control}}: {{slapd}} provides a rich and powerful access
control facility, allowing you to control access to the information
{{B:Internationalization}}: {{slapd}} supports Unicode and language
tags.
-{{B:Choice of databases backends}}: {{slapd}} comes with a variety
+{{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}}.
+interface to the {{passwd}}(5) file. The BDB backend utilizes
+{{ORG:Sleepycat}} {{PRD:Berkeley DB}}. The 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
portions of the LDAP tree, using the same or different database
backends.
-{{B:Generic modules API}}: If you require even more customization,
+{{B:Generic modules API}}: If you require even more customization,
{{slapd}} lets you write your own modules easily. {{slapd}} consists
of two distinct parts: a front end that handles protocol communication
with LDAP clients; and modules which handle specific tasks such as
{{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 proving high performance.
+required while providing high performance.
-{{B:Replication}}: {{slapd}} can be configured to maintain replica
-copies of its database. This {{single-master/multiple-slave}}
+{{B:Replication}}: {{slapd}} can be configured to maintain shadow
+copies of directory information. This {{single-master/multiple-slave}}
replication scheme is vital in high-volume environments where a
single {{slapd}} just doesn't provide the necessary availability
or reliability. {{slapd}} also includes experimental support for
-{{multi-master}} replication.
+{{multi-master}} replication (for use where strong ACID properties
+are not required). {{slapd}} supports two replication methods:
+{{LDAP Sync}}-based and {{slurpd}}(8)-based replication .
+
+{{B:Proxy Cache}}: {{slapd}} can be configured as a caching
+LDAP proxy service.
{{B:Configuration}}: {{slapd}} is highly configurable through a
single configuration file which allows you to change just about
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 BDB
-backend does not handle range queries or negation queries
-very well.
-
H2: What is slurpd and what can it do?
-{{slurpd}}(8) is a daemon that helps {{slapd}} provide replicated
-service. It is responsible for distributing changes made to the
-master {{slapd}} database out to the various {{slapd}} replicas.
-It frees {{slapd}} from having to worry that some replicas might
-be down or unreachable when a change comes through; {{slurpd}}
+{{slurpd}}(8) is a daemon that, with {{slapd}} help, provides
+replicated service. It is responsible for distributing changes
+made to the master {{slapd}} database out to the various {{slapd}}
+replicas. It frees {{slapd}} from having to worry that some replicas
+might be down or unreachable when a change comes through; {{slurpd}}
handles retrying failed requests automatically. {{slapd}} and
{{slurpd}} communicate through a simple text file that is used to
log changes.
See the {{SECT:Replication with slurpd}} chapter for information
about how to configure and run {{slurpd}}(8).
+
+Alternatively, {{LDAP-Sync}}-based replication may be used to provide
+a replicated service. See the {{SECT:LDAP Sync Replication}} chapter
+for details.
+
projects / openldap / blobdiff