Automatic desktop configuration using Ansible and Perl
Science, Not Fiction
The superluminal speed of the provisioning tool Ansible is suitable for configuration and release management of medium-sized server farms, as well as for use at home for restoring adjustments on your Linux desktop.
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.
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 filedest
: Name of the locally installed filemode
: Unix user permissions.
Listing 1
vimrc.yml
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.
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.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.
-
ZorinOS 17.1 Released, Includes Improved Windows App Support
If you need or desire to run Windows applications on Linux, there's one distribution intent on making that easier for you and its new release further improves that feature.
-
Linux Market Share Surpasses 4% for the First Time
Look out Windows and macOS, Linux is on the rise and has even topped ChromeOS to become the fourth most widely used OS around the globe.
-
KDE’s Plasma 6 Officially Available
KDE’s Plasma 6.0 "Megarelease" has happened, and it's brimming with new features, polish, and performance.
-
Latest Version of Tails Unleashed
Tails 6.0 is based on Debian 12 and includes GNOME 43.
-
KDE Announces New Slimbook V with Plenty of Power and KDE’s Plasma 6
If you're a fan of KDE Plasma, you'll be thrilled to hear they've announced a new Slimbook with an AMD CPU and the latest version of KDE Plasma desktop.
-
Monthly Sponsorship Includes Early Access to elementary OS 8
If you want to get a glimpse of what's in the pipeline for elementary OS 8, just set up a monthly sponsorship to help fund its continued existence.