In the previous two parts, we went over how to get a basic Puppet Server up and running in Docker and how to deploy your modules using r10k. This time we’ll assign some configuration to our nodes using Hiera. For a full explanation of what Hiera is, see the Puppetlabs documentation, but essentially, you are using a series of directories and files that are named in a particular way, and then specifying which is the most speccific to your node. ...

As previously mentioned, Sal now has an API. You might be wondering what you can do with this wondrous API. This is a simple example of using it to automate building packages to enrol Macs into Sal. The basic workflow of this script is: Use the API to get a list of all Machine Groups in Sal - this will return JSON (a markup language that is easily parsable with languages like Python) Download the Sal postflight scripts Download the latest Facter installer For each machine group, build a package that will install all of the packages and then set the correct Sal preferences. You can find the script in this Gist. I’m not going to go through the script line by line, but we’ll cover how to configure it. ...

I’ve been wanting to get stuck in with a simple Swift project for a while, but couldn’t think of anything suitable for a first project (Imagr was originally going to be that project, but I don’t think it would ever have been made if I chose Swift), until I saw Dr Graham R Pugh’s Do Not Disturb application. I thought it was an excellent idea that could be made even better by being a manu bar app. ...

As some of you may know, yesterday was my last day at pebble.it. Since I announced I was leaving, I’ve been getting asked this pretty regularly, so I thought I’d answer it here. My new job uses Munki extensively, and I expect to be using Sal there. As such, development of Sal will continue. I no longer have commit access to the Sal Software organisation, so I’ve forked the project and have set up Sal Open Source as an organisation on GitHub - hopefully this will be the last time anything needs to change. I’ll be moving the preference domain in version 0.4.0 of the client side scripts to com.github.salopensource.sal - once again, this should be the last time things need to change. ...

Last time we got our Puppet Server up and running - now we need to put some Puppet modules on it so we can use it. To do that, we’re going to use r10k. It’s a tool that uses a control git repository that contains something called a puppetfile- a file that lists all of the puppet modules you want to use, either from the puppet forge or from git repositories. You may want to keep this module private by using a paid account on GitHub if your configuration contains secrets, but it doesn’t have to be - mine doesn’t have anything particularly sensitive in, so here it is: grahamgilbert/personal-puppet. ...

Back when I started using Puppet, configuring a Puppet Master could be pretty tricky as there were several moving parts (it was a Rack application, so needed to run behind something like Passenger if you had any number of clients). Thankfully, the new Puppet Server simplifies things massively - it’s just one installation to get things working in a way that would be suitable for putting straight into production. Over the next few posts, I’ll take you through setting up the Puppet Server (running on Docker, naturally!), using r10k and git for managing your modules and using Hiera to configure your Macs - we’ll apply some configuration to a Mac without writing a single line of Puppet code . Why? You might well be thinking “why would I want to use Puppet?” After all, you’ve already got Munki. There are two main reasons I’ve chosen to go back to using a Puppet Server in conjunction with Munki. It’s nice to have a fallback. If I manage to do something stupid and nuke my Munki install, or my customers manage to do the same, I’ve got some way of getting the machines back under control. “Free” SSL certs - this might not be a priority now, but it gives you an easy to to secure your Munki repository later on (which we may cover in a later post). ...

So you’re managing your catalogs with munki-trello, but you also want to use git and git-fat to track the changes - what do you do? If you were using the script that I posted previously, your changes would be mangled when you pull in changes - it turned out the solution was simple. I’m going to assume your Munki server has commit access to your Munki git repository. We’re pulling down the latest version of the git repo before performing any work, and then we’re git adding just the catalogs and pkgsinfo directories - the only directories munki-trello will modify. And if there aren’t any changes, git won’t commit anything, so we can just run git commit and git push without worrying about it. ...

For the past few weeks, I’ve been working with some other Mac admins on a new application that can aid with the deployment of Macs - say hi to Imagr. It’s not intended to be a full replacement for Deploystudio, but it’s now got all of the features I need to use Imagr full time. If you’d like to get started with Imagr, head on over to the Wiki - the only requirement is a web server, so the barrier to entry is pretty low (if you followed my guide on how to set up BSDPy, you can use that web server). ...

Last time, we looked at how to spin up a Docker host and run BSDPy on it. That’s great for production, but might be a bit of a faff to do every time you want to test your NBI at home. Inspired by Dr Graham R Pugh, here’s my Vagrant setup for this. You will need: Vagrant Either VirtualBox or VMware Fusion (if you use Fusion with Vagrant, you will need to purchase the VMware plugin - this will allow you to create OS X Vagrantboxes as well as enjoy the much greater performance of VMware, but that’s another post) Xcode, or at the very least the command line tools from Xcode so you have git available. Something to NetBoot - either a physical Mac or a VM in VMware Fusion. A VM configured as per Rich Trouton’s post will do nicely. Get all of that installed and you’re ready to go. Next we need to get the Vagrantfile: ...

Have you heard of Docker, but think it all sounds a bit mystical and exotic? Then this is the post for you! Before we begin, you’re going to need a machine (or a VM, either on your machine or on a server) with Ubuntu 14.04 LTS installed on it. You can install Docker on many other operating systems, but I use Ubuntu, so we’re using that. Your Ubuntu box will also need a real IP address - if you are using VMware Fusion, this will be a Bridged Network Adapter - adjust the terminology if you’re using a different virtualization tool. You don’t need to worry about giving your machine a static IP unless you want to - Macs will NetBoot just fine when they’re on the same subnet. ...