`xdg-open` fails when using Firefox under Wayland

Recently I noticed xdg-open started failing opening links in Firefox. Giving me the following error:

Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system.

Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system.

It happened while I had Firefox running and responding to everything else. I’m running the latest stable Firefox (74 as I’m writing this) on Wayland. Wayland brings a lot of good things, but also a lot of interoperability problems, so I suspected it had something to do with it. Thanks to Martin Stransky I found out that the solution is to set the MOZ_DBUS_REMOTE environment variable prior to launching Firefox. If you are using a desktop file to launch Firefox, you can set the variable in the Exec line like this:

[Desktop Entry]
Exec=env MOZ_DBUS_REMOTE=1 MOZ_ENABLE_WAYLAND=1 /home/guyru/.local/firefox/firefox %u

You will need to restart Firefox before the fix will take affect.

Install JetBrains Mono in Debian/Ubuntu

JetBrains Mono is a new monospace typeface designed to be comfortable to read. It has clear distinction between the different letters and relatively high x-height.

The installation instruction were tested on Debian, but should work on every Linux.

Download and unzip the font:

$ wget https://download.jetbrains.com/fonts/JetBrainsMono-1.0.0.zip
$ unzip JetBrainsMono-1.0.0.zip

Install the font to either the user’s font directory

$ mv JetBrainsMono-*.ttf ~/.local/share/fonts/

or the system-wide one:

$ sudo mv JetBrainsMono-*.ttf /usr/share/fonts/

To use the font in gVim set guifont accordingly in ~/.vimrc:

:set guifont=JetBrains\ Mono\ 13

libGL error: unable to load driver: radeonsi_dri.so

After playing with installing and removing the amdgpu and amdgpu-pro drivers, my system could not load the radeonsi. glxinfo returned the following error:

$ DRI_PRIME=1 glxinfo | grep OpenGL
libGL error: unable to load driver: radeonsi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeonsi

It was solved by cleaning up leftover symlinks and reinstalling libgl-mesa-dri

$ sudo find /usr/lib/ -lname "/opt/amdgpu/*" -print -delete

$ sudo apt install --reinstall libgl1-mesa-dri

Yubikey doesn’t work on Firefox installed via Snap

Installing Firefox via Snap is an easy way to get the latest Firefox version on your favorite distro, regardless of the version the distro ships with. However, due to Snap’s security model, Yubikeys, or any other FIDO tokens do not work out of the box. To enable U2F devices, like Yubikeys, you need to give the Firefox package the necessary permissions manually:

$ snap connect firefox:u2f-devices

Generating secure passphrases on the command line

The following snippet should work on every system that has coreutils.

$ shuf /usr/share/dict/words --repeat --random-source /dev/random -n 5

You can swap /usr/share/dict/words with any good wordlist, like EFF’s or Arnold Reinhold’s Diceware list.

You can also add it for ease of use to your ~/.bash_aliases

alias passphrase="shuf ~/dotfiles/misc/diceware8k.txt --repeat --random-source /dev/random -n"

And then you could easily use it in bash:

$ passphrase 5

Disable Yubikey’s OTP

By default, when you touch a Yubikey it types an OTP code. These codes looks like:


Theoretically they are used for Yubico’s proprietry authentication, but in reality they are mostly annoying. This is especially true for Yubikey Nano, which is impossible to remove without touching it and triggering the OTP.

Yubikey 5 Nano

Disabling the OTP is possible using the Yubikey Manager, and does not affect any other functionality of the Yubikey.

$ sudo apt install yubikey-manager
$ ykman config usb --disable otp
Disable OTP.
Configure USB interface? [y/N]: y

Note for Yubikey 4: the above command will not work and fail withe the following error:

Error: Configuring applications is not supported on this YubiKey. Use the `mode` command to configure USB interfaces.

Instead use the following command:

$ ykman mode FIDO+CCID
Set mode of YubiKey to FIDO+CCID? [y/N]: y
Mode set! You must remove and re-insert your YubiKey for this change to take effect.

virt-manager: Error starting domain

Virtual Machine Manager (virt-manager) doesn’t automatically start your virtual networks. This leads to the following error when starting a vitual machine

Error starting domain: Requested operation is not valid: network 'default' is not active

To solve this error, on Virtual Machine Manger go to Edit->Connection Details->Virtual Networks, select the required network (‘default’ in our case) and press the Start Network button (has a play-button icon). You can avoid having to go through this process by ticking the Autostart checkbox, which will make the network start automatically at boot.

OpenVPN server fails to start on Debian Stretch

After a recent upgrade to Debian Stretch, my OpenVPN server stopped working. Checking the relevant log file, /var/log/openvpn.log, I found the following not very helpful error message.

Fri Nov 23 16:46:37 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Fri Nov 23 16:46:37 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Fri Nov 23 16:46:37 2018 daemon() failed or unsupported: Resource temporarily unavailable (errno=11)
Fri Nov 23 16:46:37 2018 Exiting due to fatal error

Fortunately, someone already reported this error to debian and found out that the error is caused by the


in the /lib/systemd/system/openvpn@.service. The LimintNPROC directive in systemd is used to limit the number of forks a service is allowed to make. Removing this limit, might not be the best idea. So, I would suggest that instead of commenting it out, to find out the minimal value that allows OpenVPN to start and work. After some testing, I found that the minimal value that worked for me is


After editing the /lib/systemd/system/openvpn@.service, you need to reload the systemd service files and restart the OpenVPN server process.

$ sudo systemctl daemon-reload
$ sudo systemctl restart openvpn@server