title: openldap as a metadirectory link: https://onemoretech.wordpress.com/2007/09/04/openldap-as-a-metadirectory/ author: lembobro description: post_id: 647 created: 2007/09/04 12:44:00 created_gmt: 2007/09/04 12:44:00 comment_status: open post_name: openldap-as-a-metadirectory status: publish post_type: post

openldap as a metadirectory

Now that I’ve got some experience using the OpenLDAP proxy backend, I’ve moved on to struggling with getting the meta backend (”slapd-meta” or “back-meta”, the former how it’s looked up in the man pages, the latter how it’s referred to in the doc and on the mail lists).

The doc is really sparse on this. Actually, it doesn’t really address it at all. The man pages are, well, man pages. So this is going to be a real “adventure”. There’s not much on the lists either, for the most part pleas for concrete examples are met with “what are you trying to do” or “why would you want to do that” from various quarters.

Very interesting.

Anyway, I’ve started off by building my own custom OpenLDAP server from the latest stable source. Here’s my configure syntax:

./configure --prefix=/opt/openldap/meta \--enable-ldap \--enable-meta \--enable-sql \--enable-rewrite \--enable-rwm \--enable-proxycache \--enable-glue \--enable-unique \--enable-refint \--enable-dynlist

In the list above only ldap, meta and rewrite should be essential. After some initial experimentation, I found that my efforts to merge together two or more directory trees were only successful after I compiled in the glue overlay.

If you look at my description below of where I’m going with this, I think it will become obvious why I’m including the other modules/overlays listed (except for rwm, that overlay is supposed to replace rewrite in future, so I want to try it out now).

I’m also going to try some different config variations from the slapd-meta man page, which so far hasn’t gone so well.

Before I start in earnest though, let me set out what I’m looking for.

One of the big problems that all directory admins have to deal with is the insane amount of data importing, conversion and outright munging necessary to maintain a centralized directory service that’s going to be of any use by anyone. While proxying and caching results can help, the most vexing issue remains how to most efficiently consolidate needed information into the directory.

There are other, rather simple, solutions to this dilema. The one most recommended in the early years of LDAP was to use the referral feature to have queries get redirected to another directory that would have the data the inquirer was looking for. Of course, if data were spread out over several different directories (or relational databases with LDAP listeners), that would force an application to make multiple queries and consoliate the information for itself.

What really is needed is a consolidated “view” of multiple sources of data into a single LDAP directory record for a user, all nicely massaged and normalized for use by any application that needs it. That’s why I’ve also compiled in support for the sql backend (an ODBC manager and it’s source, like unixODBC and unixODBC-devel are required to compile), proxycache, attribute uniqueness, referential integrity and dynamic groups.

This is my quest. To follow that star. No matter how hopeless. No matter how far.

I hope along the way we’ll all learn a few things we can actually use “back at the shop”, as my Dad used to say.

Copyright 2004-2019 Phil Lembo