The 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
The 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
Thank you for your reply. I'm not expert at Jamf Pro. How can i toggle or do policy call for a policy?
The 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
Another 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.
I'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
I 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
I typically just do two policies as its easier to maintain. However, it is possible to build a package to do what you are wanting.
- Place both Intel and Apple Silicon packages in a working directory.
- Use Composer to build a package containing both packages from step 1.
- Use a post install script to check the CPU architecture and run the correct package and clean up the source files when done.
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
One 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:
Name Frequency Trigger Scope
Install App Apple Ongoing installApp Apple Silicon Macs, 2 computer groups excluded
Install App Intel Ongoing installApp Intel Macs, 2 computer groups excluded
App Once Per Computer Check-In All Computers
The 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
Hello 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?