Yet Another SysAdmin Website - Blog

Installing FreeBSD 15 on any VPS

2026-05-29

Introduction

Not many Virtual Private Server (VPS) providers consider FreeBSD a first-class citizen, and few encourage you to encrypt your hard drive from inside the VPS.

Though encrypting a VPS hard drive does not protect against everything and requires one to access the web KVM of the provider to type in a password on each reboot, I still find it reassuring.

You need a little know-how to be able to set up FreeBSD in a not so friendly environment. There are several procedures to achieve this floating around the Internet, but I found those either too complicated or out of date. This article presents my preferred way to install a FreeBSD operating system on a provider that does not officially support it, and it works even for other unsupported operating systems.

Install a Linux system to inspect the pre-provisioned VPS

Depending on your provider, you will want to prepare either a BIOS boot image (for example at OVH) or a UEFI boot image (for example on Azure or on Oracle Cloud). One way to find out which one is to install any Linux image supported by your provider and run:

dmesg | grep -i "efi:"

If you see lines like the following, then you need to prepare a UEFI boot image. Otherwise, prepare a BIOS boot image:

[ 0.000000] efi: EFI v2.7 by EDK II
[ 0.000000] efi: SMBIOS=0xbbea9000 ACPI=0xbbf9c000 ACPI 2.0=0xbbf9c014 MEMATTR=0xba639518 MOKvar=0xbbe97000

Bootstrap the FreeBSD installer on a local virtual machine

Create the RAW hard drive image for your virtual machine. Using the minimal necessary size will speed up the later image transfer. At the time of this writing, FreeBSD bootstraps fine on 1.6G of storage:

qemu-img create -f raw freebsd.raw 1600M

Download the installer image from an official mirror then start up the installer in the virtual machine.

I start a BIOS booted virtual machine with something like:

qemu-system-x86_64 \
 -drive if=none,id=disk,file=$PWD/freebsd.raw,format=raw,cache=writeback \
 -cdrom $HOME/Downloads/FreeBSD-15.0-RELEASE-amd64-bootonly.iso \
 -boot d -machine type=q35,accel=kvm \
 -cpu host -smp 2 -m 4096 \
 -nic user,model=virtio-net-pci,hostfwd=tcp::10022-:22 \
 -device virtio-blk-pci,drive=disk \
 -device virtio-serial-pci \
 -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \
 -vga qxl -spice port=5902,addr=127.0.0.1,disable-ticketing=on \
 -chardev spicevmc,id=spicechannel0,name=vdagent

To boot in UEFI mode instead, add the following line somewhere in the middle. You might need to install another package and customize the path on your system, this one is for Gentoo:

 -bios /usr/share/edk2/OvmfX64/OVMF_CODE.fd \

If you are short on memory, tune down the -m 4096 flag that configures the amount allocated to the virtual machine.

This virtual machine starts up with a SPICE display device, which I like better than VNC, and can be accessed with a SPICE client like spicy. If you would rather use VNC instead, replace the lines mentioning SPICE with the following to start a VNC server on port 5900:

 -display vnc 127.0.0.1:0 \
 -vga none -device virtio-vga,edid=on,xres=2560,yres=1440

Install FreeBSD

Proceed to install FreeBSD as you normally would. I personally switched to pkgbase instead of the venerable distribution sets and am very happy with this choice. For simple host setups like this with only one drive, I use the auto ZFS partitioning mode. Make sure to choose the correct Partitioning Scheme and to encrypt your disks if you wish to. I also disable swap at this point.

To type in passwords, either for disk encryption or for the root and user accounts, the SPICE or VNC GUI can be unwieldy. When it is time for a password prompt, I like to use xdotool to simulate the keyboard inputs, bypassing the fact that copy/paste is not functional:

read -rs pass
sleep 2; xdotool type -- "$pass"
unset pass

After pressing Enter to execute this command, I have two seconds to switch to the SPICE or VNC window before the password is typed for me.

Once the installation is complete, shut down the virtual machine.

Prepare the network configuration

Restart the virtual machine on the newly installed system by setting the boot device to c and removing the ISO image flags. Make sure to keep the UEFI setting if you need it!

qemu-system-x86_64 \
 -drive if=none,id=disk,file=$PWD/freebsd.raw,format=raw,cache=writeback \
 -boot c -machine type=q35,accel=kvm \
 -cpu host -smp 2 -m 4096 \
 -nic user,model=virtio-net-pci,hostfwd=tcp::10022-:22 \
 -device virtio-blk-pci,drive=disk \
 -device virtio-serial-pci \
 -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \
 -vga qxl -spice port=5902,addr=127.0.0.1,disable-ticketing=on \
 -chardev spicevmc,id=spicechannel0,name=vdagent

Log in as root, then edit your /etc/rc.conf. You likely used DHCP for the installation, but for most providers this needs to be customized for FreeBSD (in particular if you want IPv6). I found that there are no general rules here: the best indicator is to install a Linux system supported by your VPS provider and inspect the pre-provisioned configuration.

For example on an OVH VPS, I set everything statically in a /etc/start_if.vtnet0:

ifconfig vtnet0 inet 37.187.244.19/32
route -4 add 37.187.244.1/32 -interface vtnet0
route -4 add default 37.187.244.1
ifconfig vtnet0 inet6 2001:41d0:401:3100::fd5/64
route -6 add default 2001:41d0:401:3100::1

But on Oracle Cloud Infrastructure, I use something like:

ifconfig vtnet0 inet 10.0.0.62/24
route -4 add default 10.0.0.1
ifconfig vtnet0 inet6 2603:c022:c002:8500:e2a4:f02e:43b0:c1d8/64 accept_rtadv

You will have to figure out what you need based on the provider you chose.

Boot the VPS in rescue mode and transfer the disk image

Most VPS providers offer a rescue mode that will boot your server on a Linux image with diagnostic tooling. If yours does not offer that capability, maybe you can do something similar by creating a second Linux server and attaching the boot disk of the first one to it (that’s what I did to get my FreeBSD image to Oracle Cloud).

Whatever way you proceed, your first step is to identify what the /dev path of the target block device is with blkid and fdisk -l. I will use /dev/sdb as an example. Make sure your disk is not mounted anywhere (rescue modes love to do that).

Once ready, completely erase your disk with blkdiscard /dev/sdb. If blkdiscard is unsupported for some reason, you can skip it. Then copy over your raw image. I usually copy it in place with a command like the following (replace myth.adyxax.org with your actual server address):

dd if="$PWD/freebsd.raw" | ssh root@myth.adyxax.org dd of=/dev/sdb

First boot

Once the image has finished transferring, you should be able to disable rescue mode (or shut down the temporary installation instance and reattach the boot disk to your original instance if you went that route). Reboot your server to enjoy your new FreeBSD system!

If you chose full disk encryption, or if anything goes wrong and you need to debug the boot process, then the web KVM of your provider will be your best friend.

Resizing the root disk

I deliberately set up a very small virtual disk as to speed up transfer of the resulting image. After booting into the new system, we will want to make use of the full storage space allocated to the instance. When using FreeBSD with root on ZFS, I first inspect the storage layout with these two commands:

# gpart show -p
=> 40 41942960 da0 GPT (20G)
 40 1024 da0p1 freebsd-boot (512K)
 1064 984 - free - (492K)
 2048 41940952 da0p2 freebsd-zfs (20G)

# zpool status -P
 pool: zroot
 state: ONLINE
config:
 NAME STATE READ WRITE CKSUM
 zroot ONLINE 0 0 0
 /dev/da0p2.eli ONLINE 0 0 0

