Installing JBoss Web Server by using the Red Hat Ansible Certified Content Collection

Procedure

1. On your Ansible control node, open the vars.yml file.

2. To specify the JBoss Web Server version that you want to install, set the jws_version variable to the appropriate base release.

   For example:

   [...]
   jws_version: 5.7.0

   Note

   Ensure that the value you specify for the jws_version variable matches the version of the product archive files that you want to install. For example, to install the archive files for JBoss Web Server 5.7, specify a value of 5.7.0.

   If you do not specify credentials for automatic file downloads as described in Step 4, ensure that you have copied the archive file for the specified product version to your Ansible control node.

3. If you also want to install the native JBoss Web Server archive for the operating system that is on your target hosts, set the jws_native variable to True.

   For example:

   [...]
   jws_native: True

   Note

   By default, the jws_native variable is set to False, which means the JBoss Web Server collection installs the main application server archive only.

   If you do not specify credentials for automatic file downloads as described in Step 4, ensure that you have copied the native archive for the specified product version to your Ansible control node. In this situation, ensure that the copied archive file matches the operating system version that is installed on your target hosts.

4. If copies of the JBoss Web Server archive files do not exist on your Ansible control, the collection contacts the Red Hat Customer Portal by default to download the archive files automatically. To ensure successful contact with the Red Hat Customer Portal, set the rhn_username and rhn_password variables to specify your Red Hat service account credentials.

   For example:

   [...]
   rhn_username: <client_ID>
   rhn_password: <client_secret>

   In the preceding example, replace <client_ID> and <client_secret> with the client ID and secret that are associated with your Red Hat service account.

   Note

   If the jws_native variable is also set to True, the collection automatically determines which native archive file matches the operating system that is installed on your target hosts. If copies of the appropriate archive files already exist on your Ansible control node, the collection does not download these archive files again.

   If you prefer to download the archive files manually or you have already obtained these files in some other way, you can enforce a fully offline installation. For more information about enforcing offline installations, see Enabling the automated installation of JBoss Web Server product patch updates.

5. If you changed the names of the downloaded archive files on your Ansible control node, set the zipfile_name and jws_native_zipfile variables to specify the files that you want to install.

   For example:

   [...]
   zipfile_name: <application_server_file>
   jws_native_zipfile: <native_file>

   In the preceding example, replace <application_server_file> and <native_file> with the appropriate archive file names.

   Note

   If you did not change the file names, you do not need to set the zipfile_name and jws_native_zipfile variables. The JBoss Web Server collection uses the value of the jws_version variable to determine the default file names automatically.

6. Save your changes to the vars.yml file.

Procedure

1. On your Ansible control node, open the vars.yml file.

2. Set the jws_apply_patches variable to True.

   For example:

   [...]
   jws_version: 5.7.0
   jws_native: True
   [...]
   jws_apply_patches: True

   Note

   Ensure that the jws_version variable is set to the base release for the appropriate product version (for example, 5.7.0).

   The JBoss Web Server collection is configured to install the latest patch update by default. The collection contacts the Red Hat Customer Portal to determine the correct patch to install.

3. If you want the collection to install a specified patch release rather than the latest patch update, set the jws_patch_version variable to the patch release that you want to install.

   For example:

   [...]
   jws_apply_patches: True
   jws_patch_version: 5.7.2

   Based on the preceding example, the collection installs the cumulative 5.7.2 patch only, even if later patches are also available.

4. When the jws_apply_patches variable is set to True, the JBoss Web Server collection contacts the Red Hat Customer Portal by default to check if new patch updates are available. The collection also downloads patch updates, if necessary. To ensure successful contact with the Red Hat Customer Portal, set the rhn_username and rhn_password variables to specify your Red Hat service account credentials.

   For example:

   [...]
   rhn_username: <client_ID>
   rhn_password: <client_secret>

   In the preceding example, replace <client_ID> and <client_secret> with the client ID and secret that are associated with your Red Hat service account.

   Note

   If the jws_native variable is also set to True, the collection automatically determines which native archive file matches the operating system that is installed on your target hosts. If copies of the appropriate archive files already exist on your Ansible control node, the collection does not download these archive files again.

   If the jws_patch_version variable is set to a specific patch release, the collection downloads the specified patch release only, even if later patches are also available.

   If you prefer to download the archive files manually or you have already obtained these files in some other way, you can enforce a fully offline installation as described in Step 5.

5. If you want to enforce a fully offline installation and prevent the collection from contacting the Red Hat Customer Portal, set the jws_offline_install variable to True.

   For example:

   [...]
   jws_offline_install: True

   Note

   The jws_offline_install variable is useful if your Ansible control node does not have internet access or you want the collection to avoid contacting the Red Hat Customer Portal for file downloads. In this situation, you must set the jws_patch_version variable to the patch release you want to install.

   Ensure that you have copied the archive file for the appropriate patch update to your Ansible control node. If the jws_native variable is set to True, ensure that a copy of the native archive file for the patch update also exists on the control node. Also ensure that the copied native archive file matches the operating system version that is installed on your target hosts.

   If you set the jws_offline_install variable to True, the collection does not attempt to contact the Red Hat Customer Portal, even if you have also set the rhn_username and rhn_password variables to permit automatic file downloads.

