Supporting Tivoli Directory Server version 6.3 fix pack 10 (6.3.0.10) with non-root DB2 Version 9.7 fix pack 4 product

Product lifecycle


Abstract

This document describes how to install Tivoli Directory Server Version 6.3 fix pack 10 (6.3.0.10) with non-root DB2 version 9.7 fix pack 4 product. It also describes how to create and configure the Tivoli Directory Server Version 6.3 fix pack 10 instance with non-root DB2 instance.

Content

Introduction:

In Tivoli Directory Server version 6.3 fix pack 10 (6.3.0.10), a user can install non-root DB2, create and configure the non-root DB2 instance, and upgrade Tivoli Directory Server components by using the idsNonRootDB2Install command. The idsNonRootDB2Install command must be run with root privileges. When the command is run, the installation of non-root DB2 and creation of the non-root DB2 instance is performed with non-root user privileges. Whereas, the installation or upgradation of Tivoli Directory Server components is performed with root privileges.

The upgrading of Tivoli Directory Server and non-root DB2 installation using the idsNonRootDB2Install command is supported only on AIX, Linux, and Solaris operating systems. However, the upgrading of Tivoli Directory Server and non-root DB2 installation on AIX, Linux, and Solaris operating systems are not supported using the GUI installation program.

Note: The non-root DB2 database product is not available for Windows operating system.

During the non-root DB2 installations, the DB2 product is always installed in the $HOME/sqllib directory. Where, $HOME represents the home directory of the user that is owner of non-root DB2 instance. The default value of user home directory on AIX or Linux system is /home/<username>, and /export/home/<username> on Solaris system.

During non-root DB2 database product installation, a non-root user can install only one copy of non-root DB2 database product and can create only one non-root DB2 instance per user. Creation of additional non-root DB2 instances is not supported in non-root DB2 installation. To know more about differences between root and non-root DB2 product installation, see the http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.qb.server.doc/doc/c0050566.html website.

The advantage of using a directory server instance with non-root DB2 instance is that all the processes related to Tivoli Directory Server and DB2 are run with non-root privileges. Additionally, a user can use and maintain the installed non-root DB2 product without root privileges.

Working with non-root DB2 installation has its limitations. To know more about the limitations of non-root DB2 database product, see the http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.qb.server.doc/doc/c0050568.html website.


Upgrading Tivoli Directory Server components and installing non-root DB2 product:

    Before you begin:
    To install Tivoli Directory Server version 6.3 fix pack 10 (6.3.0.10) with non-root DB2 installation, you must have Tivoli Directory Server 6.3 general availability (GA) version or higher level of fix pack versions installed on your computer.

    User must have DB2 v9.7 fix pack 4 or higher level of fix pack versions for use with Tivoli Directory Server version 6.3 fix pack 10 (6.3.0.10).

    To install Tivoli Directory Server Version 6.3 fix pack 10, user must have GSKit 8.0.14.11 (minimum required version) or higher level of fix pack version installed on the system. GSKit 8.0.14.11 or higher level of fix pack version is a must for using server with SHA-2 or salted SHA-2 family of algorithm in FIPS certified mode.

    Prerequisites for installing a DB2 database product as a non-root user:
    User must be able to mount the non-root DB2 installation DVD or have it mounted for the user. User can also have the non-root DB2 installable available on the local system and must be accessible and have the required permissions.

Procedure:
1. Extract the Tivoli Directory Server version 6.3 fix pack 10 (6.3.0.10) archive to a directory with adequate free disk space. Refer the Tivoli Directory Server version 6.3 fix pack 10 (6.3.0.10) readme file to know about the free disk space required on each of the supported platform.
2. Stop all Tivoli Directory Server client or server processes, including the directory server, administration server, and custom LDAP applications. Programs and libraries cannot be replaced while they are in use.
If tracing is on, run ldtrc off to stop the trace process.
For instructions to stop the directory server instances and administration servers, refer the Administration Guide sections titled "Basic server administration tasks" and "Directory administration server".
3. On AIX, Linux, or Solaris systems, go to the subdirectory where you extracted the file, and then run the idsNonRootDB2Install command with root privileges. If a user has not installed non-root DB2 product, then the user must provide path to DB2 v9.7 fix pack 4 setup files to the  -d < db2_installable_path> option of the idsNonRootDB2Install command for non-root DB2 installation. For example:
    ./idsNonRootDB2Install -a user_id -b user_password -c user_home_dir -d db2_installable_path
