Slashdot Mirror
What Else Is There Besides OpenLDAP?
The Stunted Leech asks: "I am trying to develop an LDAP interface to an existing customer database and would like to implement a simple LDAP listener that could be queried from e-mail clients. Before everyone suggests importing the data to OpenLDAP or developing a back-end for it, let me just say that it isn't very feasible: I'm the only person assigned to the project, and my company doesn't have the time or hardware resources to maintain an LDAP server. So I'm looking for very simple implementations of LDAP servers, preferably in a scripting language like Perl or Python (we use Perl for CGIs and wxPython for GUI front-ends). I've come across a couple of Java-based ones, but they seemed overly complex - all I need to do is retrieve a contact's e-mail or phone number from our database. Pointers to any sort of simple LDAP servers are welcome, even if they do little more than return the same result to all queries."
You'd be crazy not to re-use all the LDAP protocol work that OpenLDAP does for you. In addition, writing backends is not as hard as you infer.
In your case, you can probably use the Perl backend plugin, and base your custom thingy on:
Run the openldap server on the same machine that's running your database right now and you're done.
In any case, even Perl's too much for you - why would you write your own gateway when the vast majority of the work has been done for you? I wonder why OpenLDAP is something that you don't want? Resource-wise, unless you're handling a _lot_ of clients or a really pathological schema behind it, you shouldn't have any problems. In terms of administration, it really does mostly run itself. Setup the initial gateway, and you're done, other than having one more service to watch.
I don't know of any simpler solutions, other than "don't use it, then". Maybe I'm misunderstanding.
I do know a lot of people break out into hives when confronted with LDAP. Most of those people don't have much of a background in the theory behind it. I seriously don't mean this as a put-down - I don't have a formal background in the theory, either. All I mean is that it really isn't all that scary once you start doing it. Again, maybe I'm missing the problem.
Hope this does someone some good.
I forget what 8 was for.
Well, some applications of it (LDAP for user management) anyway, but that's a subject for a different rant.
:-D
To address your question -- you are in a situation similar to me: You need to implement LDAP access to some data you already have stored somewhere else (presumably in a format "better" than an LDAP directory).
Your best bet would be to implement an OpenLDAP or iPlanet/Netscape/Sun directory server, seed it with the data you already have(a conversion script could probably be written easily), and "educate" the software you use to maintain your current database so that it updates LDAP as well as the current system (using the Net::LDAP module for Perl, or something similarly generic that would work with any LDAP server).
However, since this is not what you want (you don't have the "time or hardware resources" to maintain an LDAP server), you are unfortunately stuck with plan B: Write a listener on port 389 that understands LDAP queries, goes into your current database, grabs the data and spits it out in an LDAP-Like way.
Were I you, I would re-evaluate the cost and difficulty of running an LDAP server and maintaining the synchronization (or migrating the data to LDAP entirely, if it lends itself well to the directory/tree structure of LDAP). Plan B generally pretty much SUCKS, and will inevitably require more time/effort/money to implement and maintain.
Nonetheless, the Net::LDAP library for Perl would be a good place to start with this task. You could also look at the OpenLDAP software as a reference implementation (the code is a fairly easy read (to me anyway) and should be helpful in designing your serverlike hybrid.
You may also wish to look into commercial "metadirectory" products which take one central authoritative datasource and multiplex it out in a variety of formats. When I last looked at these they all sucked, but the "best of breed" back then was something called "DC Directory Server". If you could find one that suits your needs it may be the way to go.
I know this wasn't very helpful, the truth is (as I have been discovering myself) anything LDAP is still kinda raw, and anything complex like what you are trying to do is really not well-explored (or at least not well-documented). Maybe some other slashdotters can be more insightful than me though
Good luck
/~mikeg
Methinks someone is just interested in tinkering with some new programming, not in really solving a problem. While the programmer in me salutes you, get real! Do you honestly think you're going to save either time OR money implementing (even just a subset of) a protocol instead of installing and tuning something that has already been written and debugged for quite a while? You can't have been writing code for very long then.
If I were you, I'd spend the week you think this is going to take you to write installing and learning OpenLDAP instead, and to set up some synchronization mechanism to your current database. This could be as simple as a database trigger that monitors all changes and spits out an LDIF file to import into OpenLDAP. Considering what you say about your resource limitations, these probably aren't enormous databases either.