Sample code for MacADUK 2017: Introduction to PyObjC

If you will be attending my session at MacADUK 2017, you might find it useful to have copies of the sample Python code and scripts I’ll be talking about and demonstrating.

I’ve set up a GitHub repo. The sample code is basically complete, but I might make some minor changes over the next several days.

You can download the code samples here:

or if you are familiar with Git, you can clone them locally:
git clone

Hope to see you in London!

Sample code for MacADUK 2017: Introduction to PyObjC

MacSysAdmin 2016 Links

Here are links to various tools, documentation and blog posts I mention in my talk on Thursday at MacSysAdmin 2016:

Apple documentation on running code at login:
Graham Gilbert’s crankd post:
Google macops’

MacSysAdmin 2016 Links

Stupid Tricks with createOSXinstallPkg and VMware Fusion

Like many people tasked with managing OS X/macOS machines, I use VMware Fusion to do a lot of testing. Fusion enables me to test in various versions of OS X, and to easily make changes and revert to a prior state. It’s a great tool.

For some of the testing I do, it’s important to be able to quickly and easily build a VM that is configured just like the “real” machines I manage. There are a few way to do that. Since we build our machines by booting into a NetBoot image and using Graham Gilbert’s excellent Imagr ( to restore an image, it’s great that we can also boot Fusion VMs from a NetBoot image.

Continue reading “Stupid Tricks with createOSXinstallPkg and VMware Fusion”

Stupid Tricks with createOSXinstallPkg and VMware Fusion

Using autopkg for “general purpose” packaging

A few days ago I made a simple tool for building packages available: munkipkg.

I got many comments and suggestions for additional features and all sorts of cool additions. Some have even been added to the tool already. But I would like to keep munkipkg a pretty simple, basic tool.

The Luggage ( has been around for a while; if munkipkg is too simple for your needs, please have look at that.

I also suggested to several people that if they had more complex needs than munkipkg could handle, it might make more sense to use autopkg, which supports very complex, customizable workflows.

I could tell by the awkward silence that my suggestion was confusing to some — that they had trouble grokking how to use autopkg to build packages “from scratch”, using files and scripts on the local disk.

So I created a GitHub repo demonstrating how to use autopkg in this manner. It’s here:

munkipkg comes with three demo package projects. Two of the packages install files, the third is a “payload-free” package that simply runs a script when installed. The autopkg-packaging-demo duplicates these packages, but uses autopkg to build them instead of munkipkg.

(One could also imagine building these packages using either tool: the payload and scripts directories would be the same — in other words, you could have both a build-info.plist for munkipkg and a recipe for autopkg in the same package project directory.)

Assuming you have autopkg installed, you can `git clone` the repo, or download and expand the zip file, and run the autopkg recipes within.

I hope this clears up some confusion, and sparks some new ideas!

Using autopkg for “general purpose” packaging

Introducing munkipkg

munkipkg is a simple tool for building packages in a consistent, repeatable manner from source files and scripts in a project directory.

Files, scripts, and metadata are stored in a way that is easy to track and manage using a version control system like git.

Another tool that solves a similar problem is Joe Block’s The Luggage ( If you are happily using The Luggage, you can probably safely ignore this tool.

Though this tool may eventually be added to the set of tools installed with the Munki command-line tools, it’s not currently tied to Munki and can be run completely standalone.

Learn more here.

Introducing munkipkg

Accessing More Frameworks with Python

This post is based on a column I wrote for MacTech magazine in 2012. MacTech used to make older columns available online, but they haven’t done that for the past several years for some reason.
I’m planning to go through my older columns and dust off and republish some that I think are still relevant or useful.

Recently, we built a command-line tool using Python and the PyObjC bridge to control display mirroring.
PyObjC supports a lot of OS X frameworks “out-of-the-box”, and accessing them from Python can be as simple as:

include CoreFoundation

But what if the problem you want to solve requires a framework that isn’t included with the PyObjC bindings? In turns out that you can create your own bindings. In this post we’ll explore this aspect of working with Python and OS X frameworks.


In my organization, we sometimes have a need to set displays to a certain ColorSync profile. The ColorSync profile to use for a given display is a per-user preference, so if you need to set it for all users of a machine, you can’t just manually set it while logged in as one user and call it good.

If you are managing display profiles for a group of machines, or a conference room machine that has network logins, you need a way to manage display profiles for all users. Using MCX or doing some defaults scripting might come to mind. Let’s look at that possibility.

Continue reading “Accessing More Frameworks with Python”

Accessing More Frameworks with Python