January 23, 2017

Use Fedora Directory Server For Manageable LDAP (Part 2)

Prerequisites and Java Madness

  • September 18, 2006
  • By Carla Schroder

Last month we were introduced to LDAP in general and Fedora Directory Server in particular. Today we'll walk through a simple Fedora Directory Server installation to learn your way around FDS.

FDS is not a substitute for understanding LDAP fundamentals. You still have to know what you're doing. FDS just makes it easier.

Despite the voluminous mounds of documentation, or perhaps because of it, there are a few vital installation steps to take that you might miss on first reading. Red Hat's online manuals link to all kinds of Fedora Directory Server documentation. The important ones are the installation, deployment and administration guides. But we don't really want to wade through all that now, do we? Let's get our hands dirty first on a nice test system where we don't care how messed up it gets.

You'll need an http server installed and a Sun Java Runtime Environment. Any others tend to not work right, especially whatever comes with Fedora, which horks up the incredibly unhelpful "GC Warning: Out of Memory! Returning NIL!" message when you try to start your FDS console.

Follow Sun's instructions for installing the JRE. After installation go to /etc/alternatives and change the soft link to your new Sun Java executable. For example, I installed it in /opt/java, then created the new soft link:

 # cd /etc/alternatives
# ls -sf /opt/java/jre1.5.0_06/bin/java java

When you're finished with that foolishness, make sure your name resolution is working correctly, so that the dnsdomain command returns a domain name, hostname -a returns only the hostname, and hostname -f returns the fully-qualified domain name, like these examples:

# dnsdomainname
# hostname -a
# hostname -f


Then create an unprivileged user and group for the server user, like this:

# useradd ldap
# passwd ldap

Don't use the "nobody" user. Everybody uses nobody, to the point that it's become a security risk. Services should run with their own unique users, not shared ones.

Sitemap | Contact Us