EAP Patching: Difference between revisions
| (13 intermediate revisions by the same user not shown) | |||
| Line 18: | Line 18: | ||
Patching with zip files and patching with RPMs is incompatible, the same method should be used for subsequent patches. | 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 | After a patch is applied, the patched JARs are loaded by the server from: | ||
<pre> | <pre> | ||
| Line 34: | Line 34: | ||
=Patching in Domain Mode= | =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. | 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: | ||
<pre> | |||
[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"} | |||
} | |||
</pre> | |||
In order to verify the outcome, use [[#patch_in_Domain_Mode|patch info in domain mode]]. | |||
=Procedure= | =Procedure= | ||
| Line 78: | Line 97: | ||
[standalone@localhost:9999 /] reload | [standalone@localhost:9999 /] reload | ||
</pre> | </pre> | ||
==What if a Previous Update Has Been Applied?== | |||
<font color=red>TODO Procedure if an older update has been applied (06) and I want to patch to 08?</font> | |||
=Verifying that Patches Have Been Applied= | =Verifying that Patches Have Been Applied= | ||
==The patch Command== | |||
<pre> | |||
[standalone@localhost:9999 /] patch info | |||
</pre> | |||
===patch in Domain Mode=== | |||
<pre> | |||
[domain@1.2.3.4:9990 /] patch --host=pc1 info | |||
</pre> | |||
==Filesystem Inspection== | |||
Check <tt>$JBOSS_HOME/modules/system/layers/base/.overlays</tt>. All cumulative patches should be listed there: | |||
<pre> | |||
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 | |||
</pre> | |||
Also, the patching mechanism seems to be reliably updating <tt>$JBOSS_HOME/version.txt</tt> file, so the file can be used for a quick test. | |||
=Clearing Patch History= | =Clearing Patch History= | ||
| Line 89: | Line 142: | ||
/core-service=patching:ageout-history | /core-service=patching:ageout-history | ||
</pre> | </pre> | ||
More details: | |||
<blockquote style="background-color: AliceBlue; border: solid thin LightSteelBlue;"> | |||
:JBoss EAP Footprint too Large after Applying an Update https://access.redhat.com/solutions/1269123<br> | |||
</blockquote> | |||
=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 <tt>$JBOSS_HOME/modules/system/layers/base/<module-path></tt>. | |||
Patching process creates an <tt>$JBOSS_HOME/modules/system/layers/base/.overlays</tt> 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 <tt>org.jgroups</tt> module on an unpatched instance is <tt>$JBOSS_HOME/modules/system/layers/base/org/jgroups/main</tt>. The location of the same module on a patched instance is <tt>$JBOSS_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.6.CP/org/jgroups/main</tt>. | |||
Latest revision as of 18:59, 19 January 2017
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
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.