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 fedorapeople.org. 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 repl-monitor.pl). 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 fedorapeople.org 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:.
[epel-testing] name=Extra Packages for Enterprise Linux 6 - Testing - $basearch #baseurl=http://download.fedoraproject.org/pub/epel/testing/6/$basearch mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=testing-epel6-arch=$basearch failovermethod=priority enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
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 ================================================================================ Installing: 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 184.108.40.206-1.el6 epel-389-ds-base 1.3 M 389-ds-base-libs x86_64 220.127.116.11-1.el6 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) Requires: libssldap60.so()(64bit) 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) Requires: libssldap60.so()(64bit) * * * 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 setup-ds.pl 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 mmr.pl perl script). And the latter is covered by another Howto. which uses the setupssl2.sh 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.