Using Ansible to set up a workstation

Ansible is  an extremely popular open-source configuration management and software automation project. While IT professionals almost certainly use Ansible on a daily basis, its influence outside the IT industry is not as wide. Ansible is a powerful and flexible tool. It is easily applied to a task common to nearly every desktop computer user: the post-installation “checklist”.

Most users like to apply one “tweak” after a new installation. Ansible’s idempotent, declarative syntax lends itself perfectly to describing how a system should be configured.

Ansible in a nutshell

The ansible program itself performs a single task against a set of hosts. This is roughly conceptualized as:

for HOST in $HOSTS; do
    ssh $HOST /usr/bin/echo "Hello World"
done

To perform more than one task, Ansible defines the concept of a “playbook”. A playbook is a YAML file describing the state of the targeted machine. When run, Ansible inspects each host and performs only the tasks necessary to enforce the state defined in the playbook.

- hosts: all
  tasks:
    - name: Echo "Hello World"
      command: echo "Hello World"

Run the playbook using the ansible-playbook command:

$ ansible-playbook ~/playbook.yml

Configuring a workstation

Start by installing ansible:

dnf install ansible

Next, create a file to store the playbook:

touch ~/post_install.yml

Start by defining the host on which to run this playbook. In this case, “localhost”:

- hosts: localhost

Each task consists of a name field and a module field. Ansible has a lot of modules. Be sure to browse the module index to become familiar with all Ansible has to offer.

The package module

Most users install additional packages after a fresh install, and many like to remove some shipped software they don’t use. The package module provides a generic wrapper around the system package manager (in Fedora’s case, dnf).

- hosts: localhost
  tasks:
    - name: Install Builder
      become: yes
      package:
        name: gnome-builder
        state: present
    - name: Remove Rhythmbox
      become: yes
      package:
        name: rhythmbox
        state: absent
    - name: Install GNOME Music
      become: yes
      package:
        name: gnome-music
        state: present
    - name: Remove Shotwell
      become: yes
      package:
        name: shotwell
        state: absent

This playbook results in the following outcomes:

  • GNOME Builder and GNOME Music are installed
  • Rhythmbox is removed
  • On Fedora 28 or greater, nothing happens with Shotwell (it is not in the default list of packages)
  • On Fedora 27 or older, Shotwell is removed

This playbook also introduces the become: yes directive. This specifies the task must be run by a privileged user (in most cases, root).

The DConf Module

Ansible can do a lot more than install software. For example, GNOME includes a great color-shifting feature called Night Light. It ships disabled by default, however the Ansible dconf module can very easily enable it.

- hosts: localhost
  tasks:
    - name: Enable Night Light
      dconf:
        key: /org/gnome/settings-daemon/plugins/color/night-light-enabled
        value: true
    - name: Set Night Light Temperature
      dconf:
        key: /org/gnome/settings-daemon/plugins/color/night-light-temperature
        value: uint32 5500

Ansible can also create files at specified locations with the copy module. In this example, a local file is copied to the destination path.

- hosts: localhost
  tasks:
    - name: Enable "AUTH_ADMIN_KEEP" for pkexec
      become: yes
      copy:
        src: files/51-pkexec-auth-admin-keep.rules
        dest: /etc/polkit-1/rules.d/51-pkexec-auth-admin-keep.rules

The Command Module

Ansible can still run commands even if no specialized module exists (via the aptly named command module). This playbook enables the Flathub repository and installs a few Flatpaks. The commands are crafted in such a way that they are effectively idempotent. This is an important behavior to consider; a playbook should succeed each time it is run on a machine.

- hosts: localhost
  tasks:
    - name: Enable Flathub repository
      become: yes
      command: flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
    - name: Install Fractal
      become: yes
      command: flatpak install --assumeyes flathub org.gnome.Fractal
    - name: Install Spotify
      become: yes
      command: flatpak install --assumeyes flathub com.spotify.Client

Combine all these tasks together into a single playbook and, in one command, Ansible will customize a freshly installed workstation. Not only that, but 6 months later, after making changes to the playbook, run it again to bring a “seasoned” install back to a known state.

$ ansible-playbook -K ~/post_install.yml

This article only touched the surface of what’s possible with Ansible. A follow-up article will go into more advanced Ansible concepts such as roles, configuring multiple hosts with a divided set of responsibilities.

Fedora Project community Using Software

10 Comments

  1. Baptiste Mille-Mathias

    In ansible 2.6 released last week there are modules flatpak_remote to manage remote and flatpak to install flatpak packages from remote.

    https://docs.ansible.com/ansible/devel/modules/flatpak_module.html
    https://docs.ansible.com/ansible/devel/modules/flatpak_module.html

    • Lennart Jern

      I was just about to make the same comment!
      The flatpak module also avoids the problem with trying to install a package that is already installed.

      Great post, this is just what I use ansible for 🙂

    • That’s excellent! I’ll be updating my own personal playbooks to use it. But for the purposes of the article, it works to demonstrate the command module too.

  2. Marco S.

    Hi,
    I have been using Ansible to setup my workstation to my basic needs for about 4 years now. Things like security, configuring git, creating SSH key pairs, adding ZSH, installing text editor/IDE and configuring backups.
    In general after the second usage it is already paying off.

  3. Started this a while back: https://github.com/onemorepereira/fedora_workstation_builder

    I am sure there must be many other flavors out there. Mine was geared to bootstrapping my workstation “just” the way I liked it.

  4. Eduardo Osorio

    Wonder if, are there any kind of playbook depot for gnome workstation?

  5. Omar

    Oh yeah, thanks so much. I have long been searching for a nice way to configure my personal machine, and this seems to be an effective way.

    Looking forward for the follow up post.

  6. Glenn

    I’ve used Ansible to configure and manage computing labs in a university setting, this was a few years ago and I used it over a number of years to do everything from last minuet software installs to distribution upgrades. We used pxe booted clonezilla to get a base image on all machines, but most of the setup and maintenance was though ansible.

    I eventually found some of the playbooks e.g. installing the required software catalog were useful when installing a new desktop for myself.

  7. I’ve been working on a handful of roles for my workstations with assisting to install common applications and drivers. I’ve published some of them on GitHub and will make sure my other private roles get open sourced as well!

    https://github.com/ekultails?utf8=%E2%9C%93&tab=repositories&q=ansible-role&type=&language=

Leave a Reply

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions

%d bloggers like this: