Armin Briegel, a Mac admin, consultant and author, walked JNUC 2020 participants through best practices when scripting for Jamf Pro.
There are many ways to script Jamf:
- Policy scripts
- Extension attributes: miniscripts
- Installation scripts
- LaunchDaemons/Agents
- Application scripts
- Terminal
How the shell environment affects scripts
You write a script, it works in testing, and it stops working. Why?
Each shell has its own environment. Each terminal gets its own instance and shell options variables, aliases and functions. When you run in Terminal, all of this is built from configuration in your terminal application, but also from the shell config files you may have created or gotten from third-party. Your scripts runs from this and inherits a certain environment.
When you run the same script as a Jamf policy or installation script, the shell will have a different environment. Data may be missing, which may lead to your script failling.
do not assume these even exist: $USER, $HOME, $SHELL, $PWD
The path environment variable will not be the same.
depending on the environment, the default path will be different.
Universal PATH folders you can rely on:
/bin /sbin /usr/bin /usr/sbin
the /usr/local/bin folder is not protected; it's meant to be a place for you to add functionality to the terminal, and because of that it might be unreliable for management.
One solution around this uncertainty is to always use the full path to commands.
Downsides: there's more code to type and to read, and there's more to remember.
There's a slight risk you'll override built-ins (/bin/echo)
A better way of creating an environment you can be certain about is to create that environment at the beginning of your script.
User Context
Scripts also inherit the user who is running the shell in terminal. But if you launch the same script from Jamf or an installation script, it will be running as root. This effects the behavior and what it can access. Many management tasks require root, but some require that it be run as user. Briegel offered several scripts to address this issue.
PPPC and (Apple)Scripts
These scripts generally need to run as the user. For safety, run all osascripts as the user. AppleScript usually talks wtih other processes that are owned by the user, and Mac has protections against root-run processes.
Display Dialog/Notification scripts also need to be run as the user.
Exempt Apple events
The following Apple events don't require approval:
- activate
- open
- open location
- quit
If you use a command that is not one of these four, the user will get a privacy dialog notification.
To avoid privacy prompts,
- Remove uneccessary tell blocks
- Use excempt Apple events
- Find alternative solutions such as using the Cocoa library or Briegel's own tool 'Desktoppr.'
Sometimes creating a PPPC profile is necessary.
Briegel walked users through building an approval profile. The best tool for this, he said, is the PPPC Utility profile creator or iAmazing profile tool. Upload it to your MDM and give certain processes pre-approval.
For the full script description and details, view the scripting Jamf JNUC 2020 video.
You can find all of the scripts, the keynote and other resources Briegel shared during this presentation at his website for JNUC 2020.
by Category:
Have market trends, Apple updates and Jamf news delivered directly to your inbox.
To learn more about how we collect, use, disclose, transfer, and store your information, please visit our Privacy Policy.