Add a database user registry on i5/OS in a clustered environment

Add a database user registry to the default federated repository to store user account information for authentication and authorization. You can add multiple database user registries to the default federated repository although you can only add one database user registry at a time.

In a single server environment the WebSphere_Portal and server1 servers can be either stopped or started.

In a clustered environment stop all appservers on the system including WebSphere_Portal and server1 and then start the nodeagent and deployment manager servers before starting the following task.

Perform the following steps, on the primary node only, to add a database user registry to the default federated repository; repeat these steps for each additional database user registry that you plan to add:

Use the wp_add_DB.properties helper file, located in...

...when performing this task to ensure the correct properties are entered. In the instructions below, when the step refers to wkplc.properties, you will use your wp_add_DB.properties helper file.

  1. To create the DB2 for i5/OS database:

    1. Login to a remote i5/OS session.

    2. Enter the strsql command to start the interactive sql session.

    3. Enter the create schema database_name command, where database_name is the name you want to use for the database.

  2. Perform the following steps to define the DbDriver and DbLibrary parameter values:

    1. Edit wkplc_dbtype.properties, located in the profile_root/ConfigEngine/propertiesdirectory.

    2. Enter a value for the following parameters under the appropriate database type properties heading:

      • db_type.DbDriver

      • db_type.DbLibrary

    3. Save changes.

  3. Edit...

      profile_root/ConfigEngine/properties/wkplc.properties

  4. Enter a value for the following parameters under the VMM Federated Database Properties heading:

  5. Edit the soap.client.props file, located in the profile/wp_profile/properties directory. Change the com.ibm.SOAP.requestTimeout value to 1000.

  6. Perform the following steps in a clustered environment:

    1. Run...

        ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=password -DDbDomain=la|federated.db -Ddb_type.DmgrDbLibrary=/path/to/DB/jars/on/Dmgr -DDmgrNodeName=dmgr_node_name

      ...from...

        profile_root/ConfigEngine

      ...to create the local Deployment Manager WebSphere variable used to access the database jars.

      Where DbDomain is either la or federated.db depending on whether you are using a property extension database (la) or a database user registry (federated.db). The db_type in db_type.DmgrDbLibrary should be set to the type of database you are using, for example db2_iseries.

      The /path/to/DB/jars/on/Dmgr should be one of the following options:

      • DB2 for i5/OS Type 2 driver:

        /QIBM/ProdData/Java400/ext/db2_classes.jar

      • DB2 for i5/OS Type 4 driver:

        /QIBM/ProdData/HTTP/Public/jt400/lib/jt400.jar

    2. If you configured a database user registry or a property extension database, run the following task for EACH WebSphere Portal node that participates in the cluster to set up access to the database drivers; if multiple nodes share the same database library path you can submit a comma separated list of node names:

      This task does not need to be executed from the node identified in the VmmNodeName parameter.

      1. Set the property value for federated.db.DbType if using a database user registry and set the property value for la.DbType if using a property extension database in wkplc.properties.

      2. Run...

          ConfigEngine.sh wp-node-prep-vmm-db-secured-environment -DWasPassword=password -DDbDomain=la|federated.db -DVmmNodeName=node_name -Ddb_type.NodeDbLibrary=/path/to/DB/jars

        ...from profile_root/ConfigEngine on each node to create the variable used to access the VMM database jars.

        Where DbDomain is either la or federated.db depending on whether you are using a property extension database (la) or a database user registry (federated.db). VmmNodeName is a list of one or more WebSphere Portal nodes names in the cell which share the same database driver paths. The db_type in db_type.NodeDbLibrary should be set to the type of database you are using, for example db2.

        The /path/to/DB/jars should be one of the following options:

        • DB2 for i5/OS Type 2 driver:

          /QIBM/ProdData/Java400/ext/db2_classes.jar

        • DB2 for i5/OS Type 4 driver:

          /QIBM/ProdData/HTTP/Public/jt400/lib/jt400.jar

    3. Run...

        ConfigEngine.sh wp-connect-database-vmm -DWasPassword=password -DDbDomain=la|federated.db

      ...to connect to the VMM database, where DbDomain is either la or federated.db depending on whether you are using a property extension database (la) or a database user registry (federated.db).

    4. Cycle all necessary servers to propagate changes.

  7. Run...

      ConfigEngine.sh wp-create-db -DWasPassword=password task, from profile_root/ConfigEngine, to add a database user registry to the default federated repository.

      Users who are not in an LDAP do not have awareness and cannot see if other users are online. This can happen if install WebSphere Portal and then enable a Federated LDAP or Federated database user repository that does not contain that user. Also, users who sign up using the Self Care portlet do not have awareness.

    • Propagate the security changes:

      Option Description
      Standalone

      1. stopServer server1 -username admin_userid -password admin_password

        ...from...

          profile_root/bin

      2. stopServer WebSphere_Portal -username admin_userid -password admin_password

        ...from...

          profile_root/bin

      3. startServer server1

        ...from...

          profile_root/bin

      4. startServer WebSphere_Portal

        ...from...

          profile_root/bin

      Cluster

      1. stopManager-username admin_userid -password admin_password, from the DMGR_PROFILE/bin

      2. stopNode -username admin_userid -password admin_password from the profile_root/bin directory

      3. stopServer WebSphere_Portal -username admin_userid -password admin_password

        ...from...

          profile_root/bin

      4. startManager, from the DMGR_PROFILE/bin

      5. startNode

        ...from...

          profile_root/bin

      6. startServer WebSphere_Portal

        ...from...

          profile_root/bin

    • Perform the following steps to update the user registry where new users and groups are stored:

      For multiple LDAP user registries and/or a database user registry, only run this task for the user registry that you want to define as the default user registry where new users and groups are stored.

      During installation, the default file repository creates a default value in the personAccountRdnProperties and groupRdnProperties parameters.

      To change the default value, run this task twice; once to clear the default value and once to add the new value.

      1. Edit...

          profile_root/ConfigEngine/properties/wkplc.properties

      2. Enter a value for the following parameters under the VMM supported entity types configuration heading:

      3. Save changes to wkplc.properties.

      4. Run...

          ConfigEngine.sh wp-set-entitytypes -DWasPassword=password task, from...

            profile_root/ConfigEngine

          ...to delete the old attributes before adding the new attributes.

        • Cycle all necessary servers to propagate changes.

    • Optional: Run...

        ConfigEngine.sh wp-query-repository -DWasPassword=password task, from profile_root/ConfigEngine, to list the names and types of configured repositories.

If you performed these steps after creating the clustered environment, run enable-jcr-security on the secondary node.


Parent topic:

Configure the default federated repository on i5/OS in a clustered environment


Related tasks


Enable LDAP security after cluster creation