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

16 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.

    • reply leaver

      hello, would you mind to share if it is public?

  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=

  8. As this seems to become a place to share some nice/useful/handy ansible repos for client installation, I’ll share mine as well, as I can imagine it’s useful to have something maintained out there for others as well:

    https://octo.sh/ansible-client/ansible-client/

    I may split the roles into own repos at some point, for now it’s just a mono repo holding everything. Feel free to reach out to me, here, on octo.sh or on IRC.

  9. Pat Kelly

    Yeah! This is the first I’ve seen Ansible and I know I really need to be using it.

    Every six months I do a bare metal clean install (blank hard drive) of the PCs I manage; so I want to automate the process as much as possible.

    The example of using the Ansible DConf module to set a gnome key to turn on the night light convinced me that I really need to get started on this because there are, just a rough guess, something close to a hundred items I set in the Gnome Control Panel and Gnome Tweaks.

    I thought that there should be a document that is sort of a data dictionary for the Gnome related keys and once I had that I would be all ready to automate the Gnome setting I use. Unfortunately I had no luck finding such a document.

    I decided to start making such a document. I found the schemas and between using gsetting, and reading the schema XML files I’ve gathered a lot toward the document. But I’m having a hard time finding linkages between the gnome-control-panel widgets and the keys. Anyone know of such documentation or do I need to search through the source code for the gnome-control-panel?

    • I use a combination of tools for key discovery. dconf-editor is handy for GUI browsing and showing an overlay view of the “upstream” default key values, and my customizations. The output of dconf dump will show you all the key-path-values that you have customized from their defaults.

  10. Pat Kelly

    I tried the following at the command line:
    command > dump.txt
    dconf dump /usr/share/lib-2.0/schemas/
    and got an empty file. I also tried /org.gnome/ as the directory with the same result. I guess I’m missing something.

    • The “DIR” dconf refers to in its help is a logical dconf path, so dconf dump / will dump everything from the root. Or if you wanted only the background keys: dconf dump /org/gnome/desktop/background/.

      • Pat Kelly

        Yeah! I got everything! with dconf dump / > dump.dconf.

        I prettied it up and saved it as an odt file so I can have it for handy copy/paste as I build by playbook. Wow I have something over 200 modified keys, but I’ll be doing a lot less scrolling and clicking when I install F29 on these PCs Thanks to you and all those involved with ansible.

Comments are Closed

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