]> git.sur5r.net Git - openldap/blob - doc/guide/admin/appendix-changes.sdf
Merge remote-tracking branch 'origin/mdb.master'
[openldap] / doc / guide / admin / appendix-changes.sdf
1 # $OpenLDAP$
2 # Copyright 2007-2012 The OpenLDAP Foundation, All Rights Reserved.
3 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
4
5 H1: Changes Since Previous Release
6
7 The following sections attempt to summarize the new features and changes in OpenLDAP
8 software since the 2.3.x release and the OpenLDAP Admin Guide.
9
10 H2: New Guide Sections
11
12 In order to make the Admin Guide more thorough and cover the majority of questions
13 asked on the OpenLDAP mailing lists and scenarios discussed there, we have added the following new sections:
14
15 * {{SECT:When should I use LDAP?}}
16 * {{SECT:When should I not use LDAP?}}
17 * {{SECT:LDAP vs RDBMS}}
18 * {{SECT:Access Control}}
19 * {{SECT:Backends}}
20 * {{SECT:Overlays}}
21 * {{SECT:Replication}}
22 * {{SECT:Maintenance}}
23 * {{SECT:Monitoring}}
24 * {{SECT:Tuning}}
25 * {{SECT:Troubleshooting}}
26 * {{SECT:Changes Since Previous Release}}
27 * {{SECT:Upgrading from 2.3.x}}
28 * {{SECT:Common errors encountered when using OpenLDAP Software}}
29 * {{SECT:Recommended OpenLDAP Software Dependency Versions}}
30 * {{SECT:Real World OpenLDAP Deployments and Examples}}
31 * {{SECT:OpenLDAP Software Contributions}}
32 * {{SECT:Configuration File Examples}}
33 * {{SECT:LDAP Result Codes}}
34 * {{SECT:Glossary}}
35
36 Also, the table of contents is now 3 levels deep to ease navigation.
37
38
39 H2: New Features and Enhancements in 2.4
40
41 H3: Better {{B:cn=config}} functionality
42
43 There is a new slapd-config(5) manpage for the {{B:cn=config}} backend. The 
44 original design called for auto-renaming of config entries when you insert or 
45 delete entries with ordered names, but that was not implemented in 2.3. It is 
46 now in 2.4. This means, e.g., if you have
47
48 >   olcDatabase={1}bdb,cn=config
49 >   olcSuffix: dc=example,dc=com
50
51 and you want to add a new subordinate, now you can ldapadd:
52
53 >   olcDatabase={1}bdb,cn=config
54 >   olcSuffix: dc=foo,dc=example,dc=com
55
56 This will insert a new BDB database in slot 1 and bump all following databases
57  down one, so the original BDB database will now be named:
58
59 >   olcDatabase={2}bdb,cn=config
60 >   olcSuffix: dc=example,dc=com
61
62 H3: Better {{B:cn=schema}} functionality
63
64 In 2.3 you were only able to add new schema elements, not delete or modify 
65 existing elements. In 2.4 you can modify schema at will. (Except for the 
66 hardcoded system schema, of course.)
67
68 H3: More sophisticated Syncrepl configurations
69
70 The original implementation of Syncrepl in OpenLDAP 2.2 was intended to support 
71 multiple consumers within the same database, but that feature never worked and 
72 was removed from OpenLDAP 2.3; you could only configure a single consumer in 
73 any database.
74
75 In 2.4 you can configure multiple consumers in a single database. The configuration 
76 possibilities here are quite complex and numerous. You can configure consumers 
77 over arbitrary subtrees of a database (disjoint or overlapping). Any portion 
78 of the database may in turn be provided to other consumers using the Syncprov 
79 overlay. The Syncprov overlay works with any number of consumers over a single 
80 database or over arbitrarily many glued databases.
81
82 H3: N-Way Multimaster Replication
83
84 As a consequence of the work to support multiple consumer contexts, the syncrepl 
85 system now supports full N-Way multimaster replication with entry-level conflict 
86 resolution. There are some important constraints, of course: In order to maintain 
87 consistent results across all servers, you must maintain tightly synchronized 
88 clocks across all participating servers (e.g., you must use NTP on all servers). 
89
90 The entryCSNs used for replication now record timestamps with microsecond resolution, 
91 instead of just seconds. The delta-syncrepl code has not been updated to support 
92 multimaster usage yet, that will come later in the 2.4 cycle.
93
94 H3: Replicating {{slapd}} Configuration (syncrepl and {{B:cn=config}})
95
96 Syncrepl was explicitly disabled on cn=config in 2.3. It is now fully supported 
97 in 2.4; you can use syncrepl to replicate an entire server configuration from 
98 one server to arbitrarily many other servers. It's possible to clone an entire 
99 running slapd using just a small (less than 10 lines) seed configuration, or 
100 you can just replicate the schema subtrees, etc. Tests 049 and 050 in the test 
101 suite provide working examples of these capabilities.
102
103
104 H3: Push-Mode Replication
105
106 In 2.3 you could configure syncrepl as a full push-mode replicator by using it 
107 in conjunction with a back-ldap pointed at the target server. But because the 
108 back-ldap database needs to have a suffix corresponding to the target's suffix, 
109 you could only configure one instance per slapd.
110
111 In 2.4 you can define a database to be "hidden", which means that its suffix is 
112 ignored when checking for name collisions, and the database will never be used 
113 to answer requests received by the frontend. Using this "hidden" database feature 
114 allows you to configure multiple databases with the same suffix, allowing you to 
115 set up multiple back-ldap instances for pushing replication of a single database 
116 to multiple targets. There may be other uses for hidden databases as well (e.g., 
117 using a syncrepl consumer to maintain a *local* mirror of a database on a separate filesystem).
118
119
120 H3: More extensive TLS configuration control
121
122 In 2.3, the TLS configuration in slapd was only used by the slapd listeners. For 
123 outbound connections used by e.g. back-ldap or syncrepl their TLS parameters came 
124 from the system's ldap.conf file.
125
126 In 2.4 all of these sessions inherit their settings from the main slapd configuration, 
127 but settings can be individually overridden on a per-config-item basis. This is 
128 particularly helpful if you use certificate-based authentication and need to use a 
129 different client certificate for different destinations.
130
131
132 H3: Performance enhancements
133
134 Too many to list. Some notable changes - ldapadd used to be a couple of orders 
135 of magnitude slower than "slapadd -q". It's now at worst only about half the 
136 speed of slapadd -q. Some comparisons of all the 2.x OpenLDAP releases are available 
137 at {{URL:http://www.openldap.org/pub/hyc/scale2007.pdf}}
138
139 That compared 2.0.27, 2.1.30, 2.2.30, 2.3.33, and CVS HEAD). Toward the latter end 
140 of the "Cached Search Performance" chart it gets hard to see the difference 
141 because the run times are so small, but the new code is about 25% faster than 2.3, 
142 which was about 20% faster than 2.2, which was about 100% faster than 2.1, which 
143 was about 100% faster than 2.0, in that particular search scenario. That test 
144 basically searched a 1.3GB DB of 380836 entries (all in the slapd entry cache) 
145 in under 1 second. i.e., on a 2.4GHz CPU with DDR400 ECC/Registered RAM we can 
146 search over 500 thousand entries per second. The search was on an unindexed 
147 attribute using a filter that would not match any entry, forcing slapd to examine 
148 every entry in the DB, testing the filter for a match.
149
150 Essentially the slapd entry cache in back-bdb/back-hdb is so efficient the search 
151 processing time is almost invisible; the runtime is limited only by the memory 
152 bandwidth of the machine. (The search data rate corresponds to about 3.5GB/sec; 
153 the memory bandwidth on the machine is only about 4GB/sec due to ECC and register latency.)
154
155 H3: New overlays
156
157 * slapo-constraint (Attribute value constraints)
158 * slapo-dds (Dynamic Directory Services, RFC 2589)
159 * slapo-memberof (reverse group membership maintenance)
160
161 H3: New features in existing Overlays
162
163 * slapo-pcache
164   - Inspection/Maintenance 
165     -- the cache database can be directly accessed via
166        LDAP by adding a specific control to each LDAP request; a specific
167        extended operation allows to consistently remove cached entries and entire
168        cached queries
169   - Hot Restart
170     -- cached queries are saved on disk at shutdown, and reloaded if
171       not expired yet at subsequent restart
172
173 * slapo-rwm can safely interoperate with other overlays
174 * Dyngroup/Dynlist merge, plus security enhancements
175   - added dgIdentity support (draft-haripriya-dynamicgroup)
176
177 H3: New features in slapd
178
179 * monitoring of back-{b,h}db: cache fill-in, non-indexed searches,
180 * session tracking control (draft-wahl-ldap-session)
181 * subtree delete in back-sql (draft-armijo-ldap-treedelete)
182 * sorted values in multivalued attributes for faster matching 
183 * lightweight dispatcher for greater throughput under heavy load and on
184 multiprocessor machines. (33% faster than 2.3 on AMD quad-socket dual-core server.)
185
186
187 H3: New features in libldap
188
189 * ldap_sync client API (LDAP Content Sync Operation, RFC 4533)
190
191 H3: New clients, tools and tool enhancements
192
193 * ldapexop for arbitrary extended operations
194 * Complete support of controls in request/response for all clients
195 * LDAP Client tools now honor SRV records 
196
197 H3: New build options
198
199 * Support for building against GnuTLS
200
201
202 H2: Obsolete Features Removed From 2.4
203
204 These features were strongly deprecated in 2.3 and removed in 2.4.
205
206 H3: Slurpd
207
208 Please read the {{SECT:Replication}} section as to why this is no longer in
209 OpenLDAP
210
211 H3: back-ldbm
212
213 back-ldbm was both slow and unreliable. Its byzantine indexing code was
214 prone to spontaneous corruption, as were the underlying database libraries
215 that were commonly used (e.g. GDBM or NDBM). back-bdb and back-hdb are
216 superior in every aspect, with simplified indexing to avoid index corruption,
217 fine-grained locking for greater concurrency, hierarchical caching for
218 greater performance, streamlined on-disk format for greater efficiency
219 and portability, and full transaction support for greater reliability.