H1: Changes Since Previous Release
-Nice intro here to praise everyones hard work!
+The following sections attempt to summarize the new features and changes in OpenLDAP
+software since the 2.3.x release and the OpenLDAP Admin Guide.
H2: New Guide Sections
-* Overlays
-* Backends
-* Tuning
-* complete later.........
+In order to make the Admin Guide more thorough and cover the majority of questions
+asked on the OpenLDAP mailing lists and scenarios discussed there, we have added the following new sections:
-H2: New Features in 2.4
+* {{SECT:When should I use LDAP?}}
+* {{SECT:When should I not use LDAP?}}
+* {{SECT:LDAP vs RDBMS}}
+* {{SECT:Backends}}
+* {{SECT:Overlays}}
+* {{SECT:Replication}}
+* {{SECT:Maintenance}}
+* {{SECT:Monitoring}}
+* {{SECT:Tuning}}
+* {{SECT:Troubleshooting}}
+* {{SECT:Changes Since Previous Release}}
+* {{SECT:Configuration File Examples}}
+* {{SECT:Glossary}}
-Another nice intro here
+Also, the table of contents is now 3 levels deep to ease navigation.
-H3: More overlays
+
+H2: New Features and Enhancements in 2.4
+
+H3: Better {{B:cn=config}} functionality
+
+There is a new slapd-config(5) manpage for the {{B:cn=config}} backend. The
+original design called for auto-renaming of config entries when you insert or
+delete entries with ordered names, but that was not implemented in 2.3. It is
+now in 2.4. This means, e.g., if you have
+
+> olcDatabase={1}bdb,cn=config
+> olcSuffix: dc=example,dc=com
+
+and you want to add a new subordinate, now you can ldapadd:
+
+> olcDatabase={1}bdb,cn=config
+> olcSuffix: dc=foo,dc=example,dc=com
+
+This will insert a new BDB database in slot 1 and bump all following databases
+ down one, so the original BDB database will now be named:
+
+> olcDatabase={2}bdb,cn=config
+> olcSuffix: dc=example,dc=com
+
+H3: Better {{B:cn=schema}} functionality
+
+In 2.3 you were only able to add new schema elements, not delete or modify
+existing elements. In 2.4 you can modify schema at will. (Except for the
+hardcoded system schema, of course.)
+
+H3: More sophisticated Syncrepl configurations
+
+The original implementation of Syncrepl in OpenLDAP 2.2 was intended to support
+multiple consumers within the same database, but that feature never worked and
+was removed from OpenLDAP 2.3; you could only configure a single consumer in
+any database.
+
+In 2.4 you can configure multiple consumers in a single database. The configuration
+possibilities here are quite complex and numerous. You can configure consumers
+over arbitrary subtrees of a database (disjoint or overlapping). Any portion
+of the database may in turn be provided to other consumers using the Syncprov
+overlay. The Syncprov overlay works with any number of consumers over a single
+database or over arbitrarily many glued databases.
+
+H3: N-Way Multimaster Replication
+
+As a consequence of the work to support multiple consumer contexts, the syncrepl
+system now supports full N-Way multimaster replication with entry-level conflict
+resolution. There are some important constraints, of course: In order to maintain
+consistent results across all servers, you must maintain tightly synchronized
+clocks across all participating servers (e.g., you must use NTP on all servers).
+
+The entryCSNs used for replication now record timestamps with microsecond resolution,
+instead of just seconds. The delta-syncrepl code has not been updated to support
+multimaster usage yet, that will come later in the 2.4 cycle.
+
+H3: Replicating {{slapd}} Configuration (syncrepl and {{B:cn=config}})
+
+Syncrepl was explicitly disabled on cn=config in 2.3. It is now fully supported
+in 2.4; you can use syncrepl to replicate an entire server configuration from
+one server to arbitrarily many other servers. It's possible to clone an entire
+running slapd using just a small (less than 10 lines) seed configuration, or
+you can just replicate the schema subtrees, etc. Tests 049 and 050 in the test
+suite provide working examples of these capabilities.
+
+
+H3: Push-Mode Replication
+
+In 2.3 you could configure syncrepl as a full push-mode replicator by using it
+in conjunction with a back-ldap pointed at the target server. But because the
+back-ldap database needs to have a suffix corresponding to the target's suffix,
+you could only configure one instance per slapd.
+
+In 2.4 you can define a database to be "hidden", which means that its suffix is
+ignored when checking for name collisions, and the database will never be used
+to answer requests received by the frontend. Using this "hidden" database feature
+allows you to configure multiple databases with the same suffix, allowing you to
+set up multiple back-ldap instances for pushing replication of a single database
+to multiple targets. There may be other uses for hidden databases as well (e.g.,
+using a syncrepl consumer to maintain a *local* mirror of a database on a separate filesystem).
+
+
+H3: More extensive TLS configuration control
+
+In 2.3, the TLS configuration in slapd was only used by the slapd listeners. For
+outbound connections used by e.g. back-ldap or syncrepl their TLS parameters came
+from the system's ldap.conf file.
+
+In 2.4 all of these sessions inherit their settings from the main slapd configuration,
+but settings can be individually overridden on a per-config-item basis. This is
+particularly helpful if you use certificate-based authentication and need to use a
+different client certificate for different destinations.
+
+
+H3: Performance enhancements
+
+Too many to list. Some notable changes - ldapadd used to be a couple of orders
+of magnitude slower than "slapadd -q". It's now at worst only about half the
+speed of slapadd -q. Some comparisons of all the 2.x OpenLDAP releases are available
+at {{URL:http://www.highlandsun.com/hyc/scale2007.pdf}}
+
+That compared 2.0.27, 2.1.30, 2.2.30, 2.3.33, and HEAD). Toward the latter end
+of the "Cached Search Performance" chart it gets hard to see the difference
+because the run times are so small, but the new code is about 25% faster than 2.3,
+which was about 20% faster than 2.2, which was about 100% faster than 2.1, which
+was about 100% faster than 2.0, in that particular search scenario. That test
+basically searched a 1.3GB DB of 380836 entries (all in the slapd entry cache)
+in under 1 second. i.e., on a 2.4GHz CPU with DDR400 ECC/Registered RAM we can
+search over 500 thousand entries per second. The search was on an unindexed
+attribute using a filter that would not match any entry, forcing slapd to examine
+every entry in the DB, testing the filter for a match.
+
+Essentially the slapd entry cache in back-bdb/back-hdb is so efficient the search
+processing time is almost invisible; the runtime is limited only by the memory
+bandwidth of the machine. (The search data rate corresponds to about 3.5GB/sec;
+the memory bandwidth on the machine is only about 4GB/sec due to ECC and register latency.)
+
+No other Directory Server in the world is this fast or this efficient. Couple
+that with the scalability, manageability, flexibility, and just the sheer
+know-how behind this software, and nothing else is even remotely comparable.
+
+H3: New overlays
* slapo-dds (Dynamic Directory Services, RFC 2589)
* slapo-memberof (reverse group membership maintenance)
-H3: New features in existing ones
+H3: New features in existing Overlays
* slapo-pcache allows cache inspection/maintenance/hot restart
* slapo-rwm can safely interoperate with other overlays
H2: Obsolete Features in 2.4
H3: Slurpd
+
+Please read the {{SECT:Replication}} section as to why this is no longer in
+OpenLDAP
projects / openldap / commitdiff