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

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