Never give up! Never surrender! Installing 389 Directory Server on EL 6.1

Really wanted to try out the 389 Directory on my new SL 6.1 workstation at home. Took awhile, but the stars finally came into just the right alignment for me to do the install.

Here’s the story from the lead developer on the user’s mail list today:

EL6 support is . . . tricky. We will not provide support for 6.0 – too many missing dependencies. With RHEL 6.1, since the 389-ds-base package is provided by the base OS, we cannot provide them via EPEL, hence the use of the private developer repo at The other “problem” with EL6 is that the 389-ds-base package is not the full package – it is missing the replication and windows sync bits (hence the problem with the missing You have to pay extra for the ds-replication package in RHEL6 – right now it is available as a “tech preview” from your local sales rep. The 389-ds-base package from does have the replication bits.

(EPEL is Extra Packages for Enterprise Linux, a subproject of Fedora)

RHEL 6.0 won’t be supported because there are too many missing dependencies. OK, fair enough. But the core package (389-ds-base) as shipped with 6.1 is crippleware?

Instructions for installing on 6.1 are here, but they’re not exactly a model of clarity.

Let me lay it out for you: in order to make this work get the 389-ds-base and 389-ds-base-libs packages from epel-389-ds-base.repo (Fedora People), and the rest of the stuff from EPEL 6 Testing. That’s right, testing. Why? Because stable EPEL 6 contains packages that will only build with the now deprecated mozldap package (a/k/a Mozilla LDAP SDK for C).

Be sure to enable the “testing” repo for EPEL 6, this will be /etc/yum.repos.d/epel-testing.repo:.

name=Extra Packages for Enterprise Linux 6 - Testing - $basearch

Here’s what you’ll see at the console if you got all that right and run yum install 389-ds

 Package                  Arch      Version           Repository           Size
 389-ds                   noarch    1.2.2-1.el6       epel-testing        9.9 k
Installing for dependencies:
 389-admin                x86_64    1.1.20-1.el6      epel-testing        342 k
 389-admin-console        noarch    1.1.7-1.el6       epel-testing        202 k
 389-admin-console-doc    noarch    1.1.7-1.el6       epel-testing         43 k
 389-adminutil            x86_64    1.1.14-2.el6      epel-testing         64 k
 389-console              noarch    1.1.7-1.el6       epel                 72 k
 389-ds-base              x86_64     epel-389-ds-base    1.3 M
 389-ds-base-libs         x86_64     epel-389-ds-base    352 k
 389-ds-console           noarch    1.2.6-1.el6       epel-testing        1.4 M
 389-ds-console-doc       noarch    1.2.6-1.el6       epel-testing         55 k
 389-dsgw                 x86_64    1.1.7-1.el6       epel-testing        469 k
 idm-console-framework    noarch    1.1.7-2.el6       epel-testing        1.1 M
 mod_nss                  x86_64    1.0.8-12.el6      sl                   80 k
 svrcore                  x86_64    4.0.4-5.1.el6     sl                   14 k
Transaction Summary
Install      14 Package(s)
Total download size: 5.4 M
Installed size: 14 M

If you see something like this:

Error: Package: 389-admin-1.1.11-0.5.rc1.el6.x86_64 (epel)
Error: Package: 389-admin-1.1.11-0.5.rc1.el6.x86_64 (epel)
           Requires: mod_nss
Error: Package: 389-adminutil-1.1.10-1.el6.x86_64 (epel)
* * *
 You could try using --skip-broken to work around the problem

then you’re still grabbing the older EPEL stable packages, not testing (and you might also be picking up the release version of 389-ds-base, etc. from the main distribution).

Remember. You want the 389-ds-base and 389-ds-base-libs from Fedora People, and the rest of the 389 packages from EPEL Testing.

Do I appreciate having to jump through hoops like this just to install a piece of software for testing?

Not in the least.

Would I ever deploy it to production as long as the distribution system is in this state?

Let me get back to you on that. Even after getting it installed I wasn’t able to get into the directory console because of a mismatch in .jar file versions for the directory console.

Not that I need that old java console. 389 Directory can be installed without the console and admin server. Just “yum install 389-ds-base” (from the Fedora People repo!) and then use the script to create your directory instances.

With a little effort you can do just about everything using the command line as you can with the console. There’s a wealth of information in the Configuration and Command-Line Tool Reference on what is possible.

About the only things that are a bit of a pain to do without the console is setting up replication agreements and enabling SSL.

There’s a Howto for the former (featuring the perl script). And the latter is covered by another Howto. which uses the shell script. Both the aforementioned scripts are maintained by the primary developer for the 389 Directory Project on github, together with a bunch of other useful scripts.

OK, so maybe I’ll give this software another try. But not right now. It’s 2 AM and there’s real work to be done early tomorrow morning for my 20,000 (give or take) users.