Product SiteDocumentation Site

Chapter 8. Migrating from Previous Versions

8.1. Migration Overview
8.2. About migrate-ds-admin.pl
8.3. Before Migration
8.3.1. Backing up the Directory Server Configuration
8.3.2. Configuring the Directory Server Console
8.4. Migration Scenarios
8.4.1. Migrating a Server or Single Instance
8.4.2. Migrating Replicated Servers
8.4.3. Migrating a Directory Server from One Machine to Another
8.4.4. Migrating a Directory Server from One Platform to Another
Red Hat Directory Server 6.x and 7.x instances can be migrated to Directory Server 8.0. Migration carries over all data and settings from the older Directory Server to the new Directory Server, including Administration Server and Console information. This is performed by running a Directory Server-specific script, migrate-ds-admin.pl. migrate-ds-admin.pl is flexible enough to allow an array of migration options, including migrating instances to new platforms and to migrate instances selectively or to migrate all installed instances simultaneously.
Unlike previous versions of Directory Server, the migration script is silent, meaning that there are no prompts and the user is not required to enter any information or approve any step in the process. After it run, the Directory Server information and settings have been moved, intact, from the old Directory Server instance to the new one. For the simplest migration scenario, the migration script only requires two pieces of information with the command: the old server root path and the password for the directory administrator.
/usr/sbin/migrate-ds-admin.pl --oldsroot /opt/redhat-ds General.ConfigDirectoryAdminPwd=password
The different migration scenarios and migration script options are described in this chapter.

8.1. Migration Overview

Migrating from a 6.x or 7.x version of Directory Server to Directory Server 8.0 is a simple process. Migration moves all of the user data and configuration settings, such as replication and synchronization agreements, from the older instance to the new one. The general process is as follows:
  1. Stop all of the old Directory Server and Administration Server instances.
  2. Back up the old Directory Server databases.
  3. For a multi-master replication environment. Edit the Directory Server Console used by the migrated server to control directory writes.
  4. For supplier and hub servers in a replicated environment. Stop directory writes.
  5. Install the new Directory Server packages.
  6. Run the migration script, migrate-ds-admin.pl.
    The migration script is silent, meaning that there are no prompts and the user is not required to enter any information or approve any step in the process. After it run, the Directory Server information and settings have been moved, intact, from the old Directory Server instance to the new one.

WARNING

If Directory Server databases have been moved from their default location (/opt/redhat-ds/slapd-instancename/db), migration will not copy these databases, but will use the directly. This means that if you run migration, you may not be able to go back to the old version. Migration will not remove or destroy the data, but may change the format in such a way that you cannot use the older version of the Directory Server. Therefore, make a database backup using db2bak and an LDIF dump using db2ldif of the databases to make sure everything can be recovered.
The most common reason for using a non-default database location is the performance for large databases. For example, if a Directory Server instance has several gigabytes of data, the index files and transaction logs can be moved to a separate disk device to improve the Directory Server performance, especially if there are high update rates. In this case, migration will not attempt to move the databases to the new default location, /var/lib/dirsrv/slapd-instancename/db, but will instead assume that the databases should be in their non-standard location and configure the new server to use the databases in the old location.
This issue does not occur in cross-platform migrations or migrating using LDIF files instead of the binary databases because these already work with an LDIF copy of the database.