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.
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.
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 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 relevent 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?).