How to automate your Mac OS X setup with Ansible

Last month I updated my development machine to the shiny new El Capitan. Unfortunately as a zsh and tmux user I ran into a very annoying bug and so I was forced to re-install my MBP with Yosemite. Because I belong to the power users which tend to customise their installations a lot and because I like automation I decided I was going to automate this cumbersome job for once and for all. Of course, with my favourite configuration management tool: Ansible.

It appears I’m not the only one and found Jeff Geerling’s excellent mac-dev-playbook repository. The README.md contains a lot of useful information and the repository is an excellent starting point. I’ve also used it as starting point for my own repository. In this post I’ll explain the most important details of my setup.

Installation of Applications and packages

I like Homebrew to install packages on my Mac so that’s also what I use in my Ansible setup. There is a ready to use Ansible role available – also created by Jeff Geerling – which I recommend. To use it:

To configure the role to suit your needs you have to edit vars/main.yml. My current version as an example:

The Dock

There is a neat utility available called dockutil which allows you to take full control over your dock. You can install it via Homebrew, so just register it under homebrew_installed_packages.

I use the following tasks and vars to fix my dock:

Vars:

Terminal

I spend a significant amount of the day in the terminal, so I’ve tweaked the default Terminal settings a lot. The cool thing is these settings can be exported via Shell > Export settings. The Ansible task to import such a file:

Mac OS X tweaks

A lot of people don’t know you can configure a lot of settings via the command line interface to the user defaults. You can read and write these settings. For some inspiration take a look at my defaults.

Debugging Selenium with X11 Forwarding on Scrutinizer CI

Last week we ran into some issues on Scrutinizer CI with our Behat Selenium test suite. These things tend to be quite hard to debug: as Selenium is running headless in X virtual framebuffer (Xvfb) there is nothing to see for the developer. It’s possible to take screenshots, but this requires code changes (probably).

X11 Forwarding

One of the cool things you can do with Selenium (or more particular Firefox or Chrome) is X11 forwarding. If you’re running a X.Org Window system it is possible to forward the display from one box to another. When you’re on a Linux desktop environment you’re golden, but if you’re on a Mac like me you have to install XQuartz to get it working. Follow the instructions on the site and don’t forget to logout and login after installation otherwise your $DISPLAY enviroment variable is empty. By the way: if you’re a Windows user I honestly suggest to get a Mac or install Ubuntu to get it working :).

If you want more information on this topic there is plenty of information to be found on the interwebz.

SSH Remote debugging session

To get this X11 forwarding working on Scrutinizer CI first request a new SSH debugging session. This can be done on the inspection page. When the inspection fails you can retry but in the same dropdown also choose for “SSH Remote debugging”. The first time you do this it will ask for your public keys from Github, you should accept the request. It may take some time but after a few seconds or minutes you’ll receive a SSH login to connect to. Add an -X switch after ssh, so the command looks like this:

Now login on the remote machine and verify your $DISPLAY server is set (should be something like localhost:10.0). Open ~/.profile in your favourite editor and remove the line:

Do not log out, but create new SSH session with the command above. If all is fine you should be able to start firefox and see the browser appearing. Kill this firefox instance, and start Selenium in this session (java -jar /location/of/selenium.jar) and in the first session start your Behat tests.

Install Selenium headless on Debian Wheezy (optionally with Ansible)

When you start testing with Behat and Mink Selenium2 driver you also need a browser running. Because we develop on a virtualised server installing FireFox was a bit more tricky then I expected. Of course a search yielded some interesting results, but also a lot of crap. So here is a little writeup on how I managed to get it running to save you some time. An example playbook can be found at the bottom of this post. But beware: this is Debian only!

On Debian there is a package called iceweasel. This is a rebranded version of FireFox. Because of that there is no firefox package available in the default repositories.

We are using Ansible for configuration management (for both our production and develop environment) so I prefer a package above compiling shit because that’s much easier to automate. There are a couple of options to install FireFox trough package manager:

  1. add Linux Mint repository
  2. add ubuntuzilla repository

Using the Linux Mint repository I experienced some problems. The Ubuntuzilla repository worked like a charm. If you want to install manually just follow the instructions in their Wiki. After adding the repository you can install the firefox package:

To run Firefox headless you also need some display server and to emulate that we are going to use xvfb. Selenium requires Java, thus we install:

Download Selenium somewhere:

You should be able to start Selenium now:

Starting by hand is a bit lame, so we use this startup script:

Copy this to /etc/init.d/selenium and after that you can:

And when we create an Ansible playbook for all this we get: