# Introduction

I know it has been a while since I put up my last post, but school was kept me busy. I wrote this one in a hurry and ask that you excuse any spelling and grammar mistakes. In particular, I’ve been taking CSC 373 - Algorithm Design, Analysis, and Complexity and have had several assignments to work on. In my free time, I’ve been working on my own Ansible script. Ansible is a tool used to deploy and update applications in an easy to use language, using SSH, with no agents to install on remote systems. The specifications for Ansible are all written in YAML, making them well structured and generally easy to follow. Back at Wave, Nathan wrote An Ansible primer blog post on the Wave Engineering blog. Here, I’ll be taking you through my Ansible script as a practical example of what you could use Ansible for, outside of setting up remote servers.

Unfortunately, having recently had a hard drive failure on my laptop. I had to manually setup my machine just the way I like it. When setting up, I realized the colossal waste of time it was to lookup the ppa’s I needed, the Sager specific driver I’d installed for my keyboard backlight and trying to recall what I used most. This time I’d done the smart thing and simply documented all my steps. There were a few missing things there involving using dconf, gconftool-2 and gsettings and a couple of steps I’d not yet written down. We’d been using Ansible at Wave and my last attempt to learn it met with confusion, ten VMs running in the background and an episode of The Sopranos. I had tried to follow Nathan’s example (simplifying it along the way) as well as a bunch of other tutorials relating to Django. They all met with failure to get a successfully provisioned VM. I’d been making small contributions at work to our Ansible scripts in hopes to get the practice I needed for when I decided to try again. That’s when Alex Tucker suggested I take my setup instructions and give it another go at Ansible. Now that you know how I got started, I’ll get into the project.

# The File Structure & Content

This is mostly self explanatory, I’ll go into more detail about each section.

# The HOSTS file

This file lets Ansible know where the machines are located, in this case all we’ll need is localhost.

# The Requirements File

Some on the Ansible modules have requirements, the Ansible docs provide them on each modules page.

# The Master Playbook

This is also pretty simple. Here we can define what we run where, here I’m just telling it to run the scripts, in my common role, on the local machine.

# Common Roles: Variables main.yml

Here we can define variables which we can use with {{ variable name ]} syntax. I use some of them to conditionally run tasks, to do them for a particular user and for downloading applications which are not available via ppa.

# Common Roles: Files

For example, I place the autostart files in there so that I can copy them into the correct directory so applications will launch on boot. I also have configuration files for applications and my terminal.

Here’s where most of the coding is and I’ll provide five examples, the rest you can checkout in the repository.

1) main.yml

‘main.yml’ is the file that the setup.yml common role calls, I just use it to conditionally call the other task files I use.

2) base16.yml

Here I make use of the git, file and command modules to checkout the amazing base-16 color scheme for my terminal, set it as the default and set the font (which I already setup in another task).

3) vim.yml

Another part of my setup is to put Vim and all of the important packages on my machine. Unfortunately, when I had tried to install the packages it seemed that missing my color scheme file prevented me from downloading it through Vundle. Using Ansible’s copy module I’m taking the current version (rather than doing a git pull for a more up to date one) to temporarily place the file there and have it replaced by running the setup.

4) work.yml

There’s a fair amount of overlap between things I use for my personal projects and those which I need for work. In here I’ve put the more development focused requirements making use of some of its wide variety of modules for installing packages through pip, .deb files and apt.

5) laptop.yml

One of the disadvantages of using linux can be that some things are hard to make work, although Ubuntu helps with a lot of it. For a long time I was unable to dim my backlight and my keyboard backlight was always on and always blue. Through the use of a small settings tweak, a custom driver and a custom script I wrote for changing the keyboard backlight, I’m not able to do all of these things. The task will only run contingent on the sager_laptop variable being true. One of the truly great modules in called ‘lineinfile’ and it does is ensure that a line exists in a file. That sounds pretty simple but it offers the ability to use a regular expression to identify the line (so that if it does not exist but it is meant to replace another line, it will) and the ability to create the file if it does not exist (configurable).

# The script

By using: bash wget -qO- https://github.com/JBKahn/provisioning-local/raw/master/run.sh | sudo bash you can have this script download and run and have the machine setup in no time. It handles the requirements, and starts up three of the applications after the provisioning is completed.

# The Output

Here after I run it, it will tell me how many of them at ran (changed) or did not require any more work (ok). There are some tasks (i.e. commands) which will always be ‘changed’ unless they are conditionally executed or a module is written to explain to Ansible how to check and see if something has changed.

# That’s It

That’s all you need to get this up and running and provisioning your own machine. I hope to be able to write a blog post about using it with Vagrant and what the differences are. For now, I’ll leave you with a few relevant links: