+4Hello,
As you know, some applications have separate installation files for Intel and Silicon. For example, I write 2 separate policies for Android Studio.
1 - Android Studio for Silicon
2- Android Studio for Intel
By creating a single policy instead of these two policies. Is it possible to distribute this policy according to the processor model of the machine in scope?
In short, I want to design 1 policy and 2 packages.
Thank you.
+8The easiest answer is some form of scripted toggle, either toggling an install package or a policy call... Basic example would be:
if [ `arch` == arm64 ]; then
# Install a package (from Resources of a master pkg) installer -pkg "AnArmVersion.pkg" -target "${3}" -dumplog
# Call a jamf policy /usr/local/bin/jamf policy -event AnArmVersion
else
# Install a package (from Resources of a master pkg) installer -pkg "AnIntelVersion.pkg" -target "${3}" -dumplog
# Call a jamf policy /usr/local/bin/jamf policy -event AnIntelVersion
fi+4The easiest answer is some form of scripted toggle, either toggling an install package or a policy call... Basic example would be:
if [ `arch` == arm64 ]; then
# Install a package (from Resources of a master pkg) installer -pkg "AnArmVersion.pkg" -target "${3}" -dumplog
# Call a jamf policy /usr/local/bin/jamf policy -event AnArmVersion
else
# Install a package (from Resources of a master pkg) installer -pkg "AnIntelVersion.pkg" -target "${3}" -dumplog
# Call a jamf policy /usr/local/bin/jamf policy -event AnIntelVersion
fiThank you for your reply. I'm not expert at Jamf Pro. How can i toggle or do policy call for a policy?
+25The easiest answer is some form of scripted toggle, either toggling an install package or a policy call... Basic example would be:
if [ `arch` == arm64 ]; then
# Install a package (from Resources of a master pkg) installer -pkg "AnArmVersion.pkg" -target "${3}" -dumplog
# Call a jamf policy /usr/local/bin/jamf policy -event AnArmVersion
else
# Install a package (from Resources of a master pkg) installer -pkg "AnIntelVersion.pkg" -target "${3}" -dumplog
# Call a jamf policy /usr/local/bin/jamf policy -event AnIntelVersion
fiAnother approach that avoids the need for a script to determine the target architecture is to create separate install policies for each architecture triggered by the same custom trigger (e.g. "InstallAppXYZ") and using a scope exclusion to control what processor type it installs on, then have your primary policy use a Files and Processes payload to execute the command "jamf policy -event InstallAppXYZ"). This will trigger installation of the appropriate version without requiring a script.
+8I'll go into a little more detail and give some context.
When you create a jamf policy it has an associated trigger with it. You can have a custom trigger MyApp which can be called (jamf policy -event MyApp) to execute that policy on demand.
Once a policy has the My App trigger and is say scoped to All Computers, you can run sudo jamf policy -event MyApp on any of your jamf clients to have them run the policy. That call could also be executed from within another policy or a script.
This thread is pretty good for info on custom triggers https://community.jamf.com/t5/jamf-pro/understanding-custom-triggers/m-p/192897
+4I use installomator for exactly this purpose. https://github.com/Installomator/Installomator/blob/main/Installomator.sh The logic in the script will determine the cpu and curl the correct version resulting in only 1 policy being needed
+26I typically just do two policies as its easier to maintain. However, it is possible to build a package to do what you are wanting.
I have used the script below in the past.
#!/bin/sh
## postinstall
pathToScript=$0
pathToPackage=$1
targetLocation=$2
targetVolume=$3
# Check the processor architecture and run the correct package based on results.
processor=$(/usr/sbin/sysctl -n machdep.cpu.brand_string | grep -o "Intel")
if [[ -n "$processor" ]]; then
echo "Installing Intel Package"
installer -pkg "/private/tmp/Java_JDK_17.0.6/Oracle_Java_JDK_17.0.6_x64.pkg" -target /
echo "done installing Intel package"
else
echo "Installing M1 package"
installer -pkg "/private/tmp/Java_JDK_17.0.6/Oracle_Java_JDK_17.0.6_ARM64.pkg" -target /
echo "done installing m1 package"
fi
sudo rm -rf "/private/tmp/Java_JDK_17.0.6"
exit 0; ## Success
exit 1; ## Failure
+5One easy way we accomplished this was to make the two policies that actually install the app - one for Intel and one for Apple Silicon. Have them trigger by custom event - "installAppName". You make BOTH the same trigger name, but only scope them to their respective architectures via Smart Group. That way, you can use the same trigger NAME, but the scoping will pull the correct architecture.
Then you have primary policy scoped to all that will call the trigger.
This is especially helpful in the event the separate releases are not in lock step for some reason and you can update one or the other. You should never have to change the actual policy that calls it as it just calls a trigger.
Ex:
+4The easiest answer is some form of scripted toggle, either toggling an install package or a policy call... Basic example would be:
if [ `arch` == arm64 ]; then
# Install a package (from Resources of a master pkg) installer -pkg "AnArmVersion.pkg" -target "${3}" -dumplog
# Call a jamf policy /usr/local/bin/jamf policy -event AnArmVersion
else
# Install a package (from Resources of a master pkg) installer -pkg "AnIntelVersion.pkg" -target "${3}" -dumplog
# Call a jamf policy /usr/local/bin/jamf policy -event AnIntelVersion
fiHello Friend,
i couldnt understand this line.
Install a package (from Resources of a master pkg) installer -pkg "AnArmVersion.pkg" -target
I deploy my packages with smb filesharing. can i set command for that?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.