I then do the resizing with something like:

gpart recover da0
gpart resize -i 2 da0
geli resize /dev/da0p2
zpool online -e zroot /dev/da0p2.eli

Conclusion

This method has served me well for years, and I am glad I finally took the time to write the FreeBSD version of these instructions for future reference.

My current nftables laptop configuration

2026-04-29

Introduction

I have blogged about my pf firewall configurations a few times, but never my Linux ones. There is nothing especially unusual about it, but it does differ somewhat from the common nftables examples.

Configuration

This is the configuration for my Gentoo laptop. It has two Wireguard interfaces and references two egress interfaces, one for Ethernet and one for WiFi:

#!/sbin/nft -f

flush ruleset

define allowed_icmp_types = { echo-reply, echo-request };
define trusted_icmp_types = { destination-unreachable, time-exceeded };
define allowed_icmpv6_types = { nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, echo-request, echo-reply };

define egress_ifs = { enp0s31f6, wlp0s20f3 };

table inet filter {
 set private4 {
 type ipv4_addr;
 flags constant, interval;
 elements = { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 };
 }
 set private6 {
 type ipv6_addr;
 flags constant, interval;
 elements = { fd00::/8, fe80::/10 };
 }
 chain forward_docker {
 # forward docker traffic only to the Internet, not to wireguard, our LAN or
 # other interfaces
 oifname $egress_ifs ip saddr @private4 ip daddr != @private4 counter accept;
 oifname $egress_ifs ip6 saddr @private6 ip6 daddr != fd00::/8 counter accept;
 }
 chain input_docker {
 # Allow container access to local Postgres and Valkey
 ct state new tcp dport { 5432, 6379 } counter accept;
 }
 chain input_egress {
 ct state new tcp dport ssh limit rate 5/minute counter accept;
 }
 chain input_wireguard_adyxax {
 icmp type $trusted_icmp_types counter accept;
 ip protocol ospf counter accept;
 ip6 nexthdr ospf counter accept;
 udp dport { 3784, 4784 } accept; # Allow BFD
 ct state new tcp dport ssh counter accept;
 }
 chain input_wireguard_normal {
 icmp type $trusted_icmp_types counter accept;
 ct state new tcp dport ssh limit rate 5/minute counter accept;
 }
 # Chain hooks
 chain input {
 type filter hook input priority 0;
 policy drop;
 iifname lo accept;
 ct state {established, related} counter accept;
 ct state invalid counter drop;
 icmp type $allowed_icmp_types counter accept;
 icmpv6 type $allowed_icmpv6_types counter accept;
 iifname docker0 counter jump input_docker;
 iifname $egress_ifs counter jump input_egress;
 iifname wg-myth counter jump input_wireguard_adyxax;
 iifname wg-normal counter jump input_wireguard_normal;
 # drop mDNS traffic without logging
 ip daddr 224.0.0.251 udp dport 5353 counter drop;
 # drop multicast membership traffic without logging
 ip protocol igmp counter drop;
 log prefix "input drop: " limit rate 10/second counter drop;
 counter drop;
 }
 chain forward {
 type filter hook forward priority 0;
 policy drop;
 ct state {established, related} counter accept;
 ct state invalid counter drop;
 iifname docker0 counter jump forward_docker;
 log prefix "forward drop: " limit rate 10/second counter drop;
 counter drop;
 }
 chain output {
 type filter hook output priority 0;
 policy accept;
 ct state {established, related} counter accept;
 ct state invalid counter drop;
 ct state new counter accept;
 ip protocol icmp counter accept;
 ip6 nexthdr icmpv6 counter accept;
 meta l4proto ipv6-icmp counter accept;
 log prefix "output accept: " counter accept;
 }
}

table ip nat {
 chain postrouting {
 type nat hook postrouting priority srcnat;
 policy accept;
 # Only NAT traffic to the Internet, not to our LAN
 oifname $egress_ifs \
 ip daddr != 10.0.0.0/8 \
 ip daddr != 172.16.0.0/12 \
 ip daddr != 192.168.0.0/16 \
 counter masquerade;
 }
}

table netdev filter {
 chain ingress {
 type filter hook ingress device $egress_ifs priority -500;
 # Drop all fragments.
 ip frag-off & 0x1fff != 0 counter drop
 # Drop XMAS packets.
 tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg counter drop
 # Drop NULL packets.
 tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 counter drop
 # Drop uncommon MSS values.
 tcp flags syn tcp option maxseg size 1-535 counter drop
 }
}

I like the private IPv4 and IPv6 sets (taken from my pf configurations), though they are not as convenient to use in nftables as they are in pf. Nftables does not let sets express inverted matches like pf does, which limits how compactly some rules can be written. They are also scoped to a single table rather than being globally reusable.

I do not allow Docker to modify my firewall ruleset, I want it to remain all static and predictable. That is why the Docker related rules are written explicitly here.

Conclusion

Overall, this setup is fairly conservative: default drop on input and forward while explicit handling of traffic on each interface for egress, containers and wireguard.

If you have nftables tips, I would be glad to read them. Feel free to reach me by email or on Mastodon.

Toying with OSPF over Wireguard on FreeBSD

2026-04-10

Introduction

For almost a decade, I have been operating my own mesh overlay network using a combination of point to point OpenVPN tunnels with OSPF on top. It was well automated with Ansible and served me well all these years.

I decided it was time I tried to move this to Wireguard instead and spent a bit of time making it all work. This article does not explain everything I did, but will present some lessons I learned in the process.

Routing OSPF over Wireguard

By default, Wireguard encourages you to only allow the minimum set of IP prefixes over a Wireguard tunnel. It filters only that traffic, and conveniently populates a host’s routing table with static routes to the tunnel for each allowed prefix.

Wireguard also supports configuring multiple peers for a single Wireguard interface which is very convenient, but sadly cannot work with OSPF. Wireguard uses the allowed IP prefixes to decide which peer will receive a packet, and this is incompatible with a protocol that relies on multicast traffic in order to work. I therefore need one Wireguard interface per peer over which to run OSPF.

Also since I need to route traffic for dynamically learned routes, the allowed IP filters pretty much need to be 0.0.0.0/0, ::/0 and cover everything. In practice I could also use the more restrictive 10/8, 172.16/12, 192.168/16, 224.0.0.5, 224.0.0.6, fd00::/8, fe80::/10, ff02::5, ff02::6.

Since I cannot have Wireguard insert multiple identical routes for all my Wireguard interfaces, I also need to disable this functionality. When using the popular wg-quick method, one needs to add Table = off to the [Interface] configuration. The native implementations do not need this, it is really only for wg-quick.

My FreeBSD /etc/start_if.wg0 config therefore looks like:

ifconfig wg0 create up description "laptop"
ifconfig wg0 inet 172.31.254.0/31
ifconfig wg0 inet6 fd00:172:31:254::/127
ifconfig wg0 inet6 fe80::/64
wg syncconf wg0 /etc/wg0.conf

And the corresponding /etc/wg0.conf looks like:

[Interface]
PrivateKey = gFAoJwJSfA0A8g+FhfxHLWXj6+CZdmPH4EW5pghqv30=
ListenPort = 342

[Peer]
PublicKey = bAg8bmMQxPFoNSG+Qq2VteCW4VUsi//VleBQBNa5Mno=
AllowedIPs = 0.0.0.0/0,::/0

FreeBSD vs Linux bridge and wireguard interfaces

