6.3. Migration Procedure
Before you start with migration process, ensure the following:
Read sections Section 6.1 Migration Overview and Section 6.2 Migration Prerequisites.
The migration script will automatically back up your Directory Server configuration if it is in the default location.
If you are migrating from Directory Server 6.x, all of the configuration files in the /opt/redhat-ds/servers/slapd-serverID/config directory will be backed up to a directory named serverRoot/slapd-serverID/config_backup.
If your configuration files are stored in non-default locations, before you migrate your server, copy them to a secure place.
This section contains the following information:
6.3.1. Migrating a Standalone Server
Once you have backed up your critical configuration information, do the following to migrate a server:
Stop your legacy Directory Server.
If you do not stop the legacy Directory Server, the migration script does it for you.
On the machine where your legacy Directory Server is installed, install a new 7.x Directory Server. This installation process is described in Chapter 3 Using Express and Typical Installation or Chapter 4 Silent Installation and Instance Creation.
Use the same port numbers as your legacy production server if you want to ensure that any directory clients that have static configuration information (including Directory Server port numbers) continue to work.
Run the migration script.
As root user, change directory to serverRoot/bin/slapd/admin/bin. Then enter the following command:
migrateInstance7 -D rootDN -w password -p port -o oldInstancePath -n newInstancePathWhere:
rootDN is the Directory Server 7.x user DN with root permissions, such as Directory Manager.
password is the password for Directory Manager in Directory Server 7.x.
port is the LDAP port number assigned to Directory Server 7.x.
oldInstancePath is the path to the installation directory of the legacy Directory Server (for example, /opt/redhat-ds/server6/slapd-serverID).
newInstancePath is the path to the installation directory of Directory Server 7.x (for example, /opt/redhat-ds/servers/slapd-serverID).
The following is an example of a command you would use to migrate an instance of Directory Server 6.21 to Directory Server 7.1:
migrateInstance7 -D cn=Directory Manager -w secret -p 389 \ -o /opt/redhat-ds/server621/slapd-phonebook \ -n /opt/redhat-ds/servers/slapd-phonebook \
This command appears on one line in usage. The slashes \ are used to wrap the line for printing, and should be removed when using the command.
Follow the prompts. For example, if you're prompted to provide a path and filename for your backup directory, enter one or accept the default.
The migration process starts. At the end of migration, your legacy Directory Server is migrated. Additionally, as a result of this migration, a new Directory Server 7.x instance is installed using the configuration information obtained from your legacy Directory Server; the data from your old server is migrated to the new server; and the new server is started.
A sample output in Example 6-1 shows a migration of Directory Server 6.21 to Directory Server 7.1. The migration script detects three backends, backend1, backend2, and userRoot, which exist in the legacy server as well as in the new server instances. To demonstrate the various options, for each backend a different option was chosen: for backend1, the choice was to continue with the migration and export processes; for backend2, the choice was to continue with the migration process only, without exporting; and, for userRoot, the choice was to skip the migration process.
In this sample, the \ has been inserted to indicate a line break for printing purposes.
migrateInstance7 -D "cn=directory manager" -w password -p 389 -o /export/server621/slapd-marmot -n /export/server71/slapd-marmot ******* Migration from 6.21 to 7.1 Directory Server ********* Shutdown the legacy Directory Server instance: /export/server621/\ slapd-marmot Shutting down server slapd-marmot . . . . . . . . . . . . . . . . . . . . . Backup /export/server71/slapd-marmot/config on /export/server71/slapd-marmot/config_backup ... Where do you want to back up your configuration directory [/export/server71/slapd-marmot/config_backup] ? Migrate the schema... Shutting down server slapd-marmot . . . . . . . . . . . . . . . . . . . . . ***************************************************************** The following LDIF files have been migrated: 99user.ldif ***************************************************************** ----------------------------------------------------------------- Migrate key/cert databases... Shutting down server slapd-marmot . . . . . . /export/server71/alias/slapd-marmot-key3.db already exists. Do you want to overwrite it ? [no]: y /export/server71/alias/slapd-marmot-cert8.db already exists. Do you want to overwrite it ? [no]: y Connected to 7.1 LDAP server ----------------------------------------------------------------- Parse the old DSE ldif file: /export/server621/slapd-marmot/ config/dse.ldif ***** This may take a while ... Migrate DSE entries... SECURITY - Update successfull: cn=encryption,cn=config SNMP - Update successfull: cn=snmp,cn=config ----------------------------------------------------------------- Migrate LDBM backend instances... *** LDBM_BACKEND_INSTANCE - cn=backend1,cn=ldbm database,\ cn=plugins,cn=config already exists *** Migration will overwrite existing database Do you want to continue Yes/No [No] ? y Do you want to export the existing data Yes/No [Yes] ? y Enter the full pathname of the file [/export/server71/slapd-marmot/db_backup/backend1.ldif]: Existing data will be exported under /export/server71/slapd-marmot/db_backup/backend1.ldif Continue Yes/No [No] ? y Now backing up database backend1 in /export/server71/slapd-marmot/db_backup/backend1.ldif Shutting down server slapd-marmot . . . . . . ldiffile: /export/server71/slapd-marmot/db_backup/ backend1.ldif [14/Apr/2005:17:54:03 -0600] - Waiting for 4 database threads to stop [14/Apr/2005:17:54:04 -0600] - All database threads now stopped try to reconnect to search cn=backend2,cn=ldbm database,\ cn=plugins,cn=config *** LDBM_BACKEND_INSTANCE - cn=backend2,cn=ldbm database,\ cn=plugins,cn=config already exists *** Migration will overwrite existing database Do you want to continue Yes/No [No] ? y Do you want to export the existing data Yes/No [Yes] ? n *** INFORMATION - NetscapeRoot is NOT migrated *** LDBM_BACKEND_INSTANCE - cn=userroot,cn=ldbm database,\ cn=plugins,cn=config already exists *** Migration will overwrite existing database Do you want to continue Yes/No [No] ? n *** Migration will not update it ----------------------------------------------------------------- Migrate mapping tree... *** MAPPING_TREE - cn="dc=example,dc=com",cn=mapping tree, cn=config already exists *** Migration will not add the suffix ----------------------------------------------------------------- Migrate default indexes... ----------------------------------------------------------------- Migrate indexes... ----------------------------------------------------------------- Migrate replicas... ----------------------------------------------------------------- Migrate replication agreements... ----------------------------------------------------------------- Migrate Certmap.conf... Where do you want to back up the file /export/server71/shared/ config/certmap.conf [/export/server71/shared/config/certmap.conf_backup] ? ***** Close the LDAP connection to the new Directory Server instance ***** Shutting down server slapd-marmot . . . . . . ----------------------------------------------------------------- Data processing... ldiffile: /export/server621/slapd-marmot/config/ldif/backend1.ldif [14/Apr/2005:17:56:46 -0600] - Waiting for 4 database threads to stop [14/Apr/2005:17:56:47 -0600] - All database threads now stopped ldiffile: /export/server621/slapd-marmot/config/ldif/backend2.ldif [14/Apr/2005:17:57:22 -0600] - Waiting for 4 database threads to stop [14/Apr/2005:17:57:23 -0600] - All database threads now stopped Done. [14/Apr/2005:17:57:26 -0600] - dblayer_instance_start: pagesize: 4096, pages: 524288, procpages: 1037 [14/Apr/2005:17:57:26 -0600] - cache autosizing: import cache: 204800k [14/Apr/2005:17:57:26 -0600] - li_import_cache_autosize: 50, import_pages: 51200, pagesize: 4096 [14/Apr/2005:17:57:26 -0600] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [14/Apr/2005:17:57:26 -0600] - dblayer_instance_start: pagesize: 4096, pages: 524288, procpages: 1041 [14/Apr/2005:17:57:26 -0600] - cache autosizing: import cache: 204800k [14/Apr/2005:17:57:26 -0600] - li_import_cache_autosize: 50, import_pages: 51200, pagesize: 4096 [14/Apr/2005:17:57:27 -0600] - import backend1: Beginning import job... [14/Apr/2005:17:57:27 -0600] - import backend1: Index buffering enabled with bucket size 100 [14/Apr/2005:17:57:27 -0600] - import backend1: Processing file "/export/server621/slapd-marmot/config/ldif/backend1.ldif" [14/Apr/2005:17:57:27 -0600] - import backend1: Finished scanning file "/export/server621/slapd-marmot/config/ldif/backend1.ldif" (1230 entries) [14/Apr/2005:17:57:27 -0600] - import backend1: Workers finished; cleaning up... [14/Apr/2005:17:57:28 -0600] - import backend1: Workers cleaned up. [14/Apr/2005:17:57:28 -0600] - import backend1: Cleaning up producer thread... [14/Apr/2005:17:57:28 -0600] - import backend1: Indexing complete. Post-processing... [14/Apr/2005:17:57:28 -0600] - Nothing to do to build ancestorid index [14/Apr/2005:17:57:28 -0600] - import backend1: Flushing caches... [14/Apr/2005:17:57:28 -0600] - import backend1: Closing files... [14/Apr/2005:17:57:28 -0600] - import backend1: Import complete. Processed 1230 entries in 4 seconds. (333.51 entries/sec) [14/Apr/2005:17:57:30 -0600] - dblayer_instance_start: pagesize: 4096, pages: 524288, procpages: 1037 [14/Apr/2005:17:57:30 -0600] - cache autosizing: import cache: 204800k [14/Apr/2005:17:57:30 -0600] - li_import_cache_autosize: 50, import_pages: 51200, pagesize: 4096 [14/Apr/2005:17:57:30 -0600] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [14/Apr/2005:17:57:30 -0600] - dblayer_instance_start: pagesize: 4096, pages:524288, procpages: 1041 [14/Apr/2005:17:57:30 -0600] - cache autosizing: import cache: 204800k [14/Apr/2005:17:57:30 -0600] - li_import_cache_autosize: 50, import_pages: 51200, pagesize: 4096 [14/Apr/2005:17:57:31 -0600] - import backend2: Beginning import job... [14/Apr/2005:17:57:31 -0600] - import backend2: Index buffering enabled withbucket size 100 [14/Apr/2005:17:57:31 -0600] - import backend2: Processing file "/export/server621/slapd-marmot/config/ldif/backend2.ldif" [14/Apr/2005:17:57:31 -0600] - import backend2: Finished scanning file "/export/server621/slapd-marmot/config/ldif/backend2.ldif" (0 entries) [14/Apr/2005:17:57:31 -0600] - import backend2: Workers finished; cleaning up... [14/Apr/2005:17:57:31 -0600] - import backend2: Workers cleaned up. [14/Apr/2005:17:57:31 -0600] - import backend2: Cleaning up producer thread... [14/Apr/2005:17:57:31 -0600] - import backend2: Indexing complete. Post-processing... [14/Apr/2005:17:57:31 -0600] - Nothing to do to build ancestorid index [14/Apr/2005:17:57:31 -0600] - import backend2: Flushing caches... [14/Apr/2005:17:57:31 -0600] - import backend2: Closing files... [14/Apr/2005:17:57:32 -0600] - import backend2: Import complete. Processed 0 entries in 1 seconds. (0.00 entries/sec) ----------------------------------------------------------------- ***** Migrate Changelog... ----------------------------------------------------------------- ***** Migrate ReplicaBindDN entries... ----------------------------------------------------------------- ***** Migrate MultiplexorBindDN entries... ****** End of migration ****** -> Migration started at Thu Apr 14 23:49:02 2005 -> Migration ended at Thu Apr 14 23:57:44 2005 *********************************************** -> The migration report file is available at: /export/server71/slapd-marmot//logs/Migration_14042005_174859.log |
Example 6-1. Sample Output of Directory Server 6.21 to Directory Server 7.1 Migration
6.3.2. Migrating a 6.x Replicated Site
If you are upgrading from Directory Server 6.x to Directory Server 7.x, your replication configuration is automatically migrated when you run the migrateInstance7 script.
To migrate a 6.x replicated site:
Stop your Directory Server 6.x.
Install Directory Server 7.x.
Run the migration script as shown in Section 6.3.1 Migrating a Standalone Server.
Once your 6.x server is migrated, test replication to make sure it is working correctly.
After you finish this process for the master, repeat the steps for the replicas.
6.3.3. Migrating a 6.x Multi-Master Deployment
This section explains how to migrate a deployed multi-master replication (MMR) scenario from Directory Server 6.x to Directory Server 7.x. The procedure outlined here ensures that your environment will stay live and no re-initialization will be needed.
 | Note |
