Category: Munki

Control Apple Remote Desktop Access with Munki

Previously, I posted how to ensure SSH access is enabled with Munki. Another favored (though sorely neglected by Apple) tool to remote control Macs is obviously Apple Remote Desktop.

Note: Apple Remote Desktop access is called ‘Remote Management’ in the Sharing Preference Pane. This also includes access for the Screen Sharing application.

We will use a nopkg setup to control, so we need one script to check wether the configuration needs to be fixed (ard_installcheck.sh) and a postinstall script to actually do the fixing (ard_postinstall.sh).

The install check script first tests wether ardagent process is running, wether the “All Users” access option is turned on, and finally wether our user for remote access (clientadmin in this example, modify for your needs) is in the privileged group.

Paradoxically, the installcheck has to return 1 when everything is ok. (The actuall install does not have to run so the install is aborted.) If any of the settings aren’t as they should be the script returns 0 (installation needs to proceed) and Munki will run the postinstall script.

The postinstall script uses the kickstart tool to setup ARD the way we want it. (In this example we enable access for two admin accounts clientadmin and localadmin, modify to what you need.)

The run makepkginfo to build the pkginfo which tells Munki what to do:

makepkginfo --name=EnableARD \
    --displayname="Enable Apple Remote Desktop" \
    --pkgvers=1.0 \
    --nopkg \
    --installcheck_script=ard_installcheck.sh \
    --postinstall_script=ard_postinstall.sh \
    --unattended-install > EnableARD.pkginfo

(ard_installcheck.sh and ard_postinstall.sh need to be in the current working directory, or give the path to the scripts.)

Then copy the pkginfo file to the pkginfo folder on the munki repository (or a subfolder), add EnableARD to a manifest and run makecatalogs.

Run managedsoftwareupdate on a client that has that manifest configured.

Even if a user changes the “Remote Management” setting, the next time Munki runs in the background it should notice the change and set them back with the postinstall script.

Creating a Droplet for munkiimport

You can use Automator to build an applet for munkiimport. Then you can just drag and drop pkgs, dmgs and Applications on it to import them.

However, can’t just use do shell script since munkiimport will prompt for some extra information. Instead you can use Terminal’s command do script. While do shell script will execute then given command quietly in the background, do script will open a new Terminal window and run the given command – just what we need.

Open Automator and create a new workflow. Choose ‘Application’ as the template. This template will accept files and folders dropped on it. Add a ‘Run AppleScript’ action and fill in the following code:

on run {input, parameters}
  repeat with x in input
    tell application "Terminal"
      do script "munkiimport" & space & quoted form of POSIX path of (x as alias)
    end tell
  end repeat
  return input
end run

Then save the Automator applet as ‘MunkImport’. (or whatever suites you)

The downside of do script versus do shell script is that you cannot receive and process the result.

Mount a dmg off a web server

I saw this project by Douglas Nerad which stream lines the bootstrapping installation of Munki, so that you can do it while booted from the Recovery partition. This is useful to inject munkitools on a new Mac without having to go through setting up a user.

The read me recommends to put the script and other resources on a USB key, which works fine, as long you have only one USB key. If you have to share this tool among multiple admins keeping the keys up to date (and in your pocket) can be a pain.

If you put all the resources and the script in an dmg file on a web server, you can run

hdiutil attach http://webserver/path/to/InstallThis.dmg

and then run scripts and installer pkgs from the attached volume.

installer -pkg /Volumes/InstallThis/munkitools2-latest.pkg
/Volumes/InstallThis/setupEverything.sh

Note that you cannot run python scripts from the Recovery partition. It is best to use shell or bash scripts.

Push Settings with Munki’s new Profile support

Note: please consider supporting supporting this webpage by purchasing one of my books! Thank you!

The combination of AutoPkg and Munki (or another package distribution system) is very powerful. You can use AutoPkg to automatically download, package and import software from the vendor’s site and then use Munki manifests to choose where and how to deploy. With the Managed Software Center interface, you can give users an App Store like interface to choose from software your insitution provides.

This is all wonderful until the user gets to the “Please Enter Your License Number!” dialog. Installing the software is just the first part of software management. You also need to manage configuration.

Since we do not want to mess around with websites to publish the serial numbers, we need another means of pushing configuration settings with Munki.

Note: your institution’s license agreement with a software vendor may or may not allow distribution of the serial number in this way. Some software may not work this way at all. Please check with the license manager/lawyer at your institution and/or the software vendor before you do this.

Which settings to manage?

My example will be the application Fetch. FetchSoftworks is very gracious as it provides free licences to educational and charitable institutions and it also stores the licensing information in a standard preferences file, which makes it perfect for this example.

You can find a Fetch recipe here. To run it in autopkg do:

autopkg repo-add jleggat-recipes
autopkg run Fetch.munki

And add it to the managed installs or optional installs section for your test client(s).

On a test client, install Fetch and open it. Before you enter any licensing info. Open the ~/Library/Preferences folder in list view and sort the contents by date modified, so the newest changes come first. Quit Fetch again, without entering anything and wait for the Fetch preference file to appear at the top of the list. Note its name (com.fetchsoftworks.Fetch.plist). You can select the file and hit the space bar to see the contents in QuickView.

