+4From an enrolled client, I am attempting to install a package stored on the JSS.
JAMF's help documentation states the syntax should appear as:
jamf install -package <filename> -path <path to file> -target <volume>
[-fut] [-feu] [-showProgress]
I have run the following command unsuccessfully and am looking for help in correcting it:
sudo jamf install -package "Mozilla_Firefox_14.01_V1.dmg" -path "//JSS/caspershare/packages" -target "Mac HD" -showProgress
Best answer by mm2270
OK, I see what you're trying to do. I think both Tom and Don are thinking of the same solution i would be, which is to call a manual trigger policy from your script in your procurement system, rather than trying to go around the use of a policy altogether. Doing it that way, you wouldn't need to worry about mounting a share or what protocol to use, etc. Its still a JSS policy, but one that doesn't show up in Self Service and won't be called by any action on the workstation, like startup, login, every15 etc.
If you can get your "Buy" button to run a 'sudo jamf policy -trigger 'manualTriggerName' on the workstation itself as the user clicks the button, you should be good.
Just scope it to all Macs that you'd expect to use it, and set it to a "once per computer" frequency.
+16First off, is there a reason you're trying to do the install this way rather than through a policy or another method?
Second, the share has to be mounted for the path part to see the package and run the install successfully. I'm pretty sure If you didn't mount your "packages" sharepoint in a previous step, its going to fail. Also, in my tests, I entered the path as /Volumes/ShareName/CasperShare/Packages/
+31Hi Eveyrone
Manual trigger policies? Also try installing the package by the JSS ID? Are the two things I'd look at.
Thanks,
Tom
+36I actually wouldn't mind using this kind of command, except for the -package and -path needed...do JSS packages have IDs we can use instead?
Just a thought...if this were possible, would make this a whole lot easier, no need for policy(ies):
jamf install -id <package-id> -target <volume>
[-fut] [-feu] [-showProgress]The above isn't valid, just sayin'...
+13upvote this bizness:
https://jamfnation.jamfsoftware.com/featureRequest.html?id=762
a puppy dies every time a vendor ships such hacked together binaries without man pages.
+4I posted this question for the following reason:
In my companies current environment, we have a software procurement tool that users purchases software license through. We'd like to be able to set up an "install" button from the software procurement website that, upon clicking, would communicate w/ the JSS and install the purchased software. We intended to use the command ```
jamf install -package -path -target
``` coupled with SSH to fulfill this function.
+36@darms21 wrote:
I posted this question for the following reason:
In my companies current environment, we have a software procurement tool that users purchases software license through. We'd like to be able to set up an "install" button from the software procurement website that, upon clicking, would communicate w/ the JSS and install the purchased software. We intended to use the command
jamf install -package -path -target
Hi Kevin,
Did you mean you want the procurement system to talk to the jamf binary on the workstation? So a user would hit "Buy Photoshop" and the procurement system would invoke a policy trigger "jamf policy -trigger installphotoshop", and of course limit the policy to run once per Mac?
Don
+16OK, I see what you're trying to do. I think both Tom and Don are thinking of the same solution i would be, which is to call a manual trigger policy from your script in your procurement system, rather than trying to go around the use of a policy altogether. Doing it that way, you wouldn't need to worry about mounting a share or what protocol to use, etc. Its still a JSS policy, but one that doesn't show up in Self Service and won't be called by any action on the workstation, like startup, login, every15 etc.
If you can get your "Buy" button to run a 'sudo jamf policy -trigger 'manualTriggerName' on the workstation itself as the user clicks the button, you should be good.
Just scope it to all Macs that you'd expect to use it, and set it to a "once per computer" frequency.
+4Thanks for the recommendation. I think we will go w/ the manual policy execution. The ability to quickly view the policy status/logs is reason enough.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
