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 H3: back-ldap Configuration
  58
  59 LATER
  60
  61 H3: Further Information
  62
  63 {{slapd-ldap}}(5)
  64
  65 H2: LDIF
  66
  67
  68 H3: Overview
  69
  70 The LDIF backend to {{slapd}}(8) is a basic storage backend that stores
  71 entries in text files in LDIF format, and exploits the filesystem to create
  72 the tree structure of the database. It is intended as a cheap, low performance
  73 easy to use backend.
  74
  75 When using the {{cn=config}} dynamic configuration database with persistent
  76 storage, the configuration data is stored using this backend. See {{slapd-config}}(5)
  77 for more information
  78
  79 H3: back-ldif Configuration
  80
  81 LATER
  82
  83 H3: Further Information
  84
  85 {{slapd-ldif}}(5)
  86
  87 H2: Metadirectory
  88
  89
  90 H3: Overview
  91
  92 The meta backend to {{slapd}}(8) performs basic LDAP proxying with respect
  93 to a set of remote LDAP servers, called "targets". The information contained
  94 in these servers can be presented as belonging to a single Directory Information
  95 Tree ({{TERM:DIT}}).
  96
  97 A basic knowledge of the functionality of the {{slapd-ldap}}(5) backend is
  98 recommended. This backend has been designed as an enhancement of the ldap
  99 backend. The two backends share many features (actually they also share portions
 100  of code). While the ldap backend is intended to proxy operations directed
 101  to a single server, the meta backend is mainly intended for proxying of
 102  multiple servers and possibly naming context  masquerading.
 103
 104 These features, although useful in many scenarios, may result in excessive
 105 overhead for some applications, so its use should be carefully considered.
 106
 107
 108 H3: back-meta Configuration
 109
 110 LATER
 111
 112 H3: Further Information
 113
 114 {{slapd-meta}}(5)
 115
 116 H2: Monitor
 117
 118
 119 H3: Overview
 120
 121 The monitor backend to {{slapd}}(8) is not an actual database; if enabled,
 122 it is automatically generated and dynamically maintained by slapd with
 123 information about the running status of the daemon.
 124
 125 To inspect all monitor information, issue a subtree search with base {{cn=Monitor}},
 126 requesting that attributes "+" and "*" are returned. The monitor backend produces
 127 mostly operational attributes, and LDAP only returns operational attributes
 128 that are explicitly requested.  Requesting attribute "+" is an extension which
 129 requests all operational attributes.
 130
 131 See the {{SECT:Monitoring}} section.
 132
 133 H3: back-monitor Configuration
 134
 135 LATER
 136
 137 H3: Further Information
 138
 139 {{slapd-monitor}}(5)
 140
 141 H2: Null
 142
 143
 144 H3: Overview
 145
 146 The Null backend to {{slapd}}(8) is surely the most useful part of slapd:
 147
 148 * Searches return success but no entries.
 149 * Compares return compareFalse.
 150 * Updates return success (unless readonly is on) but do nothing.
 151 * Binds other than as the rootdn fail unless the database option "bind on" is given.
 152 * The slapadd(8) and slapcat(8) tools are equally exciting.
 153
 154 Inspired by the {{F:/dev/null}} device.
 155
 156 H3: back-null Configuration
 157
 158 LATER
 159
 160 H3: Further Information
 161
 162 {{slapd-null}}(5)
 163
 164 H2: Passwd
 165
 166
 167 H3: Overview
 168
 169 The PASSWD backend to {{slapd}}(8) serves up the user account information
 170 listed in the system {{passwd}}(5) file.
 171
 172 This backend is provided for demonstration purposes only. The DN of each entry
 173 is "uid=<username>,<suffix>".
 174
 175 H3: back-passwd Configuration
 176
 177 LATER
 178
 179 H3: Further Information
 180
 181 {{slapd-passwd}}(5)
 182
 183 H2: Perl/Shell
 184
 185 H3: Overview
 186
 187 The Perl backend to {{slapd}}(8) works by embedding a {{perl}}(1) interpreter
 188 into {{slapd}}(8). Any perl database section of the configuration file
 189 {{slapd.conf}}(5) must then specify what Perl module to use. Slapd then creates
 190 a new Perl object that handles all the requests for that particular instance of the backend.
 191
 192 The Shell backend to {{slapd}}(8) executes external programs to implement
 193 operations, and is designed to make it easy to tie an existing database to the
 194 slapd front-end. This backend is is primarily intended to be used in prototypes.
 195
 196 H3: back-perl/back-shell Configuration
 197
 198 LATER
 199
 200 H3: Further Information
 201
 202 {{slapd-shell}}(5) and {{slapd-perl}}(5)
 203
 204 H2: Relay
 205
 206
 207 H3: Overview
 208
 209 The primary purpose of this {{slapd}}(8) backend is to map a naming context
 210 defined in a database running in the same {{slapd}}(8) instance into a
 211 virtual naming context, with attributeType and objectClass manipulation, if
 212 required. It requires the rwm overlay.
 213
 214 This backend and the above mentioned overlay are experimental.
 215
 216 H3: back-relay Configuration
 217
 218 LATER
 219
 220 H3: Further Information
 221
 222 {{slapd-relay}}(5)
 223
 224 H2: SQL
 225
 226
 227 H3: Overview
 228
 229 The primary purpose of this {{slapd}}(8) backend is to PRESENT information
 230 stored in some RDBMS as an LDAP subtree without any programming (some SQL and
 231 maybe stored procedures can’t be considered programming, anyway ;).
 232
 233 That is, for example, when you (some ISP) have account information you use in
 234 an RDBMS, and want to use modern solutions that expect such information in LDAP
 235 (to authenticate users, make email lookups etc.). Or you want to synchronize or
 236 distribute information between different sites/applications that use RDBMSes
 237 and/or LDAP. Or whatever else...
 238
 239 It is {{B:NOT}} designed as a general-purpose backend that uses RDBMS instead of
 240 BerkeleyDB (as the standard BDB backend does), though it can be used as such with
 241 several limitations. Please see {{SECT: LDAP vs RDBMS}} for discussion.
 242
 243 The idea is to use some meta-information to translate LDAP queries to SQL queries,
 244 leaving relational schema untouched, so that old applications can continue using
 245 it without any modifications. This allows SQL and LDAP applications to interoperate
 246 without replication, and exchange data as needed.
 247
 248 The SQL backend is designed to be tunable to virtually any relational schema without
 249 having to change source (through that meta-information mentioned). Also, it uses
 250 ODBC to connect to RDBMSes, and is highly configurable for SQL dialects RDBMSes
 251 may use, so it may be used for integration and distribution of data on different
 252 RDBMSes, OSes, hosts etc., in other words, in highly heterogeneous environment.
 253
 254 This backend is experimental.
 255
 256 H3: back-sql Configuration
 257
 258 LATER
 259
 260 H3: Further Information
 261
 262 {{slapd-sql}}(5)