Running a Xilinx hw_server as Docker Container

This article describes the necessary steps to run a Xilinx hw_server as a Docker container.

Xilinx’s hw_server is a command line utility which handles JTAG communication between a Xilinx FPGA board and usually the Vivado IDE. It can be used to configure the FPGA bitstream, connect to the embedded logic analyzer cores (ILA) or perform debugging of processor cores via GDB and the Xilinx System Debugger (XSDB). The hw_server is usually used when those tasks shall performed remotely as the connection between Vivado or XSDB is established via TCP connection and allows us to run it on a remote system.

Running the hw_server as a Docker container has the benefit that its installation is simplified to starting a Docker container by running:

docker run --restart unless-stopped --privileged --volume /dev/bus/usb:/dev/bus/usb --publish 3121:3121 --detach

It also allows us to run the hw_server on architectures which are not natively supported by Xilinx such as the commonly used Aarch / ARM64 and ARMv7 architectures found in Raspberry Pis.

This is enabled by Dockers support for running container images for non-native architectures. I am using the aptman/qus image to setup this user-mode emulation. qemu-user-static (qus) is a compilation of utilities, examples and references to build and execute OCI images (aka docker images) for foreign architectures using QEMU‘s user-mode emulation.

Run the following commands to run the hw_server on a embedded device:

# Install docker
sudo apt-get update && sudo apt-get upgrade
curl -sSL | sh

# Start Docker
sudo systemctl enable --now docker

# Enable qemu-user emulation support for running amd64 Docker images
# *Note:* only required if your system arch is not amd64!
docker run --rm --privileged aptman/qus -s -- -p x86_64

# Run the hw_server
docker run --restart unless-stopped --privileged --volume /dev/bus/usb:/dev/bus/usb --publish 3121:3121 --detach

This setup has been tested with a Raspberry Pi 4 running the new 64-bit Debian Bullseye Raspberry Pi OS.

The pre-built Docker image for the hw_server of Vivado 2021.2 is available via

Detailed instructions can be found in the following Git repo:

Encrypted credentials for Amazon AWS command line client

In this quick post I will show howto use the password manager “password-store1 to securely store your credentials used by the Amazon Webservices command line client.

The installation for Mac and Linux system is fairly easy:
$ pip install awscli

The credentials are stored as key-value pairs inside a PGP-encrypted file.
Everytime you call the AWS CLI tool, your keys will be decrypted and directly passed to the aws tool.

Use pass to add your keys in the store:
$ pass edit providers/aws

An editor opens. Use the following format:
User: stv0g
Secret-Key: vAAABn/PMAksd235gAs/FSshhr42dg2D4EY3

Add the following snippet to your .bashrc:

function aws {
	local PASS=$(pass providers/aws)
	local AWS=$(which aws)
	# Start original aws executable with short-lived keys
	AWS_ACCESS_KEY_ID=$(sed -En 's/^Access-Key: (.*)/\1/p' <<< "$PASS") \
	AWS_SECRET_ACCESS_KEY=$(sed -En 's/^Secret-Key: (.*)/\1/p' <<< "$PASS") $AWS $@

Then use the cli tool aws as usual:
$ aws iam list-access-keys
{ "AccessKeyMetadata": [ { "UserName": "stv0g", ...

Use Yubikey and Password-store for Ansible credentials

I spent some time over the last months to improve the security of servers and passwords. In doing so, I started to orchestrate my servers using a configuration management tool called Ansible. This allows me to spin-up fresh servers in a few seconds and to get rid of year-old, polluted and insecure system images.


My ‘single password for everything’ has been replaced by a new password policy which enforces individual passwords for every single service. This was easier than I previously expected:

To unlock the ‘paranoid’ level, I additionally purchased a Yubikey Neo token to handle the decryption of my login credentials in tamper-proof hardware.
pass‘ is just a small shell script to glue several existing Unix tools together: Bash, pwgen, Git, xclip & GnuPG (obeying the Unix philosophy). The passwords are stored in simple text files which are encrypted by PGP and stored in a directory structure which is managed in a Git repository.

Yubikey Neo und Neo-n

There are already a tons of tutorials which present the tools I describes above. I do not want to repeat all that stuff. So, this post is dedicated to solve some smaller issues I encountered:

Use One-Time passwords across multiple servers

The Yubikey Neo can do much more than decrypting static passwords via GnuPG:

  • Generate passwords:
    • fixed string (insecure!)
    • with Yubico OTP algorithm
    • with OATH-HOTP algorithm
  • Do challenge response authentication
    • via FIDO’s U2F standard
    • with HMAC-SHA1 algorithm
    • with Yubico OTP algorithm

Some third-party services already support FIDO U2F standard or traditional OATH-{H,T}OTP TFA, like used by the Google authenticator app. I suggest to have a look at:

For private servers there are several PAM modules available to integrate OTP’s or Challenge Response (CR) methods. Unfortunately, support for CR is not widespread across different SSH- and mail clients.

So, you want to use OTP’s which leds to another problem: OTP’s rely on a synchronized counter between the hardware token and the server. Once you use multiple servers, those must be synchronized as well. I’m using a central Radius server to facilitate this.

Integrate ‘pass’ into your Ansible workflow

Ansible uses SSH and Python scripts to manage several remote machines in parallel. You must use key-based SSH authentication, because you do not want to type every password manually! Additionally you need to get super user privileges for most of your administrative tasks on the remote machine.

The SSH authentication is handled by gpg-agents ‘–enable-ssh-support’ option and a PGP key on your token.

To get super user privileges, I use the following variable declaration my Ansible “group_vars/all” file:
ansible_sudo_pass: "{{ lookup('pipe', 'pass servers/' + inventory_hostname) }}"

There is a separate root password for every server (e.g. “pass servers/”). I wrote some ansible roles to easily and periodically roll those passwords.

Integrate ‘pass’ into OS X

There are already several plugins and extensions to intergrate the ‘pass’ password store into other Programs like Firefox and Android.

A prompt for the password you want

I added support for OS X by writing a small AppleScript which can be found here:

A notification with countdown


simsons_vermittlung“transWhat” ist ein XMPP Transport, der den WhatsApp Messenger in das Jabber Netzwerk einbindet.

Das Gateway simuliert dabei serverseitig die normale WhatsApp App von Android bzw. iPhone. Der User benötigt nur noch einen normalen XMPP Client wie beispielsweise Adium, Gaijm, IM+ oder Pidgin. Damit ist es nun möglich WhatsApp auf nahezu allen Geräten und Betriebssystemen einzusetzen.
Ich kann transWhat sehr in Kombination mit Pidgin auf Desktops und Laptops und mit IM+ auf Tablets empfehlen 🙂


Alle Details, Serverdaten, Logins, Tipps und Tricks findet ihr hier im Wiki.

Aus verschiedenen Gründen werde ich den Code nicht veröffentlichen sondern das Gateway nur als Service anbieten.

Ich habe mich nun doch dazu entschieden den Quelltext freizugeben. Er ist in meinem GitHub Repository zu finden.

Nach dem Break gibt’s noch ein paar technische Details und Informationen zur Umsetzung. transWhat weiterlesen


calcelestial ist ein kleines Linux-Tool zum Berechnen von Auf- und Untergangszeiten sowie der Position sämtlicher Planeten unseres Sonnensystems.

Es ist der Weiterentwicklung von sun, das ursprünglich als kleines Bash-Skript für meinen Router startete. Mittlerweile ist das Tool zu einem weit umfangreicherem Werkzeug gewachsen, welches nicht mehr nur die Auf- und Untergangszeit der Sonne berechnen kann:

Es sind mit dem Mond, Mars, Neptun, Jupiter, Merkur, Uranus, Saturn, Venus und Pluto eine Menge neuer Planeten dazugekommen. Auch kann nun die Position dieser Himmelskörper zu jedem beliebigen Zeitpunkt oder dem Auf- und Untergang berechnet werden.

Nun bin ich selber kein kleiner Hobby-Astronom, sodass ich diese ganzen Berechnungen aus dem Ärmel schütteln könnte. Stattdessen nutze ich die Bibliothek libnova. libnova benutzt die sehr genauen Algorithmen “Variations Séculaires des Orbites Planétaires” (kurz VSOP-87), die Pierre Pratagnon 1987 entwickelte.

  calcelestial [options]
  -p, --object		calc for celestial object: sun, moon, mars, neptune,
			 jupiter, mercury, uranus, saturn, venus or pluto
  -H, --horizon		calc rise/set time with twilight: nautic, civil or astronomical
  -t, --time		calc at given time: YYYY-MM-DD [HH:MM:SS]
  -m, --moment		calc position at moment of: rise, set, transit
  -n, --next		use rise, set, transit time of tomorrow
  -f, --format		output format: see strftime (3) for more details
  -a, --lat		geographical latitude of observer: -90° to 90°
  -o, --lon		geographical longitude of oberserver: -180° to 180°
  -q, --query		query for geographical coordinates
  -z, --timezone	override system timezone
  -u, --universal	use universial time for parsing and formatting
  -h, --help		show this help
  -v, --version		show version
A combination of --lat &amp; --lon or --query is required.
Please report bugs to:


Die einfachste Variante nutzt das Unix Tool at:

echo ~/bin/enable-lightning | at $(calcelestial -p sun -m set -q Frankfurt -H civil)

Mit folgenden Cronjobs, lässt sich dieses Prinzip auch leicht auf andere Anwendungen übertragen:

0 0 * * * echo 'fnctl stop && fnctl fade -c 000000' | at $(calcelestial -m rise -p sun -q Aachen)
0 0 * * * echo 'fnctl start' | at $(calcelestial -m set -p sun -q Frankfurt)

Mit dem Tool nvram-wakeup, lässt sich so bsp. der Rechner jeden Tag 10 Minuten for Sonnenaufgang automatisch starten ^^:

nvram-wakeup -s $(date -d "-10 min $(calcelestial -m rise -p sun -q Berlin)" +%s)

Oder möchtest du deinen Rechner nach Sonnenuntergang automatisch herrunterfahren?

shutdown $(date -d +10 min $(calcelestial -m rise -p sun --lat=50.55 --lon=-6.2) +%H:%M)

Die aktuelle Position des Mondes kann bspw. so bestimmt werden:

calcelestial -p moon -q Aachen -f "az: §a alt: §h"

Detailiertere Dokumentation findet ihr in der Manpage calcelestial(1).


calcelestial ist wie immer in meinem git-Repository zu finden, sowie auch direkt als Debian/Ubuntu Package in meinem APT-Repository.