5.2. Pre-migration Tasks

Red Hat Directory Server 10 servers need to be reconfigured to match the previous version. You need to reconfigure plug-ins, TLS, schema, server configuration, and so on.
Each new Red Hat Directory Server 10 instance needs to be manually reconfigured to match the previous version. This includes adding, enabling, and configuring plug-ins. If TLS was previously used, it needs to be set up on the new instance as well. Any custom schema needs to be in place on the new server. The server settings, like cache sizes, resource limits, indexing, and general configuration settings need to be re-applied.

5.2.1. Plug-in Configuration

Enable, disable, and configure plug-ins as they were set on the previous version. See the Red Hat Directory Server 10 Administration Guide for more information on how to perform these tasks.
The shared plug-in configuration entries, if any, that do not reside under the cn=config entry do not need to be recreated because they are stored in a back-end database. Only the plug-in configurations that are under the cn=config entry will need to be reconfigured.

5.2.1.1. Plug-in Configuration Changes

New to Red Hat Directory Server 10, some plug-ins now use user-friendly names in their configuration syntax, where previously attributes nslapd-pluginarg0 up to nsslapd-pluginarg10 were used.
The new style configuration syntax for some of the plug-ins is detailed below.
Attribute Uniqueness Plug-in Syntax
The two examples below show the old-style configuration syntax for the Attribute Uniqueness Plug-in:

Example 5.1. Old-style configuration syntax

nsslapd-pluginarg0: uid
nsslapd-pluginarg1: dc=people,dc=example,dc=com
nsslapd-pluginarg2: dc=sales, dc=example,dc=com

Example 5.2. Old-style configuration syntax

nsslapd-pluginarg0: attribute=uid
nsslapd-pluginarg1: markerobjectclass=organizationalUnit
nsslapd-pluginarg2: requiredobjectclass=person
The two examples below show the new-style configuration syntax for the Attribute Uniqueness Plug-in:

Example 5.3. New-style configuration syntax

uniqueness-attribute-name: uid 
uniqueness-subtrees: dc=people,dc=example,dc=com 
uniqueness-subtrees: dc=sales, dc=example,dc=com 
uniqueness-across-all-subtrees: on

Example 5.4. New-style configuration syntax

uniqueness-attribute-name: uid 
uniqueness-top-entry-oc: organizationalUnit 
uniqueness-subtree-entries-oc: person
Referential Integrity Plug-in Syntax
The example below shows the old-style configuration syntax for the Referential Integrity Plug-in:

Example 5.5. Old-style configuration syntax

nsslapd-pluginarg0: 0
nsslapd-pluginarg1: /var/log/dirsrv/slapd-localhost/referint
nsslapd-pluginarg2: 0
nsslapd-pluginarg3: member
nsslapd-pluginarg4: uniquemember
nsslapd-pluginarg5: owner
nsslapd-pluginarg6: seeAlso
The example below shows the new-style configuration syntax for the Referential Integrity Plug-in:

Example 5.6. New-style configuration syntax

referint-update-delay: 0
referint-logfile: /var/log/dirsrv/slapd-localhost/referint
referint-logchanges: 0
referint-membership-attr: member
referint-membership-attr: uniquemember
referint-membership-attr: owner
referint-membership-attr: seeAlso

5.2.1.2. Plug-ins and Replication

Some Directory Server plug-ins need special consideration when they are enabled in a replicated environment.
For more information, see the following resources:

5.2.2. Directory Server Configuration

The Directory Server configuration includes back-end suffixes, cache settings, indexing, and so on.
When migrating to Red Hat Directory Server 10:
  • Make sure that you have recreated back-end suffixes. This is especially important for replication to work properly.
  • Make sure that you have configured attribute indexes.
  • You may need to reconfigure the database cache and each back-end entry cache to match the previous version.

5.2.3. Migration and TLS

If the new server will reuse the same host name as the previous server, then the security database files can simply be copied to the new server. For example: 
/etc/dirsrv/slapd-instance_name/cert8.db
/etc/dirsrv/slapd-instance_name/key3.db
If the new server will not reuse the same host name, then you will need to issue and install new certificates in the Directory Server instance and Admin Server (if applicable).

5.2.4. Schema Migration

Using the default settings, Red Hat Directory Server 10.0 and later is RFC 4512-compliant and does not support older schema versions. To enable older schema support or to migrate:
  1. Enable the nsslapd-enquote-sup-oc parameter in the cn=config entry: 
    # ldapmodify -D "cn=Directory Manager" -W -x

dn: cn=config
changetype: modify
replace: nsslapd-enquote-sup-oc
nsslapd-enquote-sup-oc: on
  2. Append the following parameter at the end of your /etc/sysconfig/dirsrv-instance file: 
    LDAP_SCHEMA_ALLOW_QUOTED="on"
  3. Restart the Directory Server instance: 
    # systemctl restart dirsrv.target
You can migrate the schema from an old server instance in the following ways:
  • Copy the /etc/dirsrv/slapd-instance_name/schema/99user.ldif file and all custom schema files to the new instance. Restart the Directory Server instance to take the changes effect.
  • Perform a database migration. For details, see Section 5.3, “Database Migration Methods”.