JBoss EAP Patching

jboss-cli tool comes with a command named patch. As the process is obvious, this blog will be short. Nevertheless, it is still interesting to see how it changes files and directories structure of JBoss binaries.

It’s worth noting that RedHat does not offer newer versions of JBoss EAP that come with patches pre-installed, so all new installations must be patched (at least for major versions).

Global Availability Version

In my fresh installation of JBoss-EAP, I starts jboss-cli.sh (without connecting to a server) and verify the version:

[disconnected /] version
JBoss Admin Command-line Interface
JBOSS_HOME: C:\Users\ols\Documents\Technical\JBoss\Installers\jboss-eap-7.4
Release: <connect to the controller and re-run the version command to see the release info>
JAVA_HOME: C:\Installations\jdk11.0.16_9
java.version: 11.0.16.1
java.vm.vendor: Amazon.com Inc.
java.vm.version: 11.0.16.1+9-LTS
os.name: Windows 10
os.version: 10.0

I can also confirm the patching level with command patch info:

Version:             7.4.0.GA
Cumulative patch ID: base
One-off patches:     none

Patching

Still in cli, the command is as simple as patch apply <path-to-zip>. For the example below, we will patch with jboss-eap-7.4.10-patch.zip:

[disconnected /] patch apply ../../jboss-eap-7.4.10-patch.zip
{
    "outcome" : "success",
    "result" : {}
}

Followed by a patch info to confirm the version:

Version:             7.4.10.GA
Cumulative patch ID: jboss-eap-7.4.10.CP
One-off patches:     none

It is also possible to list all patches installed with patch history:

{
    "outcome" : "success",
    "result" : [{
        "patch-id" : "jboss-eap-7.4.10.CP",
        "type" : "cumulative",
        "applied-at" : "03/04/2023 16:47",
        "aged-out" : false
    }]
}

If server is running, do not forget to restart after patching with reload.

What About Rollback?

You probably guessed it, at this point, to rollback, we must provide the patch-id:

[disconnected /] patch rollback jboss-eap-7.4.10.CP
Option: --reset-configuration is required for this command.

Wait, it did not rollback. Why? Because, we must decide if we want to keep the currently running configuration or want to rollback it at the time the patching has been done. Two options exist:

• If no configuration changes were done since patch was applied, there is no risk to rollback configuration along with binaries.
• If there were configuration changes, there is a risk for inconsistency between configuration and running modules. Testing is necessary even if the risk is low.

Impact on Directory Structure

A patch contains following files:

The XML files contain a description of what needs to be patched. Folders contain binaries and are as follow:

1. jboss-eap-7.4.10.CP contains all files that are not modules
2. layer-base-jboss-eap-7.4.10.CP contains similar structure as in modules directory of JBoss installation

Thus, when installing a patch file, it will not be applied the same way.

For modules (point 2), patching will consist of a simple copy of the folder under modules\system\layers\base\.overlays plus creation of a .overlays directory. Files under that directory will take precedence when server will start which means if this directory is altered patching might be broken.

For other binaries (point 1), patching will consist of backing up files to patch under .installation directory (keeping directory structure) at root of JBoss home directory.

Why speaking about that? Because some tools like dependency-check will continue to report component vulnerabilities after patching as either patched files are backup in .information directory or they stay in modules directory. This is the reason why the results of these types of tools must be carefully and thoroughly analyzed.