EAP Patching

External

• Patching a ZIP/Installer Installation https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.4/html/Installation_Guide/sect-Patching_JBoss_EAP_6.html#sect-Patching_a_ZipInstaller_Installation

Internal

• WildFly Operations
• WildFly Versioning

Relevance

• EAP 6.4

Overview

Patches are distributed as zip files or RPMs (for a subset of products).

Patching with zip files and patching with RPMs is incompatible, the same method should be used for subsequent patches.

After a patch is applied, the patched JARs are loaded by the server from:

$JBOSS_HOME/modules/system/layers/base/.overlays/$PATCH_ID/$MODULE

while the original files are left in

$JBOSS_HOME/modules/system/layers/base/$MODULE

The patching mechanism renders the original JAR files unusable, for security reasons. If the patch is rolled back, the original files will be reverted to an usable state.

Patching in Domain Mode

The patch management system cannot be used to automatically patch server instances across a managed domain: individual server instances in the managed domain must be patched independently. However, the patch command can be applied individually for each managed host from the domain controller:

[domain@1.2.3.4:9990 /] patch --host=pc1 apply /home/ec2-user/ovidiu/jdg-555tmp.zip
{
    "outcome" : "success",
    "result" : null,
    "server-groups" : null,
    "response-headers" : {"process-state" : "restart-required"}
}
[domain@1.2.3.4:9990 /] patch --host=pc2 apply /home/ec2-user/ovidiu/jdg-555tmp.zip
{
    "outcome" : "success",
    "result" : null,
    "server-groups" : null,
    "response-headers" : {"process-state" : "restart-required"}
}

In order to verify the outcome, use patch info in domain mode.

Procedure

From CLI:

patch apply /path/to/patch.zip
shutdown --restart=true

Applying Bundled Patches (Updates)

CSP publishes periodically "updates" (example: "Red Hat JBoss Enterprise Application Platform 6.4 Update 06"), which are collections of cumulative patches ZIPs. For example, "Red Hat JBoss Enterprise Application Platform 6.4 Update 06" contains the following:

NOMBP2:archive ovidiu$ unzip -l jboss-eap-6.4.6-patch.zip
Archive:  jboss-eap-6.4.6-patch.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
 81612821  01-12-16 15:59   jboss-eap-6.4.5.CP.zip
 89218386  01-12-16 15:59   jboss-eap-6.4.2.CP.zip
 53889569  01-12-16 15:59   jboss-eap-6.4.6.CP.zip
 35954575  01-12-16 15:59   jboss-eap-6.4.1.CP.zip
      470  01-12-16 15:59   patches.xml
 79994187  01-12-16 15:59   jboss-eap-6.4.4.CP.zip
 79766732  01-12-16 15:59   jboss-eap-6.4.3.CP.zip
 --------                   -------
420436740                   7 files

Those updates can be applied using the "patch" CLI command, as well:

[standalone@localhost:9999 /] patch apply /Users/ovidiu/archive/jboss-eap-6.4.6-patch.zip
{
    "outcome" : "success",
    "response-headers" : {
        "operation-requires-restart" : true,
        "process-state" : "restart-required"
    }
}
[standalone@localhost:9999 /] reload

What if a Previous Update Has Been Applied?

TODO Procedure if an older update has been applied (06) and I want to patch to 08?

Verifying that Patches Have Been Applied

The patch Command

[standalone@localhost:9999 /] patch info

patch in Domain Mode

[domain@1.2.3.4:9990 /] patch --host=pc1 info

Filesystem Inspection

Check $JBOSS_HOME/modules/system/layers/base/.overlays. All cumulative patches should be listed there:

NOMBP2:.overlays ovidiu$ pwd
/Users/ovidiu/runtime/jboss-eap-6.4/modules/system/layers/base/.overlays
NOMBP2:.overlays ovidiu$ ls -l
total 0
drwxr-xr-x  3 ovidiu  staff  102 Jun  1 09:10 layer-base-jboss-eap-6.4.1.CP
drwxr-xr-x  4 ovidiu  staff  136 Jun  1 09:10 layer-base-jboss-eap-6.4.2.CP
drwxr-xr-x  4 ovidiu  staff  136 Jun  1 09:10 layer-base-jboss-eap-6.4.3.CP
drwxr-xr-x  5 ovidiu  staff  170 Jun  1 09:10 layer-base-jboss-eap-6.4.4.CP
drwxr-xr-x  5 ovidiu  staff  170 Jun  1 09:10 layer-base-jboss-eap-6.4.5.CP
drwxr-xr-x  5 ovidiu  staff  170 Jun  1 09:10 layer-base-jboss-eap-6.4.6.CP

Also, the patching mechanism seems to be reliably updating $JBOSS_HOME/version.txt file, so the file can be used for a quick test.

Clearing Patch History

From CLI:

/core-service=patching:ageout-history

More details:

JBoss EAP Footprint too Large after Applying an Update https://access.redhat.com/solutions/1269123

Interacting with a Module that Has Been Patched

The module deployment descriptors and resource JARs for an instance that has not been patched are located under $JBOSS_HOME/modules/system/layers/base/<module-path>.

Patching process creates an $JBOSS_HOME/modules/system/layers/base/.overlays directory that contains the deployment descriptors and resources for the modules that have been patched. Those files take precedence, so if you want to modify the configuration of a module on a parched EAP instance, the "patch" location should be checked first.

For example, the location of the org.jgroups module on an unpatched instance is $JBOSS_HOME/modules/system/layers/base/org/jgroups/main. The location of the same module on a patched instance is $JBOSS_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.6.CP/org/jgroups/main.