Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

LDAP Administration Guide
Previous Page Home Next Page

A.2. New Features and Enhancements in 2.4

A.2.1. Better cn=config functionality

There is a new slapd-config(5) manpage for the 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

A.2.2. Better 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.)

A.2.3. 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.

A.2.4. 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.

A.2.5. Replicating slapd Configuration (syncrepl and 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.

A.2.6. 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).

A.2.7. 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.

A.2.8. 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 https://www.openldap.org/pub/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.)

A.2.9. New overlays

  • slapo-constraint (Attribute value constraints)
  • slapo-dds (Dynamic Directory Services, RFC 2589)
  • slapo-memberof (reverse group membership maintenance)

A.2.10. New features in existing Overlays

  • slapo-pcache
    • Inspection/Maintenance
      • the cache database can be directly accessed via LDAP by adding a specific control to each LDAP request; a specific extended operation allows to consistently remove cached entries and entire cached queries
    • Hot Restart
      • cached queries are saved on disk at shutdown, and reloaded if not expired yet at subsequent restart
  • slapo-rwm can safely interoperate with other overlays
  • Dyngroup/Dynlist merge, plus security enhancements
    • added dgIdentity support (draft-haripriya-dynamicgroup)

A.2.11. New features in slapd

  • monitoring of back-{b,h}db: cache fill-in, non-indexed searches,
  • session tracking control (draft-wahl-ldap-session)
  • subtree delete in back-sql (draft-armijo-ldap-treedelete)

A.2.12. New features in libldap

  • ldap_sync client API (LDAP Content Sync Operation, RFC 4533)

A.2.13. New clients, tools and tool enhancements

  • ldapexop for arbitrary extended operations
  • Complete support of controls in request/response for all clients
  • LDAP Client tools now honor SRV records

A.2.14. New build options

  • Support for building against GnuTLS

LDAP Administration Guide
Previous Page Home Next Page

 
 
  Published under the terms of the OpenLDAP Public License Design by Interspire