I'm deploying a dmg with a script to install it (Chemdraw). To mount the dmg manually, it needs the enter key to be hit many times and then "yes" followed by another enter to accept the license agreement. In my terminal,
hdiutil attach cd201.dmg >/dev/null < <(echo y) >/dev/null < <(echo y)
works perfectly to attach it silently. But when I put it in a jamf policy, it fails with this error:
|Running script Install and Activate Chemdraw...|
|Script exit code: 2|
|Script result: /Library/Application Support/JAMF/tmp/Install and Activate Chemdraw: line 2: syntax error near unexpected token `<'|
/Library/Application Support/JAMF/tmp/Install and Activate Chemdraw: line 2: `hdiutil attach cd201.dmg >/dev/null < <(echo y) >/dev/null < <(echo y)'
|Error running script: return code was 2.|
Why does it run on my terminal but fail in Jamf? How can I fix this?
I'm curious why you're trying to install it this way - mounting the disk image and then presumably copying or installing whatever is in the mounted disk image, instead of just copying what's in the disk image and deploying that?
It just doesn't seem like a good way to approach this to me. What if a future version changes the types of responses needed to mount the disk image? Your script will break again, even if you manage to get it working from a Jamf policy as is.
If you're doing it this way because there's some license file or config file in the DMG that the installer needs to see, there's likely a way around that to make it work in a normal package install.
I've been trying to do something similar. Currently to track which macs aren't actively deployed I've gotten a script written that tacks on the word inventory to the end of the computer's serial name so that it will then display in a smart group that is showing all comps with inventory in the name I've done this because I'm on a small team and we don't have the resources to manually assign and keep track I'm barely keeping up as is.
The policy flat out fails to run the script on a triggered event so I found a work around that at first worked flawlessly where instead of a plicy that runs a whole script for the task it writes a .command script to the Helpdesk users desktop folder so that then it;s already there and all a user has to do is double click to launch the command script and enter in the pw to trigger another check in. however the policy has only successfully written the script file 3/8 times and I'm not sure why.
below is the script it runs phenominally when created on a local machine and the path's aren't an issue here. but when I check the logs it says the file that is supposed to be made doesn't exit both with and without touch it hasn't been working so I'm out of Ideas as to what could be the cause.
I've written other scripts that work with this stuff without issue but this one just will not work.
#automated assignment of macs to cabinet user to collect as not curren>
#echoing a series of commands out to a file that will be Placed in the>
sudo scutil --set HostName inventory
sudo scutil --set LocalHostName inventory
sudo scutil --set ComputerName inventory
#setting a policy reload to trigger check in which will then display t>
sudo jamf -policy reload
exit 1" > Desktop/storage.command
#changing to allow execute permissions as by default
chmod +wxr Desktop/storage.command
#changing the owner of the file to wheel group and the Helpdes>
chown Helpdesk wheel Desktop/storage.command
@Asmodan The problem is likely how you're defining where the script should be created, as in this line at the end:
exit 1" > Desktop/storage.command
That's not a valid path. It might work for you when you run the script locally, but when a Jamf policy runs the script, it runs it as root, so you're telling it to make the storage.command file in the root's Desktop path. And I'll add, that isn't exactly the proper way to do it. Usually it would be ~/Desktop/storage.command. For this script though, you need to provide a full path to where the file needs to be created, such as:
Try that. It should fix the issue.