The Lightweight Directory Access Protocol (LDAP) is, essentially, a database (it used to be the protocol needed to talk to a database, but it’s long-since become the name of the database itself). You can store all sorts of data in it -personnel details, perhaps, including usernames and passwords; records of each PC or server you own, complete with its hostname, IP address, and so on; or (here’s the point of this particular article!) details about what Oracle databases run on which servers.
The particular implementation of LDAP I’m going to concern myself with here is OpenLDAP. It’s open source, supplied with virtually every Linux distro in existence, and is completely and forever free of charge. It’s also quite lightweight in terms of server resources needed to run it: mine runs on a server with just 128MB RAM which is already running Apache, Bind and DHCP!
The generic name for what we’ll use this OpenLDAP server for is Oracle tnsnames resolution. You want to connect to a database called “sales”… what server is that on? What IP address? What port do we go via? The idea is that you get your Oracle client software to look those details up in an LDAP database and use the answers found to connect you automatically. Traditionally, we do tnsnames resolution using a text file stored on the client PC itself, called tnsnames.ora… but if you’ve got dozens of users connecting from different PCs, or a frequently-changing list of which databases to connect to, modifying each of those tnsnames.ora individually is a pain. Life becomes a lot easier if everyone consults a single store of tnsnames details. You make the changes to that one, central store… and all users automatically pick up on the changes.
There is an official Oracle product to do this, available for no additional licensing fees, called Oracle Internet Directory (or OID for short). OID is part of a much bigger and more complex “identity management” application, and if you use it for anything other than the simple lookup of what database runs on which server, it does cost a lot. It’s also not at present certified to run on Red Hat Enterprise Linux 6 (only RHEL 4.x and 5.x). That’s not to say there’s anything particularly wrong with OID …just that it’s a bit of sledgehammer to crack a tnsnames lookup nut.
This article will therefore explain how to configure OpenLDAP to act as a zero-cost, single, centralised source of tnsnames resolution in your Oracle database environment. It describes setting up OpenLDAP on Scientific Linux 5.7 and Centos 6.2. Of course, those are both clones of Red Hat Enterprise Linux (RHEL), so these instructions are generically true for any RHEL-ish 5.x and 6.x Linux distro.
You should know that OpenLDAP’s implementation changed dramatically between the 5.x and 6.x release of Red Hat and its clones -but for this article, I’ve simply made the earlier 5.x configuration work on the 6.x platform using backward compatibility features. I haven’t attempted, therefore, to use the ‘native’ way of doing things in RHEL 6.x. All commands work for both versions, unless specifically stated otherwise -at which point, version-specific options will be described.
What follows is done entirely as the root user, unless otherwise indicated. It assumes that you have built your LDAP server using the ‘installing Linux over the Network’ technique I have documented elsewhere -and, specifically, that you have used my rh5.cfg or rh6.cfg Kickstart configuration files during the installation.
The article will fall into three main parts:
- Installation and basic configuration of OpenLDAP
- Configuration of an Oracle Internet Directory capability for OpenLDAP
- Management of OpenLDAP via graphical tools