EAP Patching: Difference between revisions
No edit summary |
|||
| (27 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=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= | =Internal= | ||
* [[WildFly Operations#Subjects|WildFly Operations]] | * [[WildFly Operations#Subjects|WildFly Operations]] | ||
* [[ | * [[WildFly Versioning]] | ||
=Relevance= | =Relevance= | ||
| Line 13: | Line 17: | ||
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 loaded by the server from: | |||
<pre> | |||
$JBOSS_HOME/modules/system/layers/base/.overlays/$PATCH_ID/$MODULE | |||
</pre> | |||
while the original files are left in | |||
<pre> | |||
$JBOSS_HOME/modules/system/layers/base/$MODULE | |||
</pre> | |||
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: | |||
<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= | |||
From CLI: | |||
<pre> | |||
patch apply /path/to/patch.zip | |||
shutdown --restart=true | |||
</pre> | |||
==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: | |||
<pre> | |||
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 | |||
</pre> | |||
Those updates can be applied using the "patch" CLI command, as well: | |||
<pre> | |||
[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 | |||
</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= | |||
==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= | |||
From CLI: | |||
<pre> | |||
/core-service=patching:ageout-history | |||
</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.