There comes a time when writing Facts in Ruby just isn’t going to cut it - when you need to access Objective C frameworks, for example. Whilst Ruby can’t access these, Python is waiting in the wings ready to come to your rescue. There is the concept of External Facts - Facts that are written in whatever the system can run, and with Puppet 3.4 / Facter 2.0.1, they can even be distributed with pluginsync. ...

Caddy is a lightweight web server that amongst it’s features, has integration with LetsEncrypt to automatically request certificates. This means that you now have absolutely no excuse anymore to run your apps over plain old HTTP anymore. Let me be clearer. If you are running web services over HTTP, regardless of whether it touches the internet or not, you are doing it wrong. ...

There are times when you will need to load a LaunchAgent when a script is running as root - when you are running a postinstall script from a package or when you are loading the LaunchAgent via your management tool of choice (Puppet, Munki, Jamf Pro), for example. All of these example are assuming you have a LaunchAgent at /Library/LaunchAgents/com.company.example.plist. Loading a LaunchAgent #!/bin/bash # get console UID consoleuser=`/usr/bin/stat -f "%Su" /dev/console | /usr/bin/xargs /usr/bin/id -u` /bin/launchctl bootstrap gui/$consoleuser /Library/LaunchAgents/com.company.example.plist #!/usr/bin/python from pwd import getpwnam import subprocess import sys from SystemConfiguration import SCDynamicStoreCopyConsoleUser username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0] if username is None: # Exit if there isn't anyone logged in sys.exit() uid = getpwnam(username).pw_uid subprocess.call(['/bin/launchctl', 'bootstrap', 'gui/{}'.format(uid), '/Library/LaunchAgents/com.company.example.plist']) Unloading a LaunchAgent #!/bin/bash # get console UID consoleuser=`/usr/bin/stat -f "%Su" /dev/console | /usr/bin/xargs /usr/bin/id -u` /bin/launchctl bootout gui/$consoleuser /Library/LaunchAgents/com.company.example.plist #!/usr/bin/python from pwd import getpwnam import subprocess import sys from SystemConfiguration import SCDynamicStoreCopyConsoleUser username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0] if username is None: # Exit if there isn't anyone logged in sys.exit() uid = getpwnam(username).pw_uid subprocess.call(['/bin/launchctl', 'bootout', 'gui/{}'.format(uid), '/Library/LaunchAgents/com.company.example.plist']) The Python version may look more complicated, but is slightly more robust as it is retrieving the current username using Apple’s frameworks and I have also allowed for the script not to fail if there isn’t a user logged in.

Thanks to everyone who came to my session at MacAd.UK. I will link the video here when it is available, but in the meantime here are the slides.

It’s less than three weeks now until I give my talk about our journey from commercial management tools to open source nirvana at MacADUK - and whilst I’m very excited about the conference and all the fantastic speakers, I know some of you are equally as excited about visiting London. So, here’s my pocket Mac Admin’s guide to London (views are my own etc etc) ...

Imagr is a great tool when you’re wanting to deploy machines quickly in your office. But sometimes you will want to deploy machines when you’re in a smaller remote site, or a site where security concerns mean you can’t have servers. Imagr is flexible enough to handle this, and with a little creativity, we can deploy at these sites as easily as we can at our offices with NetBoot. Setup The first thing you are going to want to do it get your Imagr repo onto your own machine. I would recommend having your repo in a central repository - git fat works well, so does putting everything on an S3 bucket and using the aws cli tools to sync it down. We use an S3 bucket, as we can ship read only credentials to the machines that are performing the imaging. This guide will assume you are using S3, but you can substitute that aspect for whichever method you wish to sync your files. ...

When 10.12.2 hit this week, it introduced an awesome new feature - the ability to enable SIP without having to be booted into a Recovery like environment (either Recovery HD or a NetInstall). Unfortunately it merely enables SIP on the next reboot. Fortunately, Munki is pretty good at telling users when they need to reboot, so I wrote the following pkgsinfo file that will check if SIP is enabled, and if it isn’t, will enable it and reboot (fortunately it’s quite a bit easier to do this that it is with other tools. I’ve targeted this update at 10.12.0, because, well, if they’re not updating, I’d like them to. And it’s called ‘Critical Security Update’ so they may actually install it. If you really want them to install it, you can set a force_install_after_date and set it to the past, which will give your users a hour to install it before their machine goes byebye. ...

It’s been a long time since I wrote about Sal here (nearly three years), so with the release of Sal 3.0, it’s time to take another look at it. What is Sal? Sal is a reporting tool for macOS clients that helps you visualise what your clients are up to. It is primarily a reporting tool for Munki, but it can also ingest data from Facter (whether you are using Puppet to manage your Macs or not). It has the concept of business units, so if you wish to separate your clients out (for example, if you wish to give access to some machines to a sub organisation’s IT etc) you are able to do so. That’s the 10000 feet overview, let’s take a look at some of it’s functionality in more detail. The dashboard The first thing you see when you log into Sal is the dashboard. This is where you can get access to a quick overview of your fleet. Each graph, chart, set of buttons is a plugin - this means that each one can be re-ordered and removed - you can even make your own if you need to (more on that another time). Most plugins are clickable - click on the relevant part to show a list of machines it is referring to - and if the plugin supports showing the list (and all of the built in ones do), you can export the list to CSV (since all managers love spreadsheets, right?). ...

Sal 3.0 is a massive upgrade on Sal 2.7, so massive thanks to everyone who has contributed code and bug reports. In particular, big thanks go out to @sheagcraig for his work on the completely rewritten application inventory features. What’s new in Sal 3.0? Inventory Sal’s application inventory tracking has been completely re-written (thanks again Shea), and is much more useful, allowing for greater detail on what is installed, and where across your fleet. ...

I’m delighted to announce that the lovely people at Amsys have asked me to return to speak at MacAD.UK 2017 for it’s second year. This year I will be talking about Airbnb’s transition from a commercial macOS management platform to an entirely open source stack - “Something something commercial, something something open source”. See you all in February!