Logging of HA-related events takes place on the HSM Client workstation. The log file haErrorLog.txt shows HA errors, as well as add-member and delete-member events. It does not record status changes of the group as a whole (like adding or removing the group). Some information is recorded in the log file to help Thales customer support staff troubleshoot operational issues.
The HA log rotates after the configured maximum length is reached. When it finishes writing the current record (even if that record slightly exceeds the configured maximum), the file is renamed to include the timestamp and the next log entry begins a new haErrorLog.txt.
Configuring HA Logging
Using HSM Client 7.2.0 or newer, logging is automatically enabled when you configure an HA group (see Setting Up an HA Group), but you must configure a valid destination path before logging can begin. HA groups are configured on the client using LunaCM. The HA configuration settings are saved to the Chrystoki.conf (Linux/Unix) or crystoki.ini (Windows) file, as illustrated in the following example:
VirtualToken = {
VirtualToken00Label = haGroup1; // The label of the HA group.
VirtualToken00SN = 11234840370164; // The pseudo serial number of the HA group.
VirtualToken00Members = 1234840370164, 1234924189183; // The serial number of the members.
VirtualTokenActiveRecovery = activeEnhanced; // The recovery mode.
}
HASynchronize = {
haGroup1 = 1; // Enable automatic synchronization of objects.
}
HAConfiguration = {
HAOnly = 1; // Enable listing HA groups only via PKCS#11 library.
haLogPath = /tmp/halog; // Base path of the HA log file; i.e., “/tmp/halog/haErrorLog.txt”.
haLogStatus = enabled; // Enable HA log.
logLen = 100000000; // Maximum size of HA log file in bytes.
failover_on_deactivation = 1; // if a partition becomes deactivated then the client will immediately
// failover and resume its operation on the other HA partitions. This
// is currently an alpha feature
reconnAtt = 120; // Number of recovery attempts.
}
HARecovery = {
haGroup1 = 1; // Deprecated in this release as auto recovery will cover the use case. When cryptoki
// loads into memory it reads the number and if the number changes (gets incremented)
// then cryptoki interprets this as a manual recovery attempt.
}
To configure HA logging
Use the LunaCM command hagroup halog.
1.Set a valid path for the log directory. You must specify an existing directory.
lunacm:> hagroup halog -path <filepath>
lunacm:> hagroup halog -path "C:\Program Files\Safenet\Lunaclient\halog"
HA Log path successfully set to C:\Program Files\Safenet\Lunaclient\halog.
Command Result : No Error
2.[Optional] Set the maximum length for individual log files.
lunacm:> hagroup halog -maxlength <max_file_length>
lunacm:> hagroup halog -maxlength 500000
HA Log maximum file size was successfully set to 500000.
Command Result : No Error
3.[Optional] Enable or disable HA logging at any time.
lunacm:> hagroup halog -disable
lunacm:> hagroup halog -enable
lunacm:> hagroup halog -disable
HA Log was successfully disabled.
Command Result : No Error
4.[Optional] View the current status of the HA logging configuration.
lunacm:> hagroup halog -show
lunacm:> hagroup halog -show
HA Log: enabled
Log File: C:\Program Files\Safenet\Lunaclient\halog\haErrorLog.txt
Max File Length: 500000 bytes
Command Result : No Error
HA Log Messages
The following table provides descriptions of the messages generated by the HA sub-system and saved to the HA log. The HA log is saved to the location specified by haLogPath in the Chrystoki.conf (Linux/Unix) or crystoki.ini (Windows) file.
Message Format
Every HA log message has a consistent prefix consisting of the date, time, process id, and serial number (of the affected HA group). For example:
Wed Oct 4 16:29:21 2017 : [17469] HA group: 11234840370164 …
Message Descriptions
In the message descriptions, the term connection refers to the connection between the HSM Client and the Luna Network HSM 7 appliance. A connection is considered valid if the appliance responds correctly on the IP address and port. The connection can transition to invalid for a number of reasons. Some examples include if the appliance Ethernet cable is detached, if the appliance is shutdown/rebooted, or if the NTLS service is stopped/restarted.
| Message ID | Message/Description |
|---|---|
| HALOG_CONFIGURED_AS_PASSWORD |
Description: Message advising that the virtual partition is password-authenticated. This means that you cannot add a PED-authenticated member to the group. |
| HALOG_CONFIGURED_AS_PED |
Description: Message advising that the virtual partition is PED-authenticated. This means that you cannot add a password-authenticated member to the group. |
| HALOG_DROPMEMBER |
Description: The connection changed from valid to invalid, determined after an HSM command (such as C_Sign) fails. |
| HALOG_DROPUNRECOVERABLE |
Description: The connection is invalid, as determined during a call to C_Initialize. |
| HALOG_LOGINFAILED |
Description: The connection changed from valid to invalid, as determined during a call to C_Login. |
| HALOG_MEMBER_DEACTIVATED |
Description: The user manually deactivated the partition, as determined after an HSM command (such as C_Sign) fails. |
| HALOG_MEMBER_NOW_ACTIVATED |
Description: Additional info about the recovered partition, which was deactivated and is now becoming activated. |
| HALOG_MEMBER_REVOKED |
Description: The user manually revoked the partition, as determined during a periodic recovery attempt. |
| HALOG_MEMBERS_OFFLINE |
Description: A situation where all members go offline. Recovery is not possible at this point. |
| HALOG_MGMT_THREAD_START |
Description: This thread is responsible for managing all members and HA in general while the HA group is active. The thread starts up when the application first launches. |
| HALOG_MGMT_THREAD_TERMINATE |
Description: This thread is responsible for managing all members and HA in general while the HA group is active. If the client application shuts down, this thread will simply terminate. The thread will start up again once the application re-launches. |
| HALOG_NEWMEMBER |
Description: The user manually added a member to the HA group without restarting the application, as determined during a periodic recovery attempt. |
| HALOG_RECOVERED |
Description: The connection changed from invalid to valid, as determined during a periodic recovery attempt. |
| HALOG_RECOVERY_ATTEMPT_#_REINTRODUCING |
Description: Additional info about the recovered partition at which some objects were cloned. |
| HALOG_RECOVERYFAILED |
If autorecovery fails, then a second message is logged, as follows:
Description: The connection remains invalid, as determined during a periodic recovery attempt. |
| HALOG_RENABLEMEMBER (deprecated) |
Description: The user manually requested partition recovery, as determined during a periodic recovery attempt before an HSM command. |
| HALOG_UNRECOVERABLE (deprecated) |
Description: The connection is invalid and is not eligible for recovery. |
| No ID* |
Description: The HA member was not activated at the time when a C_Initialize call was made, and is therefore excluded from the HA group. Once the partition is activated, the HA group will attempt an automatic recovery, resulting in one of the two messages below |
| No ID* |
Description: Recovery failed |
| No ID* |
Description: Recovery succeeded |
* You might encounter these extra messages in the HA logs. They were added for HA development testing and therefore have no Message IDs assigned to them. They could duplicate information covered by other log messages as defined above.
