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 among the versions 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.
Note: If you are installing the Dynamic Workload Console version 10.2.3 or later, the Federator is also automatically installed. This component enables you to monitor your objects through the Orchestration Monitor page of the Dynamic Workload Console. For detailed information about how to configure and use the Federator, see Mirroring the z/OS current plan to enable the Orchestration Monitor.
.
Dynamic Workload Console version 10.2.0, or earlier
SSL configuration is optional. For more information, see Installing Dynamic Workload Console version 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.

To install the Dynamic Workload Console, perform the following steps:
  1. Generate a z/OS certificate.
    Note: The owner of the SAF key ring (that is, the user ID who runs the EQQINCRT sample JCL located in SEQQSAMP ) must be the same user who runs the controller and server started tasks.
  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 as follows.
    If the certification authority (CA) does not exist
    Run the following 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
    If the certification authority (CA) already exists
    1. Run the following command to generate the private key and unsigned certificate:
      • openssl genrsa -des3 -out tls.key 4096
      • openssl req -new –key tls.key -out tls.csr
    2. Send the tls.csr file to your certificate administrator to have it signed with your CA and be resent to you.

    The ca.crt, tls.crt, and tls.key files are now ready for use.

  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:
    user
    The administrator of the Dynamic Workload Console. This user is added to the group of the Dynamic Workload Console administrators at installation time. You can use this account to log in to the Dynamic Workload Console and manage your environment.
    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 Starting and stopping the WebSphere Application Server Liberty Base.
  13. In the TCPOPTS statement of the server started task, set the following parameters:
    • 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 Dynamic Workload Console version 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 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
    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.