Category: Deployment

This post is an update to an older post on the same topic. macOS has changed and I had a few things to add. Rather than keep modifying the older post, I decided to make this new one.

As MacAdmins, most of the scripts we write will use tools that require administrator or super user/root privileges. The good news here that many of the management tools we can use to run scripts on clients already run with root privileges. The pre– and postinstall scripts in installation packages (pkgs), the agent for your management system, and scripts executed as LaunchDaemons all run with root privileges.

However, some commands need to be run not as root, but as the user.

For example, the defaults command can be used to read or set a specific setting for a user. When your script, executed by your management system, is running as root and contains this command:

defaults write com.apple.dock orientation left

Then it will write this preference into root’s home directory in /var/root/Library/Preferences/com.apple.dock.plist. This is probably not what you intended to do.

Get the Current User

To get the correct behavior, you need to run the command as a user. Then the problem is as which user you want to run as. In many cases the answer is the user that is currently logged in.

I have written a few posts about how to determine the currently logged in user from shell scripts and will use the solution from those:

• Get Current User in Shell Scripts on macOS
• Getting the current user in macOS – Update

currentUser=$( echo "show State:/Users/ConsoleUser" | scutil | awk '/Name :/ { print $3 }' )

This will return the currently logged in user or loginwindow when there is none. This is the Posix sh compatible syntax, which will also run with bash or zsh.

Running as User

There are two ways to run a command as the current user. The first is with sudo:

sudo -u "$currentUser" defaults write com.apple.dock orientation left

The second is with launchctl asuser.

uid=$(id -u "$currentUser")
launchctl asuser $uid launchctl load com.example.agent

The launchctl command uses the numerical user ID instead of the user’s shortname so we need generate that first.

It used to be that the sudo solution would not work in all contexts, but the launchctl asuser solution would. This changed at some point during the Mojave release time.

Now, the lauchctl asuser works and is required when you want to load and unload LaunchAgents (which run as the user), but it does not seem to work in other contexts any more.

So, for most use cases, you want to use the sudo solution but in some you need the launchctl form. The good news here is, that you can play it safe and use both at the same time:

launchctl asuser "$uid" sudo -u "$currentUser" command arguments

This works for all commands in all contexts. This is, however, a lot to type and memorize. I built a small shell function that I use in many of my scripts. Paste this at the beginning of your scripts:

# convenience function to run a command as the current user
# usage:
#   runAsUser command arguments...
runAsUser() {  
  if [ "$currentUser" != "loginwindow" ]; then
    launchctl asuser "$uid" sudo -u "$currentUser" "$@"
  else
    echo "no user logged in"
    # uncomment the exit command
    # to make the function exit with an error when no user is logged in
    # exit 1
  fi
}

and then you can use the function like this:

runAsUser defaults write com.apple.dock orientation left

runAsUser launchctl load com.example.agent

Note: the function, as written above, will simply do nothing when the Mac is sitting at the login window with no user logged in. You can uncomment the exit 1 line to make the script exit with an error in that case. In your script, you should generally check whether a user is logged in and handle that situation before you use the runAsUser function. For example you could use:

if [ -z "$currentUser" -o "$currentUser" = "loginwindow" ]; then
  echo "no user logged in, cannot proceed"
  exit 1
fi

Insert this at the beginning of your code (but after the declaration of the currentUser variable) and you can assume that a user is logged in and safely use the $currentUser variable and the runAsUser function afterwards. The exact detail on when and how you should check for a logged in user depends on the workflow of your script. In general, earlier is better.

When to Run as User

Generally, you should run as the user when the command interacts with the user interface, user processes and applications, or user data. As MacAdmins these are common commands you should run as the user;

• defaults, when reading or changing a user’s preferences
• osascript
• open
• launchctl load|unload for Launch Agents (not Launch Daemons)

This is not a complete list. Third party configuration scripts may need to be run as root or user. You will need to refer to documentation or, in many cases, just determine the correct action by trial and error.

Sample Script

I have put together a script that combines the above code into a working example.

I introduced the Installomator script a while back. We have been using the script with our own Jamf Pro server and some of our customers.

Since I built the script, you’d think I’d have pretty good idea on how it should be deployed. But then Mischa van der Bent showed me a better way of using Installomater with Jamf Pro and I asked him to write it up for a blog post. Since he doesn’t have a blog of his own (yet), he has allowed me to post his instructions here.

Note: Installomator is designed so it can work with other management systems, too. If you have implemented Installomator with a different management system, let me know!

Everything that follows is from Mischa:

Preparation

After you have downloaded or cloned Installomator from Github, you can run Installomator.sh from the command line or from your management system:

> ./Installomator.sh googlechrome

The script requires a single argument: a label that chooses the application to download and install. (you can find a list of labels of applications in the Labels.txt file in the repository)

Adding the Installomator Script to Jamf Pro

The first thing we need to do is create a new Script in Jamf by going to Settings > Computer Management > Scripts.
In the General section you can give the Script a Display Name. I called mine Installomator. Assign a category and add the link to the GitHub repository to the notes as a reminder of the source of this script.

