IBM Global Security Kit installation instructions for Sun

The IBM® Global Security Kit (GSKit) installation must be performed as the user root.

In a temporary directory, uncompress and untar each of the compressed packages using the following command: 
zcat package.tar.Z | tar -xf -
For example, to uncompress the 64-bit GSKit Crypt package you might run the following command: 
zcat gskcrypt64-8.0.13.sun.sparc.tar.Z | tar -xf -

For GSKit Crypt 64-bit, gsk8cry64 would be the decompressed file. The installation instructions assume that you have decompressed the installation packages and are working with them directly.

Prerequisite checking

By placing the appropriate value in a response file (see the pkgadd man page for details) the installer will enforce that the required Sun patches are present before the GSKit install will succeed. In order to enforce prerequisite checking, the value to place in the response file is: GSK_ENFORCE_PREREQUISITES=1

Allowing upgrades

By default, the Sun installer does not allow the upgrade of an installed package. The existing package must first be uninstalled and then the new version installed. You can set a flag in the response file to enable the upgrade of a package if necessary. To do this, add the following line in the admin file: 
instance=overwrite
In the response file, add the line: 
GSK_UPGRADE_ONLY=1

Sun installer and directory permissions

The Sun installer has some unique behavior such that the expected directory permissions of system directories (for example, /usr/bin and /usr/lib) can be noted by the installer if specified by any package being installed (for example most of the Sun packages specify the required permission). The last installed package to require a specific permission sets this expectation for all subsequent installs that do not specify an exact required permission.

This can create problems if the system administrator changes the directory permissions of system directories outside of the install database, as they will be inconsistent with the installers expected state. Although GSKit does not require specific permissions for these directories the installer may, during the install, require that the permissions be changed to the state that it expects. This behavior is by design and it is expected that system administrators of Sun systems are aware of this behavior and should keep the actual permissions of the system directories consistent with the expected state in the installer database.

For interactive install the user will be prompted for the action to take.

For silent install the standard GSKit install will fail. There are two known workarounds for this issue for the silent install. Sun system administrators may know of more.
  • Use an admin file (as documented by the pkgadd install tool) with the following setting of the conflict parameter added or changed to: conflict=nochange

    This will leave the conflicting directory permission attributes unchanged.

  • Use an admin file (as documented by the pkgadd install tool) with the setting of the conflict parameter added or changed to: conflict=nocheck

    This will change the directory attributes to agree with the install database. This is considered the most appropriate option.

Solaris package instance names

By default, Solaris sets a 9-character limit on the package instance names. Therefore, there is a discrepancy between the naming conventions used in the GSKit package files and the system package instance name. The following table shows the relationship between the package name (pkgname), and the package instance name (pkginst).
Table 1. GSKit package names and Solaris package instance names
GSKit Package Name Solaris Package Instance Name
gskcrypt32-ver.sun.arch.tar.Z gsk8cry32
gskssl32-ver.sun.arch.tar.Z gsk8ssl32
gskcrypt64-ver.sun.arch.tar.Z gsk8cry64
gskssl64-ver.sun.arch.tar.Z gsk8ssl64