Red Hat JBoss Enterprise Application Platform Administration I

Instructions

1. Create an identity.jks Java keystore (JKS), by importing the servera.p12 and serverb.p12 certificates that the exercise provides.

   Then, copy the identity.jks file to the /opt/keystore directory on the servera and serverb machines. The keystore must have the following configuration:

   Field	Value
   srckeystore	servera.p12 or serverb.p12
   srcstoretype	PKCS12
   destkeystore	identity.jks
   deststoretype	JKS
   alias	1
   destalias	servera-identity or serverb-identity
   Destination keystore password	password
   Source keystore password	password

   1. On the worktation machine, open a new terminal window and change to the /home/student/AD248/labs/web-review/ directory:

      [student@worktation ~]$ cd /home/student/AD248/labs/web-review/

   2. Create the keystore by importing the servera.lab.example.com.p12 certificate file. Use the password value as the destination and source keystore passwords.

      [student@worktation web-review]$ keytool -v -importkeystore \
      -srckeystore servera.p12 -srcstoretype PKCS12 \
      -destkeystore identity.jks -deststoretype JKS \
      -alias 1 -destalias servera-identity
      Importing keystore servera.p12 to identity.jks...
      Enter destination keystore password:
      Re-enter new password:
      Enter source keystore password:
      [Storing identity.jks]
      
      Warning:
      The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore identity.jks -destkeystore identity.jks -deststoretype pkcs12".

      Note

      You can safely ignore the warning about the JKS format.

   3. Verify that the certificate is available in the identity.jks keystore:

      [student@servera web-review]$ keytool -list -v -keystore identity.jks
      Enter keystore password:
      Keystore type: JKS
      Keystore provider: SUN
      
      Your keystore contains 1 entry
      
      Alias name: servera-identity
      Creation date: Oct 24, 2023
      Entry type: PrivateKeyEntry
      Certificate chain length: 1
      Certificate[1]:
      Owner: CN=servera.lab.example.com, O=EXAMPLE.COM
      Issuer: CN=Red Hat Training Certificate Authority, O=EXAMPLE.COM
      ...output omitted...

   4. Add the serverb.lab.example.com.p12 certificate file to the identity.jks keystore. Use the password value as the destination and source keystore passwords.

      [student@worktation web-review]$ keytool -v -importkeystore \
      -srckeystore serverb.p12 -srcstoretype PKCS12 \
      -destkeystore identity.jks -deststoretype JKS \
      -alias 1 -destalias serverb-identity
      Importing keystore /home/student/serverb.p12 to identity.jks...
      Enter destination keystore password:
      Enter source keystore password:
      [Storing identity.jks]
      
      Warning:
      The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore identity.jks -destkeystore identity.jks -deststoretype pkcs12".

   5. Copy the keystore from workstation to servera and serverb machines. Use the jboss user to copy the identity.jks file to the /opt/keystore directory in both machines.

      [student@worktation web-review]$ scp identity.jks jboss@servera:/opt/keystore
      Warning: Permanently added 'servera' (ED25519) to the list of known hosts.
      identity.jks
      [student@worktation web-review]$ scp identity.jks jboss@serverb:/opt/keystore
      Warning: Permanently added 'serverb' (ED25519) to the list of known hosts.
      identity.jks

   Hide Solution

2. Start the domain controller.

   Use /opt/domain as the jboss.domain.base.dir value. The host file for the domain controller is called host-master.xml. Note that the jboss user owns the /opt/domain directory. Therefore, you must start the domain controller by using the jboss user.

   [student@workstation web-review]$ cd /opt/jboss-eap-7.4/bin
   [student@workstation bin]$ sudo -u jboss ./domain.sh \
   -Djboss.domain.base.dir=/opt/domain/ --host-config=host-master.xml

   Hide Solution

3. Start the host controllers on the servera and the serverb machines.

   Use /opt/domain as the jboss.domain.base.dir value. The host file for the host controllers is host-slave.xml. Note that the jboss user owns the /opt/domain directory. Therefore, you must start the host controller by using the jboss user.

   Note

   You can safely ignore the following output:

   WARNING: An illegal reflective access operation has occurred
   WARNING: Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions (jar:file:/opt/jboss-eap-7.4/modules/system/layers/base/.overlays/layer-base-jboss-eap-7.4.11.CP/org/wildfly/extension/elytron/main/wildfly-elytron-integration-15.0.26.Final-redhat-00001.jar!/) to method com.sun.net.ssl.internal.ssl.Provider.isFIPS()
   WARNING: Please consider reporting this to the maintainers of org.wildfly.extension.elytron.SSLDefinitions
   WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
   WARNING: All illegal access operations will be denied in a future release

   For more information, refer to https://access.redhat.com/solutions/4996491.

   1. Start the host controller on the servera machine.

      Open a new terminal window on the workstation machine and run the following command:

      [student@workstation ~]$ ssh -t jboss@servera /opt/jboss-eap-7.4/bin/domain.sh \
      -Djboss.domain.base.dir=/opt/domain/ \
      -Djboss.domain.master.address=172.25.250.9 \
      --host-config=host-slave.xml

      Note the use of the -t option for the ssh command to allocate a pseudo-terminal. You must use this option to properly propagate the signals that Ctrl+C sends to the remote machine.

      Hide Solution

   2. Start the host controller on the serverb machine.

      Open a new terminal window on the workstation machine and run the following command:

      [student@workstation ~]$ ssh -t jboss@serverb /opt/jboss-eap-7.4/bin/domain.sh \
      -Djboss.domain.base.dir=/opt/domain/ \
      -Djboss.domain.master.address=172.25.250.9 \
      --host-config=host-slave.xml

      Note the use of the -t option for the ssh command to allocate a pseudo-terminal. You must use this option to properly propagate the signals that Ctrl+C sends to the remote machine.

      Hide Solution

   3. Verify that both host controllers connect to the domain controller and form a managed domain.

      Inspect the console window where you started the domain controller and verify that both servera and serverb are registered as secondary controllers.

      [Host Controller] 03:28:53,434 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.4.11.GA (WildFly Core 15.0.26.Final-redhat-00001) (Host Controller) started in 3622ms - Started 80 of 81 services (22 services are lazy, passive or on-demand)
      [Host Controller] 03:29:12,302 INFO  [org.jboss.as.domain.controller] (Host Controller Service Threads - 37) WFLYHC0019: Registered remote slave host "servera", JBoss JBoss EAP 7.4.11.GA (WildFly 15.0.26.Final-redhat-00001)
      [Host Controller] 03:29:47,951 INFO  [org.jboss.as.domain.controller] (Host Controller Service Threads - 37) WFLYHC0019: Registered remote slave host "serverb", JBoss JBoss EAP 7.4.11.GA (WildFly 15.0.26.Final-redhat-00001)

      Hide Solution

4. Create the HTTPS connection configuration.

   1. Configure the HTTPS connection by modifying the https listener in the undertow subsystem. To configure this listener, you must create a security realm to store the CA signed certificates information.

      In the management section of each host controller configuration file, create a HTTPSRealm security realm.

      In a new terminal window on the workstation machine, start the management CLI and connect to the domain controller as the jboss user:

      [student@workstation ~]$ sudo -u jboss \
      /opt/jboss-eap-7.4/bin/jboss-cli.sh \
      --connect --controller=172.25.250.9:9990

      Add a HTTPSRealm security realm on the servera host:

      [domain@172.25.250.9:9990 /] /host=servera/core-service=\
      management/security-realm=HTTPSRealm:add()
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {
              "Group1" => {"host" => {"servera" => {"servera.1" => {"response" => {"outcome" => "success"}}}}},
              "Group2" => {"host" => {"servera" => {"servera.2" => {"response" => {"outcome" => "success"}}}}}
          }
      }

      Add a HTTPSRealm security realm on the serverb host:

      [domain@172.25.250.9:9990 /] /host=serverb/core-service=\
      management/security-realm=HTTPSRealm:add()
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {
              "Group1" => {"host" => {"serverb" => {"serverb.1" => {"response" => {"outcome" => "success"}}}}},
              "Group2" => {"host" => {"serverb" => {"serverb.2" => {"response" => {"outcome" => "success"}}}}}
          }
      }

      Hide Solution

   2. Configure the realm to load the /opt/keystore/identity.jks keystore file. Use the password value as the password. Also, set the alias to servera-identity for the servera host controller, and to serverb-identity for the serverb controller.

      Configure the HTTPSRealm realm for loading the identity.jks keystore on the servera host:

      [domain@172.25.250.9:9990 /] /host=servera/core-service=\
      management/security-realm=HTTPSRealm/server-identity=\
      ssl:add(keystore-path=/opt/keystore/identity.jks, \
      keystore-password=password, alias=servera-identity)
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {
      ...output omitted...
          "response-headers" => {"process-state" => "reload-required"}
      }

      Configure the HTTPSRealm realm to load the identity.jks keystore on the serverb host:

      [domain@172.25.250.9:9990 /] /host=serverb/core-service=\
      management/security-realm=HTTPSRealm/server-identity=\
      ssl:add(keystore-path=/opt/keystore/identity.jks, \
      keystore-password=password, alias=serverb-identity)
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {
      ...output omitted...
          "response-headers" => {"process-state" => "reload-required"}
      }

      Hide Solution

   3. Reload all the host controllers to enable the realm.

      [domain@172.25.250.9:9990 /] /host=servera:reload
      {
          "outcome" => "success",
          "result" => undefined
      }

      Reload the servera host to enable the realm:

      Reload the serverb host to enable the realm:

      [domain@172.25.250.9:9990 /] /host=serverb:reload
      {
          "outcome" => "success",
          "result" => undefined
      }

      Hide Solution

