1999-04-24 07:41:45 +08:00
|
|
|
# Copyright 1999, The OpenLDAP Foundation, All Rights Reserved.
|
|
|
|
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
|
1999-04-24 07:00:44 +08:00
|
|
|
H1: Introduction to slapd and slurpd
|
|
|
|
|
|
|
|
This document describes how to build, configure, and run the stand-alone
|
|
|
|
LDAP daemon ({{I:slapd}}) and the stand-alone LDAP update replication
|
|
|
|
daemon ({{I:slurpd}}). It is intended for newcomers and experienced
|
|
|
|
administrators alike. This section provides a basic introduction to directory
|
|
|
|
service, and the directory service provided by {{I:slapd}} in particular.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
H2: What is a directory service?
|
|
|
|
|
|
|
|
A directory is like a database, but tends to contain more descriptive,
|
|
|
|
attribute-based information. The information in a directory is generally read
|
|
|
|
much more often than it is written. As a consequence, directories don't
|
|
|
|
usually implement the complicated transaction or roll-back schemes regular
|
|
|
|
databases use for doing 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 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 replicated, temporary inconsistencies between
|
|
|
|
the replicas may be OK, as long as they get in sync eventually.
|
|
|
|
|
|
|
|
There are many different ways to provide a directory service. Different
|
|
|
|
methods allow different kinds of information to be stored in the directory,
|
|
|
|
place different requirements on how that information can be referenced,
|
|
|
|
queried and updated, how it is protected from unauthorized access, etc.
|
|
|
|
Some directory services are {{I:local}}, providing service to a restricted
|
|
|
|
context (e.g., the finger service on a single machine). Other services are
|
|
|
|
global, providing service to a much broader context (e.g., the entire Internet).
|
1999-05-03 09:19:22 +08:00
|
|
|
Global services are usually {{I:distributed}},
|
|
|
|
meaning that the data they contain
|
1999-04-24 07:00:44 +08:00
|
|
|
is spread across many machines, all of which cooperate to provide the
|
|
|
|
directory service. Typically a global service defines a uniform {{I:namespace}}
|
|
|
|
which gives the same view of the data no matter where you are in relation to
|
|
|
|
the data itself.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
H2: What is LDAP?
|
|
|
|
|
|
|
|
{{I:Slapd}}'s model for directory service is based on a global directory model
|
|
|
|
called LDAP, which stands for the Lightweight Directory Access Protocol.
|
|
|
|
LDAP is a directory service protocol that runs over TCP/IP. The nitty-gritty
|
|
|
|
details of LDAP are defined in RFC 1777 "The Lightweight Directory Access
|
|
|
|
Protocol." This section gives an overview of LDAP from a user's perspective.
|
|
|
|
|
1999-05-03 09:19:22 +08:00
|
|
|
{{I:What kind of information can be stored in the directory?}}
|
|
|
|
The LDAP directory
|
1999-04-24 07:00:44 +08:00
|
|
|
service model is based on {{I:entries}}. An entry is a collection of
|
|
|
|
attributes that has a name, called a {{I:distinguished name}} (DN).
|
|
|
|
The DN is used to refer to the entry unambiguously. Each of the
|
|
|
|
entry's attributes has a {{I:type}} and one or
|
|
|
|
more {{I:values}}.
|
|
|
|
The types are typically mnemonic strings, like "{{EX:cn}}" for common
|
|
|
|
name, or "{{EX:mail}}" for email address. The values depend on what type of
|
|
|
|
attribute it is. For example, a {{EX:mail}} attribute might contain the value
|
1999-04-25 07:11:27 +08:00
|
|
|
"{{EX:babs@openldap.org}}". A {{EX:jpegPhoto}} attribute would contain
|
1999-04-24 07:00:44 +08:00
|
|
|
a photograph in binary JPEG/JFIF format.
|
|
|
|
|
1999-05-03 09:19:22 +08:00
|
|
|
{{I:How is the information arranged?}}
|
|
|
|
In LDAP, directory entries are arranged in
|
1999-04-24 07:00:44 +08:00
|
|
|
a hierarchical tree-like structure that reflects political, geographic and/or
|
|
|
|
organizational boundaries. Entries representing countries appear at the top
|
|
|
|
of the tree. Below them are entries representing states or national
|
|
|
|
organizations. Below them might be entries representing people,
|
|
|
|
organizational units, printers, documents, or just about anything else you can
|
|
|
|
think of. Figure 1 shows an example LDAP directory tree, which should help
|
|
|
|
make things clear.
|
|
|
|
|
|
|
|
|
1999-05-02 06:11:02 +08:00
|
|
|
!import "intro_tree.gif"; align="center"; title="An example LDAP directory tree"
|
1999-09-26 01:17:51 +08:00
|
|
|
FT[align="Center"] Figure 1: An example LDAP directory tree.
|
1999-04-24 07:00:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
In addition, LDAP allows you to control which attributes are required and
|
|
|
|
allowed in an entry through the use of a special attribute called
|
|
|
|
{{I:objectclass}}.
|
|
|
|
The values of the {{I:objectclass}} attribute determine
|
|
|
|
the {{I:schema}} rules the entry
|
|
|
|
must obey.
|
|
|
|
|
1999-05-03 09:19:22 +08:00
|
|
|
{{I:How is the information referenced?}}
|
|
|
|
An entry is referenced by its
|
1999-04-24 07:00:44 +08:00
|
|
|
distinguished name, which is constructed by taking the name of the entry
|
|
|
|
itself (called the relative distinguished name, or RDN) and concatenating the
|
|
|
|
names of its ancestor entries. For example, the entry for Barbara Jensen in
|
|
|
|
the example above has an RDN of "{{EX:cn=Barbara J Jensen}}" and a DN of
|
1999-04-25 07:11:27 +08:00
|
|
|
"{{EX:cn=Barbara J Jensen, o=OpenLDAP Project, c=US}}". The full DN format is
|
|
|
|
described in RFC 1779, "A String Representation of Distinguished Names."
|
1999-04-24 07:00:44 +08:00
|
|
|
|
1999-05-03 09:19:22 +08:00
|
|
|
{{I:How is the information accessed?}}
|
|
|
|
LDAP defines operations for interrogating
|
1999-04-24 07:00:44 +08:00
|
|
|
and updating the directory. Operations are provided for adding and deleting
|
|
|
|
an entry from the directory, changing an existing entry, and changing the
|
|
|
|
name of an entry. Most of the time, though, LDAP is used to search for
|
|
|
|
information in the directory. The LDAP search operation allows some portion
|
|
|
|
of the directory to be searched for entries that match some criteria specified
|
|
|
|
by a search filter. Information can be requested from each entry that matches
|
|
|
|
the criteria.
|
|
|
|
|
|
|
|
For example, you might want to search the entire directory subtree below the
|
1999-04-25 07:11:27 +08:00
|
|
|
OpenLDAP Project for people with the name Barbara Jensen, retrieving
|
1999-04-24 07:00:44 +08:00
|
|
|
the email address of each entry found. LDAP lets you do this easily. Or you
|
|
|
|
might want to search the entries directly below the c=US entry for
|
|
|
|
organizations with the string "Acme" in their name, and that have a fax
|
|
|
|
number. LDAP lets you do this too. The next section describes in more detail
|
|
|
|
what you can do with LDAP and how it might be useful to you.
|
|
|
|
|
1999-05-03 09:19:22 +08:00
|
|
|
{{I:How is the information protected from unauthorized access?}}
|
|
|
|
Some directory
|
1999-04-24 07:00:44 +08:00
|
|
|
services provide no protection, allowing anyone to see the information. LDAP
|
|
|
|
provides a method for a client to authenticate, or prove its identity to a
|
|
|
|
directory server, paving the way for rich access control to protect the
|
|
|
|
information the server contains.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
H2: How does LDAP work?
|
|
|
|
|
|
|
|
LDAP directory service is based on a {{I:client-server}} model. One or more
|
|
|
|
LDAP servers contain the data making up the LDAP directory tree. An LDAP
|
|
|
|
client connects to an LDAP server and asks it a question. The server
|
|
|
|
responds with the answer, or with a pointer to where the client can get more
|
|
|
|
information (typically, another LDAP server). No matter which LDAP server a
|
|
|
|
client connects to, it sees the same view of the directory; a name presented
|
|
|
|
to one LDAP server references the same entry it would at another LDAP
|
|
|
|
server. This is an important feature of a global directory service, like LDAP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
H2: What is slapd and what can it do?
|
|
|
|
|
|
|
|
{{I:Slapd}} is an LDAP directory server that runs on many different UNIX
|
|
|
|
platforms. You can use it to provide a directory service of your very own.
|
|
|
|
Your directory can contain pretty much anything you want to put in it. You
|
|
|
|
can connect it to the global LDAP directory service, or run a service all by
|
|
|
|
yourself. Some of slapd's more interesting features and capabilities include:
|
|
|
|
|
|
|
|
{{B:Choice of databases}}: {{I:Slapd}} comes with three different backend
|
|
|
|
databases you can choose from. They are LDBM, a high-performance disk-based
|
|
|
|
database; SHELL, a database interface to arbitrary UNIX commands or shell
|
|
|
|
scripts; and PASSWD, a simple password file database.
|
|
|
|
|
|
|
|
{{B:Multiple database instances}}: {{I:Slapd}} can be configured to serve
|
|
|
|
multiple databases at the same time. This means that a single {{I:slapd}}
|
|
|
|
server can respond to requests for many logically different portions
|
|
|
|
of the LDAP tree, using the same or different backend databases.
|
|
|
|
|
|
|
|
{{B:Generic database API}}: If you require even more customization, {{I:slapd}}
|
|
|
|
lets you write your own backend database easily. {{I:Slapd}}
|
|
|
|
consists of two distinct parts: a front end that handles protocol
|
|
|
|
communication with LDAP clients; and a backend that handles database
|
|
|
|
operations. Because these two pieces communicate via a well-defined
|
|
|
|
C API, you can write your own customized database backend to {{I:slapd}}.
|
|
|
|
|
|
|
|
{{B:Access control}}: {{I:Slapd}} provides a rich and powerful access
|
|
|
|
control facility, allowing you to control access to the information
|
|
|
|
in your database(s). You can control access to entries based on
|
|
|
|
LDAP authentication information, IP address, domain name and other criteria.
|
|
|
|
|
|
|
|
{{B:Threads}}: {{I:Slapd}} is threaded for high performance. A
|
|
|
|
single multi-threaded {{I:slapd}} process handles all incoming
|
|
|
|
requests, reducing the amount of system overhead required. {{I:Slapd}}
|
|
|
|
will automatically select the best thread support for your platform.
|
|
|
|
|
|
|
|
{{B:Replication}}: {{I:Slapd}} can be configured to maintain replica
|
|
|
|
copies of its database. This master/slave replication scheme is
|
|
|
|
vital in high-volume environments where a single {{I:slapd}} just
|
|
|
|
doesn't provide the necessary availability or reliability.
|
|
|
|
|
|
|
|
{{B:Configuration}}: {{I: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.
|
|
|
|
|
|
|
|
{{I:Slapd}} also has its limitations, of course. It does not
|
|
|
|
currently handle aliases, which are part of the LDAP model. The
|
|
|
|
main LDBM database backend does not handle range queries or negation
|
|
|
|
queries very well. These features and more will be coming in a future release.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
H2: What about X.500?
|
|
|
|
|
|
|
|
LDAP was originally developed as a front end to X.500, the OSI directory
|
|
|
|
service. X.500 defines the Directory Access Protocol (DAP) for clients to
|
|
|
|
use when contacting directory servers. DAP is a heavyweight protocol that
|
|
|
|
runs over a full OSI stack and requires a significant amount of computing
|
|
|
|
resources to run. LDAP runs directly over TCP and provides most of the
|
|
|
|
functionality of DAP at a much lower cost.
|
|
|
|
|
|
|
|
This use of LDAP makes it easy to access the X.500 directory, but still
|
|
|
|
requires a full X.500 service to make data available to the many LDAP clients
|
|
|
|
being developed. As with full X.500 DAP clients, a full X.500 server is no
|
|
|
|
small piece of software to run.
|
|
|
|
|
|
|
|
The stand-alone LDAP daemon, or {{I:slapd}}, is meant to remove much of the
|
|
|
|
burden from the server side just as LDAP itself removed much of the burden
|
|
|
|
from clients. If you are already running an X.500 service and you want to
|
|
|
|
continue to do so, you can probably stop reading this guide, which is all
|
1999-05-03 09:19:22 +08:00
|
|
|
about running LDAP via {{I:slapd}}, without running X.500. If you are not
|
|
|
|
running X.500,
|
|
|
|
want to stop running X.500, or have no immediate plans to run X.500,
|
1999-04-24 07:00:44 +08:00
|
|
|
read on.
|
|
|
|
|
|
|
|
It is possible to replicate data from a {{I:slapd}} directory
|
|
|
|
server to an X.500 DSA, which allows your organization to make your
|
|
|
|
data available as part of the global X.500 directory service on a
|
|
|
|
"read-only" basis. This is discussed in section 11.6.
|
|
|
|
|
|
|
|
Another way to make data in a {{I:slapd}} server available to the X.500
|
|
|
|
community would be by using a X.500 DAP to LDAP gateway. At this time, no
|
|
|
|
such software has been written (to the best of our knowledge), but hopefully
|
|
|
|
some group will see fit towrite such a gateway.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
H2: What is slurpd and what can it do?
|
|
|
|
|
|
|
|
{{I:Slurpd}} is a UNIX daemon that helps {{I:slapd}} provide
|
|
|
|
replicated service. It is responsible for distributing changes made
|
|
|
|
to the master {{I:slapd}} database out to the various {{I:slapd}}
|
|
|
|
replicas. It frees {{I:slapd}} from having to worry that some
|
|
|
|
replicas might be down or unreachable when a change comes through;
|
|
|
|
{{I:slurpd}} handles retrying failed requests automatically.
|
|
|
|
{{I:Slapd}} and {{I:slurpd}} communicate through a simple text
|
|
|
|
file that is used to log changes.
|
|
|
|
|
|
|
|
PB:
|
|
|
|
|
|
|
|
|