+9I have a package that only successfully installs when the logged on user runs it.
Is there a way to deploy this via Self Service but not use the Jamf Binary account to install it?
The other option could be to deploy the package to the user's desktop for them to manually run but I can't find a way to do that either.
+26I have not tried this for running a package, but it is possible to run commands as the logged in user.
Something like this may be a good starting point, but again I'm not quite sure how a package will behave when triggered like this. You would need to cache the package and not install it, then use the command to run the package. Due to this you may not get much logging within Jamf.
loggedInUser=$(stat -f %Su /dev/console)
userUID=$(id -u "$loggedInUser")
launchctl asuser "$userUID" sudo -u "$loggedInUser" installer -pkg "/Library/Application Support/Jamf/Waiting Room/your-package.pkg" -target /
+9The obvious question is what is the package for? As there is a strong possibility there is another version available from the vendor/developer suited to your needs. Tools like zoom.os do this, the normal download version is designed to be installed by the user, and installs into the users profile accordingly, but there is a download package available that is designed for IT deployment, installing Zoom into the main /Applications folder.
Second to that Jamfs Composer can help you repackage the package in a couple of different ways, it can create a DMG to help place the package on the user's desktop (or a pkg, so a pkg in a pkg), or it can attempt to deconstruct the package to allow you to essentially rebuild it with change that potentially remove the logged in user requirement (there are other tools that can also help with this, Pacifist, there's one call Packages, there are some command line tools, etc).
In the end tho, I would start with the vendor/developer looking for a managed/IT install package and go from there.
+8Hi @RDowson ,
If you want to save the file to the Desktop so that users can install it manually, you can follow these steps:
Upload the YourApps.PKG file to GitHub.
Download the file using the following Jamf script, which saves it to the Desktop:
Create a policy in Jamf that includes this script and apply the desired scope.
+3Hi @RDowson ,
If you want to save the file to the Desktop so that users can install it manually, you can follow these steps:
Upload the YourApps.PKG file to GitHub.
Download the file using the following Jamf script, which saves it to the Desktop:
Create a policy in Jamf that includes this script and apply the desired scope.
I've created a script where I curl the pkg file from a web address, place it in "/var/tmp", make sure the user has access to run it (chmod), and then run it pretty much as @AJPinto Describes above just with the package in "/var/tmp/some.pkg", then delete the pkg.
(For example, This would work with Box Tools/Edit as it wants to be a user-based installl)
+9I have not tried this for running a package, but it is possible to run commands as the logged in user.
Something like this may be a good starting point, but again I'm not quite sure how a package will behave when triggered like this. You would need to cache the package and not install it, then use the command to run the package. Due to this you may not get much logging within Jamf.
loggedInUser=$(stat -f %Su /dev/console)
userUID=$(id -u "$loggedInUser")
launchctl asuser "$userUID" sudo -u "$loggedInUser" installer -pkg "/Library/Application Support/Jamf/Waiting Room/your-package.pkg" -target /
Thanks. When running this I get the following error:
Script result: installer: Error - the package path specified was invalid: '/Library/Application Support/Jamf/Waiting Room/PaperCut.pkg'.
I assume this is because the user account doesn't have permissions to the Waiting Room folder? Is there a way to modify the script to allow this to work?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.