How to test the integrity of a WebSphere Application Server V5.1 Fix Pack
 Technote (troubleshooting)
 
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:

  1. 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.

  2. 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.

  3. 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.

  4. 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:

  1. 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.


  2. 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.


  3. Make a temporary directory and change to it:

    Unix:

    mkdir test
    cd test

    Windows:

    md test
    cd test


  4. 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


  5. 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.


  6. 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
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Install
Operating system(s): AIX
Software version: 5.1
Software edition:
Reference #: 1198561
IBM Group: Software Group
Modified date: May 23, 2005