On FreeBSD, I had a little trouble making OSPF v3 (for IPv6) work on a detached bridge interface (that I use for VNET jails), and on a wireguard interface.

The problem was that FreeBSD does not generate link-local IPv6 addresses for these kinds of interfaces, because they are not backed by a MAC address. And it turns out that the Bird routing daemon needs these link-local IPv6 addresses in order to work in point-to-point mode!

Luckily these are in effect point-to-point interfaces, so it matters very little which link-local address I set manually. I just used fe80::/64 everywhere and it worked.

Linux does not have this issue and will assign random link-local addresses to all its interfaces which really made this a confusing debugging session.

Some PF configuration rules

While not something I learned this time around, I will record here that one can allow OSPF traffic via PF with:

table <myself> const { self }
table <private> const { 10/8, 172.16/12, 192.168/16, fd00::/8, fe80::/10 }

pass out from <myself> to any

pass on { wg0, wg1 } from <private> to <private>
pass on { wg0, wg1 } proto ospf allow-opts

Some Bird configuration

Here is a basic Bird3 configuration to reproduce my setup:

log syslog all;

router id 172.31.253.1;

protocol device {
}

protocol direct {
 disabled;
 ipv4;
 ipv6;
}

protocol kernel {
 ipv4 { export all; };
 persist;
}

protocol kernel {
 ipv6 { export all; };
 persist;
}

protocol static { ipv4; }

protocol ospf v2 ospf4 {
 area 0 {
 interface "bridge0" { stub; };
 interface "wg0" { bfd yes; cost 100; type ptp; };
 interface "wg1" { bfd yes; cost 100; type ptp; };
 };
}

protocol ospf v3 ospf6 {
 area 0 {
 interface "bridge0" { stub; };
 interface "wg0" { bfd yes; cost 100; type ptp; };
 interface "wg1" { bfd yes; cost 100; type ptp; };
 };
}

protocol bfd {
 interface "wg*" {};
}

Conclusion

I cannot say yet if I will rewrite my Ansible automation for OSPF over Wireguard, but I certainly had fun figuring these out. I will probably toy with BGP again next, just because it is also “fun” to redistribute routes this way.

How to run Syncthing from Termux and Tasker on Android

2026-03-19

Introduction

I recently had my phone die on me and had to get a new one. One of the first apps I install is Syncthing, in order to restore my photos and app data.

Syncthing on Android has had quite the history, and for a time it was the norm to use Syncthing-Fork. A few months ago, this fork went through an ownership change, and I stopped updating this app until things settled.

On a new device, I wanted an up to date setup I could trust long-term and maintain myself. I found that the safest way for me to run Syncthing on Android was to turn to Termux.

Termux

I have been using Termux for about a decade. It is a simple and reliable way to get a Linux shell running on your phone. I only used it to SSH on servers and run some tools while on the go up until now, but of course it is possible to run server software on it.

Installing Termux is not difficult, but a few post installation steps need to be performed. I personally download the APK from f-droid, without installing f-droid itself.

When running Termux for the first time, I update it then setup the internal phone’s storage access with:

apt update -qq && apt dist-upgrade -y
termux-setup-storage

It is important to go into the Termux app settings and allow Termux to run in the background by disabling battery optimizations. Without that, it will get killed periodically by Android.

I then install and initialize syncthing with:

apt install syncthing -y
syncthing

This opens a web browser (or prints a URL you can open, depending on your environment) with the usual syncthing configuration page. In the settings I change the following for privacy:

Disable anonymous usage reporting.
Set a gui authentication user and password.
Disable NAT traversal.
Disable local discovery.
Disable global discovery.
Disable relaying.

I then proceed to add remote servers and folders.

Tasker

Since I use syncthing to synchronize my photos with my NAS at home, one of the main features of the Syncthing apps for me was to stop the background sync while not connected to a WiFi network.

By combining Tasker and Tmux:Tasker, I managed to get this feature back and improved, since I can now also filter on which networks I allow Syncthing to run.

If you left Syncthing running in Termux, now is the time to C-c to close it. In Termux, edit ~/.termux/termux.properties and uncomment the following so that Tasker can execute commands:

allow-external-apps = true

Go to Tasker’s Android app permissions, and under Additional permissions select Run commands in Termux environment. Restart Termux for the changes to take effect.

Then I create the Termux:Tasker script directory as well as the start and stop scripts:

