Linux and UNIX systems: Installing and activating A-TAP in Zones and WPARs environment

About this task

Procedure

  1. Install STAP/KTAP on the master/global Zone/WPAR by the normal method.
  2. For Solaris Zones, for each sub-zone where Oracle is installed, make sure the Guardium device is mapped:
    • zoneadm -z <zonename> halt
    • zonecfg -z <zonename>
    • <zonename>> add device
    • <zonename>device> set match=/dev/ktap_xxx (for Solaris 10) (katp_xxx is the filename )
    • <zonename>device> set match=/dev/guard_ktap (for Solaris 11)
    • <zonename>device> end
    • <zonename>> verify
    • <zonename>> exit
    • zoneadm -z <zonename> boot
  3. With multiple KTAP devices, repeat the steps for each KTAP device by using the name, ktap_xxxx (Solaris 10) or guard_ktap_x (Solaris 11).
  4. Copy the entire A-TAP installation directory to a sub-Zone/sub-WPAR. Assuming Guardium software is installed on the master Zone/WPAR under /usr/local/guardium, and there exists a writable directory /usr/local with enough free space on the sub-Zone/sub-WPAR: On the master/global Zone/WPAR: cd /usr/local; tar -cvf - guardium | ssh root@subzonehost 'cd /usr/local && tar -xvf -'
  5. Copy the A-TAP libraries to each sub-Zone/sub-WPAR, and activate it.
    • If an A-TAP is to be activated on the master Zone/WPAR, activate it normally using guardctl.
      Note: Activation must be done using guardctl; it cannot be done through enabling encryption box in the inspection engine section in GUI interface or by setting encryption=1 in the guard_tap.ini file.
    • If A-TAP will not be used on the master Zone/WPAR, use guardctl to prepare the libraries for use. On the master Zone/WPAR: /usr/local/guardium/bin/guardctl --db_instance=<instance-name> --db_type=<database-type> --db_version=<database-version> prepare-libs
      Note: After A-TAP activation, if the database indicates that libguard-xxx.so cannot be found, re-check this step.
  6. Install and activate A-TAP for database instances using 1 through 5 on each desired sub-Zone/sub-WPAR.
    Note: A-TAP (guardctl) activation may complain and issue warnings about the following:
    • errors installing libraries under /usr/lib (since that directory belongs to the global/master zone)
    • not being able to change the guard_tap.ini to monitor oracle-guard instead of oracle (since the file is on the global zone)
    • not being able to restart S-TAP (since it is running only on the master zone)
  7. Adjust the guard_tap.ini file in the master/global Zone/WPAR by manually editing the guard_tap.ini file..
    • Change the appropriate db_exec_path line:
      • For Oracle on Solaris: set db_exec_path to oracle-guard-original instead of oracle
      • For Oracle on AIX: set db_exec_path to oracle-guard-instrumented instead of oracle
    • Change the files and directories referenced in the IE definitions ( db_install_dir and db_exec_file) so they are relative to the root directory of the WPAR and not the global partition. (IE order, tap_identifier string, etc, should be identical in all the guard_tap.ini files.)
  8. Restart S-TAP.
  9. For Solaris, verify the guard_ktap link and permissions on each sub-Zone. This must be performed as root from the global/master Zone.
    1. cd to the sub-zone device directory, for example: cd /export/home2/zones/iris3/dev
    2. Verify that the KTAP device exists (if it does not, there was a problem with the installation in 2): ls -l ktap_*
    3. Verify that the guard_ktap symbolic link exists: ls -l guard_ktap
    4. If it does not exist, create it. (Note: ktap_xxxxx is the device just listed): ln -fs ktap_xxxx guard_ktap

      For Example:

      -bash-3.00# ln -fs ktap_83164_0 guard_ktap
      -bash-3.00# ln -fs ktap_83164_1 guard_ktap1
      -bash-3.00# ln -fs ktap_83164_2 guard_ktap2
      -bash-3.00# ln -fs ktap_83164_3 guard_ktap3
      -bash-3.00# ln -fs ktap_83164_4 guard_ktap4
      -bash-3.00# ln -fs ktap_83164_5 guard_ktap5
    5. Make sure that guard_ktap and ktap_xxxxx are usable by everyone:
      chmod 0666 ktap_xxxxx_0 	 	
      chmod 0666 ktap_xxxxx_1 	 	
      chmod 0666 ktap_xxxxx_2 	 	
      chmod 0666 ktap_xxxxx_3 	 	
      chmod 0666 ktap_xxxxx_4 	 	
      chmod 0666 ktap_xxxxx_5 	 	
      chmod 0666 guard_ktap 	 	
      chmod 0666 guard_ktap1 	 	
      chmod 0666 guard_ktap2 	 	
      chmod 0666 guard_ktap3 	 	
      chmod 0666 guard_ktap4 	 	
      chmod 0666 guard_ktap5
    Note: ATAP, WPAR and encrypted traffic: with a WPAR/Zone, encrypted traffic and decrypted traffic have different IPs when this traffic goes to the analyzer. Thus the db_user in WPAR/Zones is meaningless.