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>
In zone-based CTE Agent deployments, such as Solaris Zones, always specify paths relative to the global zone, never the local zone. Also, you must guard and unguard manual GuardPoints in the global zone.
For example, to manually guard and unguard a file system directory:
-
Configure a GuardPoint with the type Directory (Manual Guard).
-
Log onto the protected host with CTE Agent as the root user.
-
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 -
Enable the GuardPoint.
# secfsd -guard /opt/apps/apps2/bin secfsd: Guard initiatedThe GuardPoint is active and the policy is enforced.
-
Disable the GuardPoint.
# secfsd -unguard /opt/apps/apps2/bin secfsd: Unguard initiated