cat >~/.termux/tasker/start-syncthing.sh <<EOF
#!/data/data/com.termux/files/usr/bin/bash
pgrep -x syncthing || syncthing serve --no-browser
EOF
cat >~/.termux/tasker/stop-syncthing.sh <<EOF
#!/data/data/com.termux/files/usr/bin/bash
pkill -x syncthing
EOF
chmod +x ~/.termux/tasker/*.sh

Then I open Tasker and create a profile for State, Net, WiFi Connected. I set my WiFi SSID, then add a task named Start Syncthing and configure it with:

Add Action, select Plugin then Termux:Tasker.
Click Configuration then set start-syncthing.sh as the command then disable wait for result.
Go back to the profile and long press the task. Select Add Exit Task and name it Stop Syncthing.
Add Action, select Plugin then Termux:Tasker.
Click Configuration then set stop-syncthing.sh as the command then disable wait for result.

All that remains to do is test by connecting and disconnecting the WiFi and run pgrep -x syncthing >/dev/null && echo running.

Conclusion

I am very happy with this setup, it works perfectly and provides me with a robust and trustworthy way to run Syncthing again.

How to check that an SSL certificate and its private key match

2026-03-09

Introduction

Though it is less common nowadays, SSL certificate provisioning can still be full of surprises when dealing with old school setups in client environments.

Some colleagues did not know how to easily check if a certificate and private key match in a clean one liner, and their LLM research came up with “interesting” suggestions with at least 6 pipes and too many checksum operations.

This prompted me to document my way of doing this.

Extracting the public key

The public key can be extracted with openssl using two commands. Here is the first one for the certificate:

openssl x509 -in mycertificate.crt -noout -pubkey

Here is the second one for the private key:

openssl pkey -in mykey.key -pubout

The diff command and process substitutions

Bash process substitutions are very useful, in particular in this context. They allow a command to read the output of other commands as pseudo files. For our purpose it looks like this:

diff -quw <(openssl x509 -in mycertificate.crt -noout -pubkey) \
 <(openssl pkey -in mykey.key -pubout)

The -quw flags are not important here, just a habit of mine. -q is to ask diff to be quiet, -u is to ask for a unified output while -w is to ignore whitespace differences.

If running the diff command from a script, know that it also exits 0 when the inputs are the same, 1 if they are different and >1 if another error occurred.

Conclusion

This provides a quick way to verify that a certificate and its private key match, while also demonstrating Bash process substitution. I encourage anyone to use these process substitutions more, they have many practical uses and can simplify command line workflows.

Updating dependencies

2026-02-04

Introduction

I find most of the popular dependency update automation tools like Dependabot or Renovate cumbersome to integrate, first and foremost because they cannot be run locally easily. Secondly, they cover everything and the kitchen sink and you cannot easily pick some languages or ecosystems to support. But if I could somehow ignore that, sadly they are clunky even in a forge setting as soon as you have to deal with private repositories and need to tightly manage access control.

I understand how valuable these popular tools can be though, especially in ecosystems that churn out new versions every other day. This makes these dependency update automation tools a must have at work where you need to reliably manage security updates across dozens of repositories I often do not own.

Since I try to avoid dependencies as much as I can in my personal development and infrastructure management, I believe I can get 90% of the value of these tools for 10% of the complexity thanks to a few lighweight scripts.

Updating dependencies

Docker Hub

The Docker Hub offers the an API endpoint to check the latest tags on a specific image. The trick is to write the right grep filter that will select only the release tags you care about:

local new_version
if ! new_version=$(curl -sSfL "https://hub.docker.com/v2/repositories/valkey/valkey/tags?page_size=100&ordering=last_updated" | \
 jq -r '.results|.[]|.name' | \
 grep -E '^[0-9](\.[0-9]){2}$'| \
 sort -V | \
 tail -n1); then
 echo "failed to get new version from docker hub tags" >&2; exit 1
fi
if [[ -z "$new_version" ]]; then
 echo "failed to get a non empty version from docker hub tags" >&2; exit 2
fi
if [[ "$new_version" != "$version" ]]; then
 echo "updating the repository to $project version $new_version"
 version="${version//./\\.}"
 sed -e "s!^version='$version'\$!version='$new_version'!" -i make.sh
fi

Git tags

The Git CLI can be used quite efficiently to get the latest tags on a specific repository. The trick is again to write the right filter the select only the tags you care about:

local new_seaweedfs_version
if ! new_seaweedfs_version=$(git ls-remote --tags --refs https://github.com/seaweedfs/seaweedfs | \
 perl -lane 'print $1 if /refs\/tags\/(\d.*)/'| \
 sort -V |
 tail -n1); then
 echo "failed to get new seaweedfs version from git RELEASE tags" >&2; exit 1
fi
if [[ -z "$new_seaweedfs_version" ]]; then
 echo "failed to get a non empty seaweedfs git RELEASE tag" >&2; exit 2
fi
if [[ "$new_seaweedfs_version" != "$seaweedfs_version" ]]; then
 echo "Updating the repository for $project version $new_seaweedfs_version"
 sed -e "s!^seaweedfs_version='$seaweedfs_version'\$!seaweedfs_version='$new_seaweedfs_version'!" -i make.sh
fi

Go

The official Go website conveniently offers a simple API endpoint to check the latest releases. I also update all module dependencies in this step for personal convenience:

local new_golang_version
if ! new_golang_version=$(curl -fsSL 'https://go.dev/dl/?mode=json' | \
 jq -r '[.[] | select(.stable == true)][0].version' | \
 sed -e 's/^go//'); then
 echo "failed to get new golang version from go.dev" >&2; exit 1
fi
if [[ -z "$new_golang_version" ]]; then
 echo "failed to get a non empty golang version number" >&2; exit 2
fi
sed -e "s/^go [0-9\\.]\+\$/go $new_golang_version/" -i go.mod
go get -t -u ./... && go mod tidy

OpenTofu/Terraform

Fetching the latest versions of OpenTofu/Terraform providers is trickier because proper parsing is needed to handle the files correctly.

I work around this by enforcing conventions. First I keep all provider definitions and configurations separate in a providers.tf file. Then I keep the source = and version = statements always sorted in that order (not a problem for me because I sort everything alphabetically anywhere I can, but critical for the script to work). I also do not use trailing comments for the source and version statements.

Note that this will pick the latest versions of each provider, not necessarily the latest compatible with your infrastructure code. One could update the script to filter on the same major versions the code currently relies on, but I do not bother in my personal circumstances and prefer to know and upgrade my code.

If I find any changes, I regenerate the Opentofu/Terraform lock file.

With this considered, I can forego proper parsing for the simpler:

get_latest_version() {
 local source=$1 latest
 if ! latest=$(curl -fsSL "https://registry.terraform.io/v1/providers/${source}/versions" | \
 jq -r '.versions[].version' | \
 sort -V | tail -n1); then
 echo "failed to get $source tofu provider version from the registry" >&2; exit 1
 fi
 if [[ -z "$latest" ]]; then
 echo "failed to get a non empty $source tofu provider version number" >&2
 exit 2
 fi
 printf '%s' "$latest"
}

process_tf_file() {
 local line source
 while IFS= read -r line <&3; do
 if [[ "$line" =~ ^[[:space:]]+source[[:space:]]+=[[:space:]]\"([A-Za-z0-9/]+)\"$ ]]; then
 printf '%s\n' "$line" >&4
 source="${BASH_REMATCH[1]}"
 elif [[ "$line" =~ ^([[:space:]]+version[[:space:]]+=[[:space:]])\"[0-9\.]+\"$ ]]; then
 printf '%s"%s"\n' "${BASH_REMATCH[1]}" "$(get_latest_version "$source")" >&4
 else
 printf '%s\n' "$line" >&4
 fi
 done
}
exec 3<providers.tf
exec 4>|providers_new.tf
process_tf_file
exec 3<&-
exec 4>&-
mv providers_new.tf providers.tf
if ! git diff --quiet providers.tf; then
 tofu providers lock -platform=linux_amd64
fi

Conclusion

Dependency management and updates are tricky subjects, and I am a firm believer that reducing the amount of dependencies is the best thing you can do in the long term. Dependency management software is no exception in my view, as they are another rather big dependency themselves.

Last but not least: this scripting approach makes me happy than I can discover new updates and bump pinned versions with a few curl, jq commands and regexes tailored to my stack.

Using Forgejo Actions without nodejs

2026-01-15

Introduction

I have been using Forgejo Actions to run CI tasks for about a year. I have been mostly content with them because they are well integrated with Forgejo itself, but I always thoroughly disliked relying on a stack of nodejs Actions that do way too much and that need to be updated way too often.

With all the supply chain attacks that make the headlines on hacker news, I started experimenting with simple handwritten shell actions that do only the minimal subset of what I need.

Checkout

The most commonly used Action must be actions/checkout which is the first step of almost every CI job. I suspect most Action users must have never looked at the source code of this action, but I encourage you to do so. Excluding tests, there are about 3k lines of typescript code, and it in turn has dependencies on other actions and libraries.

After years of GitHub Actions and now Forgejo Actions, I can count on one hand the number of times when I needed more than the simplest shallow clone. Therefore I replaced this action with:

 - name: 'checkout'
 run: |
 set -eu
 git init --quiet --initial-branch main
 git remote add origin "https://git.adyxax.org/${GITHUB_REPOSITORY}.git"
 git fetch --quiet --no-tags --depth=1 origin "$GITHUB_SHA"
 git checkout --quiet "$GITHUB_SHA"

When I need to support authentication, submodules, git LFS, or to checkout only a few sparse files, this small boilerplate can easily be taylored.

Complete workflow example

Using the same principles of minimal shell-based steps all the way, here is what this website’s main workflow looks like now:

---
on:
 push:
 branches:
 - 'main'
 workflow_dispatch:

jobs:
 all:
 runs-on: 'self-hosted'
 steps:
 - name: 'checkout'
 run: |
 set -eu
 git init --quiet --initial-branch main
 git remote add origin "https://git.adyxax.org/${GITHUB_REPOSITORY}.git"
 git fetch --quiet --no-tags --depth=1 origin "$GITHUB_SHA"
 git checkout --quiet "$GITHUB_SHA"
 - name: 'fmt'
 run: './make.sh tidy --fail-if-dirty=true'
 - name: 'build'
 run: './make.sh build'
 # we need the build step done before running check because the `search`
 # server embeds the `index.html` file, which gets generated by hugo during
 # the build step.
 - name: 'check'
 run: './make.sh check'
 - name: 'deploy'
 run: './make.sh deploy'
 env:
 SSH_PRIVATE_KEY: '${{ secrets.SSH_PRIVATE_KEY }}'

The make.sh script from this example allows for both local development and CI Actions which is how I prefer to think about CI: as a thin wrapper around the same commands you run locally.

I use a shell script because I am comfortable with shell scripting, but it could be a Perl or Raku script, a GNUmakefile or another tool as long as it can drive the full workflow locally using the same entrypoints as the CI.

Conclusion

I do not mind a little boilerplate, especially when I know I will rarely need to update it. And if I ever do need to update it, it is so simple that I fully understand and control it.

I did not mention a nice bonus: my CI is four times faster! The time spent building my blog went from about 24 seconds all the way down to about 6 seconds!

The true test on this journey will be to migrate my Terraform providers Actions workflows, more about this in another article.

Advent of code 2025 in Haskell

2026-01-06

Introduction

I participated in Advent of Code 2025 in Haskell. It was a fun experience as always! Why write about this now? Because I finished the last puzzle last Saturday!

I did all the puzzles each day on time last December except for day 10: part 2 was harder than all the rest combined! Life happened around Christmas, and I took the usual long break away from the puzzles before finishing.

Haskell for puzzles

The puzzles were all interesting without overstaying their welcome. Well except for day 10 part 2, but you need one of those for things to stay interesting! In this section I will present some of the days I enjoyed the most.

One of my favourite puzzles was day 3 where you need to find number patterns in the input. I found my solution elegant:

type Input = [String]

maxWithIndex :: String -> (Int, Char)
maxWithIndex (x:xs) = let (_, i, m) = L.foldl' step (1, 0, x) xs in (i, m)
 where
 step :: (Int, Int, Char) -> Char -> (Int, Int, Char)
 step (index, maxIndex, max) c | max < c = (index + 1, index, c)
 | otherwise = (index + 1, maxIndex, max)

compute :: Input -> Int
compute = sum . map compute'
 where
 compute' :: String -> Int
 compute' n = read . fst $ L.foldl' compute'' ("", 0) $ drop (length n - 11) $ L.inits n
 compute'' :: (String, Int) -> String -> (String, Int)
 compute'' (acc, i) s = let (ai, a) = maxWithIndex (drop i s)
 in (acc ++ [a], i + ai + 1)

I found Day 5 particularly satisfying to write. The puzzle is about merging intervals:

type Interval = (Int, Int)
data Input = Input [Interval] [Int]

compute :: Input -> Int
compute (Input intervals _) = sum $ map ilen intervals'
 where
 ilen :: Interval -> Int
 ilen (a, b) = b - a + 1
 (i:is) = L.sortOn fst intervals
 intervals' = L.foldl' step [i] is
 step :: [Interval] -> Interval -> [Interval]
 step acc@((c, d):xs) i@(a, b) | a > d = i:acc
 | otherwise = (c, max b d):xs

Day 6 was all about parsing operations with a twist (we transpose the input to parse column wise), and I always enjoy these problems:

data Op = Add | Mul deriving (Eq, Show)
type Input = [Int]
type Parser = Parsec Void String

parseNumber :: Parser Int
parseNumber = read <$> (some digitChar <* optional hspace)

parseOp' :: Parser Op
parseOp' = char '+' $> Add
 <|> char '*' $> Mul

parseOp :: Parser Int
parseOp = do
 n <- optional hspace *> parseNumber
 op <- parseOp' <* eol
 ns <- some (optional hspace *> parseNumber <* eol <* optional hspace)
 pure $ case op of
 Add -> sum $ n:ns
 Mul -> product $ n:ns

parseInput' :: Parser Input
parseInput' = some (parseOp <* optional eol) <* eof

parseInput :: String -> IO Input
parseInput filename = do
 input <- lines <$> readFile filename
 let len = maximum $ map length input
 input' = map complete input
 complete s = s ++ take (len - length s) (repeat ' ')
 input'' = unlines $ L.transpose input'
 case runParser parseInput' filename input'' of
 Left bundle -> error $ errorBundlePretty bundle
 Right input' -> return input'

compute :: Input -> Int
compute = sum

Day 7 was a fun set-management puzzle, at least that’s how I approached it. I also had fun using Parsec’s getSourcePos escape hatch to get the abscissa of the element being parsed:

type Input = [S.Set Int]
type Parser = Parsec Void String

parseTile :: Parser (Maybe Int)
parseTile = do
 SourcePos _ _ x <- getSourcePos
 char '.' $> Nothing <|> (char '^' <|> char 'S') $> Just (unPos x)

parseLine :: Parser (S.Set Int)
parseLine = S.fromList . catMaybes <$> some parseTile

parseInput' :: Parser Input
parseInput' = some (parseLine <* eol) <* eof

parseInput :: String -> IO Input
parseInput filename = do
 input <- readFile filename
 case runParser parseInput' filename input of
 Left bundle -> error $ errorBundlePretty bundle
 Right input' -> return input'

compute :: Input -> Int
compute (s:ls) = total $ foldl' compute' (M.fromList $ zip (S.toList s) [1]) ls
 where
 total :: M.Map Int Int -> Int
 total = M.foldl' (+) 0
 compute' :: M.Map Int Int -> S.Set Int -> M.Map Int Int
 compute' acc splitters = let splits = S.intersection (S.fromList $ M.keys acc) splitters
 continuingBeams = M.difference acc $ M.fromList $ zip (S.toList splits) $ repeat 0
 in S.foldl' (split acc) continuingBeams splits
 split :: M.Map Int Int -> M.Map Int Int -> Int -> M.Map Int Int
 split origin acc i = let v = origin M.! i
 acc' = case M.lookup (i+1) acc of
 Just n -> M.insert (i+1) (n+v) acc
 Nothing -> M.insert (i+1) v acc
 in case M.lookup (i-1) acc of
 Just n -> M.insert (i-1) (n+v) acc'
 Nothing -> M.insert (i-1) v acc'

I solved day 10 by very stubbornly writing a solver for underconstrained systems of linear equations, and it was a lot of fun!

Day 11 might have been my favourite this year. It is about memoization and graph exploration:

type Label = String
type Device = (Label, [Label])
type Input = M.Map Label [Label]

type Memo = M.Map (Bool, Bool, Label) Int

compute :: Input -> Int
compute input = (\(a, b) -> trace (show a) b) $ L.foldl' step (M.empty, 0) [(False, False, "svr")]
 where
 step :: (Memo, Int) -> (Bool, Bool, Label) -> (Memo, Int)
 step (m, a) (True, True, "out") = (m, a+1)
 step acc (_, _, "out") = acc
 step acc@(m, a) e@(d, f, l) = case M.lookup e m of
 Just v -> (m, a+v)
 Nothing -> let (m', a') = L.foldl' step (m, 0) $ zip3 (repeat $ if l == "dac" then True else d) (repeat $ if l == "fft" then True else f) (input M.! l)
 in (M.insert e a' m', a + a')

Some Befunge fun

I only did day 1 in befunge, but it was fun. I would love to do more puzzles in befunge but I really lack the time commitment.

Part1 is about simple parsing and keeping track of counters and modulos:

000p5a*>6j@.g000~&~$\'L-|
^ _v#:%d'<-<
^p00+1g00< ^+<

Part2 is a bit more complex because you need some math, but not too bad:

p5a*10p>6j@.g000~&~$\'L-|
v >:10g\-'d%'d+'d%\10g\:0w
;^p01p00+g00/d'+< <;# < >\:!#;_aa*\-
^ >:10g+'d%\10g^ <

Conclusion

I will always recommend tackling this kind of challenge: it is good to maintain or develop proficiency in a programming language. Also I love Haskell! I wish I could use it daily and not just for seasonal puzzles.

Wireguard jail on FreeBSD

2025-11-25

Introduction

One of my readers contacted me with an interesting question regarding Wireguard on FreeBSD: how to run Wireguard inside a jail instead of on the host. I only ever ran Wireguard on the host since that’s where I centralize all my routing and firewalling but was curious to explore the question.

Requirements

Nowadays Wireguard is easier to configure than ever on FreeBSD! But running it inside a jail needs two things that might not be straightforward: adding the if_wg module to /boot/loader.conf and using a vnet jail that exposes the right devfs rule set.

I did not take for granted that the if_wg kernel module handled jails properly, so I checked the sources. Good news is that the module seems to have enough jail specific code to properly handle the network segregation.

Loader.conf

When running Wireguard on the host, the kernel module is loaded automatically by an ifconfig wg0 create command. While running inside a jail though, this command will produce the following error message:

SIOCIFCREATE2 (wg0): Invalid argument

This is because ifconfig inside the jail does not have permissions to load kernel modules. To work around that, ensure that the module is loaded on boot by adding the following to /boot/loader.conf:

if_wg_load="YES"

Vnet jail

A standard vnet jail without special permissions is enough to run Wireguard. Just make sure to use the same devfs statements that I have in my /etc/jail.conf.d/wireguard.conf file:

wireguard {
 exec.consolelog = "/var/log/jail_console_${name}.log";

 # PERMISSIONS
 exec.clean;
 mount.devfs;
 devfs_ruleset = 5;

 # HOSTNAME/PATH
 host.hostname = "${name}";
 path = "/usr/local/jails/containers/${name}";

 # NETWORK
 vnet;
 vnet.interface = "${epair}b";
 $id = "154";
 $ip = "10.0.2.${id}/24";
 $gateway = "10.0.2.2";
 $bridge = "bridge0";
 $epair = "epair${id}";
 # ADD TO bridge INTERFACE
 exec.prestart = "/sbin/ifconfig ${epair} create up";
 exec.prestart += "/sbin/ifconfig ${epair}a up descr jail:${name}";
 exec.prestart += "/sbin/ifconfig ${bridge} addm ${epair}a up";
 exec.start = "/sbin/ifconfig ${epair}b ${ip} up";
 exec.start += "/sbin/route add default ${gateway}";
 exec.start += "/bin/sh /etc/rc";
 exec.stop = "/bin/sh /etc/rc.shutdown";
 exec.poststop = "/sbin/ifconfig ${bridge} deletem ${epair}a";
 exec.poststop += "/sbin/ifconfig ${epair}a destroy";
}

Make sure to change the jail Id, IP network, gateway and bridge interface name to match your setup.

Wireguard

Create the following files inside your jail. An easy way to do that is to start the jail and exec into it:

service jail start wireguard
jexec wireguard sh

Wireguard works out of the box on an up to date FreeBSD 14.3 without any additional packages like wireguard-tools. Just set the interface name and IP address in /etc/rc.conf:

network_interfaces="wg0"
ifconfig_wg0="inet 10.1.2.18/24"

Then add the following to /etc/start_if.wg0:

ifconfig wg0 create
wg syncconf wg0 /etc/wg0.conf

And finally your Wireguard configuration at /etc/wg0.conf:

[Interface]
PrivateKey = XXXXXX
ListenPort = 342

[Peer]
PublicKey = R4A01RXXqRJSY9TiKQrZGR85HsFNSXxhRKKEu/bEdTQ=
Endpoint = 168.119.114.183:342
AllowedIPs = 10.1.2.9/32
PersistentKeepalive = 60

Start or restart your jail, then confirm that Wireguard is running properly with:

jexec wireguard ifconfig wg0
jexec wireguard wg

Conclusion

All this made me think that an interesting next step to take would be to configure a Wireguard interface on the host, then pass it as the only interface for a jail instead of a bridge. The ramifications of this sound pretty neat!

Scripting the download of a private repository's GitHub release asset

2025-11-13

Introduction

Last week I needed to script the download of a specific asset from a release of a private GitHub repository. It turns out that there is no direct way to do this as you first need to resolve the asset name into an ID. Here is a little script that does just that without any big dependency like the gh CLI.

The script

#!/usr/bin/env bash
set -euCo pipefail

github_pat="XXXXXX"
owner="adyxax"
repository="private-repository"
regex=".*-linux-x86_64.tar.gz"
tag="v2025.11.06.0402"

if ! releases=$(curl -fsSL \
 "https://api.github.com/repos/$owner/$repository/releases/tags/$tag" \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: token $github_pat" \
 -H "X-GitHub-Api-Version: 2022-11-28"); then
 echo "failed to get latest release assets from GitHub" >&2; exit 1
fi

value=$(printf '%s' "$releases" \
 | jq -r --arg regex "$regex" \
 'first(.assets
 |to_entries[]
 |select(.value.name
 |test($regex))
 |.value)')

id=$(printf '%s' "$value" | jq -r '.id')
filename=$(printf '%s' "$value" | jq -r '.name')

if ! curl -fsSL "https://api.github.com/repos/$owner/$repository/releases/assets/$id" \
 -H "Accept: application/octet-stream" \
 -H "Authorization: token $github_pat" \
 -H "X-GitHub-Api-Version: 2022-11-28" \
 -o "$filename"; then
 echo "failed to download asset from GitHub" >&2; exit 2
fi

Conclusion

This is simple and works well. Scripting is fun!

OpenTofu/Terraform state locking with S3 object locking

2025-10-20

Introduction

Today’s AWS outage is a good time to remind sysadmins that AWS DynamoDB is no longer required to handle state file locking when storing state files on AWS S3.

Since last year, the S3 state backend has supported state locking via S3 object locks. This locking method is simpler, faster and removes a dependency on an AWS service that we no longer need. DynamoDB was the default state backend locking mechanism for many years and has served us well, but today’s AWS outage is a good time to move on if you have not already done so.

Migration steps

Make sure bucket versioning is enabled

I cannot imaging why anyone would store OpenTofu/Terraform state files without versioning, but if for some reason you did not already then know that versioning is a requirement for activating S3 object locks. A simple configuration like the following is enough:

resource "aws_s3_bucket_versioning" "tofu_states" {
 bucket = aws_s3_bucket.tofu_states.id
 versioning_configuration {
 status = "Enabled"
 }
}

resource "aws_s3_bucket_lifecycle_configuration" "tofu_states" {
 bucket = aws_s3_bucket.tofu_states.id
 rule {
 filter {}
 id = "main"
 noncurrent_version_expiration {
 noncurrent_days = 90
 }
 noncurrent_version_transition {
 noncurrent_days = 2
 storage_class = "STANDARD_IA"
 }
 noncurrent_version_transition {
 noncurrent_days = 14
 storage_class = "GLACIER"
 }
 status = "Enabled"
 }

 depends_on = [aws_s3_bucket_versioning.tofu_states]
}

Activating S3 object locks

The first step is to activate object locks on the OpenTofu/Terraform states S3 bucket. Sadly, simply adding the attribute to the aws_s3_bucket resource won’t be sufficient as OpenTofu/Terraform will then try to recreate the bucket.

aws --profile core \
 s3api put-object-lock-configuration \
 --bucket adyxax-tofu-states \
 --object-lock-configuration='{"ObjectLockEnabled":"Enabled"}'

After typing this AWS CLI command, you will be able to update your aws_s3_bucket resource. Applying the changes will refresh the state and confirm the change is correctly implemented.

resource "aws_s3_bucket" "tofu_states" {
 bucket = "adyxax-tofu-states"
 object_lock_enabled = true
}

Reconfiguring your terraform backend

Update your OpenTofu/Terraform S3 backend configuration blocks to add the use_lockfile = true attribute:

terraform {
 backend "s3" {
 bucket = "adyxax-tofu-states"
 dynamodb_table = "tofu-states"
 key = "repositories/${local.name}"
 profile = "core"
 region = "eu-west-3"
 use_lockfile = true
 }
}

By setting both dynamodb_table and use_lockfile, applying changes will lock both systems at the same time. This is important if you need to roll out your change gradually as to not disrupt your colleagues work or your CI jobs.

If you can afford the disruption, it will be faster to just delete the DynamoDB state locks table and remove the dynamodb_table attribute.

As with all backend configuration changes, you will need to init your OpenTofu/Terraform folders again:

tofu init -reconfigure

Once the change has been applied in all your OpenTofu/Terraform folders and repositories, all your pull requests merged or rebased and you are sure everybody and everything is on the new locking system, you can safely remove the dynamodb_table from your backend configuration blocks:

terraform {
 backend "s3" {
 bucket = "adyxax-tofu-states"
 key = "repositories/${local.name}"
 profile = "core"
 region = "eu-west-3"
 use_lockfile = true
 }

You will need to init -reconfigure your folders again.

Deleting the DynamoDB state locks table

The last step is to destroy the DynamoDB table that used to hold your locks. If you have deletion protection activated, remove it with:

aws --profile core --region eu-west-3 \
 dynamodb update-table \
 --table-name tofu-states \
 --no-deletion-protection-enabled

With this done, destroy your DynamoDB table and remove any IAM policies controlling DynamoDB access to the table and any cloudwatch alerts used to monitor it. I personally do this with a tofu apply because everything is managed from there.

Conclusion

S3 object locks have served me well since they were made available as a backend locking mechanism. If you are still relying on DynamoDB, now is a good time to migrate away from this service.

A Forgejo action for OpenTofu module testing on AWS

2025-09-30

Introduction

I have been using a Forgejo action (compatible with GitHub actions) for testing my OpenTofu/Terraform modules on AWS. I planned to blog this earlier, but since it worked without quirks I completely forgot to publish it.

Usage example

The action relies on having an AWS IAM access key provisioned in your CI’s secrets. An astute reader will notice I am naming the secret AWS_ACCESS_KEY_SECRET instead of the standard AWS_SECRET_ACCESS_KEY, mind this if trying to reproduce in your own environment:

- uses: "https://git.adyxax.org/adyxax/action-tofu-aws-test@2.0.0"
 with:
 aws-access-key-id: "${{ vars.AWS_ACCESS_KEY_ID }}"
 aws-access-key-secret: "${{ secrets.AWS_ACCESS_KEY_SECRET }}"

Action steps

This action initializes the AWS credentials, then runs formatting and linting checks as well as tofu tests on the repository of an OpenTofu/Terraform module.

Boilerplate

Forgejo actions need some light boilerplate to define how they are to be used:

name: "tofu-aws-test"
description: "Test a tofu module on AWS."

inputs:
 aws-access-key-id:
 description: "AWS access key id."
 required: true
 aws-access-key-secret:
 description: "AWS access key secret."
 required: true

runs:
 using: "composite"
 steps:

Formatting and linting

These are two simple steps. The only caveat is that I need to unset the GITHUB_TOKEN environment variable before running tflint. This is because Forgejo strives for compatibility with GitHub actions, but sadly tflint will try to use said token for cloning its plugins. Since the token is generated on my Forgejo instance, it is only valid there and not on GitHub. This would cause the step to fail.

 - name: "fmt"
 shell: "bash"
 run: |
 tofu fmt -check -recursive
 - name: "lint"
 shell: "bash"
 run: |
 unset GITHUB_TOKEN
 tflint --init
 tflint --recursive

AWS credentials initialization

If you followed my past articles you will know that I am using multiple AWS accounts to separate everything. I strive to have all my test resources created in a tests AWS account, but some things like DNS records will occasionally require access to my core AWS account where DNS zones are provisioned.

I am using AWS policies to tightly control what tests can provision in this core account, but I will not detail it in this article.

 - name: "configure AWS profiles"
 shell: "bash"
 run: |
 ROLE_NAME="repository_${GITHUB_REPOSITORY/\//_}"
 cat >aws_config <<EOF
 [profile core]
 role_arn = arn:aws:iam::123456789012:role/${ROLE_NAME}
 source_profile = root

 [profile root]
 aws_access_key_id = ${{ inputs.aws-access-key-id }}
 aws_secret_access_key = ${{ inputs.aws-access-key-secret }}
 region = eu-west-3

 [profile tests]
 role_arn = arn:aws:iam::345678901234:role/${ROLE_NAME}
 source_profile = root
 EOF

One should of course use their own AWS account IDs here!

OpenTofu/Terraform lock files

It is important to make sure your lock files match the provider versions pinned in your configuration. This step does exactly this!

This step has some code to recurse in subfolders because I love to use a pattern where some OpenTofu code specific to a repository lives alongside a module or some other code:

 - name: "check tofu providers lock files"
 shell: "bash"
 run: |
 unset GITHUB_TOKEN
 export AWS_CONFIG_FILE="$(pwd)/aws_config"
 shopt -s globstar nullglob
 for lockfile in **/.terraform.lock.hcl; do
 (cd "$(dirname "$lockfile")"; tofu init; tofu providers lock -platform=linux_amd64)
 done
 git diff --exit-code

