Using GoLand on Fedora Silverblue

Keith Maxwell — Fri, 10 Apr 2020 20:01:21 +0000

I could find very little information online about running JetBrains GoLand on Fedora Silverblue. I hope this post will change that. I have tested the instructions below with the latest version, 2020.1 — released yesterday — and the previous version 2019.3.4 both on Fedora Silverblue 30.

Using Fedora Silverblue as a desktop operating system means that “every installation is identical to every other installation of the same version”. I am a very happy Fedora Silverblue user; last year I gave a talk explaining why.

Why GoLand?

I normally try to use open source rather than proprietary software wherever possible. I am a long term vim user. Saying that, I also actively try to stay open minded about technology. In the end, I decided to try out GoLand because:

it was widely endorsed at Belfast Gophers
a lot of people I respect from SoCraTes UK are JetBrains fans
a recent coding test / interview involved pairing with a developer using another JetBrains product; a bit of exposure to JetBrains can only help in that sort of situation
I've already got a licence, from a Legacy Code Retreat event in 2019; the first year of a GoLand licence normally costs £149.00.

Installation process

On Fedora Silverblue the root filesystem is immutable although certain mutable directories are made available from /var. On another system I would install into /opt, to follow the Filesystem Hierarchy Standard. On Fedora Silverblue /opt is a symbolic link to /var/opt so I'll install there. I also add a link to the PATH; /usr/local/bin is writable via /var/usrlocal which is mounted at /usr/local.

version=2020.1
sudo mkdir /var/opt/goland
cd /var/opt/goland
sudo chown "$LOGNAME:$LOGNAME" .
curl -OL https://download.jetbrains.com/go/goland-$version.tar.gz
curl -O https://download.jetbrains.com/go/goland-$version.tar.gz.sha256
sha256sum -c goland-$version.tar.gz.sha256
tar xf goland-$version.tar.gz
cd GoLand-$version/bin
sudo ln -s "$PWD/goland.sh" /var/usrlocal/bin

Alt-F2 then goland.sh⏎ should start GoLand!

Next up activate your licence. Then use the UI to download an SDK ( File → Settings → GOROOT ); this happens in the background. I chose 1.13.8 to match the current version in Alpine Linux edge. After that I was all set; I started working through “The Hitchhiker's Guide to GoLand”.

Debugging

If you have an issue it might help to see messages printed to a terminal; instead at the same terminal as above try: ./goland.sh⏎. At first I was connected via SSH without $DISPLAY set properly.

Why did this need a blog post?

Fedora Silverblue is an immutable desktop operating system. The recommended methods for running GUI software include Flatpaks and or other containers using toolbox or even Podman directly. It is also possible to layer or install traditionally packaged applications with rpm-ostree but that introduces differences between one system and the next.

My early research didn't show a straight forward answer. The possibilities I came across included: an unofficial container, the official snap that JetBrains publish or even using an AppImage. No Flatpak is available. Snaps are more common on Ubuntu, on Fedora Silverblue the background service would have to be installed first: either inside a container or as a layer with rpm-ostree.

I should probably have jumped into trying this out practically more quickly. The JetBrains installation guide doesn't give much detail about this approach, but the files are clearly linked from the JetBrains Linux download page.

This isn't the perfect installation method but a set of compromises; one disadvantage is that it doesn't provide a launcher. While I knew there would be compromises, I wanted to:

Avoid changing the base Fedora Silverblue system with rpm-ostree
Avoid a complicated setup that includes manually installed dependencies
Use a supported, official method

In the end I didn't have to compromise on these three points. The process of writing out and ordering the potential compromises for someone else to follow helped me to prioritise the order in which I investigated options.

Installing GoLand under Fedora Silverblue was easier than I expected. I wonder what other surprises I will find now I have GoLand up and running.

Actionable output from Ansible 2.11

Keith Maxwell — Fri, 03 Apr 2020 12:42:30 +0000

ANSIBLE_DISPLAY_SKIPPED_HOSTS=no ANSIBLE_DISPLAY_OK_HOSTS=no \
    ansible-playbook -i, site.yaml

Though there is more to say than that. This is my first blog on https://dev.to and I've ideas and drafts for many more. I was really encouraged by Miguel Grinberg's talk at PyCon Limerick. I am pleased to have put a post out into the world.

I am a big fan of Ansible and have found the community, especially the documentation team, very welcoming. I've been using Ansible since around version 2.4 which was released in 2017. The current version is 2.9.

Ansible 2.7 deprecated a feature for limiting the output of the ansible-playbook command line interface (CLI). It is scheduled to be removed in 2.11. This post explains a little context and how to switch over to the new approach.

As you may know, deprecation is a process for removing features from software; in Ansible deprecation follows a policy. This process gives users warnings and an opportunity to move away from the deprecated feature before anything relying on it breaks.

Simplifying a little, an Ansible playbook runs a series of tasks against a host. By default the ansible-playbook CLI reports back the status from each task. This can be reported as:

OK: completed successfully and nothing was changed
Changed: completed successfully with changes
Failed: the task did not complete . Skipped: the task was not run, likely because of a when: clause

Ansible will report a task as unreachable if it cannot contact the host. Further ignored and rescued relate to bespoke error handling.

Quickly identifying tasks with a changed status is a helpful filter. It is particularly effective if you write idempotent playbooks. Failed tasks are also of interest.

If you are tracking configuration as code, for example as Ansible playbooks in a git repository, this filtering makes it easier to marry the system changes reported by Ansible and the configuration changes in git.

Before Ansible 2.7 the recommended way to filter output to only show tasks with a changed or failed status was the actionable plugin. In Ansible 2.11 that plugin will be removed.

The current approach is to set two options and use the default output plugin. The two commands below show the old and new approach:

ANSIBLE_STDOUT_CALLBACK=actionable ansible-playbook -i, site.yaml
ANSIBLE_DISPLAY_SKIPPED_HOSTS=no ANSIBLE_DISPLAY_OK_HOSTS=no \
    ansible-playbook -i, site.yaml

There are many different ways to set these options; either in configuration files or environment variables. The change is the same regardless: instead of overriding the default callback plugin for standard out, stdout_callback=actionable, instead set two options on the default callback: display_skipped_hosts=no and display_ok_hosts=no.