Restoring the LDAP user database

This outlines the steps necessary for restoring our LDAP server.

Data Recovery

Follow the steps in Restoring files with Duply to restore our LDAP backup from Amazon S3. Set these files aside somewhere safe.

Requisite Software Installation

• Set up a CentOS or RHEL 6 server.
• Add the EPEL repository (https://fedoraproject.org/wiki/EPEL) to the system.

rpm --install http://mirrors.xmission.com/fedora/epel/6/i386/epel-release-6-8.noarch.rpm

• Install a pile of packages for 389.
  

Be aware that this will also install a bunch of dependencies, including X11 and Java, so have sufficient disk space available. Not all of these are necessary, though I've listed them all for completion's sake

yum install 389-ds-console 389-dsgw 389-adminutil 389-ds-base-libs 389-admin-console \ 
389-ds 389-ds-base 389-admin-console-doc 389-ds-base-devel 389-console 389-admin \
389-ds-console-doc 389-adminutil-devel 

Restoration

Set up DNS

Make sure you have DNS working as properly as possible. This means:

The local computer's hostname (the output of hostname) as well as the directory server's name (dir.sshchicago.org) must resolve to where you're restoring. Enter both of these in your hosts file if this is not the case (my test machine here is named "townace.local"):

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
127.0.0.1   dir.sshchicago.org dir
127.0.0.1   townace townace.local

Alternately, make certain that the system's default DNS server resolves these as expected.

Create an empty directory

• Set up a new 389 server with the same directory name as the one you are restoring

setup-ds-admin.pl General.FullMachineName=dir.sshchicago.org

Accept all defaults (excepting those which are tripped up by hosts files), choose new passwords (they will be discarded in the next step). This will create a new, empty directory server.

Restore the directory

• Put the backup files somewhere the "nobody" user is able to read it. (You'll get permissions errors otherwise)
• Stop the directory server

/sbin/service dirsrv stop dir

• Change to the directory server's base config directory.

cd /etc/dirsrv/slapd-dir

• Run the restore:

/usr/lib64/dirsrv/slapd-dir/bak2db /<full path to backup directory>/

You'll get a series of messages like this:

[24/Aug/2013:22:45:31 -0500] 389-Directory/1.2.11.15 - debug level: backend (524288)
[24/Aug/2013:22:45:31 -0500] - Deleting log file: (/var/lib/dirsrv/slapd-dir/db/log.0000000017)
[24/Aug/2013:22:45:31 -0500] - Restoring file 1 (/var/lib/dirsrv/slapd-dir/db/DBVERSION)
[24/Aug/2013:22:45:31 -0500] - Copying /tmp/dir-2013_08_24_03_14_15/DBVERSION to /var/lib/dirsrv/slapd-dir/db/DBVERSION
[24/Aug/2013:22:45:31 -0500] - Restoring file 2 (/var/lib/dirsrv/slapd-dir/db/userRoot/DBVERSION)
<snip>
[24/Aug/2013:22:45:31 -0500] - Restoring file 33 (/var/lib/dirsrv/slapd-dir/db/log.0000000017)
[24/Aug/2013:22:45:31 -0500] - Copying /tmp/dir-2013_08_24_03_14_15/log.0000000017 to /var/lib/dirsrv/slapd-dir/db/log.0000000017
[24/Aug/2013:22:45:31 -0500] - All database threads now stopped 

• Start the directory server back up.

service dirsrv start dir

Testing

Launch the directory server console:

389-console

Log in (you'll need the admin password from the restore - not the one you defined during the setup-ds-admin.pl). Browse through the directory (expand sshchicago.org/dir.sshchicago.org/Server Group/Directory Server (dir)); and in the Directory Server window, flip to the Directory tab and browse the result.

References

4.3. Backing up and Restoring Data - Red Hat Directory Server Administration Guide