Friday, January 24, 2020 6:07 AM
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".
Tuesday, September 24, 2019 11:12 PM
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).
Thursday, September 5, 2019 1:31 AM
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.
Monday, May 30, 2016 11:54 AM
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".
Sunday, February 22, 2015 5:44 AM
Sunday, February 16, 2014 8:39 AM
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.