Install WebSphere Portal on an unmanaged node (secondary)

 

+
Search Tips   |   Advanced Search

 

Overview

In this scenario, you install WebSphere Portal and then federate the node to bring it under deployment manager control.

  1. Install WebSphere Portal without business process support.

    i5/OS: Install WebSphere Portal on i5/OS.

  2. For Windows and UNIX systems, reconfigure the database from Cloudscape to the database being used by the primary node.

    Note that in WebSphere Portal v6.0, the task...

    connect-database
    ...has been integrated into the task...

    cluster-setup

    Therefore it is not necessary to run the connect-database task to configure the second node with the Portal databases as you had to do with WebSphere Portal v5.x.

    1. Ensure that the database client software is installed on the secondary node using the same settings as the primary node and that we can connect to the remote database. It is not necessary to create databases or users when configuring secondary nodes.

      DB2 users: catalog the TCP/IP node and all databases used by WebSphere Portal on each secondary node.

    2. The datasources for the secondary node must be made to point to the datasources for the primary node. Update...

      ...to specify which remote database will be used. This information should match the database information used for the primary node installation. Refer to Configuring for WebSphere Portal for information on properties that are pertinent for database configuration.

      Tip: To simplify this process, we can make a backup copy of the wpconfig_dbdomain.properties file on the secondary node, and then copy the wpconfig_dbdomain.properties file from the primary node to the secondary node.

    3. Validate the database settings by running the following commands.

    4. Update wpconfig_dbtype.properties and set the DbSafeMode property to true to prevent the database configuration from being changed.

    5. Reconfigure WebSphere Portal to use the remote databases by running the following command from the portal_server_root/config directory on the secondary node:

      At this point, do not access WebSphere Portal and do not log in to WebSphere Portal as any user, as it could result in database corruption.

    6. Update wpconfig_dbtype.properties and set the DbSafeMode property to false.

  3. i5/OS only: Specify database settings and complete the configuration of WebSphere Portal.

    1. Ensure that the following properties are uncommented.

      wpconfig.properties file:

      • PrimaryNode property: Because this node is a secondary node, set this property to false.

      • PortalAdminId property: specify the fully-qualified name of the WebSphere Portal administrator.

      wpconfig_dbtype.properties file:

      • DbSafeMode property: Set this property to true to prevent the database configuration from being changed.

      wpconfig_dbdomain.properties file:

      • domain.DbUser: Specify the administrator ID for the following domains in the WebSphere Portal database.

        • release
        • customization
        • community
        • wmm
        • jcr
        • feedback
        • likeminds

    2. Reconfigure the datasources for the secondary node to point to the datasources for the primary node. Update the wpconfig_dbtype.properties and wpconfig_dbdomain.properties files to specify which remote database will be used. This information should match the database information used for the primary node installation. Refer to Configuring for WebSphere Portal for information on properties that are pertinent for database configuration.

      If you configured a local database when installing the primary node, be sure to set the appropriate property values to point to the database on the primary node machine, as described in Setting up an i5/OS database in a cluster.

      When specifying property values for the remote database on a secondary node, ensure that you replace instances of *LOCAL/schema with primary_node_hostname/schema, as described in Creating schemas and users for DB2.

    3. Validate the database settings by running the following commands.

      where profile_root is the name of the WebSphere Application Server profile where WebSphere Portal is installed; for example, wp_profile.

    4. Reconfigure WebSphere Portal to use the remote databases by running the following command from the portal_server_root/config directory: 

      WPSconfig.sh -profileName profile_root connect-database

      ...where profile_root is the name of the WebSphere Application Server profile where WebSphere Portal is installed; for example, wp_profile.

    5. Set the DbSafeMode property to false in wpconfig_dbtype.properties.

  4. Change the timeout request period for the Simple Object Access Protocol (SOAP) client. The default, in seconds, is 180. Edit the soap.client.props file in the was_profile_root/properties directory:

    Change the line to: 

    com.ibm.SOAP.requestTimeout=6000

  5. Linux only: If we have not done so already, use the ulimit command to increase the number of files that can be open concurrently. Enter the following command: 

    ulimit -n 10240

  6. Validate whether this installation of WebSphere Portal supports federation into a managed cell. Run the pre-node-federation task.

    If the task succeeds, continue to the next step. However, if the task fails, this indicates that the portal was installed with the business process integration feature provided by WebSphere Process Server. This installed configuration does not support federation into a managed cell.

    • If you require business process support and need to federate the portal server, reinstall WebSphere Portal according to the instructions for installing into a managed node.

    • If we need to federate the portal server but do not require business process support, we can install WebSphere Portal on an unmanaged node and choose not to install business process support during installation. This installed configuration allows for subsequent federation into a managed cell.

  7. Add the portal application server on the secondary node to the deployment manager cell by entering the addNode command. Do not include the -includeapps parameter. Refer to addNode command for command syntax and other information.

    • It is important not to use the -includeapps option. The applications will not be transferred as they are already in the deployment manager's master configuration.

    • Applications stored in the master configuration are still only assigned to the primary node. In order to share them with a secondary node, the node must be added to the cluster.

  8. Update the PrimaryNode property value on the secondary node to indicate its status. Edit the wpconfig.properties file.

    Ensure that the following properties are uncommented and specify appropriate values:

    • PrimaryNode property: Because this node is a secondary node, set this property to false.

  9. Update the deployment manager configuration for the new WebSphere Portal.

  10. If you are using an LDAP user registry to provide security for the cluster, update the security configuration on the node.

 

Parent Topic

Installing and federating secondary nodes