OS File Checksum Test
A checksum is a simple type of redundancy check that is used to detect errors in files.
Errors may frequently occur in files when the files are written to a disk, transmitted across a network or otherwise manipulated. The errors can even be very small - for example, a single incorrect bit - but even such small errors can greatly affect the quality of data and make it useless. For example, you can apply a checksum to an installation file after it is received from the download server to check for errors after the download, as such errors can render the corresponding software uninstallable.
To alert administrators to such integrity issues with system files that they deem critical, eG periodically runs the OS File Checksum test. This test creates a checksum by calculating the binary values (using a pre-defined algorithm) of every file configured for monitoring and storing the results. Each time the test runs, a new checksum is calculated and compared with the existing checksum. If there is a non-match, the test promptly alerts administrators to it, as it could be because of errors in the file.
Target of the test : Any Unix/Windows host system
Agent deploying the test : An internal agent
Outputs of the test : One set of results for each configured directory path
Configurable parameters for the test
- Test period - How often should the test be executed
- Host - The host for which the test is to be configured.
- port - Refers to the port used by the specified host. By default, it is NULL.
-
directory path – Provide a comma-separated list of the full path to directories and/or files that you want the test to monitor. For example, your specification can be: /usr/logs/err.log,/Oracle/logs where /usr/logs/err.log is a file and /Oracle/logs is a directory. Where a directory is provided, all files within that directory will be monitored and will appear as descriptors of the test.
Your specification can also be of the following format: DisplayName@Path_to_Directory_or_File. For example: Error@/usrlogs/err.log. Multiple such specifications can be provided as a comma-separated list – for instance, Error@/usrlogs/err.log,Oracle@/Oracle/logs,Web@/web/weblogs. In this case, the DisplayNames such as Error, Oracle, and Web will be displayed as the first-level descriptors of this test, and the files in each configured directory will be displayed as the second-level descriptors.
Note:
- When you provide the path to a directory as part of the directory path specification, only those files available within that directory will be monitored; sub-directories inside that directory and files within the sub-directories will not be considered.
- If your directory path specification includes the path to individual files, make sure that you provide the file extensions along with the file names.
-
exclude pattern – If you do not want the test to monitor specific patterns of files in the configured directories, then provide a comma-separated list of file name patterns to be excluded from monitoring, in the following format: DisplayName@FileNamePattern. The DisplayNames you use here should be the same as the DisplayNames you use as part of your directory path specification. For instance, if your directory path specification is, Oracle@/Oracle/logs,Web@/web/weblogs, then, your exclude pattern configuration may be: Oracle@*info*.log,Web@gen*.log,Web@*minor.log. This configuration holds that in the /Oracle/logs directory, all files with names that embed the string info should be configured and in the /web/weblogs directory, all files with names that begin with the string gen and all files with names that end with string minor should be ignored.
If your directory path specification does not include DisplayNames and instead includes a comma-separated list of directory paths – eg., /usr/logs,/agent/logs – then your exclude pattern specification should be of the following format: DirectoryPath@FileNamePattern. For instance, if your directory path specification is /usr/logs,/agent/logs, then your exclude pattern configuration may be:/usr/logs:*minor*.log,/agent/logs:info*.log,/agent/logs:*warn.log. According to this configuration, the test will ignore all files with names that embed the string minor in the /usr/logs directory. In the /agent/logs directory, the test will ignore the files with names that begin with info and the files with names that end with warn.
By default, the exclude pattern is set to none, indicating that no files are excluded from monitoring, by default. This is the ideal setting if your directory path specification does not include any directories, and is instead configured with the path to individual files.
- use exe – This flag is applicable to Windows platforms only. By default, this flag is set to No. This implies that, by default, the test uses a predefined Java class named Message Digest to compute the checksum of configured files. In some flavors of Windows, this Java class may not work. In such cases, you can instruct the test to use an executable named exf.exe to compute checksum. For this, set the use exe flag to Yes.
-
To make diagnosis more efficient and accurate, the eG Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.
The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:
- The eG manager license should allow the detailed diagnosis capability
- Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
|
Measurements made by the test
|
Has checksum been modified:
|
Indicates whether/not the checksum value of this file has changed since the last measurement period.
|
|
If the checksum value of a file has changed since the last time this test ran, then the value of this measure will be Yes. In this case, you can use the detailed diagnosis of this test to know what was the previous checksum value and the new checksum value of each test. Typically, a change in the checksum value indicates an error.
If there is no change in the checksum value, then this measure will report the value No. Note that the value No does not imply that there is no error. It simply means that the test could not detect any errors. Among the types of errors that cannot be detected by simple checksum algorithms are reordering of the bytes, inserting or deleting zero-valued bytes and multiple errors that cancel each other out
The numeric values that correspond to the measure values discussed above are as follows:
Note:
By default, the test reports the Measure Values listed in the table above to indicate whether/not the checksum value has changed. In the graph of this measure however, the same is represented using the numeric equivalents only.
|
