graham gilbert

Mac administration and assorted nerdity

The Future of Sal

| Comments

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.

So, what else can you expect from Sal in the near future? The next release will have a GUI for managing your plugins, and I’ve started work on a basic API, which should make it easier for people to extend Sal in any language you like. For example, I’ve been working on a way to sign Puppet certificates based on whether it’s a known machine in Sal, with the machine being created via the API if it doesn’t already exist at imaging time (using Imagr, naturally).

It’s exciting times for users of all the projects I’m working on – in addition to these changes, I have some changes planned for Crypt, and of course Imagr is still on the development rollercoaster.

Running Puppet Server in Docker Part 2: R10k

| Comments

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.

Running Puppet Server in Docker

| Comments

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.

  1. 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.
  2. “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).

Using Munki-trello With Git

| Comments

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.

If we schedule the below script to happen regularly (via cron), we also get our git changes deployed automagically.

/usr/local/bin/munki-trello.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#!/bin/bash

# Change this to wherever your Munki repository is on disk
cd /usr/local/docker/munki

# Pull down changes
git pull

# and the 'fat' files
git fat pull

docker pull pebbleit/munki-trello

docker run --rm -v /usr/local/docker/munki:/munki_repo \
-e DOCKER_TRELLO_KEY=mytrellokey \
-e DOCKER_TRELLO_TOKEN=mytrellotoken \
-e DOCKER_TRELLO_BOARDID=myboardid \
pebbleit/munki-trello


git add catalogs
git add manifests
git add pkgsinfo

# Change the following line if you want to change the git commit message
now="$(date)"
git commit -m "Munki Trello commit $now"

git push

Introducing Imagr

| Comments

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

I hope you’ll give it a go and maybe, just maybe, we can get rid of those little Mac Minis for good!