OpenTofu/Terraform tests

I am running module tests with:

 - name: "tofu test"
 shell: "bash"
 run: |
 export AWS_CONFIG_FILE="$(pwd)/aws_config"
 tofu init
 tofu test

Cleanup

We clean up to be sure that the next steps in the workflow are not affected:

 - name: "clean"
 shell: "bash"
 run: |
 rm aws_config

Conclusion

Here is the link to the repository. Writing composite actions like this one is a good exercise and can be used to keep your workflows tidy and DRY!

How to set the VNC resolution of a QEMU virtual machine

2025-09-19

Introduction

I last blogged about how to run simple QEMU virtual machines in 2021 in this article. I often use these commands to spawn virtual machines that I only access via SSH, but it was never for their GUI! Now the need arose and the necessary bits were harder to piece together than I expected.

Installation

I updated the VNC and drive sections for modern QEMU flags compared to the last article:

qemu-img create -f raw alpine.raw 16G
qemu-system-x86_64 -drive if=none,id=disk,file=/alpine.raw,format=raw,cache=writeback \  (base)
 -device virtio-blk-pci,drive=disk \
 -cdrom Downloads/alpine.iso \
 -boot d -machine type=q35,accel=kvm \
 -cpu host -smp 2 -m 2048 \
 -display vnc 127.0.0.1:0 \
 -device virtio-net,netdev=vmnic \
 -netdev user,id=vmnic,hostfwd=tcp::10022-:22

