backends.sdf 8.03 KB
Newer Older
Gavin Henry's avatar
Gavin Henry committed
1
# $OpenLDAP$
2
3
4
5
6
7
8
9
10
11
12
# Copyright 2007 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.

H1: Backends


H2: Berkley DB Backends


H3: Overview

13
14
15
The {{bdb}} backend to {{slapd}}(8) is the recommended primary backend for a 
normal {{slapd}} database.  It uses the Oracle Berkeley DB ({{TERM:BDB}}) 
package to store data. It makes extensive use of indexing and caching 
Gavin Henry's avatar
Gavin Henry committed
16
(see the {{SECT:Tuning}} section) to speed data access.
17
18
19
20
21
22
23

{{hdb}} is a variant of the {{bdb}} backend that uses a hierarchical database 
layout which supports subtree renames. It is otherwise identical to the {{bdb}}
 behavior, and all the same configuration options apply.

Note: An {{hdb}} database needs a large {{idlcachesize}} for good search performance, 
typically three times the {{cachesize}} (entry cache size) or larger.
24
25
26

H3: back-bdb/back-hdb Configuration

27
MORE LATER
28
29
30

H3: Further Information

31
{{slapd-bdb}}(5)
32
33
34
35
36
37

H2: LDAP


H3: Overview

38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
The LDAP backend to {{slapd}}(8) is not an actual database; instead it acts 
as a proxy to forward incoming requests to another LDAP server. While 
processing requests it will also chase referrals, so that referrals are fully
processed instead of being returned to the {{slapd}} client.

Sessions that explicitly {{Bind}} to the {{back-ldap}} database always create 
their own private connection to the remote LDAP server. Anonymous sessions 
will share a single anonymous connection to the remote server. For sessions 
bound through other mechanisms, all sessions with the same DN will share the 
same connection. This connection pooling strategy can enhance the proxys 
efficiency by reducing the overhead of repeatedly making/breaking multiple 
connections.

The ldap database can also act as an information service, i.e. the identity 
of locally authenticated clients is asserted to the remote server, possibly 
in some modified form. For this purpose, the proxy binds to the remote server 
with some administrative identity, and, if required, authorizes the asserted 
identity. 
56
57
58

H3: back-ldap Configuration

59
LATER
60
61
62

H3: Further Information

63
{{slapd-ldap}}(5)
64
65
66
67
68
69

H2: LDIF


H3: Overview

70
71
72
73
74
75
76
The LDIF backend to {{slapd}}(8) is a basic storage backend that stores 
entries in text files in LDIF format, and exploits the filesystem to create 
the tree structure of the database. It is intended as a cheap, low performance 
easy to use backend, and it is exploited by higher-level internal structures 
to provide a permanent storage.

When using Dynamic configuration over LDAP via {{cn=config}}, this is where all
77
configuration is stored if {{slapd}}(8) if started with {{-F}}. See {{slapd-config}}(5)
78
for more information
79
80
81

H3: back-ldif Configuration

82
LATER
83
84
85

H3: Further Information

86
{{slapd-ldif}}(5)
87
88
89
90
91
92

H2: Metadirectory


H3: Overview

93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
The meta backend to {{slapd}}(8) performs basic LDAP proxying with respect 
to a set of remote LDAP servers, called "targets". The information contained 
in these servers can be presented as belonging to a single Directory Information 
Tree ({{TERM:DIT}}).

A basic knowledge of the functionality of the {{slapd-ldap}}(5) backend is 
recommended. This backend has been designed as an enhancement of the ldap 
backend. The two backends share many features (actually they also share portions
 of code). While the ldap backend is intended to proxy operations directed 
 to a single server, the meta backend is mainly intended for proxying of 
 multiple servers and possibly naming context  masquerading.

These features, although useful in many scenarios, may result in excessive 
overhead for some applications, so its use should be carefully considered.

108
109
110

H3: back-meta Configuration

111
LATER
112
113
114

H3: Further Information

115
{{slapd-meta}}(5)
116
117
118
119
120
121

H2: Monitor


H3: Overview

122
123
124
125
126
127
128
129
130
131
132
The monitor backend to {{slapd}}(8) is not an actual database; if enabled, 
it is automatically generated and dynamically maintained by slapd with 
information about the running status of the daemon.

