Pocket Mac admin's guide to London

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)

Read more →

Imagr with target disk mode

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.

Read more →

Enable SIP with Munki

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.

Read more →

Sal: an overview

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

Read more →

Sal 3.0

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.

We have migrated the basic search from using an external application that relied on building caches (so doubling the size of your database), to just querying the database directly.

The advanced search is completely new - it allows you to build up complex queries that would previously require you to build a plugin. These queries can also be saved so they can be shared with the rest of your team.

Plugins

Your plugins can now process data server side during checkin. Perhaps you want to update Sal with information from your Inventory tool, or call out to a web service. Documentation can be found over here.

Security

Sal scripts version 2.0.0 now uses basic http authentication by default (using the key set in preferences) on any endpoint that it retrieves data from (external scripts etc). This means that any potentially sensitive data you may have in your client side scripts is now protected. This can be disabled if desired - not recommended!.

Performance

If you have a lot of plugins enabled with client side scripts to download, you will be getting a lot of requests to your server. There is now a script available that will build a package containing all the external scripts enabled on your Sal install (or just download the files so they can be deployed with something like Puppet or Chef), and after setting the preference, the client will use these in preference to downloading them again.

If you are running Facter, you may be shipping duplicate data that Sal already collects - you are now able to specify facts that should not be sent to the server (enabling you to set different facts to ignore per client) or set it on the server to configure it globally.

Finally, every single transaction with the database has been optimised. A usual run from a client that has Facter installed with 50 facts has been reduced from 70+ calls to the database to less than 10 (Postgres only, sorry SQLite and MySQL users).