Note: See "Naming rules" section to know about naming rules.
This command installs non-root DB2, creates a non-root DB2 database instance, and updates the Tivoli Directory Server components that are already installed on the system to the fix pack 10 (6.3.0.10) level.
  • During the creation and configuration of non-root DB2 instance, the ldapdb.properties file is updated.
    • Creates an ldapdb.properties file in the $HOME directory. Where, $HOME is the home directory of the non-root user. This file contains information about the installation location of non-root DB2 and non-root DB2 version. For example:
      DB2Type=NON-ROOT
      currentDB2InstallPath=/home/user1/sqllib
      currentDB2Version=9.7.0.4

      In this example, the DB2Type=NON-ROOT entry is added to the ldapdb.properties file. This entry is used for information purpose, which indicates that the DB2 used is of non-root type.
  • To set certain root-based features during non-root DB2 installation, the $HOME/sqllib/instance/db2rfe.cfg file is updated by setting the ENABLE_OS_AUTHENTICATION variable to YES. The db2rfe -f <$HOME/sqllib/instance/db2rfe.cfg> command is run after updating the file. Where, $HOME is the home directory of the non-root user. The db2rfe command is run with root privileges. To know more about setting root-based features in non-root installation, see http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.qb.server.doc/doc/t0050570.html.

Naming rules:
  • You must have a valid user ID that can be used as the owner of a non-root DB2 instance. The root user must be a member of the primary group to which the user belong. The user ID provided must comply with the naming rules. To know more see “Naming rules” and “Additional restrictions for users and groups” in IBM Tivoli Directory Server version 6.3 Installation and Configuration Guide.
  • If existing user IDs are specified instead of creating new user IDs, make sure that the user IDs:
    • Are not locked
    • Have valid password
  • The user home directory must be a valid DB2 path. DB2 installation path must follow the listed rules.
    • Can include lowercase letters (a-z), uppercase letters (A–Z), and the underscore character "_"
    • Cannot exceed 128 characters
    • Cannot contain spaces
    • Cannot contain non-English characters
    • Cannot be symbolic links
    To know more about DB2 prerequisites for installing DB2 database product as non-root user, see http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.qb.server.doc/doc/t0050571.html.

Creating and configuring a Tivoli Directory Server instance with non-root DB2 instance:
Before creating and configuring a Tivoli Directory Server instance with non-root DB2 instance, user must update the global ldapdb.properties file with the information in the $HOME/ldapdb.properties file. Where, $HOME is the home directory of the user who owns non-root DB2 instance.

Before updating the global ldapdb.properties file user must take a backup of the file. After the creation and configuration of directory server instance with non-root DB2 instance, user must restore the global ldapdb.properties file. The global ldapdb.properties file is located in the listed directories:
  • On AIX and Solaris systems: /opt/IBM/ldap/V6.3/etc/
  • On Linux systems: /opt/ibm/ldap/V6.3/etc/

For ease of use, user can set the path to the LDAP server and client utilities. These utilities are in the listed directories.
  • On AIX and Solaris systems: LDAP server utilities are in /opt/IBM/ldap/V6.3/sbin/ and client utilities are in /opt/IBM/ldap/V6.3/bin/.
    To set the path to the LDAP server and client utilities on AIX and Solaris systems, run the export command. For example:
      export PATH=/opt/IBM/ldap/V6.3/sbin/:$PATH
      export PATH=/opt/IBM/ldap/V6.3/bin/:$PATH
  • On Linux systems: LDAP server utilities are in /opt/ibm/ldap/V6.3/sbin/ and client utilities are in /opt/ibm/ldap/V6.3/bin/.
    To set the path to the LDAP server and client utilities on Linux systems, run the export command. For example:
      export PATH=/opt/ibm/ldap/V6.3/sbin/:$PATH
      export PATH=/opt/ibm/ldap/V6.3/bin/:$PATH
Note: If a user specifies a user home directory that is a symbolic link to another directory, then the user might get errors when creating a Tivoli Directory Server instance and configuring with a non-root DB2 instance. For example:
    GLPCTL004E Failed to create database instance: ’user1’. The failure might have occurred because the system was not set up correctly before using the tool.
    GLPICR033E Failed to add database instance ’user1’ to directory server instance: ’user1’.
    The reason for the error might be the specified home directory is a symbolic link. For example:
      lrwxrwxrwx 1 root root 27 Oct 18 15:25 /home -> /products/home
    In such cases the user must perform the listed steps with root privileges to overcome this limitation:
    1. Remove the symbolic link to the user home directory, if any. For example:
      rm /home
    2. Create a directory /home. For example:
      mkdir /home
    3. Instead of creating a symbolic link to a directory on another file system or a device, mount the directory. For example:
      mount -bind /products/home /home
    4. Perform Tivoli Directory Server and non-root DB2 installation for the non-root user with valid path.

Procedure:
1. Create a Tivoli Directory Server instance by using the idsicrt command. The idsicrt command can be run only by a root user on AIX, Linux, or Solaris platforms. To configure the non-root DB2 database instance, user must provide the database instance with the -t option. For example:
    #idsicrt -I <instancename> -e <encryptionseed> [-g <encryptionsalt>] -t <dbinstance> -l <instlocation>
Note: Save the encryption seed for future use.

(Optional) After creating the directory server instance, the other Tivoli Directory Server configuration commands can be run either as a root user or as a non-root user. To run the configuration commands as non-root user on AIX, Linux, or Solaris platforms, switch to effective non-root user ID.
On AIX, Linux, or Solaris platforms, to switch the effective user ID, run the su command. For example:
    su - <user_name>
2. Configure the non-root DB2 database for the Tivoli Directory Server instance by using the idscfgdb command. Run the idscfgdb command. For example:
    $idscfgdb -I <instancename> -w <dbadminpw> -a <dbadminid> -t <dbname> -l <dblocation>

    The -l <dblocation> option specifies the DB2 database location. For AIX, Linux, or Solaris systems, the location is a directory name. For example, on AIX and Linux the default value is /home/<username> and /export/home/<username> on Solaris.
    Note: If user specifies a custom path other that the user home directory for the -l <dblocation> option, then ensure that the non-root DB2 instance owner has read and write access on the specified location.
3. Configure the administrator DN and password for the directory server instance by using the idsdnpw command. Run the idsdnpw command. For example:
    $idsdnpw -I <instancename> -u <adminDN> -p <adminPWD>
4. Configure a suffix for a directory server instance by using the idscfgsuf command. Run the idscfgsuf command. For example:
    $idscfgsuf -I <instancename> -s <suffix>
5. Start the directory server instance by using the ibmslapd command. Run the ibmslapd command. For example:
    $ibmslapd -I <instancename> -t -n


Importing LDIF data to non-root directory server instance using ids_nonroot_DataImport:
After creating and configuring a Tivoli Directory Server instance with a non-root DB2 database instance, user can load data to a directory server instance with non-root DB2 instance. User can use utilities such as bulkload, ldif2db, or idsldapadd to add data to a directory server instance with non-root DB2 instance.

With this feature, user also has option to import data from an existing directory server instance with root DB2 instance. To import data from an existing directory server instance to a directory server instance with non-root DB2 instance, user must run the ids_nonroot_DataImport command with root privileges.

Notes:
1. The directory server instance is stopped when the ids_nonroot_DataImport is run. Ensure that no applications are attached to the directory database. If there are applications attached, the command might not run successfully.
2. The data import utility, ids_nonroot_DataImport, can be used only on a single system where both the directory server instances with root and non-root DB2 instances are available.
3. Data import from a directory server instance with non-root DB2 instance to a directory server instance with root DB2 instance is not supported by the ids_nonroot_DataImport command.
4. The ids_nonroot_DataImport command does not export data under the "cn=localhost" entry from a directory server instance with root DB2 instance to a directory server instance with non-root DB2 instance.
5. To import data from LDIF file into a directory server instance with non-root DB2 instance, the ids_nonroot_DataImport command internally uses the ldif2db utility. If the size of LDIF file is large, then the ids_nonroot_DataImport command might take considerable time to import data into the directory server instance with non-root DB2 instance.