Connect to the console with a vncviewer :0, or if an ssh server is running, use ssh -p10022 root@localhost.

Post-Installation

We boot from the installed disk and drop the options to mount the ISO image:

qemu-system-x86_64 -drive if=none,id=disk,file=/alpine.raw,format=raw,cache=writeback \  (base)
 -device virtio-blk-pci,drive=disk \
 -boot c -machine type=q35,accel=kvm \
 -cpu host -smp 2 -m 2048 \
 -display vnc 127.0.0.1:0 \
 -device virtio-net,netdev=vmnic \
 -netdev user,id=vmnic,hostfwd=tcp::10022-:22

How to customize the VNC resolution

You only needs to add an extra line of flags. Just substitute your native resolution (use xrandr on your host machine if you are in doubt about which values to use) in xres=...,yres=...:

qemu-system-x86_64 -drive if=none,id=disk,file=/alpine.raw,format=raw,cache=writeback \  (base)
 -device virtio-blk-pci,drive=disk \
 -boot c -machine type=q35,accel=kvm \
 -cpu host -smp 2 -m 2048 \
 -display vnc 127.0.0.1:0 \
 -device virtio-net,netdev=vmnic \
 -netdev user,id=vmnic,hostfwd=tcp::10022-:22 \
 -vga none -device virtio-vga,edid=on,xres=2560,yres=1440

