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."

Comments

Backends are not as hard as you make out.

[danpat]

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:

openldap.org/cvsweb.cgi

Run the openldap server on the same machine that's running your database right now and you're done.

Re:Backends are not as hard as you make out.

[YellowElectricRat]

I apologise in advance, since this is completely off topic and grammar nazi-ish, but I have to do it:

I think you mean 'imply' rather than 'infer'. The speaker/writer implies, the listener/reader infers.

Now to nit-pick my own nit-pick, Mr Leech could have inferred that writing backend is difficult from someone else's implication, but I don't think that's what you were getting at. :)

Re:Backends are not as hard as you make out.

[danpat]

I stand corrected

Re:Backends are not as hard as you make out.

[NoMoreNicksLeft]

Unless, he was referring to the person having inferred such from another implication, such as all the answers he had gotten before now, or the web pages he had read.

So, the grammar isn't necessarily as problemtatic as you make it to be, what we are looking at is more of an ambiguity problem.

Welcome to the english language.

Re:Backends are not as hard as you make out.

[YellowElectricRat]

Funny, I thought I had already mentioned that.

Welcome to 'read before you post' land.

Re:Backends are not as hard as you make out.

[cloudmaster]

I wrote a Perl backend for OpenLDAP that gets some data out of a MySQL database, which makes generating mailing lists from the user data in MySQL real easy. It took about oen afternoon, including installing OpenLDAP from source (that required reading a couple of docs to learn which config switch enabled the perl backend) and reading the example code (almost all written for you) that implements a simple perl backend. If you're read-only, it's even easier.

You can run OpenLDAP on pretty much any *nix. If you're without *nix, you can stick the cygwin environment on a win32 box and run OpenLDAP there. I don't care how small your company is - you guys *have* to have a machine that has adequate availability and a few spare clock cycles that an OpenLDAP solution can use. Really - that solution will be *way* easier than implenting than writing your own LDAP implentation. Heck, you can even contact me directly if you want more sample code...

Not much else.

[abulafia]

You could start with the perl-ldap page, for perl. I'm sure Python has similar, but I don't swing that way. Speaking of swing, as you note, Java is not really what you want here, unless you fit a very particular box.

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.

LDAP CONSIDERED HARMFUL

[Slipped_Disk]

Well, some applications of it (LDAP for user management) anyway, but that's a subject for a different rant.

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 :-D

Good luck

Re:LDAP CONSIDERED HARMFUL

[Suppafly]

Plan B generally pretty much SUCKS, and will inevitably require more time/effort/money to implement and maintain.


Why does plan b suck? its sounds rediculously easy to me.. it would seem like it could be written in less than a 200 lines or code..

Re:LDAP CONSIDERED HARMFUL

[styrotech]

its sounds rediculously easy to me.. it would seem like it could be written in less than a 200 lines or code..

That sounds like the geek version of a redneck saying "hey y'all, watch this..."

Famous last words.

Re:LDAP CONSIDERED HARMFUL

[Slipped_Disk]

My concern WRT "Plan B" is that you now have a second point of entry into the existing database which must be kept up-to-date with internal structure changes and the like (we no longer store "fullname" on the person table, you now get it by concatenating "firstname" and "lastname", etc.).

This basically adds to the maintainer's job, whereas "Plan A" (modifying the existing UI to update LDAP) consolidates all the DB Updating bits into one program (and presumably the LDAP server is configured only to allow that program to make updates, by host or binding-user restrictions).

As far as initial coding effort, 200 lines of code could easily implement the LDAP command parsing (in perl or C, and assuming a limited subset of the available commands), however you must take in to account the code to translate from internal storage schema (presumably some RDBMS, or (*gag*) flatfiles) to output that an LDAP client can parse without vomiting on itself. This is where I see the expense and work coming in.

I also have a visceral dislike for reinventing the wheel, since such reimplementations often result in rather defective wheels - How long has it taken OpenLDAP to get to the state it is in now? And anyone who uses it knows it still has bugs and issues...

Re:LDAP CONSIDERED HARMFUL

[Etyenne]

Well, some applications of it (LDAP for user management) anyway, but that's a subject for a different rant.

Well, I for one would like to hear your rant. Since I found about LDAP, I personnally come to believe that it is the best thing since sliced bread for user management. I am currently building a mail farm that does all it's user authentication and information lookup (aliases, etc) to an Active Directory via LDAP. Also, NIS being what it is, LDAP is pretty much the only single-sign-on scheme that is well supported in Linux.

Sounds fishy

[uradu]

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.

why not PHP LDAP?

[ubiquitin]

