One of the things I missed moving from WordPress to Hugo: scheduled posts. WP just… does that. Set a future date, and forget about it.

And static site generators don’t… The site only rebuilds when you git push, and that’s it. 😢

Why schedule posts, you ask? Because at times I write 3-4 posts in a day, and I don’t want to spam. ¯\(ツ)/¯ I have a rule that there should only be a single published post a day, and if I know I’m out of topics (especially for FlatTurtle) I tend to add a week or 2 between posts to spread it out evenly.

So I wrote (aka vibe coded) a little thing about a year or two ago, originally called BlogTurtle Rebuilder, because it was meant for FlatTurtle’s hugo blog. I’ve since repurposed it for this site.

The flow is quite simple:

1. I push a Markdown post to GitLab with date = "..." set to whenever I want it published.
2. Gitlab runs CI and deploys to Cloudflare Pages. Hugo will, however, hide posts with a date in the future.
3. On push, GitLab also pings a webhook (a docker container on a server).
4. Said container does a git pull and scans every .md for that date field.
5. Anything in the future gets an in-memory timer for that exact moment. Anything already due gets ignored at Gitlab CI would’ve deployed it.
6. When the timer pops, it triggers the GitLab CI/CD pipeline (through another webhook) that does a new Hugo build + deploy.
7. As an added bonus, I get an email telling me the post is live, with a Things3 deep-link to add a follow-up task to share it somewhere. It’s one click away.

That’s the whole thing.

Content Update

The provided scripts have been updated on 16 Jul 2023. Specifically the SmartStrip part was not working as intended.

I've been a big fan of Betteruptime. I've started using it to monitor all my assets online (websites, DNS, ping, successful script runs) as well as my servers (using heartbeats).

I have a few Raspberry Pi's, and once in a while they hang (not sure why, maybe USB-to-SSD issues or something). Nothing too critical, but annoying.

I've plugged them all on TP-Link Kasa smart plugs to remotely restart them if I had to (once or twice a year).

Note, to confuse everyone, TP-Link also launched Tapo, which... competes with Kasa and is not compatible, but does the exact same thing... ¯\_(ツ)_/¯

