Dustin Puryear wrote:

Howard-

I read through your presentation "OpenLDAP Highlights for 2.4". Very informative, thanks. Now, a few questions:

1. re: "ldapadd performance". Can you briefly explain what exactly was

done in "Optimized server and client in 2.4" to bring down the ldapadd time from 1:33:08 to 5:20. That's a huge a difference.

I don't remember all the details any more, but I covered this on the -devel list a couple months ago. The main speedups had to do with the processing of multi-valued attributes, for which duplicate-checking was taking O(n^2) time. There were also improvements to the LDIF parser used by ldapadd/ldapmodify, similar to improvements that had already been made in slapadd in 2.3. (I had rewritten the LDIF parser for slapadd in 2.3, but ldapadd/ldapmodify was still using the old UMich parser. Now they're all using my new parser.)

2. re: "The Road Ahead...", you note some useful configuration

functionality, including: TLS certs as an LDAP object rather than as a file on disk, loadable modules as LDAP objects, and automatic creation of filesystem directories for DBs. Very cool.

I do wonder about putting loadable modules into the directory. First, let me preface this by saying that obviously an administrator needs to ensure that the proper access rights are given out. That said, isn't there a real risk of someone running evil code on the LDAP server by simply having the ability to add a loadable module object in the directory? (Yes, this same admin may be able to just delete entries anyway, but that's different to me than actually being able to run code that can hook into slapd.)

Anyone with access to cn=config can already wreak havoc on the server. You can already specify that arbitrary code get dynamically loaded (by adding an olcModule entry). That's one of the reasons cn=config access was restricted to only a rootDN in 2.3, because it's a bad idea to make it too widely accessible.

What is the driver for this developing this functionality?

The point behind cn=config is to be able to do all administration through the LDAP interface, and never have any server downtime for any administrative reasons. E.g., when all the backends and overlays are dynamic modules, you should be able to deploy patches dynamically, upgrading particular backends etc., across an entire network of servers, from a single LDAP console. In fact you should be able to ldapadd an entire slapd binary onto a target server and have it re-exec itself if you so choose.

Other products tend to rely on a whole set of loosely-cobbled-together protocols and services to do administration, but we already have a powerful and secure mechanism in LDAP itself. Ultimately you should be able to deploy an embedded appliance with nothing more than a kernel and slapd itself - no extraneous network services, no terminal access, no firewall overhead, just an airtight directory-in-a-box.

We're most of the way there already now - you can install slapd with a canned 10 line config.ldif and have it suck down all of its configuration and data from another provider, then let it run without any intervention at all. All of this makes managing multiple servers in a large enterprise a whole lot simpler. You only need to enable a single network port, and you only need to understand a single protocol, to track everything going on in the infrastructure.