About every five years it is time to install a new Linux distribution in the Perlmeister labs. Only every five years because, in my experience, after running do-release-upgrade, getting all the small cronjobs that inevitably require special treatment – because of new versions of Perl, Apache, and various libraries – up and running again involves a huge amount of effort.

Many open source developers – both in the distribution scene (Hello, Ubuntu!) and in the tool area (Hello, OpenSSL! – don't give two hoots about backward compatibility and expect me to take a few days vacation each time, sitting and cussing in front of my Linux desktop while changing configurations or customizing scripts.

I then often only vaguely remember all the little manually inserted patches that were needed to finally get one tool or another running to my satisfaction. Even weeks after completing the upgrade, it is not unusual to find something that still isn't working properly; and each time, I rack my brains, trying to remember how I solved it years ago.

Laughable Manual Mode

Setting up servers manually is something that has provoked fits of laughter among professionals for many years. Tools like Puppet or Chef automatically and reliably handle the configuration and new releases. Anyone who enters their changes into the versioned configuration files of these tools also has the advantage that everything can be reproduced free of errors at any time.

Unfortunately, each of these tools goes hand in hand with a religious cult, whose disciples seemingly have to sign up for life, complete paid training, obtain certificates, and not nibble from the forbidden fruit. After consumption of said fruit, defectors may perhaps wonder whether it is actually sensible to go from being a creative script hacker to a submissive adapter of configuration files in line with a predetermined schema.

That's why I was glad to learn, while reading the new and highly recommended Ansible book [1], that this free provisioning tool [2] not only does not require an agent on the target system, because it connects easily via SSH, but also scales downward – meaning it can also manage a single desktop without much fuss.

Science Fiction Origins

The name Ansible comes from science fiction literature and refers to a device used to communicate across galactic distances at superluminal speed. Wikipedia comments tersely that our scientists do not currently yet know how such a device could be built. But, anyone can join the Ansible religion and write their instructions in YAML format, although hand-crafted Perl scripts work as well.

Ansible comes on all modern Linux distributions as a package. It can be installed in Ubuntu, for example, using:

sudo apt-get install ansible

With the ping module and the local desktop localhost as the destination, it confirms that everything is fine and nothing has been changed:

$ ansible localhost -m ping
localhost | success >> {
    "changed": false,
    "ping": "pong"
}

A typical chore on my Linux system is dumping a customized .vimrc file into my home directory. Fortunately, this file is publicly accessible in one of my repositories on GitHub (Figure 1), meaning that Ansible can now automate downloading the file and set its permissions after installation. Because the Ansible playbook, which describes the desired state of the system, resides in a directory together with many other Ansible scripts, restoring the Vim configuration is now an integral part of system setup, which not even the most scatterbrained administrator will forget.

Figure 1: The author's customized .vimrc file is on GitHub.

Play Along

Ansible draws its instructions from playbooks, which use the YAML format to describe which commands are to be executed and which files the commands modify so that it is possible to determine later whether an instruction has already been executed and therefore does not need any more attention. So, if I call up Ansible twice in succession, the second call should return very quickly without any changes. This idempotence is very helpful.

For example, to install the .vimrc file, the playbook in Listing 1 uses the Ansible module get_url, which comes with the base system and, according to the documentation at least, expects the following parameters:

• url: Download URL of a file
• dest: Name of the locally installed file
• mode: Unix user permissions.

This playbook runs on all Linux distributions and platforms supported by Ansible. This means it is also useful during my travels when using my MacBook.

The get_url module will not initiate another download during a second run with the default setting because the local file already exists. Anyone wanting to refresh the file constantly just needs to instruct Ansible to load the file again from the server for each call and then to replace the local version if it differs from the one that has just arrived by using the additional parameter force=yes.

Listing 1 [3] lists the target host with localhost, so it will install the file on the same host without having to SSH anywhere. The YAML file still has plenty of room for more such "plays" each consisting of various tasks to which a name is assigned. This name provides information about what's happing during each Ansible run and, in this particular case, what's going on after calling

ansible-playbook vimrc.yml

as shown in Figure 2. The name also helps you troubleshoot if an error occurs. What can be learned is that Ansible has downloaded and installed .vimrc without any issues, and that is why the status of the Linux system has changed.

Figure 2: Ansible loads a .vimrc file from a GitHub repository and installs it locally.

If you're wondering, I found the lengthy GitHub URL in the playbook for loading the latest version of the file checked in on github.com in the browser below the Raw button of GitHub's web UI.