To import entries from an existing directory server instance into a directory server instance with non-root DB2 instance, run the ids_nonroot_DataImport command with root privileges. For example:
    ./ids_nonroot_DataImport -a <root_instance_name> -b <non_root_instance_name> -c <encryption_seed> -d <encryption_salt> -e <output_file_name>

Notes:
1. To import data, user must know the encryption seed and encryption salt of the directory server instance with non-root DB2 instance. User can obtain the salt value of the destination server by searching the "cn=crypto, cn=localhost" DN entry. The attribute name is ibm-slapdCryptoSalt.
2. Dropping directory server instance with non-root DB2 instance by using the idsidrop command or dropping non-root DB2 instance by using the db2idrop command might result in loss of data.
User must not remove a directory server instance and destroy the associated database instance by using the idsidrop -I <instancename> -r command. This is because the idsidrop command also calls the db2idrop command internally to remove non-root DB2 instance. The db2idrop command is unavailable for non-root DB2 installation. For more information about non-root installation limitations, see http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.qb.server.doc/doc/c0050568.html.
3. Upgrading of a DB2 Version 9.5 root installation to a DB2 Version 9.7 non-root installation is not supported. For more information, see the http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.qb.upgrade.doc/doc/t0053604.html website.
4. Migration of database from DB2 Version 9.5 or 9.7 root installation to a DB2 Version 9.7 non-root installation is not supported.

Importing LDIF data to non-root directory server instance using existing LDAP utilities:
In addition to the ids_nonroot_DataImport command, user can use the existing utilities such as db2ldif, ldif2db, or idsbulkload to import data into a directory server instance with non-root DB2 instance. User can these LDAP utilities to import data into a directory server instance with non-root DB2 instance for any of the listed conditions:
  • If the directory server instance with root DB2 instance and directory server instance with non-root DB2 instance are on different computers.
  • If the size of LDIF file to be imported is large, then it might take considerable time to load data using the ids_nonroot_DataImport or ldif2db commands. In such cases, user can use the idsbulkload command to import data into the directory server.

Summary of steps that a user must perform to import data from a directory server instance with root DB2 instance into a directory server instance with non-root DB2 instance using the existing LDAP utilities.
1. Back up the schema files of the directory server instance with non-root DB2 instance.
2. Export the directory entries from an existing directory server instance with root DB2 instance.
3. Copy the schema files from the directory server instance with root DB2 instance home location to the directory server instance with non-root DB2 instance home location.
4. Update the permission of schema files as required.
5. Import the entries into directory server instance with non-root DB2 instance.

To import data from a directory server instance with root DB2 instance into a directory server instance with non-root DB2 instance, perform the listed steps. Run the commands using the root privileges.
1. To export data from a directory server instance with root DB2 instance, run the db2ldif command. For example:
    db2ldif -I <instance_name> -o <output_file> -k <destinationServer_keySeed> -t <destinationServer_keySalt>
    Notes:
    a. If encryption seed and salt values of the destination server are different from the source server then user must specify the -k and -t options with valid values. User can obtain the salt value of the destination server by searching the "cn=crypto, cn=localhost" DN entry. The attribute name is ibm-slapdCryptoSalt.
    b. To include entries under "cn=localhost" DN entry for export, the -l option must be specified.
    For more information about the db2ldif command, see the IBM Tivoli Directory Server Version 6.3 Command Reference.
2. Copy the schema files from the directory server instance with root DB2 instance home location to the directory server instance with non-root DB2 instance home location. If the destination server is on a different computer, transfer to files to the destination computer.
3. On the destination server, update the permission of the schema files appropriately for the non-root user. For example:
    chmod -R 660 V3*
    chown -R <non-root_username>:idsldap V3*
4. Depending on the size of LDIF file containing the entries, user can either use the ldif2db utility or the idsbulkload utility to import the data in the LDIF file.
  • For LDIF file with smaller size, use the ldif2db command to import the data into a directory server instance with non-root DB2 instance. For example:
      ldif2db -I <instance_name> -i <input_file> -r no
    Notes:
    • The server must be stopped before using the server import utilities.
    • Ensure that no applications are attached to the directory database. If there are applications attached, the server utilities might not run.
