Unix 6 .3.x-TIV-ITM-GSK-8.0.50.88-IJ04522 upgrade failure

Body

Unix 6.3.x-TIV-ITM-GSK-8.0.50.88-IJ04522 upgrade failure

Had a report that the upgrade to fix patch  6.3.x-TIV-ITM-GSK-8.0.50.88-IJ04522 failed with the following messages in the itmpatch.log:

TRACE Wed May 16 13:23:01 2018 (nls.cpp,142): NLS::getFormattedString() entry
TRACE Wed May 16 13:23:01 2018 (nls.cpp,158): NLS::getFormattedString() = Version 07.40.50.00 of product gks is currently installed. The patch requires that you must have at least version 08.00.50.00 of product installed to apply this patch.
ERROR Wed May 16 13:23:01 2018 (patchprocessor.cpp,268): Version 07.40.50.00 of product kgs is currently installed. The patch requires that you must have at least version 08.00.50.00 of product installed to apply this patch.

This is seen on Unix and Linux machines and it is due to there being more than one GSkit installed.

for example:

   On an AIX system, the GSKit entries shown by  "cinfo -i "  will look similar
     to the following:
gs     IBM GSKit Security Interface

       aix523  Version: 07.40.27.00
       aix526  Version: 08.00.50.05

This is a known issue, and there is a section 7  in the readme on how to solve this issue.

Basically the steps show you how to upgrade the aix523 version, so that the fix upgrade will run.

However this has lead to a number of questions about what is required, these questions and the answers are detailed below:

1) - Is the aix523 GSkit actually required in any version?

The GSKit installation platforms for AIX are aix523 and aix526.
If you have installed, or intend to install, a 32 bit agent, then the aix523 GSKit would be required and used..
If you have no intention of installing a 32 bit agent ever, you are free to remove the 32 bit GSKit and shared libraries if you desire.
(see link at end of this blog)

2) - Is the 6.3.0-TIV-ITM_TMV-Agents-FP0002 package the only way to do the uplift?

Pristine 6.3.0-TIV-ITM_xxxxx-FP0006 packages were used for the ITM 6.2.3 to ITM 6.3.0 upgrade. The subsequent ITM 6.3.0 FP0007 lift was also done using pristine packages and the latter now used for all new installation. So if the TWM-Agents package from any of these could be used we would not have to expand our repository.

If you are using pristine installation media, then you can use that level without first upgrading to any previous level.
If you are using installation packages generated using tacmd exportbundles from either pristine or upgrade media, then you can use that package without first upgrading to any previous level as long as you use the generated silentInstall.sh instead of using install.sh directly.

3) - Would an alternative not be the workaround described in 6.3.x-TIV-ITM-GSK-8.0.50.84-IJ00337 ?

In section 7 it describes a workaround to include the specific platform patch tar-file in the install command.
 In this case it would be something like this:
/6.3.0-TIV-ITM-FP0007-IJ04324/provpatch -h <candlehome> -i <dirname>/6.3.0-TIV-ITM-FP0007-IJ04324/kax_aix526_tema_ij04324.tar
this was tried and the aix526 version 8 GSkit was uplifted and the aix523 version 7 GSkit left alone.
It seems also to be the procedure other interim fixes uses after checking the installer level .

Yes some patches specify a fully qualified patch file name and some patches specify a fully qualified patch directory name. either syntax will work.

Specifying a file only attempts to apply the patch for that specific platform.
Specifying a directory attempts to apply the patch for all platforms in the directory, that exist in the installation.
The problem with only upgrading one platform when more than one platform is present is that you are still not mitigating possible vulnerabilities in the unpatched platform.
If you have previously installed a 32 bit agent based on 6.30.X, or uplifted the framework, then you would still not apply the patch to the 32 bit platform if you were patching using the file name syntax.
If you are using any type of automation, updating the framework before applying the patch (using the directory syntax) is the most secure way to mitigate vulnerabilities.

4) Why did the ITM 6.3.0 FP0006 upgrade not upgrade the 32 bit GSkit?

When you perform an initial installation with 6.2X releases, 32 and 64 bit ax and gs are installed.
When you perform an initial installation with 6.30[0-3] releases, 32 and 64 bit ax and gs are installed.
When you perform an initial installation with 6.30[4-7] releases, 64 bit ax and gs are installed.
When you perform an upgrade installation with 6.2X releases, only prerequisites of products being upgraded are also upgraded and gs 32 and 64.
When you perform an upgrade installation with 6.30.[0-3] releases, only prerequisites of products being upgraded are also upgraded and gs 32 and 64.
When you perform an upgrade installation with 6.30.[4-7] releases, only prerequisites of products being upgraded are also upgraded and gs of the same bit mode as the ax upgraded.

To get all of the ax and gs components re-synced to the same level (as long as no platform of ax is already higher than that level), you need to perform the following:

For Local installation set the following so that the copy and paste commands below can be used:
MEDIA=<Fully qualified path to directory containing install.sh>
CH=<Fully qualified path to CANDLEHOME directory>

For all releases less than 6.30.06:
for PLAT in $($CH/bin/cinfo -d | grep ax | cut -d, -f3 | tr -d '"'); do
$MEDIA/install.sh -h $CH -q -p.$MEDIA/unix/tf${PLAT}.txt
done

For all releases greater than or equal to 6.30.06:
PLAT=""
for TPLAT in $($CH/bin/cinfo -d | grep ax | cut -d, -f3 | tr -d '"'); do
[[ "$TPLAT" > "$PLAT" ]] && PLAT=$TPLAT
done
$MEDIA/install.sh -h $CH -q -p.$MEDIA/unix/tf${PLAT}.txt

For Remote installation set the following so that the copy and paste commands below can be used:
CH=<Fully qualified path to CANDLEHOME directory where HUB TEMS is installed>

$CH/bin/tacmd login -s localhost -t 1440
$CH/bin/tacmd cleanms -a
for NODE in $($CH/bin/tacmd listsystems -t ux lz | sort -k1.51,1.51br -k1.1,1.14bf | tail -n +2 | cut -d' ' -f1); do
$CH/bin/tacmd upateframework -n $NODE -v 063007000
done

After you have performed the update framework, locally or remotely, you can apply any patches required to go beyond the FP7 ax release level.

It was also discussed if a 32 bit agent was never to be installed the 32 bit GSKit and shared libraries could be removed; details of these actions are in the article :

/support/pages/node/1083303

Subscribe and follow us for all the latest information directly on your social feeds: