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.

Recently I had to work with some Python code which needs to be compatible with both the hopefully-soon-to-be-finally-deprecated Python 2.7 and recent 3.x versions.

String handling can be a tricky issue, particularly if the string in question needs to be cast to a Unicode object. Take the following example:

#!/usr/bin/env python

import ipaddress

addresses = list(ipaddress.ip_network(unicode('192.168.1.0/24')));

for address in addresses:
    print(address)

This does of course fail in Python 3.x with an error like:

Traceback (most recent call last):
  File "./python.py", line 5, in 
    addresses = list(ipaddress.ip_network(unicode('192.168.1.0/24')));
NameError: name 'unicode' is not defined

Remove the unicode() wrapper and it fails in Python 2.x with:

ipaddress.AddressValueError: '192.168.1.0/24' does not appear to be an IPv4 or IPv6 network. Did you pass in a bytes (str in Python 2) instead of a unicode object?

The solution is to use the "six" compatibility layer and add the following directive, which reassigns unicode() to a mutually compatible function:

#!/usr/bin/env python

import ipaddress

from six import u as unicode

addresses = list(ipaddress.ip_network(unicode('192.168.1.0/24')));

for address in addresses:
    print(address)

Note that the "six" compatibility layer may need to be installed separately, in RedHat et al via the packages python2x-six and python3x-six respectively.

Useful links

• Six: Python 2 and 3 Compatibility Library
• Building a Python 2/3 compatible Unicode Sandwich
• Strings, Bytes, and Unicode in Python 2 and 3

Spent a lot of time working out why openvpn wouldn't connect from a Vagrant virtual machine (running Ubuntu 14.04 LTS):

Tue Jan 10 02:51:25 2017 Control Channel Authentication: tls-auth using INLINE static key file
Tue Jan 10 02:51:25 2017 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jan 10 02:51:25 2017 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jan 10 02:51:25 2017 Socket Buffers: R=[212992->200000] S=[212992->200000]
Tue Jan 10 02:51:25 2017 UDPv4 link local: [undef]
Tue Jan 10 02:51:25 2017 UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
Tue Jan 10 02:51:25 2017 TLS: Initial packet from [AF_INET]xxx.xxx.xxx.xxx::1194, sid=92749f62 ced33a12
Tue Jan 10 02:52:25 2017 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Jan 10 02:52:25 2017 TLS Error: TLS handshake failed
Tue Jan 10 02:52:25 2017 SIGUSR1[soft,tls-error] received, process restarting
Tue Jan 10 02:52:25 2017 Restart pause, 2 second(s)

Turns out the openvpn version (2.3.2) is outdated; 2.3.4 or later is needed.

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-curses

The OS X "top" command default output is somewhat hard to decipher (and modify interactively) compared to Linux. A simple workaround is to launch it with:

top -o cpu

(or another field) which sorts on cpu activity rather than the PID (default).

htop is also available via MacPorts.

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

I was setting up a cronjob and it kept failing with the very unhelpful util.c: No such file or directory. After much headscratching it turns out this is a gnuplot error message, meaning it is unable to read from or write to a file (in this case the latter). The file in question is not of course util.c.

I was bemused by the below error when attempting to run an Ansible playbook on a new (Linux) server for the first time:

PLAY [someserver] ***************************************************************** 

GATHERING FACTS *************************************************************** 
failed: [someserver] => {"failed": true, "parsed": false}

SUDO-SUCCESS-fdhntaxupgygzrcocwghbosdkgbgguvy
/bin/sh: 1: powershell: not found

This happened with gather_facts set to true. Setting it to false worked around the issue, however I'm pretty sure powershell hasn't been ported to Debian... Ansible version:

$ ansible-playbook --version
ansible-playbook 1.8 (devel ffee9a8fe0) last updated 2014/09/27 14:24:58 (GMT +900)

The actual cause was the absence of python on the target server; this will need to be manually installed before Ansible can be of much use.

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.