Dustin Puryear wrote:
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
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
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.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/