This probably isn’t news to anyone else, but I made a discovery last week that will save me a fair bit of time. Whilst staring at System Image Utility after yet another change to the build, I thought that there must be a better way of doing this, bearing in mind that the basic InstaDMG process is: Install the OS Install Packages Make a read-only DMG Prep the DMG for ASR And SIU’s process is: ...

I’ve been using InstaDMG for nearly two years now. We all know it’s awesome (if you aren’t aware of it’s awesomeness, I suggest taking a look at Allister Banks’ talk at PSU MacAdmins last year). I’m almost ashamed to admit that I was happily making my Golden Master images on my test iMac and hoping for the best when I cleaned them up by hand and pushed them out. Anyway, that’s enough of my admissions. Over these two years, I’ve picked up a few tips and tricks for working effectively with InstaDMG. ...

I’ve had my Mac scripts dotted around my Macs over the years, so after spending twenty minutes looking for my script to add a login item to a user, I decided to put them all in one place on GitHub. Hopefully someone will find them useful, I’ll be adding the rest as soon as I work out where I put them. MacScripts on GitHub

I’ll preface this with one thing - I’m not a Casper Suite expert. I don’t use it regularly, and at what it costs, I probably won’t! It’s this price that gave me high expectations for this last install. Unfortunately they were unfounded. I’m hoping to write a series of articles comparing the various aspects of Casper against the free tools I use every day. First up is DeployStudio. Workflow creation Both Casper Imaging and DeployStudio have a nice GUI for creating the workflow. It’s just a drag and drop to place the tasks you need. The DeployStudio interface feels a bit more polished, but that’s probably just my bias showing though. The only real differentiator here are the package groups that DeployStudio offers. If you had a standard group of packages that you deploy over several different workflows, DeployStudio makes it easy to maintain - yes, this should probably be done elsewhere, but it can be handy to install a certain set of applications at imaging time. I couldn’t see a direct replacement for this in Casper Imaging. ...

A few months ago, we decided to move away from DeployStudio for imaging our Macs to reduce the OS X footprint in the server room (a plain old NetRestore can be run from NetSUS). This left us with a problem - how are we going to name our Macs now (a task previously performed by DeployStudio)? Enter MacNamer. It’s usage and installation is detailed in the Readme file, please fork, try to break, file pull requests. This has been in production for several months at work, but I’m sure someone will manage to make it break!

Maintaining visibility over your fleet of machines is always difficult. It’s even more difficult when you’ve got Macs. It gets nearly impossible when you decide you’d like something hosted in the cloud. We’ve been looking for a good solution for ages now - we even resorted to using OCS Inventory for a while. We then discovered Meraki’s Systems Manager. This isn’t going to be one of those fancy review type things - you can go and look at it’s features yourself. This is more an overview of the factors that came into our decision: ...

This post could also be called “Things we could learn from our developer brethren, but I digress, to the list! (Lists are awesome, aren’t they?) I’m not going to try and tell you how to get started with Git (go here instead for that), I’m merely going to get on my soapbox. Branches - need to test something? No need to spend all day making a test setup, just make a branch and clone it to the test server. If it turns out that I wasn’t mad and my changes were a good idea, they can be merged back into the main branch just as easily. Accountability - who made that strange config change? A quick look at the commit history is all you need. Diff - what actually changed? It’s easy to see the exact changes Change history - why was that random change even made? Hopefully it’s in the commit message! (Your commit messages are useful, aren’t they?!) You can be a nice sysadmin - if you use GitHub it’s simple to take your repo public and share your awesomeness. So there you go - I hope this goes some way to answering the question “why should I be using Git?”

This will probably be obvious to most seasoned Puppet inclined OS X admins, but this is a relatively recent revelation for me. Up until very recently, I wasn’t really making full use of Facter, merely pointing my clients to the appropriate classes and leaving it at that. When tasked with giving end users the option to install their own printers when they went to a different site than the one they usually work at, my initial thought was to go for a Payload-free package and pop it into their optional installs in Munki. But then I was asked if it could happen without the user doing anything - they go to the other site, and they automatically get the right printers set up - so after a little thought, came up with this. I’ve made use of the excellent mosen-puppet-cups module on GitHub to get the printers set up, and the drivers are already deployed with Munki (I did consider moving them to Puppet, but why reinvent the wheel for the sake of it?). ...

Update: There’s a better method over at afp548 that does this better. Use that! A few months ago I made a package to create a Recovery HD on a freshly deployed Lion Mac. It’s time to do the same for Mountain Goat. In true Blue Peter style, you will need: The Luggage (If you’re having problems getting The Luggage working with the latest version of Xcode, please see this post on macenterprise The GitHub Repo A read only DMG of a never booted 10.8 Recovery HD The Lion Recovovery HD Update ...

Last week at work we were discussing where we were headed. Our email is now firmly in the cloud with Google providing a better infrastructure than we ever could. They’ve also got word processing and spreadsheets solved for most people with the hard to beat price of free. So, what else could we do better with the cloud? ...