Installing a Dynamic Workload Console server

You can choose between installing a Dynamic Workload Console version 10.2.1 or later, or a Dynamic Workload Console version 10.2.0 or earlier. The main differences between the versions of the Dynamic Workload Console are described hereafter.

About this task

This picture describes the steps required for installing the Dynamic Workload Console. You are now at step 4: installing the Dynamic Workload Console server.
Dynamic Workload Console version 10.2.1, or later
SSL configuration is required and is provided with the custom certificates generated during the installation process. For more information, see Installing a Dynamic Workload Console version 10.2.1, or later.
Dynamic Workload Console version 10.2.0, or earlier
SSL configuration is optional. For more information, see Installing a Dynamic Workload Consoleversion 10.2.0, or earlier.

Installing a Dynamic Workload Console version 10.2.1, or later

About this task

The HCL Workload Automation administrator installs the Dynamic Workload Console by running the dwcinst command. You can run the dwcinst specifying a typical set of parameters. In this case, default values are used for all remaining parameters.

Default values are stored in the dwcinst.properties file, located in the root directory of the installation image. If you need to modify any of the default values, edit the dwcinst.properties file, but do not modify the dwcinst.template file located in the same path.

You have to configure your environment in SSL mode, by using the sslkeysfolder and sslpassword parameters. These parameters process automatically the certificates for each workstation in your environment. For details about these parameters, see Dynamic Workload Console installation - dwcinst script.

In a typical installation scenario, it is recommended that you install the Dynamic Workload Console as a non-root user on UNIX systems and as a local administrator on Windows systems.

This user is automatically created by the installation process in the WebSphere Application Server Liberty Base repository. Ensure that the user has full access to the WebSphere Application Server Liberty Base installation directory.

To install the Dynamic Workload Console, perform the following steps:
  1. Generate a z/OS certificate.
  2. Export the z/OS certificate by using the RACF utility panel RACF - SERVICES OPTION MENU (options 7.1.4) to a data set that you have previously allocated. For example:
    Data Set Name . . . . : <dataset_name>   
     Space units . . . . . TRKS                                
     Primary quantity  . . 5                                      
     Secondary quantity    1                                     
     Directory blocks  . . 0                   
     Record format . . . . VB                                                     
     Record length . . . . 84                                                     
     Block size  . . . . . 27998
  3. Generate the distributed certificates on a distributed environment. Consider the following example commands:
    openssl genrsa -out ca.key 4096
    openssl req -x509 -new -nodes –key ca.key -subj "/CN=<common_name>" -days <dddd> -out ca.crt
    openssl genrsa -des3 -out tls.key 4096
    openssl req -new -key tls.key -out tls.csr
    
    openssl x509 -req -in tls.csr -CA ca.crt -CAkey ca.key
    -CAcreateserial -out tls.crt -extfile /etc/pki/tls/openssl.cnf -extensions v3_req
  4. Store the resulting ca.crt, tls.crt, and tls.key files in a folder of your choice on the workstation where you plan to install the Dynamic Workload Console.
  5. Import the certificate from the z/OS to the distributed environment in ASCII mode.
  6. Convert the certificates to the p12 format, as follows:
    1. Navigate to the folder where you stored the ca.crt, tls.key, and tls.crt files.
    2. Issue the following command:
      openssl pkcs12 -export -out TWSServerTrustFile.p12 -inkey tls.key -in tls.crt -certfile ca.crt
      You are prompted to enter the password used for generating the certificates, and verify it.
    3. Issue the following command:
      openssl pkcs12 -export -out TWSServerKeyFile.p12 -inkey tls.key -in tls.crt -certfile ca.crt
      You will be prompted to insert the same password of the creation of the certificates, and verify it.
    4. Now that you have created the databases, issue the following commands to add the z/OS certificates into them:
      keytool -importcert -keystore TWSServerTrustFile.p12 -trustcacerts -alias <alias> 
      -keypass <key_pass> -storepass <store_pass> -file /path/to/zos/certificate -storetype PKCS12 
      -keyalg RSA 
      
      keytool -importcert -keystore TWSServerKeyFile.p12 -trustcacerts -alias <alias> 
      -keypass <key_pass> -storepass <store_pass> -file /path/to/zos/certificate -storetype PKCS12 
      -keyalg RSA
      If prompted, confirm the insertion of the certificates.
    5. To display a list of all the certificates that are stored in the databases, issue the following commands:
      keytool -list -keystore TWSServerTrustFile.p12 -storetype PKCS12 -storepass <store_pass>
      keytool -list -keystore TWSServerKeyFile.p12 -storetype PKCS12 -storepass <store_pass>
  7. Import the ca.crt and tls.crt certificates from the distributed to the z/OS environment in ASCII mode and add them to a data set that you have previously allocated.
  8. Import the distributed certificate in the RING created in step 1.
  9. Transfer the certificate database created in step 6 to z/OS, as follows:
    zip -q certs.zip TWSServerKeyFile.p12 TWSServerTrustFile.p12 //to create a zip file with the certificates
    
    ftp 									     //to open ftp connection
    open <z/OS_ip_address>							//to connect to a specific mainframe ip
    <user_id>									//TSO user enabled to OMVS
    <passwd>									 //TSO password for the user enabled to OMVS
    bin										//to chose the right format for the transfer
    put certs.zip /path/to/certs/certs.zip				   //to actually transfer the zip file inside uss path
    close									    //to close the ftp connection
    quit									     //to go back to terminal
    
    From OMVS launch the following commands:
    
    cd /path/to/certs/							   //to navigate to the unzipped certs file	
    unzip -q certs.zip /path/to/certificates_unzipped		    //to unzip the files in a specific directory
  10. When running the dwcinst script, specify the path to the database with the sslkeysfolder parameter. This folder must contain two files named TWSServerKeyFile.p12 and TWSServerTrustFile.p12, in which your certificates are already stored.
  11. Start the installation specifying a typical set of parameters. Specify the user defined in step 1 in the --user parameter. Default values are used for all remaining parameters:
    On Windows operating systems
    cscript dwcinst.vbs --acceptlicense yes --rdbmstype db_type 
    --user dwc_admin_user --password dwc_pwd --dbname db_name 
    --dbuser db_user --dbpassword db_pwd --dbhostname db_hostname 
    --dbport db_port --wlpdir Liberty_installation_dir\wlp
    --sslpassword keystore_password --sslkeysfolder distributed_certificates_path
    On UNIX operating systems
    ./dwcinst.sh --acceptlicense yes --rdbmstype db_type 
    --user dwc_admin_user --password dwc_pwd --dbname db_name 
    --dbuser db_user --dbpassword db_pwd --dbhostname db_hostname 
    --dbport db_port --wlpdir Liberty_installation_dir/wlp
    --sslpassword keystore_password --sslkeysfolder distributed_certificates_path
    On z/OS operating system
    ./dwcinst.sh --acceptlicense yes --rdbmstype DB2z 
    --user non-root_user --password dwc_pwd --dbname db_name 
    --dbuser db_user --dbpassword db_pwd --dbhostname db_hostname 
    --dbport db_port --wlpdir Liberty_installation_dir/wlp
    --zlocationname zOS_location_containing_db
    --sslpassword keystore_password --sslkeysfolder distributed_certificates_path
    where:
    password
    The password of the Dynamic Workload Console user.
    sslpassword
    The keystore password.
    sslkeysfolder
    The name and path of the folder containing the distributed certificates.
  12. Stop and start WebSphere Application Server Liberty Base for the Dynamic Workload Console, as described in Installing a Dynamic Workload Consoleversion 10.2.0, or earlier.
  13. In the TCPOPTS statement of the server started task, define the following lines:
    • SSLKEYSTORETYPE(SAF)
    • SSLKEYSTORE(MDMCSTMRING)
    • SSLLEVEL(FORCE)
  14. In the connectionFactory.xml file, set useSsl="true".

