At pebble.it, we always wanted to have an easy dashboard to look at to visualise the information we could collect from Puppet and Munki. We tried a few options, but didn’t like any of them, so we made our own. Say hi to Sal - the Munki Puppet. It’s a multi-tenanted reporting solution for Munki and optionally, Facter. You can find all of the details over on GitHub, including installation instructions and a package to send out to your clients. ...

Have you ever wished you didn’t have to take calls from your users to unlock various parts of System Preferences? That standard users could unlock Energy Saver or Date and Time preferences? Well dear reader, this is the article for you. If, for some strange reason you can’t be bothered to read this overly long article (I do love to procrastinate), you can head over to my macscripts repo on GitHub for the scripts and resulting pkginfo files I’ve made for this. ...

I just pushed up version 0.5 of Crypt - the release details are over at GitHub. This is the last version that will be compatible with the current version of Crypt-Server - which has also been updated to be compatible with Django 1.5. This is fully tested (in my environment!) with Mavericks, so go forth and escrow FileVault keys.

A couple of weeks ago, I had a chat with Ed Marczak for the AFP548 Podcast. We discussed packaging, community and convincing clients that they shouldn’t stab themselves in the leg. Go listen.

Sometimes we are asked by clients to set a default desktop picture for new users - sometimes we are deleting home directories on logout, so need to warn the users, other times the client just wants their corporate wallpaper to be the default. If you are lazy and don’t want to read this post then the script that changes the desktop picture is on GitHub. Whatever, here’s what we used to do: ...

Yes, it’s true. The most interesting conversations in the Mac admin world take place using technology from the 1980’s - IRC (##osx-server on freenode). Those of you who know me will know that I’m borderline OCD. In this instance, my major annoyance was that I’d only get half of the conversation and I’d miss private messages when I had to put my laptop to sleep. I needed to somehow keep a persistient connection to IRC without having to sit in front of my computer 24/7. I’d heard of IRC bouncers before - an app that runs on a server, saving the messages in the rooms you specify for you until you are able to read them, but always assumed they were much more difficult to set up than it turned out to be. This is set up on a box running Ubuntu 12.04, with port 6666 opened on your firewall and forwarded to the box if you want to access it from outside the network. Mine is running on an Amazon EC2 Micro instance - available for free for one year if you don’t already have a server to run it on. Right, let’s get started. All of these commands are to be run as your normal user (graham in this case - not root). First we’re going to enable backports in Ubuntu. I like editing text files in nano so I’m going to install that first, but feel free to use Vi or whatever you like. sudo apt-get install -y nano sudo nano /etc/apt/sources.list Find the two backports lines commented out (lines 44-45 on my test box) and unomment them. deb http://us.archive.ubuntu.com/ubuntu/ precise-backports main restricted universe multiverse deb-src http://us.archive.ubuntu.com/ubuntu/ precise-backports main restricted universe multiverse If you are using nano, hit CTRL+O and press return to save it, then CTRL-X to exit. To install ZNC, issue the following command: sudo apt-get update sudo apt-get install -y znc/precise-backports znc-dbg/precise-backports znc-dev/precise-backports znc-extra/precise-backports znc-perl/precise-backports znc-python/precise-backports znc-tcl/precise-backports ...

A while ago, the chaps over at the Vagrant project have recently released a plugin to let Vagrant work with VMWare Fusion - this means we can finally use Vagrant to provision OS X VMs. Why is this a good thing? Do you NetBoot VMWare to test your builds? Or maybe you still have that test Mac on your desk to test your builds. Either way, it’s going to be several minutes to restore an image, even if you’re thin imaging. With the VM already on your machine, you’re ready to go in seconds. Another bonus is that Vagrant isn’t only limited to OS X virtual machines - for example, I have a Vagrant configuration that spins up an Ubuntu box configured as a Munki server, with a copy of my repository on an external drive. This allows me to test deployments from anywhere, with everything local to my Mac (have you ever tried testing a Final Cut Studio package from home? 48GB takes a while to download.). I’ll go into more detail on this setup in a future post, but for now here’s how to get a Mac base box into Vagrant. ...

As promised in my previous post, today we’re going to look at how we can further refine our workflow, with the aim of cutting out as many manual steps as possible (every IT person knows it’s not computer that make mistakes, it’s the idiots in front of them) and making as much of our code reusable in other packages. If you’ve not read the previous article, you will need to before carrying on with this, unless you’re already familiar with The Luggage. If you get stuck, all of the code from this post is up on Github. ...

If you’ve managed OS X for any amount of time, chances are you’ve needed to deploy software. And chances also are that you’ve come across a vendor (I’m looking at you, Adobe) that seems to be incapable of distributing their software in a useful manner. Or maybe you’ve got your own scripts or software that you need to get installed on the machines that you look after - either way, you’re going to want to build a package. You’ve got a few options - Iceberg, Packages, Composer, you’ve even got Package Maker. However, my personal choice is The Luggage. It has a few advantages over the alternatives: It’s all text files: You’re building software distributions, you should be checking the files in to build the packages into version control, such as Git. Text files are ideal for checking into version control. It’s free: if it costs nothing, there’s no reason it can’t be installed on everyone’s machine. It’s (still) all text files: Want to see what will be in the package without any extra work? Crack open the Makefile and you can see straight away what will be in the package. The Luggage has a metric buttload of shortcuts built in: it does the hard work, so you don’t have to. It’s repeatable: Have you ever tried to talk someone through a series of windows and buttons to get the same result as you’re getting? Every time you run The Luggage, you will get the same result. It’s (really, still) all text files: It’s the most precise tool I’ve used - you only package exactly what you need, no cruft is left behind. Your workflow is limited only by your imagination: Seriously, you can do pretty much anything you can think of. We’ll be going through more advanced workflows in future posts, but let’s get started with using The Luggage. ...

Updated 14/7/2013: After Alister’s suggestion, the script now loops over network interfaces up to en19 (hopefully that’s enough!). So, you’ve heard of this crankd thing, maybe even had a look at it, but have no idea how to get it going? You’re in the right place. I’m by no means an expert on it, having only been playing with it for less than a week, but I already have it running in production running the simple script below. My initial work, and therefore this post was inspired by Gary Larizza’s two articles on the subject. What is crankd? It’s part of the PyMacAdmin set of tools that Chris Adams and Nigel Kersten released a while ago. In a nutshell, it runs in the background via a LaunchDaemon and reacts to events on the Mac by running a script or a Python function, class or method. It has loads of events it knows about (application launches, power events, network events etc), but in this case I wanted to run something when there was a network change. Some of our machines never get turned off (and for some reason the Puppet Launch Daemon has crapped out), or aren’t turned on long enough for Puppet or Munki to run. I wanted a script that would run every time the machine came back onto the network, checking if there was an active connection and run Puppet and Munki. What do I need to do? There are a few parts that we need to bring together to make this work: The crankd.py executable and the supporting files A Launch Daemon to start the thing A preferences file to tell crankd what to do And finally, our custom code ...