Difference between revisions of "Restoring the LDAP user database"
(Notes about hosts files) |
(More hosts file and DNS resolution fun!) |
||
| Line 16: | Line 16: | ||
= Restoration = | = Restoration = | ||
<i>Still testing this.</i> | <i>Still testing this.</i> | ||
| − | * | + | * '''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. | ||
* Set up a new 389 server with the same directory name as the one you are restoring (TODO: Figure out if this is stored in the db2bak backup program output, and if not, fix the script to add that in)<br/> | * Set up a new 389 server with the same directory name as the one you are restoring (TODO: Figure out if this is stored in the db2bak backup program output, and if not, fix the script to add that in)<br/> | ||
setup-ds-admin.pl General.FullMachineName=dir.sshchicago.org | setup-ds-admin.pl General.FullMachineName=dir.sshchicago.org | ||
Revision as of 21:36, 24 August 2013
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
Still testing this.
- 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.
- Set up a new 389 server with the same directory name as the one you are restoring (TODO: Figure out if this is stored in the db2bak backup program output, and if not, fix the script to add that in)
setup-ds-admin.pl General.FullMachineName=dir.sshchicago.org
Accept all defaults (excepting those which are tripped up by hosts files), choose secure passwords. This will create a new, empty directory server.
- Restore the backup using bak2db
- Start 389 up
Testing
TODO: Write out how to validate that the restore worked properly
References
4.3. Backing up and Restoring Data - Red Hat Directory Server Administration Guide