Conclusion

It is good to refresh one’s memory for something so simple and useful: no virt-manager or other tools required, no complicated networking… QEMU is fun and easy!

The Raku programming language

2025-08-31

Introduction

I gave Raku several tries over the last 15 years. I was initially a bit disappointed when it was first released as Perl6 as it was very slow to start and a resource hog. I was disappointed again sometime in the late 2010s I tried the freshly renamed Raku. Still very slow to start up and consumming too much memory for what I was attempting, but much better.

I tried again this summer and I am glad to see that Raku has become much more usable! The language and its ecosystem have made strides of progress. Startup time (critical for a scripting language imho) is now good. CPU and memory usage remain on the high side, but have become more reasonable.

The language

The language is clearly Perlish, with sigils and unusual syntax that seem alien compared to other programming languages. Having liked Perl, I must say that I very much like the subtle changes Raku brought to the overall syntax. One such change is the array indexing: where you would have written $a[0] in Perl, you now write @a[0] in Raku.

I love all the convenience features and all the syntax sugar Raku brings to the table. For example, you can declare a list of string literals with my @l = <one two three>; instead of the heavier my @l = ("one", "two", "three");. Note that the parentheses are also optional here. Another related example is about hash indexing when keys are string literals: %h{'one'} is equivalent to %h<one>.

