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

Last time we saw our heroes, there was the unfuffilled promise of making small NetInstall sets. Now is the time to deliver on that promise. We’re going to make a small NetInstall that will open up Terminal.app. If you’ve not read the previous post (and have got AutoNBI), go and do it now. I’ll wait. All done? ...

Another day, another tool made by Mr Bruienne! A while back, Pepijn released AutoNBI - a tool for automating the creation of NetInstall sets. At the time, it was filled away in the “this is cool, but isn’t this what System Image Utility does?” section. Then I saw his NetInstall running at MacTech (are you seeing a theme here?). It had this really simple DeployStudio like imagaing app - it was really cool. And suddently it made sense why you can replace the Packages directory with AutoNBI - a NetInstall is a really stripped down OS X environment, so it it much easier to distribute and use - we’re looking at around 1.8GB for my current NetInstall vs 5-6GB for a normal NetBoot. ...

Over the past few months, I’ve been trying to take small pieces of our workflow and see if we can expand on the number of people able to manage it. We’ve got AutoPkg populating our Munki repositories without any manual intervention, but we still need to edit pkgsinfo files to move items through development to testing to production catalogs. Sure, there are existing tools like MunkiWebAdmin or MunkiAdmin, but they either still require knowledge of how Munki works or full access to the repository via a file share of some sort. And we obviously already have a tool for assigning software to machines in Sal+ - we needed something that can speed this incredibly common task. ...

A while back, Nate Walck wrote scriptRunner. It’s a tool that can run a script either every time a user logs in or just the one time. It has served the test of time, but last year Joe Chilcote released Outset. It has all of the functionality of scriptRunner, but it can also install packages at the Mac’s first boot, and run scripts as root at either the first boot or every boot. This comes into it’s own when you’re trying to do things like skipping the iCloud screens on 10.10 using Rich Trouton’s script - this script needs to run after every OS update, so it makes sense to run this every time the Mac boots. ...