Skip to main content

1E 8.1 (on-premises)

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.logbelow).

Download process

The process for the download is:

  1. Clients retrieve this LSZ and check it for any errors.

  2. If they evaluate an error (NomadBranch.log shown opposite), they quit the download immediately.

  3. If not, the download proceeds normally.

NomadBranch.log
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

0x80000

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.

0x100000

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.