For more information about all dwcinst parameters and default values, see Dynamic Workload Console installation - dwcinst script.

Installing a Dynamic Workload Consoleversion 10.2.0, or earlier

About this task

The HCL Workload Automation administrator installs the Dynamic Workload Console by running the dwcinst command. You can run the dwcinst specifying a typical set of parameters. In this case, default values are used for all remaining parameters.

Default values are stored in the dwcinst.properties file, located in the root directory of the installation image. If you need to modify any of the default values, edit the dwcinst.properties file, but do not modify the dwcinst.template file located in the same path.

You can optionally configure your environment in SSL mode, by using the sslkeysfolder and sslpassword parameters and generating automatically the certificates for each workstation in your environment. For details about these parameters, see Dynamic Workload Console installation - dwcinst script.

In a typical installation scenario, it is recommended that you install the Dynamic Workload Console as a non-root user on UNIX systems and as a local administrator on Windows systems.

This user is automatically created by the installation process in the WebSphere Application Server Liberty Base repository. Ensure that the user has full access to the WebSphere Application Server Liberty Base installation directory.

To install the Dynamic Workload Console, perform the following steps:
  1. Start the installation specifying a typical set of parameters. Specify the user defined in step 1 in the --user parameter. Default values are used for all remaining parameters:
    On Windows operating systems
    cscript dwcinst.vbs --acceptlicense yes --rdbmstype db_type 
    --user dwc_admin_user --password dwc_pwd --dbname db_name 
    --dbuser db_user --dbpassword db_pwd --dbhostname db_hostname 
    --dbport db_port --wlpdir Liberty_installation_dir\wlp
    On UNIX operating systems
    ./dwcinst.sh --acceptlicense yes --rdbmstype db_type 
    --user dwc_admin_user --password dwc_pwd --dbname db_name 
    --dbuser db_user --dbpassword db_pwd --dbhostname db_hostname 
    --dbport db_port --wlpdir Liberty_installation_dir/wlp
    On z/OS operating systems
    ./dwcinst.sh --acceptlicense yes --rdbmstype DB2z 
    --user non-root_user --password dwc_pwd --dbname db_name 
    --dbuser db_user --dbpassword db_pwd --dbhostname db_hostname 
    --dbport db_port --wlpdir Liberty_installation_dir/wlp
    --zlocationname zOS_location_containing_db
    where:
    password
    The password of the Dynamic Workload Console user.

For more information about all dwcinst parameters and default values, see Dynamic Workload Console installation - dwcinst script.