|---|---|
If you want to preserve your replication agreements, you must use the same port numbers in your new installations that you used in your legacy servers. |
The instructions are written with these assumptions:
Your deployment consists of separate configuration and standard access instances of Directory Server.
You are migrating to Directory Server 7.x.
The migration process can be summarized into these steps:
Stop directory writes on both masters.
Warning It is imperative that there are no entries being written or changed on the masters during the migration. After both the masters are migrated, writes can resume.
After stopping provisioning, make sure all changes have been replicated from the server to migrate to all of its replicas.
Any changes left over in the changelog will be lost after migration, so make sure all changes in the changelog have been replicated to all replicas.
Migrate the first master; refer to Section 6.3.3.1 Master Migration.
Verify that writes and changes are being replicated through the servers.
Migrate the second master; refer toSection 6.3.3.1 Master Migration. If required, continue migrating up to four masters.
Verify that writes and changes are being replicated through the servers.
Migrate the hubs (if any); refer to Section 6.3.3.2 Hub Migration.
Verify that writes and changes are being replicated through the servers.
Migrate the replicas; refer to Section 6.3.3.3 Replica Migration.
Verify that writes and changes are being replicated through the servers.
6.3.3.1. Master Migration
Follow these steps for the first master, and then repeat the steps for the others, up to four masters.
Stop the 6.x Directory Server.
Install Directory Server 7.x.
Make this your configuration instance since it is not replicated. For the other masters, register against the first master's configuration instance.
Log into the Console, and create a new instance to which you are going to migrate.
This instance needs to be created to listen on the port that your standard access uses, which is usually 389.
Next run the migration script, following the instructions in Section 6.3.1 Migrating a Standalone Server.
Once your master is migrated, test replication to make sure that it is working correctly.
After you finish this process for the first master, repeat the steps for the other masters.
You may wish to set up multi-master replication for o=NetscapeRoot between the instances on the masters.
6.3.3.2. Hub Migration
To migrate a 6.x hub:
Stop your Directory Server 6.x.
Install Directory Server 7.x, registering against the first master's configuration instance.
Next run the migration script, following the instructions in Section 6.3.1 Migrating a Standalone Server.
Once your hub is migrated, test replication to make sure that it is working correctly.
After you finish this process for the first hub, repeat the steps for any additional hubs.
6.3.3.3. Replica Migration
To migrate a 6.x replica server:
Stop the 6.x Directory Server.
Install Directory Server 7.x, registering against the first master's configuration instance.
Run the migration script; refer to Section 6.3.1 Migrating a Standalone Server.
Once your replica is migrated, test replication to make sure that it is working correctly.
After you finish this process for the first replica, repeat the steps for any additional replicas.
6.3.4. Managing Console Failover
If you have a multi-master installation with o=NetscapeRoot replicated between your two masters, server1 and server2, you can modify the Console on the second server (server2) so that it uses server2's instance instead of server1's. (By default, writes with server2's Console would be made to server1 then replicated over.)
To accomplish this, you must:
Shut down the Administration Server and Directory Server.
Change these files to reflect server2's values:
serverRoot/userdb/dbswitch.conf:directory default ldap://configHostname:configPort/o%3DNetscapeRoot serverRoot/admin-serv/config/adm.conf:ldapHost:configHostname serverRoot/admin-serv/config/adm.conf:ldapPort:configPort serverRoot/shared/config/dbswitch.conf:directory default ldap://configHostname:configPort/o%3DNetscapeRoot serverRoot/slapd-serverID/config/dse.ldif:nsslapd-pluginarg0: ldap://configHostname:configPort/o%3DnetscapeRoot
Turn off the Pass-through Authentication (PTA) Plug-in on server2 by editing its dse.ldif file.
In a text editor, open this file:
serverRoot/slapd-serverID/config/dse.ldif
Locate the entry for the PTA plug-in:
dn: cn=Pass Through Authentication,cn=plugins,cn=config
Change nsslapd-pluginEnabled: on to nsslapd-pluginEnabled: off.
Restart the Directory Server and Administration Server.