When my organisation deployed Munki, we did so with little provision for remote support. The reasons for this were:

  • Goals. The focus of the project was to increase the level of Self Service for Mac users, and the ease of deployment of Macs for technicians.
  • Hardware. A majority of our Macs are Macbooks, frequently off site, often abroad. Remote support therefore potentially complicated.
  • Software. Apple Remote Desktop is considered too expensive for widespread use. There are also not enough IT support staff with access to Macs for this to be viable.
  • Resourcing. Of the 500+ staff in IT, there were only 3 considered to be "Mac supporters". This has since reduced to 2! The costs of teaching colleagues in remote support via Screen Sharing or SSH therefore deemed too high. This lead to...
  • The setup of additional tools (MunkiWebAdmin, Munki Report) intended for use by a broader selection of IT support staff. These tools are considerably more user friendly, with less of a learning curve, than the command line.

While the above are all legitimate reasons for our initial approach, we've found an increasing need for per-machine support. MunkiWebAdmin and Munki Report are both excellent tools, but are limited by design in what "hands on" functions they provide. Furthermore, the particular circumstances of the 2 Mac supporters at my organisation (time, location), mean that it's very difficult to arrange face to face support. We engage with end users and IT support staff in a number of ways, but this can often lead to much back and forth in diagnosing issues, retrieving log files, etc. One solution would be to enable Remote Login as part of the automated build process, but this would then only affect machines built from the time of implementation. It also doesn't solve the issue of data retrieval.

I therefore wanted to put together a means of making it trivial for end users and IT support staff to get us the information we need. To this end, I put together 2 simple packages - one that enables Remote Login for members of a Macs Administrators group, and another that copies the most commonly needed log files in problem diagnosis to a folder on the logged in users Desktop. These log files can then be emailed to Mac support via our Incident Management system. Once packaged and imported to our Munki Repo, I created a new manifest and added these items to it. This manifest can then be added to client manifests, and the included packages run by remote users via Managed Software Center.

My setup and workflow is as follows:

  • Macbook Air with SMB access to Munki Repo
  • The Luggage for package creation
  • Bitbucket for version control

The following steps therefore assume you have The Luggage setup on your development machine.

Enable Remote Login

Make your working directory and prepare your files:

$ mkdir -p ~/luggage-packages/enable-remote-assistance
$ cd ~/luggage-packages/enable-remote-assistance
$ touch Makefile && touch postinstall
$ chmod +x postinstall

Modify the contents of your Makefile :

$ vi Makefile
include /usr/local/share/luggage/luggage.make


Modify the contents of your postinstall script:

$ vi postinstall


# Set remote login
systemsetup -setremotelogin on

# Create ssh group

dseditgroup -o create -q com.apple.access_ssh

# Add administrators to ssh group

dseditgroup -o edit -a admin -t group com.apple.access_ssh

Build the package and import to your repository:

$ make pkg
$ munkiimport Enable-Remote-Assistance.pkg

Format the .pkginfo file to your requirements. I opted for the following location:


And a Category of:

Remote Support

You can modify the pkginfo to reset the changes made by changing the uninstall_method:

systemsetup -setremotelogin off

pkgutil --forget your.reverse.domain.Enable-Remote-Assistance

In my testing, using this caused the uninstall to hang, so I simply used removepackages.

Get Log Files

Ideally, I'd want this package to retrieve the log files and email/copy them directly to us. However, this would require modification of the local MTA settings and possibly use of unauthenticated SMTP. Such configuration could be a security risk, and in any case, somewhat beyond me at this stage.

I don't want this to function as a traditional package installer, as a user may need to run this more than once. We can therefore leverage Munki's built-in OnDemand feature to achieve this.

$ mkdir -p ~/luggage-packages/get-log-files
$ cd ~/luggage-packages/get-log-files

Create get-log-files.sh:

# get logged in user
CURRENT_USER=`/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }'`

# make logfile directory and set permissions
mkdir -p /Users/$CURRENT_USER/Desktop/LogFiles
chmod 777 $LOGDIR

# set logfile variables
MSU="/Library/Managed Installs/Logs/ManagedSoftwareUpdate.log"

# copy files and don't exit if logs not found
cp "$MSU" $LOGDIR || true
cp $DS $LOGDIR || true
cp $INS $LOGDIR || true


Create OnDemand/nopkg pkginfo file:

$ /usr/local/munki/makepkginfo --preinstall_script ./get-log-files.sh \
 --OnDemand \
 --category SelfService \
 --name get-log-files \
 --pkgvers 1.0 \
 --displayname "Get Log Files" \
 --category "Remote Support" \
 --nopkg > get-log-files-{your-version}.plist
$ cp get-log-files-{your-version}.plist /path/to/your/munki_repo/pkgsinfo/remotesupport
$ makecatalogs
Configure manifest

Create your manifest and add the packages to it:

$ manifestutil
> new-manifest _sw_remote_support
> add-pkg Enable-Remote_Assistance --manifest _sw_remote_support --section optional-installs
> add-pkg get-log-files --manifest _sw_remote_support --section optional-installs

You can then add this manifest to clients as required. After a Managed Software Update run, the packages will appear under a new "Remote Support category. Your remote user can then run these on their system. As the latter is an OnDemand type package, it can be run multiple times.

Munki users - do you provide remote support in your setup? If so, how, and to what extent?