After some Googling (actually Kagi'ing) I found out, there's a Python library that lets you control your smart plugs.

So, the idea was born to:

• Check Betteruptime heartbeats, if down, power cycle the smart plug
• Do this at most once per day (in case something else is causing issues)
• Betteruptime heartbeats manage when a device is marked as offline (i.e.: it expects a heartbeat every 5 minutes, but will only consider the device down if no heartbeats are received for 2 hours).
• The bulk of the code had to be written by ChatGPT. Let ChatGPT choose the language (it ended up being a mix of Bash and Python)
• Everything needs to run in Docker (using a cron, the Docker container doesn't daemonise)
• These run on Raspberry Pi's (but of course the RPi can't check itself: so RPi1 checks for RPi2, and vice versa. As these RPis are on different networks (my parent's home, my own home, etc) I had to enable "--net=host" in Docker run to get the correct routes from the host system, but you may not actually need this
• To top if off, sent an email (using Mailgun EU servers) to warn me something broke and it rebooted

So, after some fiddling (half an evening or so) the proof-of-concept worked.

I should probably throw this in a Git repo but shrug. I don't want to give the impression that I'll maintain this and provide support.

Dockerfile:

FROM python:alpine
RUN apk add bash curl jq
RUN pip3 install python-kasa
COPY heartbeat.sh kasa-api.py /
VOLUME /tmp/kasa/
CMD ["/heartbeat.sh"]

Python script kasa-api.py (this works with both smart strips and smart plugs):

import sys
import asyncio
from kasa import SmartPlug, SmartStrip

async def main():
	if len(sys.argv) != 4:
		print("Usage: python kasa-api.py type IP-address outlet-index")
		return

	device_type = sys.argv[1]
	ip_address = sys.argv[2]
	outlet_index = int(sys.argv[3])

	if device_type == "smartplug":
		await control_smart_plug(ip_address)
	elif device_type == "smartstrip":
		await control_smart_strip(ip_address, outlet_index)
	else:
		print(f"Unsupported device type: {device_type}")

async def control_smart_plug(ip_address):
	plug = SmartPlug(ip_address)

	try:
		await plug.update()

		# Retrieve the current state
		plug_state = plug.is_on

		# Turn off the plug
		await plug.turn_off()

		print(f"Turned off SmartPlug at {ip_address}")
		await asyncio.sleep(5)

		# Turn on the plug if it was previously on
		if plug_state:
			await plug.turn_on()

		print(f"Turned on SmartPlug at {ip_address}")
	except Exception as e:
		print(f"Failed to control SmartPlug at {ip_address}: {e}")

async def control_smart_strip(ip_address, outlet_index):
	strip = SmartStrip(ip_address)

	try:
		await strip.update()

		# Retrieve the current state of the specified child plug
		child_state = strip.children[outlet_index].is_on

		# Turn off the specified child plug
		await strip.children[outlet_index].turn_off()

		print(f"Turned off child plug {outlet_index} in SmartStrip at {ip_address}")
		await asyncio.sleep(5)

		# Turn on the child plug if it was previously on
		await strip.children[outlet_index].turn_on()

		print(f"Turned on child plug {outlet_index} in SmartStrip at {ip_address}")
	except Exception as e:
		print(f"Failed to control SmartStrip at {ip_address}: {e}")

# Run the asyncio event loop
asyncio.run(main())

heartbeat.sh -- with example devices. Be sure to fill in the variables (including hb, that's the heartbeat ID you can get from the Betteruptime URL and the IP or DNS hostname of the smartplug):

#!/bin/bash

API_KEY="BetterUptime API token"
BU="https://uptime.betterstack.com/api/v2/heartbeats/" # no need to change this

MAILGUN_API_KEY="Mailgun API token"
MAILGUN_DOMAIN="mg.you.com" # use your own domain

if [[ "$DEVICE" = tyr ]] || [[ "$1" = tyr ]]; then

	# Tyr
	device="Tyr"
	hb=1111
	bu="https://uptime.betterstack.com/team/1/heartbeats/$hb"
	plug_type="smartplug"
	plug_host="smartplug1.kasa.you.com"

elif [[ "$DEVICE" = mammoth ]] || [[ "$1" = mammoth ]]; then

	# Mammoth
	device="mammoth"
	hb=2222
	bu="https://uptime.betterstack.com/team/1/heartbeats/$hb"
	plug_type="smartstrip"
	plug_host="smartstrip1.kasa.you.com"
	plug_index=0 # plug 2 is rly plug 3 because the index counts from 0 to 2 and not from 1 to 3.

elif [[ "$DEVICE" = liana ]] || [[ "$1" = liana ]]; then

	# Liana
	device="liana"
	hb=3333
	bu="https://uptime.betterstack.com/team/1/heartbeats/$hb"
	plug_type="smartstrip"
	plug_host="smartstrip1.kasa.you.com"
	plug_index=1 # plug 2 is rly plug 3 because the index counts from 0 to 2 and not from 1 to 3.

elif [[ "$DEVICE" = eagle ]] || [[ "$1" = eagle ]]; then

	device="eagle"
	hb=4444
	bu="https://uptime.betterstack.com/team/1/heartbeats/$hb"
	plug_type="smartstrip"
	plug_host="smartstrip1.kasa.yeri.be"
	plug_index=2 # plug 2 is rly plug 3 because the index counts from 0 to 2 and not from 1 to 3.

else
	echo "Unknown device."
	exit 1
fi

url=$BU/$hb

send_alert() {
	MAILGUN_URL="https://api.eu.mailgun.net/v3/$MAILGUN_DOMAIN/messages"
	from="kasa@you.com"
	to="alert@you.com"
	subject="Smartplug power cycled: $device"
	body="rebooted device $device!"$'\n'"Kasa IP: $plug_host."$'\n'"$bu"

	# Send alert email
	curl -s --user "api:$MAILGUN_API_KEY" \
		"$MAILGUN_URL" \
		-F from="$from" \
		-F to="$to" \
		-F subject="$subject" \
		-F text="$body"
}

kasa_cycle() {
	echo "Betteruptime heartbeat ($hb) says the service for $device is down, restarting."
	python /kasa-api.py "$plug_type" "$plug_host" "$plug_index"
	# Update the last execution date in the file
	echo "$current_date" > "$file"
}

kasa_info() {
	kasa --host $plug_host
}

response=$(curl -sL "$url" -H "Authorization: Bearer $API_KEY")
status=$(echo "$response" | jq -r '.data.attributes.status')

if [[ "$status" == "down" ]]; then
	dir="/tmp/.kasa/"
	mkdir -p "$dir"
	file="${dir}${device}.txt"

	# Get current date
	current_date=$(date "+%F")
	# Check if the file exists
	if [ -f "$file" ]; then
		# Get last execution date from the file
		last_execution=$(cat "$file")
		# We only want to run this once every 24hrs. If a reboot doesn't fix it, something more
		# serious is going on and likely needs manual intervention. No point spam rebooting the device.
		if [[ "$current_date" != "$last_execution" ]]; then
			kasa_cycle
			send_alert
		else
			echo "Power cycle already executed today."
		fi
	else
		kasa_cycle
		send_alert
	fi
elif [[ "$status" == "up" ]]; then
	echo "Betteruptime heartbeat says the service ($hb) for $device is up."
else
	# this could happen if the heartbeat is paused.
	echo "Unknown status."
	kasa_info
	exit 1
fi

I run Docker with two scripts, a builder (rebuild.sh) and a file that runs it (start.sh). It should rebuild in case a docker cleanup script ran (and deleted dangling containers).

I run this as root and probably shouldn't, but yeah... That'll be for another lifetime.

Be sure to change the paths (/root/git/kasa-api) in both scripts.

rebuild.sh:

#!/bin/bash
cd /root/git/kasa-api # the path where this project exists

git pull > /dev/null

BASEIMAGE=`cat Dockerfile | grep FROM | awk '{print $2}'`
docker pull $BASEIMAGE
docker build -q -t kasa-api .
rm -f /tmp/.kasa/*.txt

start.sh:

#!/bin/bash

if [ -z "$1" ]; then
	echo "Missing device name."
	exit 1
fi

docker stop kasa-api 2> /dev/null
docker rm kasa-api 2> /dev/null

run_kasa() {
	DEVICE=$1
	docker run --net=host -v /tmp/.kasa:/tmp/.kasa --rm -e DEVICE=$DEVICE --name kasa-api kasa-api
}

if [[ $(docker image ls | grep kasa-api) ]]; then
	run_kasa $1
else
	cd /root/git/kasa-api
	/root/git/kasa-api/rebuild.sh > /dev/null
	run_kasa $1
fi

And that's pretty much it. I run this using with cron in /etc/cron.d/. For example (be sure to edit the parameter/device name/path):

#
# cron-jobs for kasa-api
#

MAILTO=root

*/15 * * * *	root	if [ -x /root/git/kasa-api/start.sh ] && [ -f /root/git/kasa-api/start.sh ]; then /root/git/kasa-api/start.sh tyr >/dev/null; fi

I'm sure there must be bugs in this ChatGPT generated code but... so far, it has actually worked.

Started looking into a service to auto-post from this blog onto my Mastodon feed. Feed2Toot fit the bill perfectly.

I wanted to run the whole thing from a Docker container, though, so I'll quickly write a how-to.

This whole thing runs from a Raspberry Pi, as root. No k8s or k3s for me. The path I use is /root/git/feed2toot/, so be sure to modify that to whatever you're using.

First off, get your credentials for the app. You can either install the Feed2Toot package on a system (i.e. throwaway VM, to keep it clean), or use the Docker container below, but add RUN apk add bash and change the last line to CMD ["bash"] and then chroot into it via docker exec -it feed2toot bash.

This will generate two files (feed2toot_clientcred.txt and feed2toot_usercred.txt). Be sure to save these.

You can also try to run Feed2Toot at least once to make sure it's working and to fine-tune your ini file. This is mine:

[mastodon]
instance_url=https://m.superuser.one
; Here you need the two files created by register_feed2toot_app
user_credentials=/etc/feed2toot/feed2toot_usercred.txt
client_credentials=/etc/feed2toot/feed2toot_clientcred.txt
; Default visibility is public, but you can override it:
; toot_visibility=unlisted

[cache]
cachefile=/feed2toot/feed2toot.db
cache_limit=10000

[lock]
lock_file=/var/lock/feed2toot.lock
lock_timeout=3600

[rss]
uri=https://yeri.be/feed
; uri_list=/feed2toot/rsslist.txt
toot={title} {link}
; toot_max_len=500
title_pattern=Open Source
title_pattern_case_sensitive=true
no_uri_pattern_no_global_pattern=true
; ignore_ssl=false

[hashtaglist]
; several_words_hashtags_list=/feed2toot/hashtags.txt
; no_tags_in_toot=false

[feedparser]
; accept_bozo_exceptions=true

[media]
; custom=/var/lib/feed2toot/media/logo.png

I have three other files to make this work, first off Dockerfile:

FROM python:3.6-alpine
RUN pip3 install feed2toot && mkdir -p /etc/feed2toot/
COPY feed2toot.ini feed2toot_clientcred.txt feed2toot_usercred.txt /etc/feed2toot/
VOLUME /feed2toot/
CMD ["feed2toot", "-c", "/etc/feed2toot/feed2toot.ini"]

The script I run to build the container (start.sh):

#!/bin/bash
git pull

BASEIMAGE=`cat Dockerfile | grep FROM | awk '{print $2}'`
docker pull $BASEIMAGE
docker stop feed2toot
docker rm feed2toot
docker build -t feed2toot .
./run.sh

And finally, the script to run the container every so often (run.sh):

#!/bin/bash
docker run -d --rm -v /srv/mastodon/feed2toot/:/feed2toot/ --name feed2toot feed2toot

This will save the database file under /srv/mastodon/, to preserve states across rebuilds.

Note that once Feed2Toot runs, it'll exit, and the container will be stopped. So it does not automatically run all the time.

So, you'll want to run this every so often. You can add a file to /etc/cron.d/ to run it, for example, every six hours:

#
# cron-jobs for feed2toot
#

MAILTO=root

0 */6 * * *		root	if [ -x /root/git/feed2toot/run.sh ]; then /root/git/feed2toot/run.sh >/dev/null; fi

That's it. Should do the trick. It'll now post stuff from your RSS feed onto your timeline.

Oh, and Jeroen has a good post about Mastodon.

I've revamped my Smokeping infra a bit since 2020.

First off, starting to use the smokeping.eu¹ domain that Bianco got 10 or so years ago instead of using weird URLs under superuser.one domain.

It's running on four nodes as we speak:

• a virtual machine on a colocation server in Leaseweb, Amsterdam, NL -> leaseweb.nl.smokeping.eu
• a RPi3 (+SD card, slowest of all), Telenet, Belgium -> telenet.be.smokeping.eu
• a RPi4, EDPnet, Belgium -> edpnet.be.smokeping.eu
• a RPi4, Starhub, Singapore -> starhub.sg.smokeping.eu

This is achieved using Smokeping in a docker container, Cloudflare tunnel and Cloudflare CDN/DNS.

1 Doesn't point at anything at the moment. To do later.

This follows the my two other posts about WireGuard.

Most of this can be copied from the amd64 post -- with a minor change for making it work on RPi4. This is the full git repo (including both rpi and amd64).

The main difference is in the run.sh file. The installation is a bit different and we'll need to install the Raspberry Pi kernel headers.

WireGuard is also installed from testing instead of Debian backports.

Note that for older RPi's (ie gen 1) you'll need to compile from scratch.

I was rebuilding my WireGuard Docker container today and this error started popping up:

Setting up dkms (2.6.1-4) ...
Setting up wireguard-dkms (1.0.20200429-1~bpo10+1) ...
Loading new wireguard-1.0.20200429 DKMS files...
It is likely that 4.19.0-8-cloud-amd64 belongs to a chroot's host
Building for 4.19.0-8-amd64 and 4.19.0-8-cloud-amd64
Building initial module for 4.19.0-8-amd64
Error! Bad return status for module build on kernel: 4.19.0-8-amd64 (x86_64)
Consult /var/lib/dkms/wireguard/1.0.20200429/build/make.log for more information.
dpkg: error processing package wireguard-dkms (--configure):
 installed wireguard-dkms package post-installation script subprocess returned error exit status 10
Setting up build-essential (12.6) ...
Setting up libalgorithm-diff-xs-perl (0.04-5+b1) ...
Setting up libalgorithm-merge-perl (0.08-3) ...
dpkg: dependency problems prevent configuration of wireguard:
 wireguard depends on wireguard-dkms (>= 0.0.20200121-2) | wireguard-modules (>= 0.0.20191219); however:
  Package wireguard-dkms is not configured yet.
  Package wireguard-modules is not installed.

dpkg: error processing package wireguard (--configure):
 dependency problems - leaving unconfigured
Processing triggers for systemd (241-7~deb10u3) ...
Processing triggers for libc-bin (2.28-10) ...
Errors were encountered while processing:
 wireguard-dkms
 wireguard
E: Sub-process /usr/bin/dpkg returned an error code (1)

The solution was to install bc. Seems like Debian is not pulling the right dependencies. I'll be adding it to my Dockerfile.

This is the 2nd post about WireGuard.

So I am running two WireGuard servers -- one on a Raspberry Pi 4, and one in an amd64 virtual machine. This post will be about getting WireGuard working on amd64 in a Docker container.

As this container rarely get rebuild, I am running unattended-upgrades inside the container to make sure security updates are applied.

I am also running Bind9 to act as a caching DNS server inside the container. Ideally this should be running from its dedicated container but that makes everything more complicated and not worth it for what I am trying.

I am also

The public repo that acts as a proof of concept can be found here.

start.sh -- this file starts (or restarts) and builds the container. It will also create the files as needed, set the forwarding DNS server, etc.

Dockerfile -- the example will start a basic container based on debian-slim, set up the port forwarding, install the tools we need, and copy over the configs

run.sh -- this file will be executed after the container has been built. We need to install WireGuard from this file or it will fail due to the volume not being mounted and not having the right params.
This will also start the named (bind9) server.
I manually set ip address add dev wg0 10.200.200.1/24 because using Address in wg0.conf caused issues. I haven't recently tested if that's still the case.

named.conf.options -- pretty standard bind9 config file; I want to be in control of my forwarding server because I am using NextDNS and want to apply a different config.

And of course your wg0.conf.

Running docker exec wireguard wg should give details about your connected hosts.

This is the first post of several. Next posts will focus on running WireGuard inside a Docker container on amd64 Linux and a Raspberry Pi.

I've been running WireGuard for a few months now and I've been loving it.

I first started using it about a year ago when in China — OpenVPN was once again being actively blocked and it was driving me nuts. Overnight I set up a DigitalOcean server in Singapore and ran WireGuard from it — both my phone and laptop were able to actively bypass the GFW and (at that time) surf the internet freely once more. As WireGuard gains popularity, I am sure the GFW will start detecting it — it's a quiet but not a stealthy protocol.

Since then I've dug quite a bit deeper in WireGuard and am really looking forward to what it's going to bring.

WireGuard differentiates itself to be an extremely simple VPN server (which can make getting started and debugging a bit more challenging) — but it wants to seamlessly work together with existing tools. One of the main features still missing is for example running a DHCP server on the server and dynamically assigning IPs (like oVPN does).

It's also pretty cool because any node can both be a server and a client at the same time. In my setup I am running two servers: one running at home in Singapore on a RPi4 (1Gbit fiber connection) and one on a virtual machine in Amsterdam (1Gbit as well). The RPis at my parents are connected to the server in Amsterdam, my iPad and phones are connected to the server in Singapore. If I am in Europe I might switch over and let my iDevices connect to the AMS server instead.

The example above clearly shows speed gains by cloaking the traffic in UDP packets. The shared folder has only two nodes (sender and receiver) and shows several big files being transferred from Amsterdam to Singapore. Resilio Sync uses the Bittorrent protocol, something ISPs generally hate and tend to slow down as much as they can — thanks Starhub.

Wireguard also allows the client to decide what to route through the server: only the VPN LAN traffic, or a whole subnet, or 0.0.0.0/0? So for my iPhone I for example route all traffic through VPN to avoid hotel/airport/... WiFi's to mine/log/scan my data. For my laptop I have two configs, one to only connect to the LAN, but another that routes all my traffic through the VPN if I want to avoid exposure or circumvent censoring.

Note that I am not running WireGuard to remain anonymous and I'll definitely leak some information — just trying to minimise and remain in control of what I leak. This is not a Tor replacement.

A couple of months ago I had the great idea to set up a shell server in Docker. Simply because my docker skillz were quite rusty and a shell server was something I actually genuinely needed.

Shell servers... so 2005. I remember in the good old IRC days people asking for (free) shell servers to run their eggdrop and stuff. OMG am I getting old? Anyhow...

I ssh quite often. I manage quite a few servers (~15?) and routers that require me to login and do some random stuff. I also work on a laptop quite often and that means closing the lid and moving around.

First of all, mosh is amazing and allows you to stay connected via ssh, even with crappy (airport/hotel) internet as well as moving around networks -- that solves half the problem. If you are not using it, start using it now!

Second, during my datacenter technician days at Google we used to have a "jump server" -- a shell server that allowed us to bridge the corporate network and ssh into prod machines. Doubt that's still used nowadays, but the idea stuck. I wanted something similar to ssh from, wherever I was, and easily connect to my servers. And as the network the shell server is running on is stable, I only need to use mosh to the shell server. Thereafter, the connection very rarely dies.

And I guess, third, I recently purchased an iPad Pro and I really need to have my local "dev" environment with my git repo that I edit quite frequently but iPadOS isn't really your average computer, and doesn't even have a proper terminal. This is my experiment to make iPadOS work as a main computer when on the move.

Enter box -- Docker shell server...

I've copied over the files I use to this example repo, and added some comments. Mind you that this repo acts as a proof of concept and isn't kept up to date, as I have my own private repo -- but this should give you a good idea on how to set up your own shell server with Docker.

start.sh -- this is a simple script that I execute when I first run or need to update the container. I execute the same file on two different servers: Liana, my Raspberry Pi at home and Ocean, my server in Amsterdam.

zsh.sh -- this installs what I care about for zsh. This could be part of the Dockerfile but for some reason I separated it. ¯\_(ツ)_/¯

git.sh -- this clones my Git repos so I can edit and commit stuff from the shell server.

run.sh -- this file is launched by Dockerfile at the end and executes what matters: the ssh daemon. It also adds a Wireguard route and executes the scripts above.

Dockerfile -- this installs everything I need and configures the whole thing. I've added tons of comments that should get you going.

I am also cloning misc and homefiles as submodules in files/ -- but you should change this to something that works for you. See the Dockerfile for more info.