Oracle Explorations and Investigations
All about the Oracle Database….and whatever else I decide to write about….
OpenLDAP – Installation and Basic Configuration
This is part 2 of a multi-part blog post on using OpenLDAP for Net Service Name Resolution. Part 1 can be found here.
Installation
Installing and configuring OpenLDAP on Oracle Linux 6 is a fairly simple and straightforward process. (Note that I’m working with Oracle Linux 6.4, this process may differ on other Linux distributions and/or versions.)
Installation of OpenLDAP consists of simply executing the following command as root:
That’s it for installation. Now, you’ll need to do the basic OpenLDAP configuration, and finally set it up to handle Oracle Net Service Names.
Configuration
First, you need a DB_CONFIG file in the /var/lib/ldap directory. Fortunately, one can be found at /usr/share/openldap-servers/DB_CONFIG.example. You’re free to peruse the contents of this file, but I won’t be getting into the details. Also, I wouldn’t recommend changing anything in that file, unless you know exactly what you’re doing.
So, go ahead and copy that file into place:
Now, you need to set up the administration password. That can be done by executing the following:
Enter your password, then enter it again to verify it, and you’ll get an output that looks something like:
Please make a note of this value (the one you got when you ran slappasswd on your server, not the one shown above!), as you’ll need it momentarily.
Next, you need to setup the slapd.conf file. Before you can do that, you’ll need to decide if you’re planning to setup master/slave replication between two servers. If you do want to setup replication, download slapd.conf.rep_master, otherwise, you’ll want to download slapd.conf.no_rep. Either way, you’ll want to save it to the root user’s $HOME (probably /root) and name it slapd.conf. Now, open this file in your favorite text editor, and about 3/4 of the way through the file, you’ll find a section that looks like this:
You’ll want to update the defaultsearchbase, suffix, rootdn and rootpw sections to values that are appropriate for your environment. For the defaultsearchbase, suffix and rootdn, you’ll want to replace the “dc=proquest,dc=com” string with your domain information. The “dc” means “domain component”, so, for example, my domain, “proquest.com”, becomes “dc=proquest,dc=com”. Note that this does NOT have to be a real domain. Your domain could be “my.home”, and you could use “dc=my,dc=home”. It really doesn’t matter, as long as you are consistent throughout. The “rootpw” value, is the string you generated earlier, when you ran the ‘slappasswd’ command.
Ok, at this point, you should have a correctly configured slapd.conf. So, copy it into place, thus:
Finally, by default, you’ll have a directory, /etc/openldap/slapd.d, which you’ll need to move:
Ok, finally, you should be ready to start the slapd server, with the following command:
Hopefully, that command successfully started your LDAP server. (If you have any errors, please double check the slapd.conf file for typos, errors, extraneous spaces, etc.)
Also, you can set it up as a service that will automatically startup at boot time, with this command:
Replication
If you are planning to setup replication, this is the time to do it. Let’s assume that the server you just completed the initial setup on, will be the master server. Now, you’ll need a second server, which will serve as the slave server. To do so, just repeat the process you just followed, with one exception. For the slave server, when it’s time to download the slapd.conf, you’ll want to download slapd.conf.rep_slave instead. Once you’ve done that, you should rename it to slapd.conf, just like you did when you downloaded it for the master server. There are a few edits you’ll need to make to this file. First, make all the same edits you did to the master server slapd.conf file, to the defaultsearchbase, suffix, rootdn, and rootpw. Once that’s done, at the end of the file, you’ll find a section of text that looks like this:
You’ll need to modify the provider, which should point to the host and port of the master server you’d previously set up. Then, the searchbase and binddn should be modified to match your specific domain, and finally, you’ll enter the master server’s admin password in the credentials parameter. (Note that the ‘searchbase’ parameter in this section, and the previously seen ‘defaultsearchbase’ parameter, are different and distinct.) Finally, the first line in the section shown above, the value for rid, the replica id, is 123. This is fine, if you’re only setting up one slave server. If you plan to have more than one slave, be sure to set rid to a unique value for each slave server. (Note that rid can be any 1 to 3 digit number, as long as it’s unique among the slaves.)
Ok now, if you’re setting up replication, switch back to the master server. All changes from here on out will be done on the master server, and the replication mechanism will propagate the changes to the slave. (Obviously, if you’re not setting up replication, you have only the one server to update.)
You’ll want to download the initialize_ldap.ldif file. The contents of that file will look like this:
As you may have guessed by now, you’ll need to modify the bolded text above, to be consistent with your domain, etc. Once those edits are complete, you’ll need to load this data, using ldapadd. To do that, execute the following command:
If you’d like to do an initial query, to verify everything looks good, you can do it with this command:
Also, if you have replication set up correctly, you should be able to run the above ldapsearch against the slave server as well. Even though you didn’t run ldapadd on the slave server, the replication should propagate the change to the slave server. (Note that, if you didn’t mess with any of the replication parameters on the slave server, it should take approximately 30 seconds for a change to replicate from master to slave.)
At this point, you should have an LDAP server up and running, optionally with a slave server also setup. However, at this point, it’s very much an empty shell. It’s been initialized with your domain, but that’s it. It has no data, nor even any metadata that describes the type of data that l it will be storing.
Next, OpenLDAP configuration for Net Service Name resolution.
Installation
Installing and configuring OpenLDAP on Oracle Linux 6 is a fairly simple and straightforward process. (Note that I’m working with Oracle Linux 6.4, this process may differ on other Linux distributions and/or versions.)
Installation of OpenLDAP consists of simply executing the following command as root:
yum -y install openldap-servers openldap-clientsThat’s it for installation. Now, you’ll need to do the basic OpenLDAP configuration, and finally set it up to handle Oracle Net Service Names.
Configuration
First, you need a DB_CONFIG file in the /var/lib/ldap directory. Fortunately, one can be found at /usr/share/openldap-servers/DB_CONFIG.example. You’re free to peruse the contents of this file, but I won’t be getting into the details. Also, I wouldn’t recommend changing anything in that file, unless you know exactly what you’re doing.
So, go ahead and copy that file into place:
cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIGNow, you need to set up the administration password. That can be done by executing the following:
slappasswdEnter your password, then enter it again to verify it, and you’ll get an output that looks something like:
{SSHA}GUPTyXKIN6fAAU7yi9PFBVkCEu0gVWB+Please make a note of this value (the one you got when you ran slappasswd on your server, not the one shown above!), as you’ll need it momentarily.
Next, you need to setup the slapd.conf file. Before you can do that, you’ll need to decide if you’re planning to setup master/slave replication between two servers. If you do want to setup replication, download slapd.conf.rep_master, otherwise, you’ll want to download slapd.conf.no_rep. Either way, you’ll want to save it to the root user’s $HOME (probably /root) and name it slapd.conf. Now, open this file in your favorite text editor, and about 3/4 of the way through the file, you’ll find a section that looks like this:
#default searchbase
defaultsearchbase "dc=proquest,dc=com"
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################database bdb
suffix "dc=proquest,dc=com"
rootdn "cn=admin,dc=proquest,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
rootpw {SSHA}t4RCF9n3x7k5qAnMEMbXgG9mowJKitAgYou’ll want to update the defaultsearchbase, suffix, rootdn and rootpw sections to values that are appropriate for your environment. For the defaultsearchbase, suffix and rootdn, you’ll want to replace the “dc=proquest,dc=com” string with your domain information. The “dc” means “domain component”, so, for example, my domain, “proquest.com”, becomes “dc=proquest,dc=com”. Note that this does NOT have to be a real domain. Your domain could be “my.home”, and you could use “dc=my,dc=home”. It really doesn’t matter, as long as you are consistent throughout. The “rootpw” value, is the string you generated earlier, when you ran the ‘slappasswd’ command.
Ok, at this point, you should have a correctly configured slapd.conf. So, copy it into place, thus:
cp $HOME/slapd.conf /etc/openldap
Finally, by default, you’ll have a directory, /etc/openldap/slapd.d, which you’ll need to move:
mv /etc/openldap/slapd.d /etc/openldap/slapd.d.disableOk, finally, you should be ready to start the slapd server, with the following command:
service slapd startHopefully, that command successfully started your LDAP server. (If you have any errors, please double check the slapd.conf file for typos, errors, extraneous spaces, etc.)
Also, you can set it up as a service that will automatically startup at boot time, with this command:
chkconfig slapd onReplication
If you are planning to setup replication, this is the time to do it. Let’s assume that the server you just completed the initial setup on, will be the master server. Now, you’ll need a second server, which will serve as the slave server. To do so, just repeat the process you just followed, with one exception. For the slave server, when it’s time to download the slapd.conf, you’ll want to download slapd.conf.rep_slave instead. Once you’ve done that, you should rename it to slapd.conf, just like you did when you downloaded it for the master server. There are a few edits you’ll need to make to this file. First, make all the same edits you did to the master server slapd.conf file, to the defaultsearchbase, suffix, rootdn, and rootpw. Once that’s done, at the end of the file, you’ll find a section of text that looks like this:
syncrepl rid=123
provider=ldap://einstein:389
type=refreshOnly
interval=00:00:03:00
retry="30 120 60 +"
searchbase="dc=proquest,dc=com"
filter="(objectClass=*)"
schemachecking=off
bindmethod=simple
binddn="cn=admin,dc=proquest,dc=com"
credentials=myadminpasswordYou’ll need to modify the provider, which should point to the host and port of the master server you’d previously set up. Then, the searchbase and binddn should be modified to match your specific domain, and finally, you’ll enter the master server’s admin password in the credentials parameter. (Note that the ‘searchbase’ parameter in this section, and the previously seen ‘defaultsearchbase’ parameter, are different and distinct.) Finally, the first line in the section shown above, the value for rid, the replica id, is 123. This is fine, if you’re only setting up one slave server. If you plan to have more than one slave, be sure to set rid to a unique value for each slave server. (Note that rid can be any 1 to 3 digit number, as long as it’s unique among the slaves.)
Ok now, if you’re setting up replication, switch back to the master server. All changes from here on out will be done on the master server, and the replication mechanism will propagate the changes to the slave. (Obviously, if you’re not setting up replication, you have only the one server to update.)
You’ll want to download the initialize_ldap.ldif file. The contents of that file will look like this:
dn: dc=proquest,dc=com
objectclass: dcObject
objectclass: organization
o: ProQuest LDAP Server for Net Service Names
dc: proquestdn: cn=admin,dc=proquest,dc=com
objectclass: organizationalRole
cn: adminAs you may have guessed by now, you’ll need to modify the bolded text above, to be consistent with your domain, etc. Once those edits are complete, you’ll need to load this data, using ldapadd. To do that, execute the following command:
ldapadd -a -x -D 'cn=admin,dc=proquest,dc=com' -W -f initialize_ldap.ldifIf you’d like to do an initial query, to verify everything looks good, you can do it with this command:
ldapsearch -h 127.0.0.1 -x -b "dc=proquest,dc=com"Also, if you have replication set up correctly, you should be able to run the above ldapsearch against the slave server as well. Even though you didn’t run ldapadd on the slave server, the replication should propagate the change to the slave server. (Note that, if you didn’t mess with any of the replication parameters on the slave server, it should take approximately 30 seconds for a change to replicate from master to slave.)
At this point, you should have an LDAP server up and running, optionally with a slave server also setup. However, at this point, it’s very much an empty shell. It’s been initialized with your domain, but that’s it. It has no data, nor even any metadata that describes the type of data that l it will be storing.
Next, OpenLDAP configuration for Net Service Name resolution.