Is it web-based? Try giving PHP's ldap functions a look-through.

TinyLDAP

[mirabilos]

There is always TinyLDAP from Felix "SMTP is not
simple, LDAP is not light-weight, wtf?" von Leitner.

He doesn't want to implement read/write access at
the moment though, unless you provide code to him
which does that in 600 KB.

Something doesnt sound right

[kzadot]

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.

all I need to do is retrieve a contact's e-mail or phone number from our database.

If your requirements are so simple, and your company really doesnt have the hardware resources to implement this simple little thing, (which could easily go on an existing server) then I would suggest two things.

1) Using a paper based system, or just writing a little database and client app or something. (I know, you lose LDAP buzzword points here) or..

2) If your company is too large for such a solution, and REALLY doesnt have the hardware resources, then somethings real wrong. Look at folding up the company.

LDAP interface for bespoke CRM solution

[Anonymous Coward]

Have i got this correct - just to clarify?

I would just chuck a web front end up for this sort of thing though. :)

Ldaptor is a Python lib and a collection of apps

[Tv]

Ldaptor is a pure-python LDAP library and a collection of utilities and apps such as a web interface.

There's not much of the server side implemented yet -- only a dummy server that answers all search requests with "nothing found", but the protocol decoding etc. is all there.

LDAP on an existing server

[Sxooter]

Why not put LDAP on an existing server? We tossed it onto our pre-existing apache/PHP/pgsql server, and it only takes up about 100 Megs or so of memory total after it's been up for a day or two (mostly for buffers of course.)

While our load numbers went up, they didn't shoot through the roof or anything.

LDAP tends to be a pretty small load for us. If we weren't providing authentication for a non-buffering external server (*COUGH people soft *COUGH) it's be no real load at all. As it is, providing a dozen or so logins a second, it's still only about 0.2 load factor or so on the box.

Any old PII-450 with 256 Meg of ram could handle OpenLDAP quite well.

What Else is there besides OpenLDAP?

[sekbeep]

Ditch LDAP and use a relational database. LDAP isn't ACID anyway so you are putting your data at risk. Read this article by Peter Gutman: http://www.cypherpunks.to/~peter/09a_cert_store.pd f Although he was writing about X.509 certificate storage, it still applies. Save yourself a lot of time and headaches.

Useful Answer: a Simple Perl Daemon

[Anonymous Coward]

http://www.xray.mpe.mpg.de/mailing-lists/perl-ldap /2002-05/msg00050.html

Source code included, works with Net::LDAP support. Just hack away at the request array until you have what you want.

Geez. Why do people keep answering simple questions with "No, No, You Should Use My Favorite Package/Approach/Pet Project"? It's not as if what the guy wants isn't totally viable, simple to do and damn USEFUL.

Besides, I wonder how many Open Source geniuses have figured out that THERE IS NO ALTERNATIVE TO OPENLDAP.

None. Zilch. You either go for OpenLDAP or you write your own.

Methinks TinyLDAP is on the right track, generally - at least it provides an alternative.

But for what this guy needs, the Perl sources above should be more than enough. Why can't people actually HELP for a change?

There's always Ruby/LDAP....

[tcopeland]

....since we're all suggesting LDAP implementations in our favorite languages. Get it here.

Note that it aims to be RFC 1823 compliant, so it'll work with OpenLDAP. If you pick an LDAP server that uses proprietary extensions, of course, you'll have to do some hacking...

Perl or Shell backend in OpenLDAP

[lkaos]

Dude, there's a perl and shell backend in OpenLDAP. No database, no storage, you just get your shell or perl script invoked on every request.

What more could you possibly want?

REALLY Painless LDAP

[dublin]

A lot of people here are suggesting using LDAP anyway, despite your statement that you don't have hte time or desire to learn al lthe arcana required to implement it.

In that case, then, I have a solution for you - the E-smith Linux distro, which will build you a dang useful server, including LDAP, within about 5 minutes of completing one of the easiest Linux installs you've ever encountered.

I don't bother with crap like configuring LDAP, Samba, firewalls, or mail servers anymore - E-smith has made it automatic and left me to add real value where it can do some good. Download an ISO and go to town - you'll be glad you gave it a try, and you'll have a complete working, properly configured LDAP server in mere minutes.

Read the LDAP RFCs and make your own basic server

[t-maxx cowboy]

Read the LDAP RFCs and make your own basic server. I do realize you are one person. But I am writing from experience in a slightly different area. I once wrote a mail client for reading and maintaining Fido messages in the BBS days. I also have written a pop3 e-mail checker. Neither of these were very complex for 1 person once I had all the RFCs available.