A colleague (the infamous Gary Utz, “Worlds Greatest SysAdmin”) has been asked to install Fedora Directory on a Red Hat Enterprise 3 VMWare guest, and needs some guidance on how to approach it. Since he’s been my lifeline in more tight spots than I can remmember, there wasn’t any question that I would help.
So here, for both him and my vast Internet audience (both of you), is my own take on how to install Fedora Directory on Red Hat Enterprise Linux.
Note to The Experienced
First, if you happen to be an experienced Netscape/Sun Directory admin, keep in mind that the Red Hat team has been through 4 minor version updates since the purchase of Netscape Directory 6. There are differences in the Red Hat product that you should keep an eye out for.
Minimum system requirements to install and run Fedora Directory are simple. First, although you can try to compile from source for other platforms, at the moment binary packages are only available in rpm format for Red Hat Enterprise and Fedora Linux. As a RHEL clone, CentOS works fine too and is highly recommended at least for test environments (it’s what I use in my home lab). You’ll need at least 1 Gb RAM and 1.5 Gb swap. CPU should be above 1 GHz. Dual core, or dual CPUs, are better than single core. Like all LDAP servers, FDS is a cycle hog. The software itself needs about 300 Mb of space when it first installs, last time I checked, but I’d give it at least 1 Gb because once you start running you’re going to need it for the database files.
Get the Software
To begin, you need to download the appropriate rpm from Fedora Directory Project Download. The latest as of this writing is v1.0.4, and is available for every Red Hat platform starting with Fedora Core 2/RHEL 3 and up to Fedora Core 6. Starting with Fedora Core 4 there is also a version for x86_64. For Red Hat Enterprise 3, you need to use the Fedora Core 2/RHEL 3 version, for Red Hat Enterprise 4 the Fedora 3/RHEL4 version and so on.
These rpms all install to /opt. Sorry, but that’s how it is. The next version (1.0.5?) may change that to an install into the base filesystem in accordance with the latest “Filesystem Hierarchy Standard” specification. For more, see the the notes on FHS Packaging. For now, DO NOT try to change this by recompiling with the srpm. It won’t work. Believe me, I’ve tried.
Installing the RPM
Before installing the rpm, you’ll need to check on a couple of major system dependencies and install the required software, these are:
1. Red Hat’s version of the Apache web server (use Red Hat’s rpm for
2. Sun’s Java 1.4 or above (I use Sun’s J2SE SDK 1.5 rpm for this, off java.sun.com, which installs to /usr/java/jdk1.5.0_x). You can use the alternatives system for configuring Java (see my article on how to do this).
Installing the rpm is as easy as doing a
rpm -Uvh fedora-ds-1.0.4-1.RHEL3.i386.opt.rpm
to install the latest version for Red Hat 3, for example.
This will put the setup binaries and utilities under /opt/fedora-ds.
Gather Further Requirements
Next, you need to go over to /opt/fedora-ds and execute the
idsktune utility as root in order to determine what needs to be done in preparation for setup.
Pay close attention to what it reports. I would recommend executing like this,
idsktune >idsktune.log so that you can scroll through the output in a text editor.
In addition to some additional software, you will probably also need to make some kernel configuration changes.
At a miniumum you’re going to want/need to:
1. Increase the number of local ports available with
echo "net.ipv4.ip_local_port_range = 1024 65000" >> /etc/sysctl.conf
/sbin/sysctl -p to effect the change.
2. Make the following changes to the number of available files and file descriptors available:
echo "fs.file-max = 64000" >> /etc/sysctl.conf
echo "* soft nofile 8192" >> /etc/security/limits.conf
echo "* hard nofile 8192" >> /etc/security/limits.conf
Effect these changes by a
sysctl -p and a
ulimit -n 8192.
Do this with a
/opt/fedora-ds/setup/setup as root.
Before getting into the details of how to respond to the prompts, here are some quick design pointers that may be of some help in getting the overall picture:
1. Red Hat Directory, like it’s predecessors from Netscape and Sun, consists of two parts, an Administration Server and at least one Directory Server. The Administration Server provides access to the Directory environment via the Directory Console, a gui managment utility that connect over http on a custom port. It stores its configuration in the first Directory installed. Red Hat has modified the code so that the Admin Server now uses the system httpd binary and system Java.
2. For clarity I also used a function-based directory instance naming scheme, “slapd-[hostname]-admin” for the Administration Server directory and “slapd-[hostname]-user”, for first Master user directory if these are separate. This is alot more descriptive than the “slapd-[hostname]1”, the default. Where there’s only one directory instance on the box (which is how I usually set things up nowadays), I just leave off the “-admin” or “-user” qualifier.
3. Apart from the above, the defaults presented by the installer are actually pretty reasonable.
The Fedora Directory installer is still (thank God) curses based. That means you don’t need to fire up X to use it, and the install proceeds pretty briskly along without the usual hesitation (and smearing) that those of us who have to install the latest Sun and Oracle directories have to deal with (there is actually a way to do both of the latter from the command line, but the interfaces are … clumsy).
The Red Hat Installation Guide is still a pretty good reference for this part of the job. As I said above, I used to set up separate administration and user directories on each server, to provide greater flexibility in managing the directory environment with the GUI Directory Console. Two important drawbacks to this approach were that it required the Console user have an account on the administration directory or use Directory Mananger, and, that it forces you to use a separate Console session for each directory server (since every directory server has it’s own unique admin server). In my old age I now prefer a really simple, single, directory environment.
1. The installer will begin by asking you to accept the license. Answer yes.
2. Select “install mode” 2 – Typical.
3. Accept the hostname presented, unless none is found — in which case quick enter something in /etc/hosts and use that (the directory constantly checks for the host name where it lives).
4. Server user and group to use. I usually accept “nobody”.
5. Accept the defaults for Directory Manager dn, enter a password. Do the same for the Administration Server admin.
6. Set the directory suffix, this should be the Internet domain name for your host, unless you want it to be something different. I usually accept the default (which is the domain name split up like “dc=blogger,dc=com”).
7. When asked about the configuration directory, use the default — you want a new one on this machine (unless your enterprise architecture calls for a central config directory — not a good idea in my opinion, but to each his own).
8. Port numbers. For the first directory (which will be your main directory for both config and users, if you follow my practice), use standard LDAP port 389. For the Admin Server, again pick something high that won’t interfere with other stuff. I like something in the 3000’s (usually port 3389).
9. For the user directory location, I always choose the default — a new one on this machine.
10. Administration domain: default (usually the domain of the machine you’re installing to, unless you’ve got an extensive and complicated architecture calling for multiple admin domains — God help you).
11. At some point you’ll get through all of this and setup will finally start the directory and admin servers.
12. To set up additional directories the best procedure is to fire up the gui Directory Console in an X session,
/opt/fedora-ds/startconsole and connect to the Admin Server using it’s unique URL (e.g. http://hostname.domain.com:port), which should have been echoed to the screen when the Admin Server first came up.
14. Don’t forget to create and install an init script to automatically start your environment. A sample is here.
So there you go. That’s all there is to it!