Skip to main content
Solved

Copying Cached Installers from a Local Distribution Point

  • October 4, 2013
  • 5 replies
  • 56 views
R
Forum|alt.badge.img+8

I don't know if my subject made sense, but here goes...

Most of the software installs we deploy go through a two-step process: cache the installers, then run the installers.

I'm testing different ways to run the Adobe CS6 installation (at logout, in the background, at startup, etc.), but to save cooking time, I'd like to be able to cache the hefty-sized CS6 .pkg file from a Mac that has a local distribution point, over either a Firewire or Thunderbolt connection instead of letting it cache from our JSS server.

Occasionally we'll push out cached .pkg files through Casper Remote, but it doesn't appear to interact with the local distribution point the same way that Casper Imaging can. Am I missing something or is this not possible through the standard Casper suite? Thanks!

JSS 8.62, etc, etc.

Best answer by mm2270

Ah I see now what you're looking to do. Thanks for the additional details.

So, I can't say that this would necessarily work for you, but when a package gets cached down, there are really only 2 files that get placed onto the Mac. 1) The package itself and 2) an xml file describing some basics about the package.

What you may want to try is to first cache these files down to one of your test Macs and then capturing these 2 (or more) files in the /Library/Application Support/JAMF/Waiting Room/ directory. I'd just package them up in an installer or even just make a copy of them to a different location before running any test policies on the Mac.
Since the policy run will delete those files after installation completes, making a backup of them should allow you to simply copy them back to the test Mac after each test policy run, which will be loads faster than having them re-cache down every time. Then just make sure to do a sudo jamf recon, just in case you have something like Smart Groups that depend on the existence of those cached files being in place.

There's nothing all that special about the caching process. Its simply copying down the installer and creating an xml file that rides along with it. The xml file has some information about it such as the package name, the package ID (as seen in Casper Admin) whether the package was specified to use FEU/FUT options, and a few other possible items.

Note that the "Waiting Room" directory is a locked location (only root can peek inside) so you'll want to use a Terminal session to make a copy of the files there.