To inspect all monitor information, issue a subtree search with base {{cn=Monitor}}, 
requesting that attributes "+" and "*" are returned. The monitor backend produces 
mostly operational attributes, and LDAP only returns operational attributes 
that are explicitly requested.  Requesting attribute "+" is an extension which 
requests all operational attributes.

See the {{SECT:Monitoring}} section.
133
134
135

H3: back-monitor Configuration

136
LATER
137
138
139

H3: Further Information

140
{{slapd-monitor}}(5)
141

142
H2: Null
143
144
145
146


H3: Overview

147
The Null backend to {{slapd}}(8) is surely the most useful part of slapd:
148

149
150
151
152
153
154
155
- Searches return success but no entries.
- Compares return compareFalse.
- Updates return success (unless readonly is on) but do nothing.
- Binds other than as the rootdn fail unless the database option "bind on" is given.
- The slapadd(8) and slapcat(8) tools are equally exciting.

Inspired by the {{F:/dev/null}} device.
156

157
158
159
H3: back-null Configuration

LATER
160
161
162

H3: Further Information

163
{{slapd-null}}(5)
164

165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
H2: Passwd


H3: Overview

The PASSWD backend to {{slapd}}(8) serves up the user account information 
listed in the system {{passwd}}(5) file.

This backend is provided for demonstration purposes only. The DN of each entry 
is "uid=<username>,<suffix>".

H3: back-passwd Configuration

LATER

H3: Further Information
181

182
183
184
{{slapd-passwd}}(5)

H2: Perl/Shell
185
186
187

H3: Overview

188
189
190
191
192
193
194
195
The Perl backend to {{slapd}}(8) works by embedding a {{perl}}(1) interpreter 
into {{slapd}}(8). Any perl database section of the configuration file 
{{slapd.conf}}(5) must then specify what Perl module to use. Slapd then creates 
a new Perl object that handles all the requests for that particular instance of the backend.

The Shell backend to {{slapd}}(8) executes external programs to implement 
operations, and is designed to make it easy to tie an existing database to the 
slapd front-end. This backend is is primarily intended to be used in prototypes.
196
197
198

H3: back-perl/back-shell Configuration

199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
LATER

H3: Further Information

{{slapd-shell}}(5) and {{slapd-perl}}(5)

H2: Relay


H3: Overview

The primary purpose of this {{slapd}}(8) backend is to map a naming context 
defined in a database running in the same {{slapd}}(8) instance into a 
virtual naming context, with attributeType and objectClass manipulation, if
required. It requires the rwm overlay.

This backend and the above mentioned overlay are experimental.

H3: back-relay Configuration

LATER
220
221
222

H3: Further Information

223
{{slapd-relay}}(5)
224
225
226
227
228
229

H2: SQL


H3: Overview

230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
The primary purpose of this {{slapd}}(8) backend is to PRESENT information 
stored in some RDBMS as an LDAP subtree without any programming (some SQL and 
maybe stored procedures cant be considered programming, anyway ;).

That is, for example, when you (some ISP) have account information you use in 
an RDBMS, and want to use modern solutions that expect such information in LDAP 
(to authenticate users, make email lookups etc.). Or you want to synchronize or 
distribute information between different sites/applications that use RDBMSes 
and/or LDAP. Or whatever else...

It is NOT designed as a general-purpose backend that uses RDBMS instead of 
BerkeleyDB (as the standard BDB backend does), though it can be used as such with 
several limitations. You can take a look at {{URL:http://www.openldap.org/faq/index.cgi?file=378}}
 (OpenLDAP FAQ-O-Matic/General LDAP FAQ/Directories vs. conventional databases) 
 to find out more on this point.

The idea is to use some meta-information to translate LDAP queries to SQL queries, 
leaving relational schema untouched, so that old applications can continue using 
it without any modifications. This allows SQL and LDAP applications to interoperate 
without replication, and exchange data as needed.

The SQL backend is designed to be tunable to virtually any relational schema without 
having to change source (through that meta-information mentioned). Also, it uses 
ODBC to connect to RDBMSes, and is highly configurable for SQL dialects RDBMSes 
may use, so it may be used for integration and distribution of data on different 
RDBMSes, OSes, hosts etc., in other words, in highly heterogeneous environment.

This backend is experimental.
258
259
260

H3: back-sql Configuration

261
LATER
262
263

H3: Further Information
264
265

{{slapd-sql}}(5)