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

For those of you who attended my talk yesterday at PSU MacAdmins on Managing Macs with Puppet, here are are my slides and all of the code and servers used are up on grahamgilbert/puppet_psu_2013 on GitHub. Please comment, email me or catch me on the twitter if you have any questions about any of this. Hopefully the video will be up soon, so those of you who weren’t there to laugh at the guy with the funny accent can see me dealing with internet fails and my obscure British sit-com references. ...

At work, we’ve recently changed how we build our bootstrap package to having the main code that connects a Mac to our Puppet infrastructure pulled down from GitHub when the client boots up for the first time. Why? This might sound like madness to you. Why would anyone want to do this? We had two main issues to solve: I got sick of rebuilding our images every time our bootstrap script changed. Our engineers got sick of downloading the latest version of our package every time they thin / no-imaged a Mac. Why would our script change so much? In our case, it is to install the latest versions of Puppet and Facter. This isn’t strictly necessary, as we update Puppet and Facter with Munki, but occasionally there will be something in our Puppet config that requires a specific version - for example, when we started configuring usernames on 10.8 Macs with Puppet, the salt parameter was introduced. This required Puppet 3.0.2-ish or higher - which meant that any NetRestore image or old package that contained a version of Puppet lower than this would fail, and the engineer on site was in for a world of pain. ...

Facter is what gives Puppet it’s brains. It collects information about the computer it is run on and then passes it to the Puppet Master for use in manifests and can optionally be stored. I know, it doesn’t sound like the most earth shattering revelation of all time, but stop for a moment. Every time your current scripts need to target a specific OS version or a machine with a certain bit of hardware, you need to code it directly into the script. If the method of extracting that information changes, you need to modify every single script that uses that method. With Facter, you’re editing one file, which is always up to date on the client. Anyway, that’s enough waffle from me. Let’s get started. ...

We’ve made quite a bit of progress with our Puppet install. We’ve already made Puppet do something useful with setting up an admin user, but let’s get back to being lazy - let’s get someone else to write the code. Before reading this post, you really need to read part 1, part 2 and part 3 of the series. Modules are little pre-built bits of Puppet code. They’re a good example of Puppet’s philosophy of convention over configuration - Puppet will assume your modules follow a set pattern. We’ll be using two of the available folders in modules today: files and manifests. Files are static files that Puppet will copy over to our client machine, and manifests will contain the Puppet code we’ve previously been putting into /etc/puppet/manifests/site.pp - whilst it’s been easy to put code into this file, it can become unwieldy when you have a few nodes to manage. There are also loads of pre-built modules on the Puppet Forge - it’s one of these modules we’ll be using today. ...

In this post, we’ll do something pretty much all Mac admins will need to do - set up their admin user. Bust first, a little housekeeping. Before reading this post, you really need to read part 1, part 2 and most importantly my post on building a Puppet Master with Vagrant. The Puppet Labs provided VM won’t cut it here, we need the latest version of Puppet on our Master. If you are using the same Mac / OS X VM that was previously hooked up to the Puppet Master VM, you will need to run the following command on the client - don’t worry, it will get new certificates from your very own Puppet Master: ...