sudo cp /Library/Application Support/JAMF/Waitiing Room/* ~/Desktop/CacheCopy/

If your package isn't a flat package you may need to throw the -R option into the above copy command.

Once you've gone though a policy that installs the cached packages, just do this to get them back in place-

sudo ~/Desktop/CacheCopy/* /Library/Application Support/JAMF/Waiting Room/; sudo jamf recon

Hopefully that helps you some.

    5 replies

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • October 4, 2013

    I'm not sure I completely understand what the goal is here. When you say, "I'd like to be able to cache the hefty-sized CS6 .pkg file from a Mac that has a local distribution point, over either a Firewire or Thunderbolt connection instead of letting it cache from our JSS server." I'm confused on exactly how you envision this working. Are we talking about an imaging process? Because your post doesn't make it sound like this is being done at imaging time, since you talk about possibly doing it at logout or startup. I'm assuming you mean to cache this to already deployed systems, in which case, how would this work to use a FireWire or Thunderbolt connection?

    R
    Forum|alt.badge.img+8
    • RobbG
    • Author
    • Contributor
    • October 4, 2013

    Hi Mike, sorry for the confusion and thanks for the reply...

    I'm just trying to save some time while I'm testing different installation scenarios. Since cached .pkgs have to copy down from our JSS server over the LAN, it can take a while for the 4 GB Adobe CS6 installer to complete (up to 30 minutes) before I can test a different installation.

    Sometimes I'll use Casper Remote to copy a cached installer to a Mac, but again it's copying down from the JSS server (we then let the install policy run from the JSS server).

    We have a couple of Macs set up as Imaging stations with a local distribution point so that we can image Macs in target mode either by Firewire or Thunderbolt, which is a lot faster than imaging over the LAN connection to the JSS server.

    So my thought was, "I can use Casper Remote to cache installers from the JSS server, can I do the same from an Imaging Mac that has a local distribution point?" The file transfer would be much faster than waiting for it to copy over the LAN and the follow up install policy would still run from the JSS server. The problem is that Casper Remote only appears to interact with the JSS server, where Casper Imaging can be toggled to run from the JSS or from a local distribution point.

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • Answer
    • October 5, 2013

    Ah I see now what you're looking to do. Thanks for the additional details.

    So, I can't say that this would necessarily work for you, but when a package gets cached down, there are really only 2 files that get placed onto the Mac. 1) The package itself and 2) an xml file describing some basics about the package.

    What you may want to try is to first cache these files down to one of your test Macs and then capturing these 2 (or more) files in the /Library/Application Support/JAMF/Waiting Room/ directory. I'd just package them up in an installer or even just make a copy of them to a different location before running any test policies on the Mac.
    Since the policy run will delete those files after installation completes, making a backup of them should allow you to simply copy them back to the test Mac after each test policy run, which will be loads faster than having them re-cache down every time. Then just make sure to do a sudo jamf recon, just in case you have something like Smart Groups that depend on the existence of those cached files being in place.

    There's nothing all that special about the caching process. Its simply copying down the installer and creating an xml file that rides along with it. The xml file has some information about it such as the package name, the package ID (as seen in Casper Admin) whether the package was specified to use FEU/FUT options, and a few other possible items.

    Note that the "Waiting Room" directory is a locked location (only root can peek inside) so you'll want to use a Terminal session to make a copy of the files there.

    sudo cp /Library/Application Support/JAMF/Waitiing Room/* ~/Desktop/CacheCopy/

    If your package isn't a flat package you may need to throw the -R option into the above copy command.

    Once you've gone though a policy that installs the cached packages, just do this to get them back in place-

    sudo ~/Desktop/CacheCopy/* /Library/Application Support/JAMF/Waiting Room/; sudo jamf recon

    Hopefully that helps you some.

    S
    R
    Forum|alt.badge.img+8
    • RobbG
    • Author
    • Contributor
    • October 9, 2013

    Thanks Mike, that's a great idea! In this particular case the .pkg file was cooked up by the AAME builder so it's a flat .pkg file instead of a .dmg.I'll just copy the files from the waiting room and re-add them when I have another test to run.

    S
    Forum|alt.badge.img+1
    • Srvan
    • New Contributor
    • November 25, 2024

    Ah I see now what you're looking to do. Thanks for the additional details.

    So, I can't say that this would necessarily work for you, but when a package gets cached down, there are really only 2 files that get placed onto the Mac. 1) The package itself and 2) an xml file describing some basics about the package.

    What you may want to try is to first cache these files down to one of your test Macs and then capturing these 2 (or more) files in the /Library/Application Support/JAMF/Waiting Room/ directory. I'd just package them up in an installer or even just make a copy of them to a different location before running any test policies on the Mac.
    Since the policy run will delete those files after installation completes, making a backup of them should allow you to simply copy them back to the test Mac after each test policy run, which will be loads faster than having them re-cache down every time. Then just make sure to do a sudo jamf recon, just in case you have something like Smart Groups that depend on the existence of those cached files being in place.

    There's nothing all that special about the caching process. Its simply copying down the installer and creating an xml file that rides along with it. The xml file has some information about it such as the package name, the package ID (as seen in Casper Admin) whether the package was specified to use FEU/FUT options, and a few other possible items.

    Note that the "Waiting Room" directory is a locked location (only root can peek inside) so you'll want to use a Terminal session to make a copy of the files there.

    sudo cp /Library/Application Support/JAMF/Waitiing Room/* ~/Desktop/CacheCopy/

    If your package isn't a flat package you may need to throw the -R option into the above copy command.

    Once you've gone though a policy that installs the cached packages, just do this to get them back in place-

    sudo ~/Desktop/CacheCopy/* /Library/Application Support/JAMF/Waiting Room/; sudo jamf recon

    Hopefully that helps you some.


    @mm2270 One easy way to deal with larger files. You may get permission denied, even if you use 'sudo' while performing operations with "Waiting Room", in that case use below command.

    Command:

    sudo sh -c 'cp /Library/Application\\ Support/JAMF/Waiting\\ Room/* ~/Desktop/CacheCopy/'

    sudo sh -c runs the command with elevated privileges. You can also add additional command along with above by adding '&&'. && ensures the next command runs only if the cd command is successful.

    For example:

    sudo sh -c 'cp /Library/Application\\ Support/JAMF/Waiting\\ Room/* ~/Desktop/CacheCopy/ && YOUR_NEW_COMMAND'

    Terms & ConditionsCookie settingsAccessibility statement