When logged into a server via SSH, usually any attempt to decrypt a file with GPG results in an unhelpful error message like:

gpg: cancelled by user
...
gpg: decryption failed: No secret key

with no attempt made to ask for a password.

Fix for this is simply to execute: export GPG_TTY=`tty`,

Note that if pinentry-program in ~/.gnupg/gpg-agent.conf is set to /usr/bin/pinentry-gtk, and this is an alias for /usr/bin/pinentry-gtk-2, set pinentry-program to the latter (/usr/bin/pinentry-gtk-2), which appears to change the behaviour (pinentry-gtk-2 should be able to automatically detect whether to execute in GUI or text mode, whereas the original pinentry-gtk is GUI-only.

See also "Forcing GPG passphrase input in the terminal".

I started getting intermittent sets of error messages like this:

error: rpmdb: BDB0113 Thread/process 26154/140393252489024 failed: BDB1507 Thread died in Berkeley DB library
error: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db5 -  (-30973)
error: cannot open Packages database in /var/lib/rpm

when deploying changes to a bunch of AWS EC2 instances.

The error messages are misleading as (in this case at least) the RPM database is not corrupted; the underlying issue was this:

[67897.740241] Out of memory: Kill process 28759 (yum) score 330 or sacrifice child
[67905.749492] yum invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

i.e. simply a lack of memory (the instances were just too small).

The Prometheus PostgreSQL storage adapter does not seem amenable to being executed directly from a systemd service file.

As a workaround I created a wrapper script like this (adjust parameters as required):

#!/bin/bash

# Wrapper to launch prometheus-postgresql-adapter, as calling
# it directly from the systemd service file doesn't seem to work.
#
# Disclaimer: there is probably a better way of doing this.

nohup /usr/local/bin/prometheus-postgresql-adapter \
-pg-host=... \
-pg-port=... \
-pg-database="..." \
-pg-user="..." \
>> /var/log/prometheus-postgresql-storage-adapter/prometheus-pg-adapter.log 2>&1

and a service file like this:

[Unit]
Description=Prometheus PostgreSQL Storage Adapter
Documentation=https://github.com/timescale/prometheus-postgresql-adapter
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=prometheus
Group=prometheus
ExecStart=/usr/local/bin/prometheus-postgresql-adapter-wrapper
Restart=on-failure

[Install]
WantedBy=multi-user.target

which works fine (YMMV of course).

There may of course be a more elegant way of solving this issue, if so feel free to share.

One annoyance when entering GPG passphrases in terminal applications on many systems is that a seperate GUI window pops up. To enable passphrase entry in the comfort of your own terminal, set the following line in .gnupg/gpg-agent.conf

pinentry-program /usr/bin/pinentry-tty

or in some older distributions (e.g. CentOS 7):

pinentry-program /usr/bin/pinentry-curses

The running agent's settings can be reconfigured with:

gpg-connect-agent reloadagent /bye

See also "Making GPG pinentry work over SSH".

• VirtualBox now works from the default repository (in 13.1 there were some issues with the stock VirtualBox installation)

After upgrading to openSUSE 13.1, the Samba configuration - which I use mainly to share a directory on my workstation-cum-fileserver to a media player on the local network - mysteriously failed to work as expected. The client could mount, but not see, any directories or files. The only vaguely relevant clue appeared to be this entry in /var/log/samba/log.smbd:

Invalid key 0 given to dptr_close

After much head-scratching, it turns out AppArmor is enabled by default on openSUSE 13.1 and was the source of the error. Resolving the issue with AppArmor brought Samba back to life.