Resolving content integrity (hash checks) issues
When an LSZ request is made and the request contains a hash, Nomad on DP computes a corresponding hash for the content on its disk. If the computed hash does not match the hash sent by the client, the content is considered corrupted and if it matches, the content is considered good, (see the example NomadBranch.log
below).
Download process
The process for the download is:
Clients retrieve this LSZ and check it for any errors.
If they evaluate an error (N
omadBranch.log
shown opposite), they quit the download immediately.If not, the download proceeds normally.
Set CompatibilityFlags on the DP and client
We also need to make sure that we have CompatibilityFlags set correctly on the DP and client respectively as follows:
Bit | Description |
---|---|
| The bit is enabled by default. Setting this bit enables full hash generation for SIS content when an LsZ file is generated on a DP. If this is not enabled, SIS content is trusted, and corrupted content may be downloaded. |
| The bit is enabled by default. Setting this bit would abort download on a Nomad client if an LsZ hash mismatch is detected. If this is not set, when a Nomad client detects a hash mismatch it will re-request LsZ generation on the DP then try again, and get stuck in a loop if the SIS content is corrupt. |