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
-
Red Hat Enterprise Linux 9.5 Released
Notify your friends, loved ones, and colleagues that the latest version of RHEL is available with plenty of enhancements.
-
Linux Sees Massive Performance Increase from a Single Line of Code
With one line of code, Intel was able to increase the performance of the Linux kernel by 4,000 percent.
-
Fedora KDE Approved as an Official Spin
If you prefer the Plasma desktop environment and the Fedora distribution, you're in luck because there's now an official spin that is listed on the same level as the Fedora Workstation edition.
-
New Steam Client Ups the Ante for Linux
The latest release from Steam has some pretty cool tricks up its sleeve.
-
Gnome OS Transitioning Toward a General-Purpose Distro
If you're looking for the perfectly vanilla take on the Gnome desktop, Gnome OS might be for you.
-
Fedora 41 Released with New Features
If you're a Fedora fan or just looking for a Linux distribution to help you migrate from Windows, Fedora 41 might be just the ticket.
-
AlmaLinux OS Kitten 10 Gives Power Users a Sneak Preview
If you're looking to kick the tires of AlmaLinux's upstream version, the developers have a purrfect solution.
-
Gnome 47.1 Released with a Few Fixes
The latest release of the Gnome desktop is all about fixing a few nagging issues and not about bringing new features into the mix.
-
System76 Unveils an Ampere-Powered Thelio Desktop
If you're looking for a new desktop system for developing autonomous driving and software-defined vehicle solutions. System76 has you covered.
-
VirtualBox 7.1.4 Includes Initial Support for Linux kernel 6.12
The latest version of VirtualBox has arrived and it not only adds initial support for kernel 6.12 but another feature that will make using the virtual machine tool much easier.