Note: It may take a few seconds after quitting the application for the plist file to appear. This is because preference management is handled thorugh a system daemon cfprefs which will hold values in memory and wait for an “opportune moment” to actually write new and changed values to disk. Keep this in mind when fiddling with preference files.
The safest way to get an up-to-date view of preferences is using the defaults command in Terminal:

defaults read com.fetchsoftworks.Fetch

Then start Fetch again and enter your licensing information. Once you have successfully licensed Fetch, quit it again. Wait for the list of files in the Preferences folder to update. We see that Fetch has created or updated three plist files. com.fetchsoftworks.Fetch.plist, com.fetchsoftworks.Fetch.License.plist and com.fetchsoftworks.Fetch.Shortcuts.plist. It is pretty obvious which one we are interested in and looking at the contents confirms that the Fetch.License file contains the licensing info. We can verify once more on the Terminal with:

defaults read com.fetchsoftworks.Fetch.License

Note: the com.fetchsoftworks.Fetch domain also contains redundant license information, you could manage it either way. Most applications do not split information this way.

Creating the Profile

There are a few approaches to pushing this plist file to a client machine. You could build an installer package that places this file in a specific user’s home directory, but that would fail if the user name varies from client to client. You could write a postinstall script that moves the file to the current user’s Preferences folder, but that would only work for the current user, not other users and especially not users that may log in the future. There are work arounds for all of these problems, and we may need them for other software. But if we want to control preferences in plist files in either ~/Library/Preferences or /Library/Preferences then the best solution are Configuration Profiles.

Configuration Profiles are also property list files, but use a different schema because they contain more metadata around the settings. Tim Sutton has written a wonderful tool to convert ‘normal’ preference plist files to conifguration profiles: mcxToProfile.

You run mcxToProfile like this:

./mcxToProfile.py --plist ~/Library/Preferences com.fetchsoftworks.Fetch.License.plist --identifier FetchLicense --manage Once

The --manage Once option sets up the profile, so that it sets the preference keys in it once per user and then stops enforcing them. This is usually the safest and least intrusive choice for management, since it allows the application or the user to override or change settings.

Another option for the --manage setting are Often, which will reset the value on every user login. If you do not specify the --manage switch, then the preference keys in the profile will be always enforced and cannot be changed by the user or the application. This might be very useful in a scrictly controlled environment. Some third party applications may only work with one of the possible --manage options. Experiment to find out which.

The command above will generate a file called FetchLicense.mobileconfig open it in a text or property list editor. At the top there is a PayloadContent area where you can find the preference keys from the Fetch.License file nested inside. You can delete any keys and values you do not want to set on the clients.

Further down there are a few top level keys that you will want to modify:

  • PayloadDisplayName: this is the ‘Name’ of the config that will be displayed to the User in System Preferences. You will want to change this from the default supplied by mcxToProfile. You can also use the --displayname option to provide that during profile generation.
  • PayloadOrganization: Your institution’s name. You can also provide this during profile generation with the --organization key.
  • PayloadDescription: a description of what the profile does.

When you later import the profile into Munki it will use these values to fill the pkginfo file.

Testing the Profile

Now quit Fetch and delete all the preferences it may have set. Use the defaults command rather than just deleting the files to make sure cfprefsd is not still caching values:

defaults delete com.fetchsoftworks.Fetch
defaults delete com.fetchsoftworks.Fetch.License
defaults delete com.fetchsoftworks.Fetch.Shortcuts

Then double-click the configuration profile we just created in the Finder. System Preferences should open and prompt to install the profile. Click on “Show Profile” to view the contents, note where and how the data we entered earlier appears. You can also see the keys and settings.

Click “Continue” and confirm again to actually install the profile. You can still inspect the profile in the “Profiles” pane of System Preferences. Remember this for future debugging.

Now launch Fetch again and it should not prompt you for a license. If you can try again with a different user and/or on a different computer/virtual machine.

Importing the Profile into Munki

Once you have confirmed that the profile works as expected. You can import it into Munki. With version 2.2 and higher Munki recognizes files with the .mobileconfig extension as profiles and know how to install, update and un-install them.

To add a configuration profile, you use munkiimport

munkiimport Profile.mobileconfig

As usual munkiimport will interactively confirm extra metadata. It will parse most of the metadata from the profile and use it where appropriate. Then you can use the profile like any other item in munki as a managed install, managed un-install, optional install or update.

In our case we want to deploy the FetchLicense profile whenever the Fetch software is installed. In Munki terminology it is an update-for.

munkiimport FetchLicense.mobileconfig --update-for Fetch

Answer the prompts for the remaining metadata inputs. As an update, this profile does not have to be added to a manifest. As soon as the Fetch package itself is installed on a client, Munki will install the FetchLicense.mobileconfig.

To test, use Managed Software Center to add Fetch or run managedsoftwareupdate if Fetch is a managed install. You should also see the FetchLicense.mobileprofile appear as a required install. Once the install is done, check the Profiles pane in System Preferences to see if the profile is installed. Then open Terminal and run:

defaults read com.fetchsoftworks.Fetch.License

Finally launch Fetch and it should not ask for the license.

Obviously you can use this method to control other settings in Fetch and other applications as well.