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.
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 🙂
Link Dupont
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.
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?
Miguel Pereira
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.
Eduardo Osorio
Wonder if, are there any kind of playbook depot for gnome workstation?
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.
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.
Luke Short
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=
sheogorath
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.
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?
Link Dupont
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.
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.
Link Dupont
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.