The last time I had to do a NIS->LDAP migration, it was in a heterogenous environment with Solaris and Linux boxes, and it was around 2004 or so. Although I hit some rough patches adjusting to changes in how FDS is packaged, the community was awesome, and helped me get back up to speed in no time. We shouldn’t forget that the community was what drove me from OpenLDAP to FDS in the first place.
But I digress. The purpose of this article (first of a series) is to share with you some technical information about how to get things going. How, exactly, do you get RHEL 4, and RHEL 5 to utilize Fedora Directory Server’s data to support NSS and PAM for user information and authentication, and autofs for automounting directories? There are documents on this, written by people who clearly do (or did) care, but at times they can be a little disjointed, a little outdated, and require some tweaking.
This document talks specifically about installing the fedora-ds-1.1.2-1.fc6 package on RHEL 5.2, populating the People and Groups trees, and testing that it actually works. Later posts will deal with getting RHEL 4 and 5 clients to talk to it for various purposes, using TLS (with certificate verification, btw).
If your real issue is understanding how LDAP data works, why it looks the way it does, or you need a refresher, I would urge you to look at two other articles I wrote for O’Reilly, devoted completely to the topic: here, and here.
Get it installed
There is no precompiled binary package of Fedora Directory Server built specifically for Red Hat
Enterprise Server (because Red Hat, of course, provides that, with support, for a fee). If you want to run FDS for free on a RHEL server, the installation process is somewhat non-trivial. First, you must add a couple of new package repositories to your yum configuration:
cd /etc/yum.repos.d/ sudo wget http://directory.fedoraproject.org/sources/idmcommon.repo sudo wget http://directory.fedoraproject.org/sources/dirsrv.repo
Then, you’ll need to import a couple of keys in order to verify signatures of the packages we’ll install
later:
sudo rpm --import \ http://archives.fedoraproject.org/pub/archive/fedora/linux/core/6/i386/os/RPM-GPG-KEY-fedora sudo rpm --import \ http://archives.fedoraproject.org/pub/archive/fedora/linux/core/6/i386/os/RPM-GPG-KEY-Fedora-Extras
Next, install some prerequisite packages (you could do this first – these come from standard
repositories, not the new ones we added):
sudo yum install svrcore mozldap perl-Mozilla-LDAP libicu
You’ll need jss, and I wasn’t able to get it via a repository, so I downloaded it using a URL directly:
sudo rpm -ivh http://download.fedoraproject.org/pub/fedora/linux/extras/6/x86_64/jss-4.2.5-1.fc6.x86_64.rpm
Next, install ldapjdk (used by the FDS console application), and finally, the directory server itself:
sudo yum install ldapjdk sudo yum install fedora-ds
WIth these packages installed, the next thing to check is that permissions are set up correctly, otherwise the initial setup script will fail:
sudo chown -R nobody:nobody /var/lock/dirsrv; sudo chmod -R u=rwX,go= /var/lock/dirsrv sudo chown nobody:nobody /var/run/dirsrv; sudo chmod -R u=rwX,go= /var/run/dirsrv
Finally, run the setup script which was installed with the fedora-ds package:
sudo /usr/sbin/setup-ds-admin.pl
Populating the Direcotory
The directory initially consists of a top-level entry representing the domain, and by default, FDS creates for you two “organizational units”, which are subtrees representing “People” and “Groups”. I’ll create an LDIF file for the Groups first, but there’s no reason to go in any particular order. We’re just adding data, and LDAP isn’t relational: you can add People objects who are members of Groups that aren’t in the tree yet. Here’s my LDIF file for the groups:
dn: cn=wheel,ou=Groups,dc=example,dc=com objectClass: posixGroup objectClass: top cn: wheel gidNumber: 1000 memberUid: jonesy memberUid: tasha memberUid: molly dn: cn=eng,ou=Groups,dc=example,dc=com objectClass: posixGroup objectClass: top cn: eng gidNumber: 1001
For the moment, only ‘wheel’ contains any actual members. No biggie, you can add members to groups later, or add more groups later whenever you want. Once the clients are configured, there’s no restarting of anything to get them to pick up changes to data in the LDAP data.
It’s easy to use the OpenLDAP tools to add data to FDS, but I’m going to use the FDS-supplied tool here to insert this data:
/usr/lib64/mozldap/ldapmodify -a -D "cn=Directory Manager" -w - -h localhost -p 389 -f ~/groups.ldif -c
If you’re familiar with the OpenLDAP tools, this probably doesn’t look too scary. The OpenLDAP tools require a ‘-x’ flag to bypass SASL. Aside from that, pretty straightforward.
To populate the “People” tree in FDS, or any other LDAP product, I wrote a really cheesy awk script that I can pipe the contents of /etc/passwd or ‘ypcat passwd’ through and get good results with only minor tweaking. Redirect the output to a file called ‘people.ldif’, and then you can populate your “People” tree:
/usr/lib64/mozldap/ldapmodify -a -D "cn=Directory Manager" -w - -h localhost -p 389 -f ~/people.ldif
At any time, you can verify that your FDS installation is returning results by running a query like this:
/usr/lib64/mozldap/ldapsearch -b dc=example,dc=com objectclass=organizationalUnit
I have a few more posts to follow this one. One is one getting SSL/TLS working (either one, perhaps both), creating a root CA and setting things up with certutil, another on getting the RHEL 4 and 5 clients to use LDAP, and another separate one for configuring autofs to talk to LDAP, which is a little different between RHEL 4 and 5. Subscribe to this blog in your reader to be updated as those posts come out over the next 2 weeks.