In the Script section, paste the entire code from the Installomator.sh file.

Important: Change the DEBUG variable from 1 to 0 for using Installomator in procduction, otherwise it will not actually install the new software.

The script requires a single argument and designed to use argument 4 from Jamf when present.

We can set the Parameter Label of parameter 4 to “Application name” in the Options section. This is going to be a reminder that we need to fill in the argument when we are creating a policy. You can leave the labels for the other parameters empty or fill in “DONT-USE” because the script does not use the other arguments.

We are done here and you can save the Script.

Scoping

To make sure that we are targeting to the right devices with an older release version we need to create a couple of things.

I’m going to use Jamf Patch Management to determine the latest release version of Google Chrome. Jamf will check the version before publishing this into the Patch Management. And if the software title is not in Jamf default Patch Management list you can create your own Patch Management source and add this on to Jamf Pro. You can also join the community patch server.

Go to Patch Management under Computers > Content Management and create a New Software Title. We are going to use Jamf Repository. Scroll down the list and select Google Chrome.
The only thing we need to set here is the Software Title Settings and assign a Category. You can select the Jamf Pro Notification option to get emails when an update is posted..

Jamf Patch Management will query the inventory and list the clients where Google Chrome is installed and their versions. We now have the all the information we need!

Two Smart Computer Groups

Go to Smart Computer Groups and create a new one. I called this “Google Chrome not installed or out of date”

In the ‘Criteria’ section I add two criteria:

• Patch Reporting Software Title: after choosing this select the right report; for our example select “Patch Reporting: Google Chrome”
• change the ‘Operator’ to “Less than” with the ‘Value’ “Latest Version.”
• add a second line and Changed the AND/OR to “or” and for the second criteria I used “Application Title”
• change the ‘Operator’ to “does not have” with the ‘Value’ “Google Chrome.app”

This Smart Group will contain the clients where the application is not installed or is not up to date.

Unfortunately, we cannot use this smart group with a Policy. When you try you will get this error ‘Policy scope cannot be based on a smart computer group that uses the “latest version” criteria.’

But there is a work around:

• create a second Smart Group, I called this one “Member of Google Chrome not installed or out of date”
• in the ‘Criteria’ section add the criteria “Computer Group” changed the ‘Operator’ to “member of” with the ‘Value’ to “Google Chrome not installed or out of date”

The result is the same as the Smart Computer Group “Google Chrome not installed or out of date” but we can use this in a policy.

Policy

Let’s put all the bits and pieces together and create one policy that will install or update to the latest release version of Google Chrome. We also want to promote this in Self Service and we want to push this out as a mandatory update with a deferral duration of 7 days.

• go to Policies and create a new one. I called this policy “Google Chrome”
• use “Recurring Check-in as the trigger, and set the custom event value to ”googlechrome.” With the custom trigger name, we can use this policy in a script or can test with the terminal command sudo jamf policy -event googlechrome -verbose
• set the ‘Execution Frequency’ to On-Going.
• add the Installomator script to the payload
• the Priority doesn’t matter, because there is no package, so leave it default ‘After’

• in the Parameter values you see that the first one is ‘Application name’ (which we set earlier). Set “googlechrome” as value.

I removed the payload “Restart Options” because we don’t need to restart after we install Google Chrome , we can leave it there, but I like to keep my policies clean.

We need to report back to the Jamf Pro Server that we just installed the latest version so we are going to add the payload “Maintenance” and enable “Update Inventory” (this should be enabled by default).

We are done with the payload and need to set the Scope:

• under target we add the Smart Computer Group: “Member of Google Chrome not installed or out of date”

Self Service

• enable “Make the policy available in Self Service”
• leave the Display Name the same as Policy.
• Button Name Before Installation: use “Install”
• Button Name After Installation: use “Update”
• give a Description to display for the policy in Self Service like “Install or Update to the latest release of Google Chrome”
• upload or select the Google Chrome icon for making the Self Service pretty (you can use the macOS Icon Generator app)

• under User Interaction we change the Deferral Type to “Duration” and use 7 days.
• we don’t need to set a Start or Complete Message (Installomator can notify on success)

Now, we can save and test the policy.

Testing

I tested this Policy with a couple of scenarios;

The first scenario is: no Google Chrome installed. Second: old version Google Chrome installed, notification for update, end user deferral, and later installation from the Self Service. Third: Google Chrome Beta is installed

The first scenario is easy, after running the policy latest version get installed.

In the second scenario I got prompted with the following message, and I submitted 1 hour.

I can’t install this update before the hour because I got this message in the jamf log “Policy ‘Google Chrome’ will not be executed because it was deferred by the user.”

The last scenario I installed the Google Chrome Beta version 84.0.4147.30, the latest version in Patch Management (for this moment) is 83.0.4103.61. This beta version registers as an “Unknown Version” and it will not fall into scope.

I can use this policy with the Installomator script to install the latest version on a clean machine, and I can push out an update (with a deferral time) to push a mandatory update in a polite way 😉

Because Installomator is checking the Developer Team ID of Google directly, I can be confident that it is the real installer from Google. So, we get security with less effort.