git.sur5r.net Git - openldap/blob - doc/guide/admin/backends.sdf

   1 # $OpenLDAP$
   2 # Copyright 2007-2008 The OpenLDAP Foundation, All Rights Reserved.
   3 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
   4
   5 H1: Backends
   6
   7
   8 H2: Berkeley DB Backends
   9
  10
  11 H3: Overview
  12
  13 The {{bdb}} backend to {{slapd}}(8) is the recommended primary backend for a
  14 normal {{slapd}} database.  It uses the Oracle Berkeley DB ({{TERM:BDB}})
  15 package to store data. It makes extensive use of indexing and caching
  16 (see the {{SECT:Tuning}} section) to speed data access.
  17
  18 {{hdb}} is a variant of the {{bdb}} backend that uses a hierarchical database
  19 layout which supports subtree renames. It is otherwise identical to the {{bdb}}
  20  behavior, and all the same configuration options apply.
  21
  22 Note: An {{hdb}} database needs a large {{idlcachesize}} for good search performance,
  23 typically three times the {{cachesize}} (entry cache size) or larger.
  24
  25 H3: back-bdb/back-hdb Configuration
  26
  27 MORE LATER
  28
  29 H3: Further Information
  30
  31 {{slapd-bdb}}(5)
  32
  33 H2: LDAP
  34
  35
  36 H3: Overview
  37
  38 The LDAP backend to {{slapd}}(8) is not an actual database; instead it acts
  39 as a proxy to forward incoming requests to another LDAP server. While
  40 processing requests it will also chase referrals, so that referrals are fully
  41 processed instead of being returned to the {{slapd}} client.
  42
  43 Sessions that explicitly {{Bind}} to the {{back-ldap}} database always create
  44 their own private connection to the remote LDAP server. Anonymous sessions
  45 will share a single anonymous connection to the remote server. For sessions
  46 bound through other mechanisms, all sessions with the same DN will share the
  47 same connection. This connection pooling strategy can enhance the proxy's
  48 efficiency by reducing the overhead of repeatedly making/breaking multiple
  49 connections.
  50
  51 The ldap database can also act as an information service, i.e. the identity
  52 of locally authenticated clients is asserted to the remote server, possibly
  53 in some modified form. For this purpose, the proxy binds to the remote server
  54 with some administrative identity, and, if required, authorizes the asserted
  55 identity.
  56
  57 It is heavily used by a lot of other {{SECT: Backends}} and {{SECT: Overlays}}.
  58
  59 H3: back-ldap Configuration
  60
  61 As previously mentioned, {{slapd-ldap(5)}} is used behind the scenes by many
  62 other {{SECT: Backends}} and {{SECT: Overlays}}. Some of them merely provide a
  63 few configuration directive themselves, but have available to the administrator
  64 the whole of the {{slapd-ldap(5)}} options.
  65
  66 For example, the {{SECT: Translucent Proxy}}, which retrieves entries from a
  67 remote LDAP server that can be partially overridden by the defined database, has
  68 only four specific {{translucent-}} directives, but can be configured using any
  69 of the normal {{slapd-ldap(5)}} options. See {[slapo-translucent(5)}} for details.
  70
  71 Other {{SECT: Overlays}} allow you to tag directives in front of a normal
  72 {{slapd-ldap(5)}} directive. For example, the {{slapo-chain(5)}} overlay does
  73 this:
  74
  75 {{"There are very few chain overlay specific directives; however, directives
  76 related to the instances of the ldap backend that may be implicitly instantiated
  77 by the overlay may assume a special meaning when used in conjunction with this
  78 overlay.  They are described in slapd-ldap(5), and they also need to be prefixed
  79 by chain-."}}
  80
  81 You may have also seen the {{slapd-ldap(5)}} backend used and described in the
  82 {{SECT: Push Based}} {{SECT: Replication}} section of the guide.
  83
  84 It should therefore be obvious that the {{slapd-ldap(5)}} backend is extremely
  85 flexible and heavily used throughout the OpenLDAP Suite.
  86
  87 The following is a very simple example, but already the power of the {{slapd-ldap(5)}}
  88 backend is seen by use of a {{uri list}}:
  89
  90 >       database        ldap
  91 >       suffix          "dc=suretecsystems,dc=com"
  92 >       rootdn          "cn=slapd-ldap"
  93 >       uri             ldap://localhost/ ldap://remotehost ldap://remotehost2
  94
  95 The URI list is space or comma-separated. Whenever the server that responds
  96 is not the first one in the list, the list is rearranged and the responsive
  97 server is moved to the head, so that it will be first contacted the next time
  98 a connection needs be created.
  99
 100 This feature can be used to provide a form of load balancing when using
 101 {{SECT: MirrorMode replication}}.
 102
 103 As always, refer to the {{slapd-ldap(5)}} man page for the finer details.
 104
 105
 106 H3: Further Information
 107
 108 {{slapd-ldap}}(5)
 109
 110 H2: LDIF
 111
 112
 113 H3: Overview
 114
 115 The LDIF backend to {{slapd}}(8) is a basic storage backend that stores
 116 entries in text files in LDIF format, and exploits the filesystem to create
 117 the tree structure of the database. It is intended as a cheap, low performance
 118 easy to use backend.
 119
 120 When using the {{cn=config}} dynamic configuration database with persistent
 121 storage, the configuration data is stored using this backend. See {{slapd-config}}(5)
 122 for more information
 123
 124 H3: back-ldif Configuration
 125
 126 LATER
 127
 128 H3: Further Information
 129
 130 {{slapd-ldif}}(5)
 131
 132 H2: Metadirectory
 133
 134
 135 H3: Overview
 136
 137 The meta backend to {{slapd}}(8) performs basic LDAP proxying with respect
 138 to a set of remote LDAP servers, called "targets". The information contained
 139 in these servers can be presented as belonging to a single Directory Information
 140 Tree ({{TERM:DIT}}).
 141
 142 A basic knowledge of the functionality of the {{slapd-ldap}}(5) backend is
 143 recommended. This backend has been designed as an enhancement of the ldap
 144 backend. The two backends share many features (actually they also share portions
 145  of code). While the ldap backend is intended to proxy operations directed
 146  to a single server, the meta backend is mainly intended for proxying of
 147  multiple servers and possibly naming context  masquerading.
 148
 149 These features, although useful in many scenarios, may result in excessive
 150 overhead for some applications, so its use should be carefully considered.
 151
 152
 153 H3: back-meta Configuration
 154
 155 LATER
 156
 157 H3: Further Information
 158
 159 {{slapd-meta}}(5)
 160
 161 H2: Monitor
 162
 163
 164 H3: Overview
 165
 166 The monitor backend to {{slapd}}(8) is not an actual database; if enabled,
 167 it is automatically generated and dynamically maintained by slapd with
 168 information about the running status of the daemon.
 169
 170 To inspect all monitor information, issue a subtree search with base {{cn=Monitor}},
 171 requesting that attributes "+" and "*" are returned. The monitor backend produces
 172 mostly operational attributes, and LDAP only returns operational attributes
 173 that are explicitly requested.  Requesting attribute "+" is an extension which
 174 requests all operational attributes.
 175
 176 See the {{SECT:Monitoring}} section.
 177
 178 H3: back-monitor Configuration
 179
 180 LATER
 181
 182 H3: Further Information
 183
 184 {{slapd-monitor}}(5)
 185
 186 H2: Null
 187
 188
 189 H3: Overview
 190
 191 The Null backend to {{slapd}}(8) is surely the most useful part of slapd:
 192
 193 * Searches return success but no entries.
 194 * Compares return compareFalse.
 195 * Updates return success (unless readonly is on) but do nothing.
 196 * Binds other than as the rootdn fail unless the database option "bind on" is given.
 197 * The slapadd(8) and slapcat(8) tools are equally exciting.
 198
 199 Inspired by the {{F:/dev/null}} device.
 200
 201 H3: back-null Configuration
 202
 203 LATER
 204
 205 H3: Further Information
 206
 207 {{slapd-null}}(5)
 208
 209 H2: Passwd
 210
 211
 212 H3: Overview
 213
 214 The PASSWD backend to {{slapd}}(8) serves up the user account information
 215 listed in the system {{passwd}}(5) file.
 216
 217 This backend is provided for demonstration purposes only. The DN of each entry
 218 is "uid=<username>,<suffix>".
 219
 220 H3: back-passwd Configuration
 221
 222 LATER
 223
 224 H3: Further Information
 225
 226 {{slapd-passwd}}(5)
 227
 228 H2: Perl/Shell
 229
 230 H3: Overview
 231
 232 The Perl backend to {{slapd}}(8) works by embedding a {{perl}}(1) interpreter
 233 into {{slapd}}(8). Any perl database section of the configuration file
 234 {{slapd.conf}}(5) must then specify what Perl module to use. Slapd then creates
 235 a new Perl object that handles all the requests for that particular instance of the backend.
 236
 237 The Shell backend to {{slapd}}(8) executes external programs to implement
 238 operations, and is designed to make it easy to tie an existing database to the
 239 slapd front-end. This backend is is primarily intended to be used in prototypes.
 240
 241 H3: back-perl/back-shell Configuration
 242
 243 LATER
 244
 245 H3: Further Information
 246
 247 {{slapd-shell}}(5) and {{slapd-perl}}(5)
 248
 249 H2: Relay
 250
 251
 252 H3: Overview
 253
 254 The primary purpose of this {{slapd}}(8) backend is to map a naming context
 255 defined in a database running in the same {{slapd}}(8) instance into a
 256 virtual naming context, with attributeType and objectClass manipulation, if
 257 required. It requires the rwm overlay.
 258
 259 This backend and the above mentioned overlay are experimental.
 260
 261 H3: back-relay Configuration
 262
 263 LATER
 264
 265 H3: Further Information
 266
 267 {{slapd-relay}}(5)
 268
 269 H2: SQL
 270
 271
 272 H3: Overview
 273
 274 The primary purpose of this {{slapd}}(8) backend is to PRESENT information
 275 stored in some RDBMS as an LDAP subtree without any programming (some SQL and
 276 maybe stored procedures can’t be considered programming, anyway ;).
 277
 278 That is, for example, when you (some ISP) have account information you use in
 279 an RDBMS, and want to use modern solutions that expect such information in LDAP
 280 (to authenticate users, make email lookups etc.). Or you want to synchronize or
 281 distribute information between different sites/applications that use RDBMSes
 282 and/or LDAP. Or whatever else...
 283
 284 It is {{B:NOT}} designed as a general-purpose backend that uses RDBMS instead of
 285 BerkeleyDB (as the standard BDB backend does), though it can be used as such with
 286 several limitations. Please see {{SECT: LDAP vs RDBMS}} for discussion.
 287
 288 The idea is to use some meta-information to translate LDAP queries to SQL queries,
 289 leaving relational schema untouched, so that old applications can continue using
 290 it without any modifications. This allows SQL and LDAP applications to interoperate
 291 without replication, and exchange data as needed.
 292
 293 The SQL backend is designed to be tunable to virtually any relational schema without
 294 having to change source (through that meta-information mentioned). Also, it uses
 295 ODBC to connect to RDBMSes, and is highly configurable for SQL dialects RDBMSes
 296 may use, so it may be used for integration and distribution of data on different
 297 RDBMSes, OSes, hosts etc., in other words, in highly heterogeneous environment.
 298
 299 This backend is experimental.
 300
 301 H3: back-sql Configuration
 302
 303 LATER
 304
 305 H3: Further Information
 306
 307 {{slapd-sql}}(5)