1# OpenLDAP: pkg/openldap-guide/admin/appendix-changes.sdf,v 1.8.2.8 2010/04/13 20:22:32 kurt Exp 2# Copyright 2007-2010 The OpenLDAP Foundation, All Rights Reserved. 3# COPYING RESTRICTIONS APPLY, see COPYRIGHT. 4 5H1: Changes Since Previous Release 6 7The following sections attempt to summarize the new features and changes in OpenLDAP 8software since the 2.3.x release and the OpenLDAP Admin Guide. 9 10H2: New Guide Sections 11 12In order to make the Admin Guide more thorough and cover the majority of questions 13asked 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 36Also, the table of contents is now 3 levels deep to ease navigation. 37 38 39H2: New Features and Enhancements in 2.4 40 41H3: Better {{B:cn=config}} functionality 42 43There is a new slapd-config(5) manpage for the {{B:cn=config}} backend. The 44original design called for auto-renaming of config entries when you insert or 45delete entries with ordered names, but that was not implemented in 2.3. It is 46now in 2.4. This means, e.g., if you have 47 48> olcDatabase={1}bdb,cn=config 49> olcSuffix: dc=example,dc=com 50 51and 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 56This 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 62H3: Better {{B:cn=schema}} functionality 63 64In 2.3 you were only able to add new schema elements, not delete or modify 65existing elements. In 2.4 you can modify schema at will. (Except for the 66hardcoded system schema, of course.) 67 68H3: More sophisticated Syncrepl configurations 69 70The original implementation of Syncrepl in OpenLDAP 2.2 was intended to support 71multiple consumers within the same database, but that feature never worked and 72was removed from OpenLDAP 2.3; you could only configure a single consumer in 73any database. 74 75In 2.4 you can configure multiple consumers in a single database. The configuration 76possibilities here are quite complex and numerous. You can configure consumers 77over arbitrary subtrees of a database (disjoint or overlapping). Any portion 78of the database may in turn be provided to other consumers using the Syncprov 79overlay. The Syncprov overlay works with any number of consumers over a single 80database or over arbitrarily many glued databases. 81 82H3: N-Way Multimaster Replication 83 84As a consequence of the work to support multiple consumer contexts, the syncrepl 85system now supports full N-Way multimaster replication with entry-level conflict 86resolution. There are some important constraints, of course: In order to maintain 87consistent results across all servers, you must maintain tightly synchronized 88clocks across all participating servers (e.g., you must use NTP on all servers). 89 90The entryCSNs used for replication now record timestamps with microsecond resolution, 91instead of just seconds. The delta-syncrepl code has not been updated to support 92multimaster usage yet, that will come later in the 2.4 cycle. 93 94H3: Replicating {{slapd}} Configuration (syncrepl and {{B:cn=config}}) 95 96Syncrepl was explicitly disabled on cn=config in 2.3. It is now fully supported 97in 2.4; you can use syncrepl to replicate an entire server configuration from 98one server to arbitrarily many other servers. It's possible to clone an entire 99running slapd using just a small (less than 10 lines) seed configuration, or 100you can just replicate the schema subtrees, etc. Tests 049 and 050 in the test 101suite provide working examples of these capabilities. 102 103 104H3: Push-Mode Replication 105 106In 2.3 you could configure syncrepl as a full push-mode replicator by using it 107in conjunction with a back-ldap pointed at the target server. But because the 108back-ldap database needs to have a suffix corresponding to the target's suffix, 109you could only configure one instance per slapd. 110 111In 2.4 you can define a database to be "hidden", which means that its suffix is 112ignored when checking for name collisions, and the database will never be used 113to answer requests received by the frontend. Using this "hidden" database feature 114allows you to configure multiple databases with the same suffix, allowing you to 115set up multiple back-ldap instances for pushing replication of a single database 116to multiple targets. There may be other uses for hidden databases as well (e.g., 117using a syncrepl consumer to maintain a *local* mirror of a database on a separate filesystem). 118 119 120H3: More extensive TLS configuration control 121 122In 2.3, the TLS configuration in slapd was only used by the slapd listeners. For 123outbound connections used by e.g. back-ldap or syncrepl their TLS parameters came 124from the system's ldap.conf file. 125 126In 2.4 all of these sessions inherit their settings from the main slapd configuration, 127but settings can be individually overridden on a per-config-item basis. This is 128particularly helpful if you use certificate-based authentication and need to use a 129different client certificate for different destinations. 130 131 132H3: Performance enhancements 133 134Too many to list. Some notable changes - ldapadd used to be a couple of orders 135of magnitude slower than "slapadd -q". It's now at worst only about half the 136speed of slapadd -q. Some comparisons of all the 2.x OpenLDAP releases are available 137at {{URL:http://www.openldap.org/pub/hyc/scale2007.pdf}} 138 139That compared 2.0.27, 2.1.30, 2.2.30, 2.3.33, and HEAD). Toward the latter end 140of the "Cached Search Performance" chart it gets hard to see the difference 141because the run times are so small, but the new code is about 25% faster than 2.3, 142which was about 20% faster than 2.2, which was about 100% faster than 2.1, which 143was about 100% faster than 2.0, in that particular search scenario. That test 144basically searched a 1.3GB DB of 380836 entries (all in the slapd entry cache) 145in under 1 second. i.e., on a 2.4GHz CPU with DDR400 ECC/Registered RAM we can 146search over 500 thousand entries per second. The search was on an unindexed 147attribute using a filter that would not match any entry, forcing slapd to examine 148every entry in the DB, testing the filter for a match. 149 150Essentially the slapd entry cache in back-bdb/back-hdb is so efficient the search 151processing time is almost invisible; the runtime is limited only by the memory 152bandwidth of the machine. (The search data rate corresponds to about 3.5GB/sec; 153the memory bandwidth on the machine is only about 4GB/sec due to ECC and register latency.) 154 155H3: 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 161H3: 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 177H3: 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 184multiprocessor machines. (33% faster than 2.3 on AMD quad-socket dual-core server.) 185 186 187H3: New features in libldap 188 189* ldap_sync client API (LDAP Content Sync Operation, RFC 4533) 190 191H3: 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 197H3: New build options 198 199* Support for building against GnuTLS 200 201 202H2: Obsolete Features Removed From 2.4 203 204These features were strongly deprecated in 2.3 and removed in 2.4. 205 206H3: Slurpd 207 208Please read the {{SECT:Replication}} section as to why this is no longer in 209OpenLDAP 210 211H3: back-ldbm 212 213back-ldbm was both slow and unreliable. Its byzantine indexing code was 214prone to spontaneous corruption, as were the underlying database libraries 215that were commonly used (e.g. GDBM or NDBM). back-bdb and back-hdb are 216superior in every aspect, with simplified indexing to avoid index corruption, 217fine-grained locking for greater concurrency, hierarchical caching for 218greater performance, streamlined on-disk format for greater efficiency 219and portability, and full transaction support for greater reliability. 220