Where does JamfSync store calculated Checksums for destination?

[staze]

We sync our JCDS down to a local file share and use that for on-prem deployments (by default, falling back to cloud if it's not on local DP)

Where does JamfSync store the calculated checksums (when you hit the "calculate checksums" button in the GUI)?

Wondering if it would make sense to store that on the destination share then if you have a different machine run JamfSync it can reference those checksums?

Thanks!

[HarryStrandJamf]

Jamf Sync doesn't actually store those checksums, except in memory, and Jamf Pro also stores it with the package info when a package is added or updated. Jamf Pro uses this to ensure that a package that is being installed by a policy is actually the package that was uploaded. Clicking Calculate Checksums is optional, and it will calculate the checksums during the synchronization process if it hasn't already been calculated. However, if you do calculate the checksums, it will take the checksums into account when checking to see if the files have changed or not. If the checksum is not calculated, it will use the size and date of the file to determine if it has been changed, which could cause it to not update if the file did change but the size and date don't reflect that. That would be pretty rare though.

[staze]

Hey Harry. I guess I'm confused.

JCDS obviously has checksums stored in Jamf. Perfect. When it syncs something from JCDS to a file share, for example, it calculates Checksum to confirm copy worked? If you are giving it an already existing on-prem File Share (with stuff already on there), I assume it just uses the modification date/file size? Since Jamf has no concept of the Fileshare contents (really) it has no way to store that checksum.

Okay, so to make sure I understand:

The calculate checksum function would primarily be for the situation I describe, where you're starting to use Jamf Sync on pre-existing distribution points, and want to confirm things match (not just based on date/time), yea? So it doesn't overly matter if they're stored because this is an infrequent requirement.

[justintrant]

I'd love to know more about the sync/verification process, as I'm seeing weirdness when replicating to AWS S3:

• Add a new package to an on-prem DP using Jamf Sync
• Sync to S3 which completes successfully, however clicking ‘Refresh’ shows that the package is still pending upload
• If I inspect the S3 bucket, the file is there but with 0KB file size
• Sync and refresh repeatedly (sometimes up to 10 times and over the course of 24+ hours)
• Eventually the file will upload correctly, and checksum validate during deployment/installation
• This is especially problematic with larger files as the sync/refresh process can take a LONG time
• Sometimes, uploading the package with a slightly different name helps, but not always. This also requires modifying every policy associated with the package in question

What I’ve tried:

• Using an account with full admin permissions instead of the permissions described in the Jamf Sync user guide
• A different user account on the Mac being used for replication, in addition to a completely different Mac
• Updating Jamf Sync
• Setting up Jamf Sync completely from scratch
• Clicking "Calculate Checksum" before syncing to S3

Our environment:

• Clustered (on-prem) Jamf Pro v11.4.1 with two hosts – internal and external. Separate database server
• Jamf Sync 1.5.1
• AWS S3 bucket with associated CloudFront CDN, AWS is the primary distribution point

One thing I have noticed is that Jamf Sync appears to use a mixture of SHA and MD5 checksums. When initially adding a package the checksum in the source pane shows as SHA but once the package (eventually) validates it changes to MD5. This is confirmed by querying the API for the package in question and inspecting the signature there.

Jamf Case: CS1370704