OID is Oracle’s official solution
Several years ago, I was struggling with a solution to managing hundreds of net service names across several dozen database servers and many hundreds of Oracle client machines. At the time, Oracle had just discontinued ONAMES (which I never had an opportunity to use), and the “official” Oracle solution was the OIM/OID software suite. Well, after weeks of struggling with OID, I decided it was an unwieldy beast, and was just plain painful to set up. (I don’t think I ever did get it completely working.) Just as things were looking down, I spotted a bit of sunlight, through the fog.
After much thrashing about with Oracle’s OID, I discovered a very cool little program, called tnsManager. tnsManager is a scaled-down, highly specialized LDAP server, whose sole purpose in life is to serve up net service names. tnsManager, written by Andrew Barry of ShutdownAbort.com, was an absolute godsend. It was lightweight, extremely simple to set up, and supported replication. It offered (almost) everything I wanted in terms of a solution for net service name resolution. On the downside, to my knowledge, Mr. Barry only ever released tnsManager as a binary, available on Windows, Linux, and Solaris. As it turns out, the Linux version, which I was interested in, was extremely stable and reliable. I have been running tnsManager, in production, on a tnsnames.ora file that has around 250 entries, since around 2008. It has never failed, and never given me any problems whatsoever. So, why mess with it? Well, I wouldn’t have, except that Mr. Barry seems to have fallen off the face of the earth. Emails to his last known email address don’t bounce, but have not been returned. Also, his website, ShutdownAbort.com is still online, but all content has been wiped. So, on one hand, I have a program that has proven itself a winner, with over 5 years of continuous service. On the other hand, my entire enterprise is reliant on a piece of software, for which I have no source code, and which the author seems to have abandoned. So, I decided a pragmatic approach was appropriate here. I’m continuing to run the very reliable tnsManager in production. However, at the same time, I’ve started down the path of finding a replacement. This quickly lead me to OpenLDAP, as a free, open source solution, which others have proven works well with Oracle.
With just a bit of searching with my favorite search engine, I discovered an excellent blog post by Howard Rogers. Howard did an excellent job demonstrating a very quick and easy setup to get OpenLDAP up and running for net service name resolution. By following the steps in Howard’s blog post, I had OpenLDAP installed, configured, and running in less than an hour. I have to give kudos to Howard, for documenting a simple, straightforward procedure. However, there are a couple of features that are not implemented or configured in Howard’s basic setup. Specifically, aliases and replication are not touched upon. Both of these features were supported in tnsManager, so, I’m quite interested in getting them working with OpenLDAP.
Net service names aliases are quite straightforward, in that they simply allow for multiple aliases for the same net service name. An example of a tnsnames.ora entry that demonstrates a net service name would be:
mydb,myalias,myalias2 = (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=myhost)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=myservice)))
In the above tnsnames.ora entry, the net service name is ‘mydb’, and ‘myalias’ and ‘myalias2’ are both aliases. All three strings will resolve to the same connect string. After a bit more searching, I ran across Ronny Egner’s blog, which showed how to implement aliases in OpenLDAP. More on this just a bit later.
The other thing that my initial OpenLDAP configuration didn’t support was replication. This is a feature that is used in my current setup with tnsManager, so, if I was planning to replace tnsManager, getting replication up and running was important to me. After doing a bit of reading, I learned that OpenLDAP supports different types of replication, including multi-master and master/slave. With a bit of research and experimentation, I was able to configure simple master/slave replication, using the OpenLDAP documentation.
Finally, it would be desirable to be able to use DNS autodiscovery. If you’re not familiar with DNS autodiscovery, it’s a method by which one does not provide an ldap.ora file, and instead, the Oracle Client code can discover the location of the LDAP server. Very briefly, the way it works is, the DNS administrator creates a service record (type SRV) in DNS, which points to the LDAP server. Then, the client will query the rootOracleContext for the defaultSubscriber, which it will use to set the DEFAULT_SEARCH_DOMAIN since there is no ldap.ora file. For a detailed explanation, see MOS Doc ID 1363773.1.
Next Steps – Installation and Configuration
In my next post, I’ll get into the specifics of installing and configuring OpenLDAP for Net Service Name resolution. Stay tuned for part 2, OpenLDAP Installation and Configuration.