OR
  • For LDIF file with large size, use the idsbulkload command to import the data into a directory server instance with non-root DB2 instance. For example:
      idsbulkload -I <instance_name> -a parse_and_load -i <input_file> -n -L /tmp
    Notes:
    • The server must be stopped before using the server import utilities.
    • Ensure that no applications are attached to the directory database. If there are applications attached, the server utilities might not run.
    • To run the idsbulkload utility user must have dbadm or sysadm privilege.
    For more information about the ldif2db and bulkload commands, see the IBM Tivoli Directory Server Version 6.3 Command Reference.


Unconfiguring and uninstalling non-root instance:
User can unconfigure and uninstall the directory server instance and the non-root DB2 instance. This section describes unconfiguring and uninstalling of directory server instance and non-root DB2 instance.
    Unconfiguring the database for a directory server instance:
    To unconfigure a database of a directory server instance, user can use the idsucfgdb command. By default, the command unconfigures the database from the ibmslapd.conf file and does not delete the database. However, user can opt to destroy the database that is configured with a directory server instance. To specify to delete the database during the unconfiguration process, the -r option can be specified.
    Note: User can also use GUI interface, the Configuration Tool (idsxcfg), to unconfigure a database associated with a directory server instance.
    The idsucfgdb command can be run either as a root user or as a non-root user. To run the command as non-root user on AIX, Linux, or Solaris platforms, switch to effective non-root user ID. For example:
      su - <user_name>

    To unconfigure the database for directory server instance, myinst, and not prompt before unconfiguring, run the idsucfgdb command. The idsucfgdb command must be run using the For example:
      $ idsucfgdb -n -I myinst

    To unconfigure and delete the database for directory server instance, myinst, and not prompt for confirmation before removing the database associated with the directory server instance, run the idsucfgdb command. For example:
      $ idsucfgdb –r –n -I myinst

    For more information about the idsucfgdb command, see the IBM Tivoli Directory Server Version 6.3 Command Reference.

    Removing directory server instance:
    To remove a directory server instance, user can use the idsidrop command. This command can be run only by root on AIX, Linux, or Solaris systems.
    Note: User can also use GUI interface, the Instance Administration Tool (idsxinst), to remove a directory server instance.
    The administrator can specify a directory server instance name and optionally can specify whether to delete the database instance. The idsidrop command does not delete the directory server instance until the directory server instance is stopped. For more information about the idsidrop command, see the IBM Tivoli Directory Server Version 6.3 Command Reference.

    To remove a directory server instance and retain the associated database instance without prompting for confirmation, run the idsidrop command. For example:
      # idsidrop -I <instancename> -n

    To unconfigure the associated database instance without removing a directory server instance without prompting for confirmation, run the idsidrop command. For example:
      # idsidrop -I <instancename> -R -n

    Note: User must not remove a directory server instance and destroy the associated database instance by using the idsidrop -I <instancename> -r command. This is because the idsidrop command with -r option calls the db2idrop command internally to remove non-root DB2 instance. The db2idrop command is unavailable for non-root DB2 installation. For more information about non-root installation limitations, see http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.qb.server.doc/doc/c0050568.html.

    Uninstalling non-root DB2 database product:
    This section describes steps for removing non-root DB2 product from AIX, Linux, or Solaris systems. To remove the DB2 that was installed with non-root authority, user must perform the listed steps:
    1. Stop the non-root DB2 instance.
    2. Remove the non-root DB2 product using the db2_deinstall command.
      Stopping non-root DB2 instance:
      User must stop the non-root DB2 instance before uninstalling the DB2 database product. To stop the non-root DB2 instance, perform the listed steps:
      1. Log in as the non-root instance owner.
      2. Run the startup script if it not included in .profile.
        . $HOME/sqllib/db2profile (bash, Bourne, or Korn shells)
        source $HOME/sqllib/db2cshrc (C shell)
        where, $HOME is the home directory of non-root user
      3. You might want to save the DB2 files for future use.
      • The database manager configuration file, db2systm.
      • The configuration file used to enable root features before running db2rfe.
      • User-defined functions or fenced stored procedure applications in $HOME/sqllib/function.
      4. Stop the DB2 database manager by running the db2stop command. For example:
        db2stop force
      5. Confirm that the instance is stopped.
        db2 terminate

      For more information about stopping a non-root DB2 instance, see http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.qb.server.doc/doc/t0052045.html.

      Removing non-root DB2 database product using db2_deinstall:
      User can use the db2_deinstall command to remove non-root DB2 database product or its components. When non-root user runs the db2_deinstall command, it uninstalls the DB2 database product and drops the non-root DB2 instance.
      Note: User must stop the non-root DB2 instance before running the db2_deinstall command.

      Perform the listed steps to uninstall a DB2 database product that was installed by a non-root user.
      1. Log in using the non-root user credentials using which the DB2 database product was installed.
      2. Change to the $HOME/sqllib/install directory. Where, $HOME is the home directory of non-root user.
      3. Run the db2_deinstall command.
      Notes:
      • If you run the db2_deinstall command with the -a option, the DB2 database program files are removed. If there are any configuration files, they are stored in a backup directory called sqllib_bk.
      • If you run the db2_deinstall command with the -a -f sqllib option, the entire sqllib subdirectory in your home directory is removed. If you have files in sqllib that you want to keep, be sure to copy them in a different location before running db2_deinstall -a -f sqllib.
      • As with root installations, running the db2_deinstall command with the -F option against a non-root installation allows the non-root user to remove specific DB2 features.

      For more information about removing non-root DB2 database product, see http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.qb.server.doc/doc/t0050575.html.
    Uninstalling Tivoli Directory Server:
    To uninstall the Tivoli Directory Server product, see the "Chapter 16: Uninstalling Tivoli Directory Server" in the IBM Tivoli Directory Server Version 6.3 Installation and Configuration Guide.

