Failure to Enable GuardPoints

The following alerts trigger when LDT fails to enable a GuardPoint:

• LDT-ALERT: Cannot enable GuardPoint due to wrong policy applied to [GuardPoint]

  This message indicates that there was an attempt to apply an LDT policy to a GuardPoint that was previously guarded with a different LDT policy:

  The GuardPoint status changes to Incorrect policy .

  Solution

  Unguard the GuardPoint and re-guard with the correct policy or, if you want to change the policy associated with the GuardPoint, clean up the LDT metadata and the re-guard. For details on cleaning up the GuardPoint, see Deleting LDT Metadata (Linux).

• LDT-ALERT: Failed to update LDT attribute (Linux only)

  LDT failed to create or update an LDT extended attribute of a file in a GuardPoint.

  Solution

  An I/O error is the most common cause of failure when updating an LDT extended attribute. For I/O errors, fix the problem at the host OS or storage level.

  If you cannot find and fix the host OS or storage issue, contact Customer Support for troubleshooting and recovery.

• LDT-ALERT: Failure to Enable GuardPoint Due to Mismatched Policy or Key (Linux only)

  The following status indicates that a node has attempted to apply an LDT policy to a GuardPoint that uses a policy or key version that is different than the primary host.

  • The GuardPoint status changes to Stale Policy.

  Solution

  Wait for the CipherTrust Manager to send the new policy to all members of the LDT group. If left in this state, the GuardPoint will automatically be guarded once the policy version matches the primary version. If the GuardPoint does not guard, make sure network connection between CipherTrust Manager and CipherTrust Transparent Encryption host is active and running, and the policy applied to the GuardPoint on the CTE host matches the policy applied across all members of LDT GuardPoint Group.

• LDT-ALERT: Failure to Enable GuardPoint due to Unavailability of LDT Communication Group (Linux only)

  The following status indicates that the LDT Communication Group is not yet running on the host.

  • The GuardPoint status changes to LDT Group Services is not initialized.

  Solution

  Wait for the LDT Communication Group to start up. This can occur if the attempt to guard the GuardPoint occurs immediately after LDT start up. The GuardPoint will automatically complete the guard operation once the LDT Communication Group completes initialization.

Note

The LDT Communication Group may require up to a minute to start up after rebooting the CTE host.

• LDT-ALERT: Failure to Enable or Disable GuardPoint due to Singe File Rekey (Linux only)

  The following status indicates that a GuardPoint is busy with single file rekey jobs and cannot be interrupted to allow a member to join or leave the group.

  • When guarding, the status changes to Single file rekey in progress, retrying.

  • When unguarding the status changes to Busy, will continue to retry.

  Solution

  Wait for the single file rekey to finished so that the group allows members to join or leave. The status of a single file rekey can be found by running voradmin ldt list all on the primary host. This command lists all of the single file rekey jobs as type=FILE. The GuardPoint will automatically complete the guard or unguard operation once all single file rekey jobs are completed.

• LDT-ALERT: Failure to Enable GuardPoint on Primary Host after Crash

  The following status indicates that the primary host failed to leave the group correctly, and is now attempting to re-join the group.

  • The GuardPoint status changes to, Group join failed, GuardPoint needs LDT repair

  Solution

  Run the following commands to manually clean up the group and allow the primary to rejoin as a member. Client will complete the guard operation once the group has been repaired.

  voradmin ldt group repair /<primary IP> <absolute GuardPoint>  (Windows)
  
  voradmin ldt group repair /<primary IP> <${gp}>  (Linux)

  Copy

• LDT-ALERT: Failure to Enable GuardPoint due to mismatched NFS Version (Linux only)

  The following status indicates that a member is attempting to guard an NFS share mounted with a different version than what the primary uses.

  • The GuardPoint status changes to, NFS version mismatch with primary

  Solution

  Unguard on the member, unmount the NFS share, and remount it with the same NFS version as the primary.

• LDT-ALERT: Failure to Enable GuardPoint due to mismatched LDT Message Versions (Linux only)

  The following status indicates that the member is using a message version that is incompatible with the primary.

  • The GuardPoint status changes to, LDT message version mismatch with primary.

  Solution

  Unguard and verify that the member is running the same version of CipherTrust Transparent Encryption as the primary. If this problem persists, contact Thales Support for further troubleshooting. Note that the LDT message service in CipherTrust Transparent Encryption v7.2 and CipherTrust Transparent Encryption v7.3 are incompatible. When members of an LDT GuardPoint Group consist of CTE 7.2 and 7.3 hosts, this failure is expected and the solution is to upgrade those members running CipherTrust Transparent Encryption 7.2 to CipherTrust Transparent Encryption 7.3 or a subsequent version. All members of the LDT GuardPoint Group must be running the same version of CipherTrust Transparent Encryption.