The Directory appliance comes with a pre-configured IBM® Security
Directory Suite instance that is configured
to an embedded DB2® instance.
Before you begin
- Ensure that the service port is not in use by another service before using the
idscfgremotedb script.
- The network connectivity between the Directory and the remote DB2 can have performance impact. It is
suggested that the remote DB2
server is in the same geography and subnet as the Directory appliance.
About this task
The user also has the option to configure the existing server instance to use an external
or remote database instance on another machine. This is primarily intended for following users:
- Users that have an existing DB2
server
- Users having the need for fine grained control over their DB2 instance for performance tuning and
compliance.
- Users who need a DB2 level High
Availability or Monitoring
- Users who are anticipating high volume of transactions or data having highly scalable
disk space requirements.
A remote database can be configured on top of an existing embedded database in which
case the information in the embedded database is retained. However, the remote database
cannot be configured for the following scenarios:
- The remote database cannot be configured in combination with any of these options:
-c -collate -k -m -s -x -z.
- A remote database cannot be configured on top of an existing embedded database if
there is an existing change log configured. Since the Directory Server is configured to
a remote database, the change log must also be remote.
- A remote database cannot be configured on top of an existing remote database
configuration. If the remote database is configured to communicate over SSL, the change
log (if configured) will also automatically communicate over SSL.
Procedure
- Create a new DB2 instance on the
remote DB2 server by using the
idscfgremotedb script.
idscfgremotedb –c –u user_name –w passwd –t db_name –p db2_path –S port
Note: - You can also use an existing DB2 instance that is used by any
existing Directory Server.
- The idscfgremotedb script requires an existing user on the
remote DB2 server with a
valid password and proper authority. The path specified by the
db2_path must already exists and contains a pre-installed
DB2.
- Configure the Directory Server instance in the appliance to use the remote DB2 instead of the pre-configured
embedded DB2 by using the
idscfgdb script.
idscfgdb –I instance_name –a instance_user_id –t db_alias –w instance_user_pwd
–Y -S port –l location –P remote_server_ip
–u remote_username –p remote_pwd
Note: - The idscfgdb script does not unconfigure or drop the existing
embedded database instance. Existing data are not lost.
- Ensure that only a single Directory appliance is configured with any given
DB2 instance. The
idscfgdb script does not ensure this. Multiple
applications or Directory appliances that are using the same DB2 instance can result in an
application failure or data loss and is not a supported configuration.
- Create a change log database on the remote DB2.
Note: - The change log database must be created inside an existing DB2 instance, on a remote machine
(This is the same instance to which the IBM Security
Directory Suite appliance
instance is configured for a remote DB2 communication).
- The change log database is created on the remote DB2 by using the same script that
is used to create the remote DB2 instance.
- Create a remote DB2
instance by using the idscfgremotedb script.
idscfgremotedb -c -u dem1in -w inst123 -t dem1in -p /opt/ibm/db2/V10.5/ -s 6512
- Create a change log database in the remote DB2 instance by using the
idscfgremotedb script.
idscfgremotedb -c -u dem1in -w inst123 -t LDAPCLOG -p /opt/ibm/db2/V10.5/ -s 6512
- Verify that you have successfully created a change log database in the remote
DB2 instance .
su - DEM1IN
[dem1in@islrppcxv44 ~]$ db2 connect to dem1in user dem1in using inst123
[dem1in@islrppcxv44 ~]$ db2 list db directory
System Database Directory
Number of entries in the directory = 2
Database 1 entry:
Database alias = DEM1IN
Database name = DEM1IN
Local database directory = /home/dem1in
Database release level = 10.00
Comment =
Directory entry type = Indirect
Catalog database partition number = 0
Alternate server hostname =
Alternate server port number =
Database 2 entry:
Database alias = LDAPCLOG
Database name = LDAPCLOG
Local database directory = /home/dem1in
Database release level = 10.00
Comment =
Directory entry type = Indirect
Catalog database partition number = 0
Alternate server hostname =
Alternate server port number =
- The IBM Security
Directory Suite
appliance is configured to DEM1IN and the change log can now be
configured using the idscfgchlg script.
idscfgchlg -Y
- Configure the change log for the remote DB2 by using the
idscfgchglg and sdsinst1 commands.
idscfgchglg -I sdsinst1 -Y
Note: When you have a remote database configured to the Directory Server instance, you can
only configure a remote change log. The remote change log database must be created in
the same
DB2 instance as that
configured to the Directory Server instance.
The user must perform the following tasks
to configure the
IBM Security
Directory Suite appliance
instance to remote
DB2 over
SSL and to configure the change log:
- Create both databases. For example, remote DB2 instance and the change log
database inside an existing DB2 instance before configuring
the remote DB2 instance
for SSL.
- Once both databases are created, the user can proceed with the SSL configuration
on the remote DB2
instance.
The sequence of the previous steps is important because, if SSL is
configured before configuring the Changelog DB, then the script overrides the SSL
settings of the remote DB2 instance.
- Set up the SSL on the remote DB2.
- Create the database by running the idsremotecfgdb command.
- Run the following command.
db2 update dbm cfg using SSL_SVR_KEYDB PATH_TO_KDB
db2 update dbm cfg using SSL_SVR_STASH PATH_TO_STASH
db2 update dbm cfg using SSL_SVR_LABEL LABEL_OF_CERTIFICATE
db2 update dbm cfg using SSL_SVCENAME SSL_PORT_NAME
db2set DB2COMM=SSL
db2 update dbm cfg using DIAGLEVEL 4
db2stop force
db2start
- Configure the remote database over SSL for IBM Security
Directory Suite.
- Copy the .kdb and stash file to the appliance by using one of the following
methods:
- Local Management Interface (LM)
- CLI, idsgetfile
- Run the following command:
idscfgdb –I instance_name –a instance_user_id –t db_alias
-w instance_user_pwd -Y –S port -l location -P remote_server_ip
-u remote_username -p remote_pwd -L -B kdb_file -H stash_file
Results
You see the following messages after successfully configuring the remote
DB2:
GLPSRV247I Initializing primary REMOTE database Database Name and its connections
GLPSRV248I Initializing REMOTE changelog database and its connections
What to do next
- The password of the remote database configured to the SDS can be updated by using
idscfgdb -I sdsinst1 -p new_password.
- If any parameters of the remote database (except password) like IP address, instance
name, port are changed, the database must be unconfigured by using the
idsucfgdb command and re-configured with the new parameters by using
the idscfgdb command.
- Unconfiguring a remote database does not automatically configure the Directory Server
instance to the embedded database. Re-configure the remote database to a
remote\embedded database by running the idscfgdb
tool.