5. Configure the HTTPS listener

   The HTTPS listener is responsible for enabling the HTTPS protocol in the undertow subsystem. All the server groups are running using the full profile. The full profile uses an HTTPS connector with a self-signed certificate, which the ApplicationRealm security realm references.

   Modify the HTTPS listener to use the HTTPSRealm.

   1. Reload the host controllers to enable the realm.

      [domain@172.25.250.9:9990 /] /host=servera:reload
      {
          "outcome" => "success",
          "result" => undefined
      }
      [domain@172.25.250.9:9990 /] /host=serverb:reload
      {
          "outcome" => "success",
          "result" => undefined
      }

   2. Verify that you can access the root application at https://servera.lab.example.com:8443 and https://serverb.lab.example.com:8443.

   [domain@172.25.250.254:9990 /] /profile=full/subsystem=undertow/server=\
   default-server/https-listener=https:\
   write-attribute(name=security-realm, value=HTTPSRealm)
   {
       "outcome" => "success",
       "result" => undefined,
       "server-groups" => {
           "Group1" => {"host" => {
               "servera" => {"servera.1" => {"response" => {
                   "outcome" => "success",
                   "result" => undefined,
                   "response-headers" => {
                       "operation-requires-reload" => true,
                       "process-state" => "reload-required"
                   }
               }}},
               "serverb" => {"serverb.1" => {"response" => {
                   "outcome" => "success",
                   "result" => undefined,
                   "response-headers" => {
                       "operation-requires-reload" => true,
                       "process-state" => "reload-required"
                   }
               }}}
           }},
           "Group2" => {"host" => {
               "servera" => {"servera.2" => {"response" => {
                   "outcome" => "success",
                   "result" => undefined,
                   "response-headers" => {
                       "operation-requires-reload" => true,
                       "process-state" => "reload-required"
                   }
               }}},
               "serverb" => {"serverb.2" => {"response" => {
                   "outcome" => "success",
                   "result" => undefined,
                   "response-headers" => {
                       "operation-requires-reload" => true,
                       "process-state" => "reload-required"
                   }
               }}}
           }}
       }
   }

   Hide Solution

6. Tune the HTTPS listener

   By default, the maximum connections number has no limits. To avoid excessive compute resources usage, set the maximum connections to 150 in the undertow subsystem for the full profile.

   1. Set the maximum possible connections:

      [domain@172.25.250.9:9990 /] /profile=full/subsystem=undertow/server=\
      default-server/https-listener=https:\
      write-attribute(name=max-connections, value=150)
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {
              "Group1" => {"host" => {
                  "servera" => {"servera.1" => {"response" => {
                      "outcome" => "success",
                      "result" => undefined,
                      "response-headers" => {
                          "operation-requires-reload" => true,
                          "process-state" => "reload-required"
                      }
                  }}},
      ...output omitted...
      }

   2. Reload the servers to enable the new value of maximum connections:

      [domain@172.25.250.9:9990 /] /:reload-servers
      {
          "outcome" => "success",
      ...output omitted...
      }

   3. Verify that the max-connections attribute is set to 150:

      [domain@172.25.250.9:9990 /] /profile=full/subsystem=undertow/server=\
      default-server/https-listener=https:\
      read-attribute(name=max-connections)
      {
          "outcome" => "success",
          "result" => 150
      }

   Hide Solution

7. Deploy the kitchensink.war application.

   Deploy the kitchensink.war application to the Group1 server group. Verify that you can use the application with the HTTP and the HTTPS protocols at:

   • http://servera.lab.example.com:8080/kitchensink

   • http://serverb.lab.example.com:8080/kitchensink

   • https://servera.lab.example.com:8443/kitchensink

   • https://serverb.lab.example.com:8443/kitchensink

   1. Deploy the application:

      [domain@172.25.250.254:9990 /] deploy \
      /tmp/kitchensink.war \
      --server-groups=Group1
      [domain@172.25.250.254:9990 /]

   2. Verify that you can use the kitchensink application by using the provided URLs.

   Hide Solution

8. Set the kitchensink application as the root application.

   By default, the root application is the JBoss welcome application. Replace the root application by changing the default-web-module attribute from the default-host host.

   1. Replace the root application:

      [domain@172.25.250.9:9990 /] /profile=full/subsystem=undertow/server=\
      default-server/host=default-host:write-attribute(name=\
      default-web-module,value=kitchensink.war)
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {
              "Group1" => {"host" => {
                  "servera" => {"servera.1" => {"response" => {
                      "outcome" => "success",
                      "result" => undefined,
                      "response-headers" => {
                          "operation-requires-reload" => true,
                          "process-state" => "reload-required"
      ...output omitted...
      }

   2. Reload the servers to enable the new root application:

      [domain@172.25.250.9:9990 /] /:reload-servers
      {
          "outcome" => "success",
      ...output omitted...
      }

   3. Test the root application using one of the following URLs:

      • http://servera.lab.example.com:8080

      • http://serverb.lab.example.com:8080

      • https://servera.lab.example.com:8443

      • https://serverb.lab.example.com:8443

      Note

      If the kitchensink application is not displayed, try to clean the browser cache and refresh the page.

   Hide Solution

9. Clean up.

   1. Exit from the CLI:

      [domain@172.25.250.9:9990 /] exit

   2. Press Ctrl+C to stop the domain and host controllers in all opened terminals.