On Macs, all the software is pretty automatic. Munki installs VirtualBox, git, and Vagrant. On Ubuntu, you’ve got a few more steps - add our apt-repo and install VirtualBox, Vagrant, git, nfs-kernel-server. From there, the user simply has to install our vagrant plugin and run it. That will clone all the repos, install other plugins, and configure anything that needs to be configured!

And that’s it! vagrant up.

Well, sort of anyway. We have a vagrant plugin that helps manage our vagrant resources. This plugin is internal only at the moment because it statically deals with our project configuration. Essentially it has 3 commands - setup, clean, and purge. The setup command checks your vagrant install for the plugins that we require, and installs them if you don’t have them or if you are out of date. It also clones all the git projects you need and prompts you to configure your a...

So I came across a very interesting bug in Profile Manager (running on Server 3) that made it so my users could not sleep their Macbooks - even by closing the lid! Upon closer inspection I noticed that the Sleep button in the MenuBar was also greyed out. So what happened?

In Profile Manager I had configured some settings related to display sleep and disk sleep - but there is certainly nothing related to disabling sleep completely in there!

So the next step - what does pmset sleepnow do? Nothing.
Ok, so pmset -g assertions tells me that different things are preventing sleep on each affected machine. But those assertions are transitory, and they certainly do not prevent the machine from sleeping with the lid closed!
So next - pmset -g. That finally got me somewhere! The first bit of output looked like this:

System-wide power settings:
 SleepDisabled      1
Active Profiles:
Battery Power

So recently (in my attempts at cleaning up kitchen-cabinet), I’ve started to look at the benefits and pitfalls of omnibus installers.

Vagrant is a good example of the benefits - it started out life as a pure ruby gem, but it had a lot of dependencies, and it was kind of hard to manage all of them. In addition, the developers of vagrant realized that speed and efficiency could be increased by not always using pure ruby code - tools like bsdtar are much faster than the ruby implementation! So, Vagrant switched to a package installer. This allows it to have an embedded ruby installation, complete with all the extensions and dependencies it needs! Because these are all managed internally, you can’t break vagrant by changing things with your system ruby (and you reallly don’t need to have or use your system ruby at all!).
Not everyone who uses vagrant is a ruby developer, so the less...

In order to get NFS working in Vagrant, you have to specify type: 'nfs' in your Vagrantfile for each shared folder. If you are using chef, you will also want to use chef.synced_folder_type = 'nfs'

But that’s not functional for most people! NFS will mount in your guest with the same UID as your host (for OSX that is most likely 501 or 502, for Ubuntu that’s probably 1000). To compound the issue, chmod and chown operations are also useless on NFS - not only are they ineffective, they fail hard (they tend to interrupt things like chef runs with their failure, even if there aren’t actually permission changes). There are a few options to get around this though. One of those is vagrant-bindfs. Essentially this takes your NFS mounts, and then remounts them under the user you specify. Bindfs is a thing outside the Vagrant world, this plugin just makes automating it simpler. This is a good...

A little bit of background: We use Vagrant to replicate our Production environment on each one of our developer’s machines. We’ve gone through numerous configurations trying to figure out which one would work the best. A couple of things have stayed largely the same however - we use the VirtualBox provider and the chef recipes we use to set up those VMs are the same we use in production.
Originally we used chef-server to provision each of the machines - this meant our Devs were tied to our corporate office. Every single run required a connection to our internal Chef Server, and that sort of cramped our style! We are aiming to simplify the setup required to get a developer going, so the less stuff we need on each machine, the better.

Enter the next phase: Chef Solo! At the beginning we were using berkshelf, as well as some custom scripting to ensure that older cookbooks got purged from...

UPDATE: (This update is a little late) there is now the ChefDK which pretty much does everything kitchen-cabinet did and more.

Last night I was at the San Diego DevOps meeting, and kitchen-cabinet came up. Some people were ‘skeptical’ about its usage. There are half a dozen or so tools that do the same sort of thing - meez, berks init, etc. Obviously its useful to use one of these tools - who can resist having to do less manual work! So what makes kitchen-cabinet specifically worth using?

I took a look at some of the other solutions out there before writing it, and I didn’t like what I saw. The code is often more complicated than it has to be, which makes it harder to maintain and update, and most of them don’t put any effort into providing a way to keeping existing cookbooks up to date. Besides that, none of the other tools set things up the way we like them.

So, I wrote kitchen-cabi...

There are many ways to setup a cookbook - knife cookbook create, berks init, etc. The problem is after that, you’ve also got to setup a whole suite of other tools to make sure your cookbooks are decent quality. These tools include rubocop, foodcritic, chefspec, test-kitchen, and more. Here’s a quick breakdown of the tools we use, and the order they should be used in:

Chefspec - Write your tests first. You’re unlikely to go back after you’ve written your cookbook to add tests, and it can help you stay a bit more organized if you outline it with tests first.

Rubocop/Foodcritic - These are both linting tools. Rubocop checks for ruby style plus complexity and a few other markers. Foodcritic checks specifically for cookbook style. Both these tools are useful for making sure your cookbooks are readable and that you are using proper syntax.

Chefspec - Now that you’ve written your cookbook...

Kitchen-cabinet is a gem that is intended to ease the setup of new cookbooks. It’s easy enough to use knife cookbook to make a new cookbook (or berks init) but then we’ve got to create a Gemfile, Strainerfile, rubocop.yml, etc! This leads to cookbooks being created without the proper testing suites, which leads to sloppy cookbooks!

Enter cabinet. This gem allows you to initialize a cookbook with the proper tools to keep your code organized and functional with a single command! It even allows you to update things in your old cookbooks so they can stay up to date.

Give it a try!

So now that AutoPkg is setup for use with munki, we can create overrides to (just guess) override the default values in our recipes.
In my last article, I gave this as an example -

The following new items were downloaded:
    /Users/tprice/Library/AutoPkg/Cache/com.github.autopkg.munki.google-chrome/downloads/GoogleChrome.dmg

The following new items were imported:
    Name                     Version          Catalogs                         Pkginfo Path
    ----                     -------          --------                         ------------
    GoogleChrome             29.0.1547.57     production                       apps/GoogleChrome-29.0.1547.57.plist

But what if you want Chrome to go to apps/Google/GoogleChrome? Or you want things added to a testing catalog at first, rather than being potentially thrust into Production before they are ready?

Well, if you run autopkg...

So my last post was about using AutoPkg in general, but lets talk about using it with munki! It only makes sense that a tool made to automate the downloading of packages would also be able to automate adding them to your munki repo.

Once you’ve got AutoPkg set up and a few repositories added to it, you can tell it where your munki repository is located like this: defaults write com.github.autopkg MUNKI_REPO /path/to/munki_repo

• It is important to note that this writes to the autopkg plist in your user’s Library. Do not run this command with sudo, and remember you will have to do it for every user on that same machine who will be using AutoPkg with Munki.

Now, All you do is run autopkg run <recipe>.munki and it will do the rest!

You will get some output like this:

The following new items were downloaded: