Adding a database user registry on Linux 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 add only one database user registry at a time.

Before you begin

In a stand-alone server environment, you can complete the following task when the servers are either stopped or started. In a clustered environment, start the deployment manager and node agent and verify that they are able to synchronize.

About this task

Complete the following steps to add a database user registry to the default federated repository. You must repeat these steps for each additional database user registry that you plan to add:
Tip: Complete these steps on the primary node only.
Note: Use the wp_add_DB.properties helper file, in the wp_profile_root/ConfigEngine/config/helpers directory to ensure that the correct properties are entered. In the following instructions, when the step refers to the wkplc.properties file, use your wp_add_DB.properties helper file. When you run the task, include the -DparentProperties=dir_path_helperfile -DSaveParentProperties=true parameters.

Procedure

  1. Before you configure security, you must use the IBM® WebSphere® Application Server backupConfig task to create and store a backup of the IBM WebSphere Portal configuration; see backupConfig command for information.
  2. Set up a new database, including creating a new user with appropriate database privileges for accessing the database:
    Instructions for setting up databases: Refer to the appropriate documentation for the type of database you want to set up.
    Consulting your database administrator: A database administrator typically completes the task of setting up a new database. However, the following steps are provided for your reference in the event you are creating a stand-alone database for testing or demonstration purposes. Consult your database administrator before you proceed with the following steps if you plan to create a database for a production environment.
    Table 1. Steps for creating a database to use as a database user registry.
    Database Steps
    DB2® Complete the following steps to create a DB2 database:
    1. Install DB2.
    2. Enter the following database tuning commands:
      db2 "CREATE DB dbname using codeset UTF-8 territory us PAGESIZE 8192"