Raku has gradual typing, and its type system is really powerful. Two of my favorite features are junctions and subsets. Junctions in particular are wild:

my $j = 0|1|2|3; # $j is a junction, a composite value
if 3 == $j + 1 { # this matches because 2 is a possible value for $j
 say 'yes';
}

Note that junctions are not sets, they are only meant for boolean evaluation. But they are very neat! Subsets are also fun, allowing you to write things like:

subset MyBiggerInts of Int where * >= 42;
subset Three-letter of Str where .chars == 3;
subset Foo of List where (Int,Str); # Only a List where the first element is an
 # Int and the second a Str will pass the type check.

Many scripts are very concise in Raku. One of the neatest things is the amount of features, classes and functions that are built-in. This might seem trivial, but not having 10 lines of imports at the top of every script is refreshing! This is of course true for all the regex stuff, but also for some things like argument parsing on the command line. Here is how you write it in Raku:

sub MAIN(
 Str $file where *.IO.f = 'file.dat', #= an existing file to frobnicate
 Int :$length = 24, #= length needed for frobnication
 Bool :$verbose, #= required verbosity
) {
 say $length if $length.defined;
 say $file if $file.defined;
 say 'Verbosity ', ($verbose ?? 'on' !! 'off');
}

Calling a program with --help or invalid flags will produce the following for you, free of charge:

Usage:
 frobnicate.raku [--length=<Int>] [--verbose] [<file>]

 [<file>] an existing file to frobnicate
 --length=<Int> length needed for frobnication
 --verbose required verbosity

With all that I did not say anything yet about the object system which is very well thought out, the regexes and grammar which are a lot of fun, or all the convenience added to the standard classes. For example you can open a file and read its contents with:

"some/file.txt".IO.lines

The documentation and the language reference seem complete and are full of useful examples. Numeric maths are treated carefully: arithmetic is exact by default (big integrers when values exceed 64 bits, and rational numbers for fractions). How neat is that?

Conclusion

Learning Raku has been a lot of fun and I recommend giving it a try. Installing it is easy thanks to a tool called rakubrew. Packages are managed with zef and finding libraries is easy by browsing raku.land.

Of course wanted to solve some puzzles in Raku, as I do when learning new languages: https://git.adyxax.org/adyxax/advent-of-code/src/branch/master/2019

Advent of code 2024 in Haskell

2025-07-24

Introduction

I participated in advent of code 2024 in Haskell: it was a fun experience as always! Why writing about this now? Because I just finished the last puzzle!

I did the first 12 puzzles each day last December but then life happened and I could no longer complete one puzzle per day. I only finished the first 19 puzzles by Christmas then took the usual long break. I picked up this challenge again about a month ago while waiting at the airport and have now completed the last one.

Haskell for puzzles

Usually this kind of article is an opportunity to explain some of the patterns I used and things I learned. Solving these puzzles was a lot of fun as always.

The puzzles were interesting, my favorite one being day 24 in which you need to debug a binary adder. It is made of logic gates with a few wires that have been inverted and need to be fixed. It was the hardest challenge for me by far and I only solved it when I realized that instead of needing to simulate wire permutations I could try to build the adder from the pool of logic gates that were available. When I could not find a gate I needed, it meant I had to look for a wire to swap.

I also thoroughly enjoyed day 21 where you need to input codes via proxy robots and need to compute a very convoluted shortest path algorithm where the key was careful usage of memoization.

I will also make a special mention for day 13 where the problem can be reduced to a system of linear equations. I love an excuse to whip out a matrix triangularization to achieve this, but I doubly loved that I could use the Rational type to deal with exact ratio numbers computations. Haskell really shines in these situations!

Conclusion

I recommend tackling this kind of challenge, it is good to maintain or develop proficiency in a programming language. I love Haskell, I wish I could use it daily and not just for seasonal puzzles.

Enforcing AWS Secret version with OpenTofu/Terraform

2025-07-08

Introduction

Managing secrets in AWS is a common task. It is therefore surprising that the default aws_secretsmanager_secret_version usage does not properly enforce a secret value.

At first glance, it appears to enforce secret versions properly because updating the secret’s value results in an updated AWS secret version accordingly. Furthermore, if the secret is deleted then OpenTofu/Terraform will recreate it with the proper value as well! However, the unexpected behavior occurs when the value of the secret is manually changed: in that case, OpenTofu/Terraform will do nothing to reconcile or restore the value.

Properly enforcing a secret value

To solve this issue, the stage of the managed secret version needs to be enforced. Given the following basic resources that generate a random password and a secret:

resource "random_password" "main" {
 length = 64
}

resource "aws_secretsmanager_secret" "main" {
 name = "secret"
}

A secret version stage can be enforced with:

resource "aws_secretsmanager_secret_version" "main" {
 secret_id = aws_secretsmanager_secret.main.id
 secret_string = random_password.main.result
 version_stages = ["AWSCURRENT"]
}

The important attribute in the context of this article is version_stages. Though optional and not mentioned in the example usages of the resource’s documentation, it is what properly enforces this secret’s value as the current version.

Conclusion

I am in awe that I managed to go on for so many years without encountering this particular issue! Systematically specifying the version_stages attribute in all secret version resources is a boilerplate that I could have lived without, but necessary to ensure reliability. I find solace knowing that any manual changes to a secret value performed outside of OpenTofu/Terraform are now properly detected and corrected.