GIM user interfaces

The purpose of GIM is to provide automatic installation capability for modules, taking advantage of a GIM client residing on each database server and a and GIM server on the Guardium® system.

Users may also interact with GIM through the CLI. See GIM CLI commands for information on installing and upgrading modules with GIM using CLI.

You can use the GUI of the Guardium Installation Manager (GIM) for these tasks:
  • Process Monitoring
  • Upload Module Package
  • Configure, Install, or Update Modules
  • Rollback Mechanism
Note: If A-TAP is being used, A-TAP must first be disabled on the database server before performing a GIM-based S-TAP upgrade or uninstall.
Note: GIM does not support the installation of native S-TAP installers (rpm, dept, bff, etc.)
Note: Installation of modules on a specific client for the FIRST TIME using the GIM utility must be in the form of a BUNDLE. Future upgrades of specific modules which are part of the installed bundle can be either as single modules or bundles.

GIM Processes

  • Supervisor: The GIM Supervisor is a process with the main purpose of supervising and monitoring Guardium processes. Specifically, it is responsible for starting, stopping, and making sure all of Guardium processes are running at all times, and restarting them if they fail.
  • GIM: The GIM process is the GIM client process, which is responsible for such duties as registering to the GIM server, initiate a request to check for software updates, installing the new software, updating module parameters, and uninstalling modules.

Commands for starting and stopping services are listed in Linux-UNIX: Start and stop S-TAP and GIM processes for various OS types/versions.

GIM Processes Monitor page

This page displays the status of GIM processes on servers. You can filter for: up, down, unknown; or use the free text filter.

Configure, Install, or Update Modules

For information about the latest GIM software management tool, see Set up by Client.

Windows S-TAP Parameters in GIM

During S-TAP installation, or to update the S-TAP configuration, you can use the WINSTAP_CMD_LINE field in the Setup by Client page.

You can input any parameter in the Setup by Client page, in the Choose parameters row, using the command WINSTAP_CMD_LINE with the syntax parameter=value for [TAP] parameters, or CLI parameters (Windows: S-TAP command line installation parameters) with the syntax -param value, and it is added or updated in the guard_tap.ini.

CAUTION:
There is no validation of input to this field.
For example, the following command line options skip the installation of CAS and Named Pipes support. 
CAS=0 NamedPipes=0
If you are installing an S-TAP and you do not want it to automatically discover MSSQL databases, type START=0 in the WINSTAP_CMD_LINE column to prevent the S-TAP from starting when it is installed. You can also specify this parameter for a single database server by using the GIM API:
grdapi gim_update_client_params clientIP=xx.xx.xx.xx paramName=WINSTAP_CMD_LINE paramValue="START=0"

Additional guard_tap.ini parameters may also be set at installation. An example is paramValue="START=1 !client_timeout_sec=120&use_tls=1!"

Note: When using GuardAPI commands, the WINSTAP_CMD_LINE paramValue should be quoted and each parameter separated by spaces, such as paramValue="START=1 CAS=0" as in the prior example. A lack of spaces can cause the subsequent installation to not complete as anticipated.

Rollback Mechanism

GIM's rollback mechanism purpose is to handle errors during installation and recover modules to their prior state. The Rollback mechanism supports the following recovery scenarios:
  1. Live Upgrade Recovery
    For Bundles
    • When bundles are installed, recovery will rollback the modules that have an install failure within the bundle.
    • Modules that are marked as NO_ROLLBACK (in the form of a read-only parameter <MODULE>_NO_ROLLBACK=1) will not be rolled back in the event of a failure. S-TAP/KTAP are two such modules that once successfully installed will not be rolled back in the event of a failure of another module.
    For non-Bundles
    • Rollback entails the removal of the standalone module in the case of a scratch install or reverting back to the previous version in case of an upgrade.
  2. Boot Time Installation Recovery
    If installation failure occurs during a system reboot, a second system reboot will be needed in order to complete the recovery. Users will still see the status IP-PR after reboot, and a GIM_EVENT entry that indicates a second reboot is needed to complete the recovery process. The module/bundle state will then indicate a “FAILED” status after the second reboot.
    Note: When the status is 'IP-PR' booting the DB-server is different per OS (Any other way of rebooting the system will keep the pending modules in a pending state):
    Linux   : shutdown -r
SuSe    : reboot
HP      : shutdown -r
Solaris : shutdown -i [6|0]  (Note : '0' can be used only if shutdown is done  from the terminal server)
AIX     : reboot
Tru64   : reboot
    Note: In addition, prior to reboot, A-TAP instances must be disabled/deactivated.