If there is a ghastlier bit of technology than LDAP, I don’t know what it is. The very name is redolent of nerds laughing at you: Lightweight Directory Access Protocol? Lightweight??! Very funny, guys!
There’s nothing really lightweight about it, of course. It’s a mostly-incomprehensible melange of apparently bizarre syntax and a propensity to throw a wobbly at the slightest mis-placed comma or out-of-position double quote. What’s more, it’s documentation sucks and it’s difficult even to find anyone explaining why you might want to do battle with it in the first place.
And the cause of the ‘Aaaargh!’ in this blog’s title is that it gets even better: the entire methodology, structure, call it what-you-will of the OpenLDAP implementation of LDAP changed between Red Hat Enterprise Linux 5.x and 6.x. In the old days, we configured a slapd.conf configuration file; these days, you are now supposed to poke around inside a directory called, fetchingly, /slapd.d/cn=schema. Yup, they stuck an equals sign in the directory name. Just wait until you have to edit such catchy files as olcDatabase={0}config.ldif or olcDatabase={-1}frontend.ldif. I mean, what were they on when they came up with those filenames??!
What little documentation you may find on the old slapd.conf way of doing things is mostly meaningless in this brave new world of RHEL6-style madness. So back to square one, then… which is to say, fumbling around in the dark in the hope you’ll get lucky.
Ordinarily, at this point I’d give up, consigning the whole thing to the too-hard basket. But there is actually a good reason to do battle with OpenLDAP: it makes for a free (and ultimately relatively simple) way of doing centralized TNS names resolution for Oracle databases.
Of course, the official way of doing that is to use Oracle’s own Oracle Internet Directory (OID) -and I did actually write an article about setting that up way back in about 2006. But there are lots of problems with OID. It’s a tiny part of the gigantic ‘Oracle Identity Management’ infrastructure for one thing: I defy anyone who isn’t religiously following some documentation to go to www.oracle.com and download the correct bit of OIM in order to just get the names resolution stuff working! For another thing, I never did get OID working on any version of Red Hat EL later than 4.7. I don’t know if that’s changed (I presume it has), but it was a bit of a show-stopper at the time, that’s for sure! Dare I mention at this point that RHEL 4.7 is to reach its end-of-life on February 29th 2012… er, in approximately 6 weeks, in other words?
I suppose I might also throw in the fact that I would prefer ‘completely and definitely free’ to ‘possibly, but probably not, but just maybe comes with licensing issues that are associated with a price tag’.
All of which is by way of explaining why I decided to (a) get OpenLDAP running on RHEL 5.x and 6.x -and then (b) get OID functionality working with it in both configurations. I then decided to throw in (c): a nice GUI way of working with the LDAP monster.
The OpenLDAP-as-OID-Replacement article is therefore now available.
Great job!
A word of warning: check to make sure all of your Oracle clients are able to perform TNS lookups via LDAP.
I went down this route in a Windows environment — with a lot of swearing and cursing — until I got TNS resolution working via LDAP served out of our AD server.
Then I found out that the Oracle client that Designer uses (one of the main apps we still use) refused to use LDAP for TNS resolution.
So I’ve reverted to placing tnsnames.ora and associated files on a centrally accessible file share and configured all Oracle homes’ registry entries on all machines with TNS_ADMIN=\\fileserver\share\directory to point to these.
So while I like the idea, I’ve gone back to the old fashioned shared directory solution — which might be easier to do than setup and configure an LDAP server. And it requires less server resources too.
Of course, if you are going to use LDAP for user accounts (like we do with AD on Windows), then that’s a good argument to use the same directory for other naming too.
But if you’re only going to use LDAP for TNS name resolution, I’d think twice and use a shared directory instead.
Hi Colin:
A fair point. I’ve checked 10gR2 and 11gR2 32 and 64 bit clients, plus the 11g Instant Client, on both Linux and Windows, and they all work fine. However, it’s a fair point you make: I have no experience in Designer so wouldn’t have a clue what that required. As far as I understand the intracacies of OCI and TNS, LDAP lookup should be a completely standard part of *any* Oracle client (at least since 9i), but YMMV, for sure.
But yeah: the last job I had, Cold Fusion servers don’t use any part of the Oracle networking stack to make their database connections, so you certainly wouldn’t have been able to use this technique for them.
But I would never recommend a shared directory on a file server, despite that being a popular technique with some of my clients as far back as 1999. It’s a potential single point of failure. LDAP has replication (which I’ll document some time soon), so if one LDAP server dies, others remain available. A single mapped network drive…. bad news the day that file server dies (though obviously it would be full of redundant hardware, so maybe it’s a gamble you’d be prepared to take).
Anyway, having thought at least thrice about it over the years, I’d still recommend LDAP. But sure: environments vary and you may get unlucky, in which case the advice wouldn’t apply.
Howard,
you saved my day with OID article in 2006 and hopefully, you’ll save a week (or two) with your OpenLDAP article. Thank you very much! What do you read nowadays?
Regarding LDAP for serving Oracle tns, at the time of this writing, I’m using, imho, the most elegant, easy to use and most important, totally cholesterol free tnsManager, written by Andrew Barry, more or less out of pure frustration when Oracle announced that OID is meant to be a replacement for Oracle Name Server. Unfortunately, Andrew stopped developing and supporting tnsManager, so I started thinkering with an idea to replace tnsManager with OpenLDAP if newer Oracle client versions (12c) will break tnsManager compatibility.
Just compare 10 minutes of total time for: downloading tnsManager (29 KB, yes kilobytes!), read documentation, install daemon, and have a working “LDAP” server serving tnsnames.ora….with let’s say time you need just to find a proper installation set for OID!
Anyway, if you have a 10 minutes to spare, take a look at: http://www.shutdownabort.com/tnsmanager/index.php
Regards,
Ales
Thanks Ales. Nice someone remembers the old OID article!
If speed is your thing, I’ve prepared a summary version of the full OpenLDAP-as-OID article in the Quick Tips section of the site. Eating my own dog-food, I was able to do the whole thing on a Centos 6.2 box at the command line, via ssh, in about 8 minutes (I’m a slow typist!)
Current reading: Roman Emperors.
And also -funnily enough – Mastering OpenLDAP
Cheers!