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
- 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.
- Generate a z/OS certificate.
- 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
- 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
- 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.
- Import the certificate from the z/OS to the distributed environment in ASCII mode.
- Convert the certificates to the p12 format, as
follows:
- Navigate to the folder where you stored the ca.crt, tls.key, and tls.crt files.
- Issue the following command:
You are prompted to enter the password used for generating the certificates, and verify it.openssl pkcs12 -export -out TWSServerTrustFile.p12 -inkey tls.key -in tls.crt -certfile ca.crt
- Issue the following command:
You will be prompted to insert the same password of the creation of the certificates, and verify it.openssl pkcs12 -export -out TWSServerKeyFile.p12 -inkey tls.key -in tls.crt -certfile ca.crt
- 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
If prompted, confirm the insertion of the certificates.keytool -importcert -keystore TWSServerKeyFile.p12 -trustcacerts -alias <alias> -keypass <key_pass> -storepass <store_pass> -file /path/to/zos/certificate -storetype PKCS12 -keyalg RSA
- 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>
- 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.
- Import the distributed certificate in the RING created in step 1.
- 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
- 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.
- 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
- 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.
- 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.
- In the TCPOPTS statement of the server started task, define the
following lines:
- SSLKEYSTORETYPE(SAF)
- SSLKEYSTORE(MDMCSTMRING)
- SSLLEVEL(FORCE)
- In the
connectionFactory.xml
file, setuseSsl="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.
- 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
- 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.