Skip to main content

If I have a .pkg which requires the existence of another file in the same directory that the .pkg is run. How would I accomplish this utilizing Jamf Pro?



It seems I need to know the following:



1) where Jamf copies and runs a .pkg from locally
2) how to accomplish copying the dependent file to that location first in the policy, prior to the .pkg running.



Any help would be appreciated :)

Off the cuff, How i'd skin this cat, Gonna reverse your thought process here. I'm not saying your wrong, you can 100% do it & it'd be perfectly fine. This is just how I would personally attack this. Instead of deploying your file to the location Jamf deploys packages to, My method involves complete control of where you place both the .pkg & file.



For this example



Your file path will be - /Library/BrianMcBride/
Your .pkg will be - McBride.pkg
Your "Another File" will be - Brian.file
Your Package containing McBride.pkg & Brian.file will be "FullPackage.pkg"



Step 1. Create the FullPackage.pkg with composer placing your McBride.pkg & Brian.file in the /Library/BrianMcBride/ directory.



Step 2. Create a script in jamf containing the following



#!/bin/sh

installer -target / -pkg /Library/BrianMcBride/McBride.pkg


Step 3. Create a policy that installs "FullPackage.pkg" on end user machine placing your McBride.pkg & Brian.file in the /Library/BrianMcBride/ directory



Step 4. Add the script you created in Jamf & set to run After



& that should do the trick, a few different ways to do this but thats my 2cents, hope it helps!


The other way to do this would be to repackage the original pkg. Drop the pkg and other loose files into a tmp folder as a payload, and include a postflight script that runs the installer command mentioned above. This way it's fully self-contained, so if you need to distribute the pkg some other way it's not relying on a second policy.


I've always approached this the way @alexjdale mentioned. Keeping the post install script inside the .pkg itself, that way it's self contained and doesn't need a script running as After in the policy. It's the same general idea though. This approach has always worked well for me with these types of installers.


@Hugonaut Thanks a ton, this worked flawlessly. I was exploring repackaging the pkg to include the dependent file but I didn't realize I needed a script to kick off the original package installation. This makes sense now. To the others, thanks for the responses, I may try this the next time I go through this exercise!



Brian


You're welcome @brianmcbride99 glad to help. What @alexjdale & @mm2270 advised is the same exact thing but without a doubt a much cleaner approach.