|
Problem(Abstract) |
When the updateInstaller throws errors which indicate that
a WebSphere Application Server fix pack could be corrupt, it is important
to check the integrity of the fix pack. This document describes a method
of testing the integrity of a fix pack file using tools which should be
available on a WebSphere Application Server system. |
|
Symptom |
Installing a corrupt fix pack file using the
updateInstaller utility can cause unpredictable behavior. Frequently, a
corrupt fix pack file will cause the updateInstaller to throw an error
which says, "Detected corrupt fix pack data. Please try again." In other
circumstances, the updateInstaller will attempt to install the corrupt fix
pack, but then it will fail at some point during the process with a
"ZipException" error. |
|
Cause |
Purpose of this document
In circumstances where the integrity of a fix pack file is questionable,
the simplest solution is to download a new copy of the fix pack from the
appropriate IBM support site. Presumably, a fresh copy of that fix pack
file would not be corrupt when downloaded directly from IBM. This is a
simple solution, but downloading a new copy of the fix pack may not be a
straightforward or fast process in secure lab environments or
geographically dispersed environments. In such cases, clients may need
supporting evidence to guarantee that downloading a new copy of the fix
pack will help improve the situation. The purpose of this document is to
provide a method of producing that evidence by testing the integrity of
the fix pack file.
There are multiple methods which determine whether or not the fix pack
file is actually corrupt. Using utilities such as "md5sum" to compare the
content of a fix pack file with a "known good" copy of the fix pack file
is one way of accomplishing this; however, such methods require that both
the md5sum utility and a "known good" copy of the file are locally
accessible. This is not always the case. This is why this document
describes one particular method of verification. This method should always
be available on systems which use WebSphere Application Server
products. |
|
Resolving the
problem |
Part 1: Test integrity of fix pack archive
If possible, verify that the fix pack archive is intact by following this
procedure:
- When transferring the fix pack archive between systems via FTP, be
sure to use binary mode, not ASCII mode.
Also, do not transfer the individual files from within the archive.
Transfer the original entire archive file via binary FTP to the target
system.
- After downloading the fix pack archive, compare the byte size of the
downloaded fix pack archive with the byte size listed on the download page
for that package on the IBM support site.
- Extracting the content of the fix pack archive only on the
target system which will receive the fix pack.
This is important because it avoids problems introduced by transferring
extracted fix pack content between multiple systems, such as lost file
permissions, lost symbolic links, and files truncated or corrupted by
network issues.
- Ensure that the extraction utility responsible for processing the
archive file does not report any errors during the process.
Note: This document makes use of the terms "fix pack archive" and
"fix pack deliverable", which represent two different things. A "fix pack
archive" is the package downloaded from the IBM support site. A "fix pack
deliverable" is the .jar file contained by the fix pack archive, and is
processed by the updateInstaller in order to deliver the fix pack. For a
more detailed explanation, see the "Terminology" section below.
Part 2: Test integrity of fix pack deliverable (JAR file)
If the fix pack archive is delivered in the form of a .tar file, it
is possible for the extraction process to produce corrupt data but not
report errors, which means that the procedure outlined in Part 2 is valid
but not sufficient. Also, if the fix pack archive has already been
extracted to the target system, then it may not be possible to use the
procedure outlined in Part One. For such reasons, following this secondary
procedure is also recommended.
Summary of Part 2
In order to test the integrity of the fix pack deliverable, expand the
content of the .jar file. Expanding the file will automatically check the
integrity of the content. If the .jar file is corrupt, then errors are
reported during the expansion process. If the expansion process does not
report errors, then the fix pack deliverable is not corrupt.
Once this process is complete, delete the content produced by expanding
the fix pack deliverable. The updateInstaller does not recognize the
expanded content, so there is no reason to preserve that content.
Detailed steps for Part 2
These steps provide a detailed explanation of the recommended procedure to
expand the content of the fix pack deliverable:
- Source the WebSphere product's setupCmdLine.sh utility to set
the correct environment:
Unix:
cd install_root/bin
. ./setupCmdLine.sh
The "dot space" preceding
./setupCmdLine.sh is very important.
Windows:
Execute all these commands in a single
command prompt session.
cd install_root\bin
setupCmdLine.bat
|
Note: install_root is the installation location of the product
targeted for fix pack installation.
|
- Change directories to the location of the fix pack deliverable:
Unix:
cd
install_root/update/fixpacks
Windows:
cd install_root\update\fixpacks
|
Note: This example assumes that the fix pack archive was extracted to
the install_root /update directory. If the fix pack archive was
extracted to a different location, then change to the fixpacks
subdirectory in that location.
|
- Make a temporary directory and change to it:
Unix:
mkdir test
cd test
Windows:
md test
cd test
|
|
- Expand the fix pack deliverable content into the temporary directory
created in the previous step:
Unix:
jar xvf ../fix_pack_name.jar
Windows:
jar xvf ..\fix_pack_name.jar
|
Substitute the fix_pack_name with the appropriate fix pack file
name. For example:
jar xvf ../was50_fp2_aix.jar
jar xvf ..\was502_cf3_windows.jar
|
- Verify that no errors occurred in the output of the jar command.
If no errors occurred, then the fix pack deliverable is not corrupt. If
any errors occurred, then the fix pack deliverable is corrupt, and it is
definitely necessary to obtain a new copy of that fix pack deliverable.
- Delete the temporary directory:
Unix:
cd ..
pwd
Verify that the current directory is "fixpacks", then execute the command
below.
rm -r test
Windows:
cd ..
cd
Verify that the current directory is
"fixpacks", then execute the command below.
rmdir /s test
|
Use the "rm" or "rmdir /s" commands with care! These commands will wipe
out the content of an entire directory hierarchy.
|
Other methods are available
Archive expansion utilities capable of processing .jar files, such as
WinZip, can also be used to verify the integrity of an archive. However,
this document describes the "jar" method because this utility should be
present on any system which uses WebSphere Application Server V5.x
products. Other methods of verification are available, but those methods
are outside the scope of this document.
Terminology
This supplemental section describes the distinction between the terms "fix
pack archive" and "fix pack deliverable".
A "fix pack archive":
- refers to the single file which is downloaded from the IBM
support site.
- contains two major components: a version of the
updateInstaller software, and one or more "fix pack deliverables".
- contains the "fix pack deliverables" in the "fixpacks"
subdirectory within the archive.
- may be distributed in the form of a .zip, .tar, or .tar.gz
file, depending on the operating system it applies to.
- must be processed using the appropriate extraction utility
(for example, tar, gunzip, or WinZip) before it can be used.
A "fix pack deliverable":
- refers to the fix pack file which the updateInstaller uses
to deliver the actual fix pack data.
- is always a .jar file.
- is contained in the "fixpacks" subdirectory of a "fix pack
archive" downloaded from the IBM support site.
- is the file used by the updateInstaller to deliver the fix
pack data to the targeted product.
- should not be expanded for use with the updateInstaller.
For example, do not use the "jar xvf" command on the fix pack deliverable
and then instruct the updateInstaller to process the expanded content. An
expanded fix pack deliverable is not recognized by the updateInstaller.
Conclusion
The procedures described in this document provide a means for determining
whether or not a fix pack deliverable is corrupt. If a fix pack
deliverable is corrupt, then it is absolutely necessary to obtain a new
copy of that file before any attempts are made to install the fix
pack. |
|
|
|
Cross Reference information |
Segment |
Product |
Component |
Platform |
Version |
Edition |
Application Servers |
Runtimes for Java Technology |
Java SDK |
|
|
|
|
|
|
|