My workaround for a 5GB file limit, especially for use with Casper Imaging and a Jamf Cloud Distribution Point

arekdreyer
Contributor

I've run into a chicken-and-egg problem with Casper Imaging and the Jamf Cloud Distribution Point: in order to add a disk image file (.dmg) to an imaging Configuration, it has to be in my main repository. But when I try to upload it to my Jamf Cloud Distribution Point, it fails. Update: I was wrong in my original post by attributing the problem to the current 5GB file limit from Amazon S3), specifically,

With a single PUT operation you can upload objects up to 5 GB in size.

But in order to use that .dmg file in Casper Imaging (like with Target Mode imaging), you need that .dmg file to be available in a Configuration (which you create with Casper Admin) as well as in your local repository.

Here is how I work around the 5GB limitation with an empty placeholder file. Your workflow might vary from mine, but I hope this gives you a start.

I've been told that I should be able to upload via Jamf Pro instead of Casper Admin, but I tried and it failed for me, at least with hosted Jamf Pro. If it works for you, then you don't need my workaround.

  1. Prepare to replicate your JAMF Cloud Distribution Point to a local volume of a Mac you'll use for imaging: Use Terminal to create a local repository and allow yourself to write to it:
    sudo mkdir /jamf
    (you can replace /jamf with /casper or whatever you like, but be consistent)
    sudo chown ladmin /jamf
    (of course, replace ladmin with the name of your local administrator name) Open Casper Admin. Open a new Finder window, choose Go > Computer. Double-click your boot volume so you can see the /jamf folder (it won't be displayed with the leading slash; I just refer to it like that in written instructions) Drag your /jamf folder to the sidebar in Casper Admin.
  2. Create two folders, one for the real AutoDMG file, and one for the empty placeholder file (in the commands below, the tilde, ~, signifies the home folder of the currently-logged-in user):
    mkdir ~/Desktop/Zero-Byte-File
    mkdir ~/Desktop/Real-DMG-File
  3. Use AutoDMG to create an image: Use AutoDMG, the latest version of the OS X or macOS installer ("Install macOS Sierra" - but from 10.11 make a 10.11 image, and use 10.12 to make a 10.12 image), and any additional apps or packages in .pkg format, to make a never-been-booted .dmg of the OS. Let's say you name this "MyUnbootedImage.hfs.dmg" Save the file to ~/Desktop/Real-DMG-File.
  4. Use Terminal to create an empty placeholder file: Use the touch command, which either updates the time stamp on an existing file, or creates a new file if one doesn't exist yet. Use the same name as you used for the real AutoDMG file:
    touch ~/Desktop/Zero-Byte-File/MyUnbootedImage.hfs.dmg
  5. Copy the placeholder file to your local repository:
    cp ~/Desktop/Zero-Byte-File/MyUnbootedImage.hfs.dmg /jamf/Packages/MyUnbootedImage.hfs.dmg
  6. Copy the placeholder file to the JAMF Cloud Distribution Point: Open Casper Admin if it isn't open yet. In the Casper Admin sidebar, in the Repository section in the upper-left corner, select All Items. Drag the empty ~/Desktop/Zero-Byte-File/MyUnbootedImage.hfs.dmg file into Casper Admin.
  7. Configure the settings for the placeholder file: In Casper Admin double-click the placeholder file you just dragged into Casper Admin. Click the General tab then set the Category if applicable (I usually use "OS"). Don't select the checkbox ("Item is a DMG...") Click the Options tab then set the Priority to 1. Leave the other options at their defaults. Close the Information for MyUnbootedImage.hfs.dmg window.
  8. Add the placeholder to a Configuration: Drag the placeholder into the appropriate Configuration in the Casper Admin sidebar. If you don't already have an imaging configuration, click New Config in the Casper Admin toolbar.
  9. Replicate: Select the local repository (/jamf) in Casper Admin, then click Replicate. Don't worry that when you open Casper Admin again, the placeholder appears in red.
  10. Save and quit Casper Admin.
  11. Copy the useful .dmg file to your local repository so that Casper Imaging can use it:
    cp ~/Desktop/Real-DMG-File/MyUnbootedImage.hfs.dmg /jamf/Packages/MyUnbootedImage.hfs.dmg
  12. Use Casper Imaging: In Casper Imaging, the configuration with the dmg should now be available, and you can use Target Mode imaging.

Don't worry, you do not need to copy the empty .dmg back to your local repository when you replicate again!

5 REPLIES 5

akarneboge
New Contributor II

Thanks Arek!

Josemocha
New Contributor II
New Contributor II

Great pro tip!

Christopher Holmes, Jamf Certified Trainer & Integrator

ccarlton
New Contributor II
New Contributor II

Nicely done!

peter
New Contributor III
New Contributor III

@arekdreyer Awsome stuff!

I'm of the engineers who built JCDS and I'd like to provide some clarification here:

But when I try to upload it to my Jamf Cloud Distribution Point, it fails because of the current 5GB file limit from Amazon S3)

All JCDS->S3 uploads use the Multipart upload, which has a 5TB limit, so that's the theoretical limit for JCDS. In addition, all JSS->JCDS communication sends files in much smaller chunks to be reassembled later. Unfortunately, there are two product issues (PI-002171 and PI-003331) that are making things difficult when it comes to large files. Casper Admin uploads files to the JSS all in one request, so if anything happens to a connection on either the server or Casper Admin, the whole upload fails (PI-002171). Uploading through the Jamf Pro webapp sends small chunks directly to JCDS, bypassing the JSS entirely and retrying any file chunks that fail. That was built to be the most reliable way to upload files to JCDS, but currently your session can time out before that upload completes (PI-003331). Jamf is working to address these issues and, as we plan any upcoming work on distribution, I'll be sure to link back to this post so that we can make sure that this kind of workaround isn't necessary in the future.

arekdreyer
Contributor

Thanks, @peter. I jumped to a conclusion that I shouldn't have. I updated my article. I shouldn't have shared a reason for the problem I was experiencing, without confirming that it was correct; I won't do that again. Thanks for the clarification.