What Else Is There Besides OpenLDAP? 28
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."
Backends are not as hard as you make out. (Score:5, Insightful)
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.
Re:Backends are not as hard as you make out. (Score:1, Troll)
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. (Score:2)
Re:Backends are not as hard as you make out. (Score:1, Offtopic)
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. (Score:1, Offtopic)
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. (Score:2)
You can run OpenLDAP on pretty much any *nix. If y
Not much else. (Score:5, Interesting)
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 (Score:5, Informative)
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
Re:LDAP CONSIDERED HARMFUL (Score:2)
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 (Score:5, Funny)
That sounds like the geek version of a redneck saying "hey y'all, watch this..."
Famous last words.
Re:LDAP CONSIDERED HARMFUL (Score:3, Informative)
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 th
Re:LDAP CONSIDERED HARMFUL (Score:4, Interesting)
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 (Score:5, Insightful)
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? (Score:2)
Is it web-based? Try giving PHP's ldap functions [php.net] a look-through.
TinyLDAP (Score:3, Interesting)
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 (Score:2, Insightful)
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 o
Ldaptor is a Python lib and a collection of apps (Score:3, Informative)
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 (Score:3, Interesting)
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.
There's always Ruby/LDAP.... (Score:2)
Note that it aims to be RFC 1823 [ietf.org] 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 (Score:3, Interesting)
What more could you possibly want?
REALLY Painless LDAP (Score:2)
In that case, then, I have a solution for you - the E-smith Linux distro [e-smith.org], 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 auto
Read the LDAP RFCs and make your own basic server (Score:1)