Log details:
To troubleshoot any issues with installation of non-root DB2 database product, user must check the log files. The log files related to non-root installation are stored in the /var/idsldap/V6.3/ directory and have the idsNonRootDB2Install_<timestamp> .log format.
To troubleshoot issues of data import from a directory server instance with root DB2 to an instance with non-root DB, user must check the /var/idsldap/V6.3/ directory for the log files. The log files related to data import have the ids_nonroot_DataImport_<timestamp>.log format.


Command-line utilities:
This section provides the information about the commands and the syntax of the commands used in this feature.

    idsNonRootDB2Install
    Description:
      The idsNonRootDB2Install command installs non-root DB2 and Tivoli Directory Server. This command also creates and configures the non-root DB2 instance. This command must be run with root privileges.
    Synopsis:
        idsNonRootDB2Install [-a user_id -b user_password
                             [-c user_home_dir ]
                             [-d db2_installable_path]] | -h
    Options:
      -a user_id: Specifies the name of the user to create on the operating system. This option is required.
      -b user_password: Specifies the user's password. This option is required.
      -c user_home_dir: Specifies the user's home directory. The default value for a user's home directory on AIX or Linux is /home/username and on Solaris is /export/home/username.
      -d db2_installable_path: DB2 installable location with absolute path. For new DB2 installation, the DB2 installable path is required.
      -h Displays the usage.
      ids_nonroot_DataImport
      Description
        The ids_nonroot_DataImport command imports data from Tivoli Directory Server with root DB2 to Tivoli Directory Server with non-root DB2. This command must be run with root privileges.
      Synopsis
        ids_nonroot_DataImport [-a Root_Instance_Name
                                -b Non_Root_Instance_Name
                                -c Encryption_Seed
                                -d Encryption_Salt
                                -e Output_File_Name] | -h
      Options
      All options are required.
        -a Root_Instance_Name: Specifies the name of the directory server instance configured with root DB2.
        -b Non_Root_Instance_Name: Specifies the name of the directory server instance configured with non-root DB2.
        -c Encryption_Seed: Specifies the encryption key seed value of the destination server.
        -d Encryption_Salt: Specifies the encryption key salt value of the destination server.
        -e Output_File_Name: Specifies the name of the LDIF file to which data is to be redirected. Absolute path of the file is required.
        -h Displays the usage.

    Rate this page:

    (0 users)Average rating

    Document information


    More support for:

    IBM Security Directory Server
    General

    Software version:

    6.3

    Operating system(s):

    AIX, Linux, Solaris

    Reference #:

    1578295

    Modified date:

    2012-01-31

    Translate my page

    Machine Translation

    Content navigation