1# $OpenLDAP: pkg/openldap-guide/admin/backends.sdf,v 1.8.2.5 2008/04/14 19:00:49 quanah Exp $ 2# Copyright 2007-2008 The OpenLDAP Foundation, All Rights Reserved. 3# COPYING RESTRICTIONS APPLY, see COPYRIGHT. 4 5H1: Backends 6 7 8H2: Berkeley DB Backends 9 10 11H3: Overview 12 13The {{bdb}} backend to {{slapd}}(8) is the recommended primary backend for a 14normal {{slapd}} database. It uses the Oracle Berkeley DB ({{TERM:BDB}}) 15package 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 19layout which supports subtree renames. It is otherwise identical to the {{bdb}} 20 behavior, and all the same configuration options apply. 21 22Note: An {{hdb}} database needs a large {{idlcachesize}} for good search performance, 23typically three times the {{cachesize}} (entry cache size) or larger. 24 25H3: back-bdb/back-hdb Configuration 26 27MORE LATER 28 29H3: Further Information 30 31{{slapd-bdb}}(5) 32 33H2: LDAP 34 35 36H3: Overview 37 38The LDAP backend to {{slapd}}(8) is not an actual database; instead it acts 39as a proxy to forward incoming requests to another LDAP server. While 40processing requests it will also chase referrals, so that referrals are fully 41processed instead of being returned to the {{slapd}} client. 42 43Sessions that explicitly {{Bind}} to the {{back-ldap}} database always create 44their own private connection to the remote LDAP server. Anonymous sessions 45will share a single anonymous connection to the remote server. For sessions 46bound through other mechanisms, all sessions with the same DN will share the 47same connection. This connection pooling strategy can enhance the proxy's 48efficiency by reducing the overhead of repeatedly making/breaking multiple 49connections. 50 51The ldap database can also act as an information service, i.e. the identity 52of locally authenticated clients is asserted to the remote server, possibly 53in some modified form. For this purpose, the proxy binds to the remote server 54with some administrative identity, and, if required, authorizes the asserted 55identity. 56 57H3: back-ldap Configuration 58 59LATER 60 61H3: Further Information 62 63{{slapd-ldap}}(5) 64 65H2: LDIF 66 67 68H3: Overview 69 70The LDIF backend to {{slapd}}(8) is a basic storage backend that stores 71entries in text files in LDIF format, and exploits the filesystem to create 72the tree structure of the database. It is intended as a cheap, low performance 73easy to use backend. 74 75When using the {{cn=config}} dynamic configuration database with persistent 76storage, the configuration data is stored using this backend. See {{slapd-config}}(5) 77for more information 78 79H3: back-ldif Configuration 80 81LATER 82 83H3: Further Information 84 85{{slapd-ldif}}(5) 86 87H2: Metadirectory 88 89 90H3: Overview 91 92The meta backend to {{slapd}}(8) performs basic LDAP proxying with respect 93to a set of remote LDAP servers, called "targets". The information contained 94in these servers can be presented as belonging to a single Directory Information 95Tree ({{TERM:DIT}}). 96 97A basic knowledge of the functionality of the {{slapd-ldap}}(5) backend is 98recommended. This backend has been designed as an enhancement of the ldap 99backend. 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 104These features, although useful in many scenarios, may result in excessive 105overhead for some applications, so its use should be carefully considered. 106 107 108H3: back-meta Configuration 109 110LATER 111 112H3: Further Information 113 114{{slapd-meta}}(5) 115 116H2: Monitor 117 118 119H3: Overview 120 121The monitor backend to {{slapd}}(8) is not an actual database; if enabled, 122it is automatically generated and dynamically maintained by slapd with 123information about the running status of the daemon. 124 125To inspect all monitor information, issue a subtree search with base {{cn=Monitor}}, 126requesting that attributes "+" and "*" are returned. The monitor backend produces 127mostly operational attributes, and LDAP only returns operational attributes 128that are explicitly requested. Requesting attribute "+" is an extension which 129requests all operational attributes. 130 131See the {{SECT:Monitoring}} section. 132 133H3: back-monitor Configuration 134 135LATER 136 137H3: Further Information 138 139{{slapd-monitor}}(5) 140 141H2: Null 142 143 144H3: Overview 145 146The 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 154Inspired by the {{F:/dev/null}} device. 155 156H3: back-null Configuration 157 158LATER 159 160H3: Further Information 161 162{{slapd-null}}(5) 163 164H2: Passwd 165 166 167H3: Overview 168 169The PASSWD backend to {{slapd}}(8) serves up the user account information 170listed in the system {{passwd}}(5) file. 171 172This backend is provided for demonstration purposes only. The DN of each entry 173is "uid=<username>,<suffix>". 174 175H3: back-passwd Configuration 176 177LATER 178 179H3: Further Information 180 181{{slapd-passwd}}(5) 182 183H2: Perl/Shell 184 185H3: Overview 186 187The Perl backend to {{slapd}}(8) works by embedding a {{perl}}(1) interpreter 188into {{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 190a new Perl object that handles all the requests for that particular instance of the backend. 191 192The Shell backend to {{slapd}}(8) executes external programs to implement 193operations, and is designed to make it easy to tie an existing database to the 194slapd front-end. This backend is is primarily intended to be used in prototypes. 195 196H3: back-perl/back-shell Configuration 197 198LATER 199 200H3: Further Information 201 202{{slapd-shell}}(5) and {{slapd-perl}}(5) 203 204H2: Relay 205 206 207H3: Overview 208 209The primary purpose of this {{slapd}}(8) backend is to map a naming context 210defined in a database running in the same {{slapd}}(8) instance into a 211virtual naming context, with attributeType and objectClass manipulation, if 212required. It requires the rwm overlay. 213 214This backend and the above mentioned overlay are experimental. 215 216H3: back-relay Configuration 217 218LATER 219 220H3: Further Information 221 222{{slapd-relay}}(5) 223 224H2: SQL 225 226 227H3: Overview 228 229The primary purpose of this {{slapd}}(8) backend is to PRESENT information 230stored in some RDBMS as an LDAP subtree without any programming (some SQL and 231maybe stored procedures can’t be considered programming, anyway ;). 232 233That is, for example, when you (some ISP) have account information you use in 234an 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 236distribute information between different sites/applications that use RDBMSes 237and/or LDAP. Or whatever else... 238 239It is {{B:NOT}} designed as a general-purpose backend that uses RDBMS instead of 240BerkeleyDB (as the standard BDB backend does), though it can be used as such with 241several limitations. Please see {{SECT: LDAP vs RDBMS}} for discussion. 242 243The idea is to use some meta-information to translate LDAP queries to SQL queries, 244leaving relational schema untouched, so that old applications can continue using 245it without any modifications. This allows SQL and LDAP applications to interoperate 246without replication, and exchange data as needed. 247 248The SQL backend is designed to be tunable to virtually any relational schema without 249having to change source (through that meta-information mentioned). Also, it uses 250ODBC to connect to RDBMSes, and is highly configurable for SQL dialects RDBMSes 251may use, so it may be used for integration and distribution of data on different 252RDBMSes, OSes, hosts etc., in other words, in highly heterogeneous environment. 253 254This backend is experimental. 255 256H3: back-sql Configuration 257 258LATER 259 260H3: Further Information 261 262{{slapd-sql}}(5) 263