db2 "UPDATE DB CFG FOR dbname USING applheapsz 4096"
db2 "UPDATE DB CFG FOR dbname USING app_ctl_heap_sz 1024"
db2 "UPDATE DB CFG FOR dbname USING stmtheap 32768"
db2 "UPDATE DB CFG FOR dbname USING dbheap 2400"
db2 "UPDATE DB CFG FOR dbname USING locklist 1000"
db2 "UPDATE DB CFG FOR dbname USING logfilsiz 4000"
db2 "UPDATE DB CFG FOR dbname USING logprimary 12"
db2 "UPDATE DB CFG FOR dbname USING logsecond 20"
db2 "UPDATE DB CFG FOR dbname USING logbufsz 32"
db2 "UPDATE DB CFG FOR dbname USING avg_appls 5"
db2 "UPDATE DB CFG FOR dbname USING locktimeout 30"
db2 "UPDATE DB CFG FOR dbname using AUTO_MAINT off"
    Oracle Complete the following steps to create an Oracle database:
    1. Install Oracle by using Unicode database and National character sets such as UTF8, AL32UTF8, or AL16UTF16.
    2. Configure the database in Dedicated Server Mode.
    3. Enter the initial buffer pool sizes or set them according to your business needs:
      • db_block_size = 8192
      • db_cache_size = 300M
      • db_files = 1024
      • log_buffer = 65536
      • open_cursors = 1500 open_cursors = 1500
      • pga_aggregate_target = 200M
      • pre_page_sga = true
      • processes = 300
      • shared_pool_size = 200M
    SQL Server Complete the following steps to create an SQL Server database:
    1. Create a SQL Server database with a name of your choice.
    2. Optional: Create a new SQL Server database user with the same permissions as your Portal database users for this new database.
    Note: Install SQL Server with the appropriate portal database collation so that your tempdb collation setting matches the collation you use for the property extension database. The tempdb collation is inherited from the master database, which you set when you install SQL Server.
  3. Complete the following steps to define the DbDriver and DbLibrary parameter values:
    1. Go to the following directory: wp_profile_root/ConfigEngine/properties
    2. Locate and open wkplc_dbtype.properties with any text editor.
    3. Enter a value for the following parameters in the appropriate database type properties heading:
      • db_type.DbDriver
      • db_type.DbLibrary
      • db2.JdbcProviderName
    4. Save your changes.
  4. Use a text editor to open the wkplc.properties file, in the wp_profile_root/ConfigEngine/properties directory.
  5. Enter a value for the following parameters in the wkplc.properties file under the VMM Federated database Properties heading:
    Note: See the properties file for specific information about the advanced parameters.
    • federated.db.DataSourceName
    • federated.db.DbType
    • federated.db.DbUrl
    • federated.db.id
    • federated.db.baseDN
    • federated.db.DbUser
    • federated.db.DbPassword
    • federated.db.DbName
  6. Change the value for the com.ibm.SOAP.requestTimeout parameter to 1000.
    1. Go to the following directory: wp_profile_root/properties.
    2. Locate and open soap.client.props with any text editor.
    3. Locate the com.ibm.SOAP.requestTimeout parameter and ensure that the value is greater than 1000.
    4. Save and close soap.client.props.
  7. Complete the following steps to configure the database repository library paths:
    1. Run the ./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=password -DDbDomain=federated.db -Ddb_type.DmgrDbLibrary=local path of the database jars on the Deployment Manager -DDmgrNodeName=dmgr_node_name task from the wp_profile_root/ConfigEngine directory to create the local Deployment Manager WebSphere variable that is used to access the database JAR files.
      Note: The db_type in db_type.DmgrDbLibrary must be set to the type of database you are using, for example db2. The local full path of the database jars on the Deployment Manager must be one of the following options:
      • DB2 Type 2 driver: db2java.zip
      • DB2 Type 4 driver: db2jcc4.jar:db2jcc_license_cu.jar
      • DB2 for z/OS® Type 2 driver: db2java.zip
      • DB2 for z/OS Type 4 driver: db2jcc4.jar:db2jcc_license_cisuz.jar
      • Oracle: ojdbc14.jar
      • SQL Server JDBC driver that is provided by Microsoft: sqljdbc.jar
    2. Run the following task. Include each node name as a comma-separated list in the command:
      Running the task: You do not have to run this task more than one time. You can run this task from any node in the cluster.
      1. Set the property value for federated.db.DbType in the wkplc.properties file if you use a database user registry or if the cell is migrated from a previous version.
      2. Run the ./ConfigEngine.sh wp-node-prep-vmm-db-secured-environment -DWasPassword=password -DDbDomain=federated.db -DVmmNodeName=node_name -Ddb_type.NodeDbLibrary=local full path of the database jars task from the wp_profile_root/ConfigEngine directory on each node to create the variable that is used to access the VMM database JAR files.
        Note: VmmNodeName is a list of one or more WebSphere Portal nodes names in the cell which share database driver paths. The db_type in db_type.NodeDbLibrary must be set to the type of database you are using, for example db2.
    3. Stop and restart all necessary servers to propagate your changes.
  8. Run the ./ConfigEngine.sh wp-create-db -DWasPassword=password task, from the wp_profile_root/ConfigEngine directory to add a database user registry to the default federated repository.
    Note: Users who are not in an LDAP do not have awareness and cannot see whether other users are online. This can happen if you 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.
  9. Stop and restart the appropriate servers to propagate the changes. For specific instructions, see Starting and stopping servers, deployment managers, and node agents.
  10. Complete the following steps to update the user registry where new users and groups are stored:
    Note: If you have multiple LDAP user registries or a database user registry, run this task for the user registry that you want to define as the default user registry.
    1. Use a text editor to open the wkplc.properties file, in the wp_profile_root/ConfigEngine/properties directory.
    2. Enter a value for the following parameters in the wkplc.properties file under the VMM supported entity types configuration heading:
      Note: See the properties file for specific information about the advanced parameters.
      • personAccountParent
      • groupParent
      • personAccountRdnProperties
      • groupRdnProperties
      The parameters groupParent and personAccountParent must be set to the same value.
      • personAccountParent=dc=yourco,dc=com
      • groupParent=dc=yourco,dc=com
    3. Save your changes to the wkplc.properties file.
    4. Run the ./ConfigEngine.sh wp-set-entitytypes -DWasPassword=password task, from the wp_profile_root/ConfigEngine directory to delete the old attributes before you add the new attributes.
    5. Stop and restart all necessary servers to propagate your changes.
  11. Optional: Run the ./ConfigEngine.sh wp-query-repository -DWasPassword=password task, from the wp_profile_root/ConfigEngine directory to list the names and types of configured repositories.

What to do next

If you created your clustered environment, including the additional nodes, and then completed the steps in this task, you must now run the update-jcr-admin task on the secondary node. See the related links section for instructions.