6. Save your changes to the vars.yml file.

Procedure

1. If you want to create a Java keystore, perform the following steps:

   1. Log in to the target host where you want to create the keystore.

      Note

      Ensure that a JDK is already installed and the JAVA_HOME variable is already set on the target host.

   2. To create the keystore, enter the following command:

      $JAVA_HOME/bin/keytool -genkeypair -alias tomcat -keyalg RSA -keystore <path_to_keystore>

      In the preceding command, replace <path_to_keystore> with the full path to the keystore file that you want to create. If you do not specify the -keystore option, the command creates the keystore file in some default location that depends on the version of the JDK you have installed. For example, if you are using Red Hat build of OpenJDK, the default location for the keystore is /etc/ssl/keystore.jks.

      The preceding command generates a keystore file that contains a pair of public and private keys and a single self-signed certificate for server authentication. The key pair and self-signed certificate are stored in a single keystore entry that is identified by the -alias option (for example, tomcat).

   3. When the keytool command prompts you for the following information, enter the appropriate values for your setup:

      • Keystore password (by default, changeit)
      • General information about the certificate
      • Key password for the certificate (by default, the keystore password)
   Note

   Alternatively, rather than create a new keystore, you can use the Linux scp command to copy an existing keystore file between different hosts.

2. To enable support for HTTPS connections, perform the following steps:

   1. On your Ansible control node, open the vars.yml file.

   2. Set the jws_listen_https_enabled variable to True.

      For example:

      [...]
      jws_listen_https_enabled: True

   3. If the Java keystore on each target host is located in a path other than /etc/ssl/keystore.jks, set the jws_listen_https_keystore_file variable to the appropriate value.

      For example:

      [...]
      jws_listen_https_keystore_file: <keystore_path>

      In the preceding example, replace <keystore_path> with the full path to the keystore file that is on each target host.

      Note

      If you do not set the jws_listen_https_keystore_file variable, the JBoss Web Server collection automatically configures the certificateKeystoreFile setting in the server.xml file with a value of /etc/ssl/keystore.jks.

   4. If the Java keystore on each target host uses a password other than changeit, set the jws_listen_https_keystore_password variable to the appropriate value.

      For example:

      [...]
      jws_listen_https_keystore_password: <keystore_password>

      In the preceding example, replace <keystore_password> with the correct password for the Java keystore that is on each target host.

      Note

      If you do not set the jws_listen_https_keystore_password variable, the JBoss Web Server collection automatically configures the certificateKeystorePassword setting in the server.xml with a value of changeit.

   5. Save your changes to the vars.yml file.

Procedure

1. On your Ansible control node, open the vars.yml file.

2. To enable the mod_cluster listener, set the jws_modcluster_enabled variable to True.

   For example:

   [...]
   jws_modcluster_enabled: True

3. To specify the IP address and port of the mod_cluster instance, set the jws_modcluster_ip and jws_modcluster_port variables to the appropriate values. The default IP address is 127.0.0.1. The default port is 6666.

   For example:

   [...]
   jws_modcluster_ip: <ip_address>
   jws_modcluster_port: <port>

   In the preceding example, replace <ip_address> with the appropriate bind address for the mod_cluster instance on the target host, and replace <port> with the appropriate port that the mod_cluster instance uses to listen for incoming requests.

4. Save your changes to the vars.yml file.

Procedure

1. On your Ansible control node, open the vars.yml file.

2. To specify the paths to the vault.keystore, VAULT.dat, and vault.properties files that you created as part of the prerequisite step, set the following variables to the appropriate values.

   For example:

   [...]
   jws_vault_name: ./vault_files/vault.keystore
   jws_vault_data: ./vault_files/VAULT.dat
   jws_vault_properties: ./vault_files/vault.properties

1. To enable the password vault feature, set the jws_tomcat_vault_enabled variable to True.

   For example:

   [...]
   jws_tomcat_vault_enabled: True

2. To specify the keystore alias, keystore password, iteration count, and salt values that you configured for the password vault, set the following variables to the appropriate values.

   For example:

   [...]
   jws_tomcat_vault_alias: <keystore_alias>
   jws_tomcat_vault_storepass: <keystore_password>
   jws_tomcat_vault_iteration: <iteration_count>
   jws_tomcat_vault_salt: <salt>

   In the preceding example, ensure that you specify the appropriate values that you configured as part of the prerequisite step.

3. Save your changes to the vars.yml file.