Automatic and Manual GuardPoints

A CTE Agent GuardPoint is usually applied immediately after it is configured in the Management Console. This is called an Automatic GuardPoint. However, GuardPoints can also be applied later on a host system. This is called a Manual GuardPoint.

When would you want to apply the GuardPoint later? Consider the case of a 2-node protected host cluster configured as active/passive in a cluster environment, such as Veritas Cluster Server (VCS) or IBM PowerHA (formerly HACMP). There are two nodes, one which is currently active and the other that is currently inactive. Both nodes are locked. You apply GuardPoint protection to active nodes only. You should never apply a GuardPoint to a passive node. If the active node develops a problem and tries to switch over to the inactive node, the cluster process will fail to switch over because the mirror directory on the inactive node is currently mounted on the active node. The solution is for the cluster process to unmount (for example, unguard) the currently active node, place it in an inactive state, place the old inactive node in an active state, and then mount (for example, guard) the mirror directory on the newly active node. Inappropriate switching on any AIX system can spawn messages like:

• “invalid GuardPoint”

• “The directory is not on cluster file system partition shared across nodes”

• “secfsd Failed to unguard - will retry later”

• “Agent is calling clean for resource because the resource became OFFLINE unexpectedly, on its own.”

Generally, when you get messages like these, check that only active nodes are properly guarded.

Automatic and Manual GuardPoints are set in the Edit Host window, Guard File System sub-window.

The GuardPoint type is usually set to Directory (Auto Guard) for file system based directories and to Raw or Block Device (Auto Guard) when applying GuardPoint protection to raw or block devices. When an auto GuardPoint is applied, regardless if it is a file system directory or a raw device, the change is pushed to the host system, and the GuardPoint is applied immediately. This is evident by using the df command to display secfs mounts (for example, GuardPoints) or secfsd to display the GuardPoints themselves. The secfsd output shows a guard type of local for directories configured with Directory (Auto Guard).

# df
Filesystem                       1K-blocks     Used  Available Use%  Mounted on
/dev/mapper/VolGroup00-LogVol00  40123784  11352236   26733380  30%  /
/dev/sda1                          101086     14590 81277  16%  /boot
none                               254492         0     254492   0%  /dev/shm
/opt/vormetric/DataSecurityExpert/agent/secfs/.sec
                                 40123784  11352236   26733380  30% /opt/vormetric/DataSecurityExpert/agent/secfs/.sec
/opt/apps/apps1/tmp              40123784  11352236   26733380  30% /opt/apps/apps1/tmp
/opt/apps/apps1/lib              40123784  11352236   26733380  30% /opt/apps/apps1/lib
/opt/apps/apps1/doc              40123784  11352236   26733380  30% /opt/apps/apps1/doc

# secfsd -status guard
GuardPoint           Policy        Type    ConfigState  Status  Reason
----------           ------         ----   ------------- ------  ------
/opt/apps/apps1/tmp  allowAllOps_fs           local   guarded    guarded    N/A
/opt/apps/apps1/lib  allowAllRootUsers_fs     local   guarded    guarded    N/A
/opt/apps/apps1/doc  allowAllOps-winusers1_fs local   guarded    guarded    N/A

When a manual GuardPoint is applied, regardless if it is a file system directory or a raw device, the change is pushed to the host system only. The host is aware of the GuardPoint but the host does not mount it. This is indicated in the Type column of the “secfsd -status guard” output. For example, the GuardPoint /opt/apps/apps2/bin has been configured with Directory (Manual Guard) so the guard type is set to “manual”.

# secfsd -status guard
GuardPoint           Policy                   Type   ConfigState   Status   Reason
----------          ----------                ----   -----------   ------   -----
/opt/apps/apps1/tmp  allowAllOps_fs           local   guarded     guarded   N/A
/opt/apps/apps1/lib  allowAllRootUsers_fs     local   guarded     guarded   N/A
/opt/apps/apps1/doc  allowAllOps-winusers1_fs    local guarded    guarded   N/A
/opt/apps/apps2/bin  HR_policy01              manual unguarded  not guarded Inactive

Note the Type value. A Type of manual indicates a manual GuardPoint. A Type of local indicates an automatic GuardPoint.

A manually applied GuardPoint retains a yellow triangle status (Pending) in the Management Console until the GuardPoint is applied on the host. After the GuardPoint is applied on the host, and the host communicates the change to the server, the status changes to a green ball (Normal). It returns to the yellow triangle when the GuardPoint is manually unguarded.

Use the secfsd command to guard and unguard Directory (Manual Guard) and Raw or Block Device (Manual Guard) GuardPoints. The secfsd syntax is:

secfsd -guard <path>
secfsd -unguard <path>

For example, to manually guard and unguard a file system directory:

1. Configure a GuardPoint with the type Directory (Manual Guard).

2. Log onto the protected host with CTE Agent as the root user.

3. Wait until the configuration change is downloaded to the protected host.

   You can run the status command until you see the manual GuardPoint. For example:

   # secfsd -status guard
   GuardPoint        Policy          Type     ConfigState  Status      Reason
   ----------        ------          ----     -----------  ------      ------
   /opt/apps/etc     allowAllOps_fs  manual  unguarded   not guarded  N/A
   /opt/apps/lib/dx3 allowAllOps_fs  local   guarded     guarded      N/A
   

4. Enable the GuardPoint.

   # secfsd -guard /opt/apps/apps2/bin
   secfsd: Guard initiated
   

   The GuardPoint is active and the policy is enforced.

5. Unguard the GuardPoint.

   # secfsd -unguard /opt/apps/apps2/bin
   secfsd: Unguard initiated