Enough is enough… enter a glasses holder in the shape of an adjustable necklace that I just created from paracord.

I took a small key ring (18mm dia) I happened to have on hand, and some 1.5mm mini paracord I also happened to have on hand². I measured out the needed length of paracord by hanging it around my neck so that both ends met just below my chest. Then I put two figure 8 knots into the ends and around itself, so that I got an adjustable closure.

Finally, I put the key ring on in the middle of the necklace using a basic cow hitch.

Aaaand done!

Holds my regular glasses or my sunglasses just fine, can be adjusted in length to easily get over my head but also not wiggle around too much. Somewhat fashionable too, but most importantly functional. I might make another one out of leather, but for now my problem is solved.

Update from 2026-06-26: I’ve made another one using a black leather cord and a metal o-ring and now it almost looks like a fashion accessory vs a practical solution to a problem. It turns out that this is also a nice fidget toy.

I’m quite happy with that!

I recently got a new phone and thus had to re-do the setup of my mobile blogging pipeline. So, basically, allow me to checkout, modify, test, commit and push the sources of this Hugo based static page under Android. While doing so I noticed some necessary changes and improvements, and also wanted to make use of my Taskfile which does most of the heavy lifting now, so here are my updated steps.

Apps & permissions

1. Install Tasker
2. From F-Droid install
   • Termux
   • Termux:Tasker
   • Markor
3. Grant permissions
   • Tasker: Run commands via Termux
   • Termux: Draw over apps

Termux setup

# setup access to storage
termux-setup-storage

# install packages
pkg upgrade
pkg install git gh hugo iconv vim

# log into github
gh auth login

# navigate to Markor's document folder & checkout sources
cd storage/shared/Documents/markor
git clone --recurse-submodules https://github.com/foosel/foosel.github.io

# create symlink in home
ln -s foosel.github.io ~/foosel.net

# mark checkout as safe
git config --global --add safe.directory /storage/emulated/0/Documents/markor/foosel.github.io

# set git user metadata
git config --global user.email "you@example.com"
git config --global user.name "Your Name"

# we want to use our Taskfile...
pkg install golang
go install github.com/go-task/task/v3/cmd/task@latest

As Tasker will stay the only app on my system allowed to send commands to Termux, and I write all my tasks myself, I also added allow-external-apps=true to .termux/termux.properties as described here. That allows me to directly execute stuff from Tasker by absolute path vs having to add a bunch of wrapper scripts to ~/.termux/shortcuts

To quickly test if everything works so far:

cd ~/foosel.net
task serve

This should build the page and serve it on http://127.0.0.1:1313 (with auto reload).

Tasker setup

I created a bunch of tasks, gave all of them an icon and added them to my launcher.

Serve foosel.net

    Task: Serve foosel.net
    
    A1: Termux [
         Configuration: ~/go/bin/task serve
         
         Working Directory ✓
         Terminal Session ✓
         Wait For Result ✕
         Timeout (Seconds): 10
         Structure Output (JSON, etc): On ]
    

Pull foosel.net

    Task: Pull foosel.net
    
    A1: Termux [
         Configuration: /data/data/com.termux/files/usr/bin/git pull
         
         Working Directory ✓
         Stdin ✕
         Custom Log Level null
         Terminal Session ✕
         Wait 
         Timeout (Seconds): 10
         Structure Output (JSON, etc): On ]
    
    A2: Flash [
         Text: Pulled foosel.net sources
         Continue Task Immediately: On
         Dismiss On Click: On ]
    

Push foosel.net

    Task: Push foosel.net
    
    A1: Termux [
         Configuration: /data/data/com.termux/files/usr/bin/git push
         
         Working Directory ✓
         Stdin ✕
         Custom Log Level null
         Terminal Session ✕
         Wait 
         Timeout (Seconds): 10
         Structure Output (JSON, etc): On ]
    
    A2: Flash [
         Text: Pushed foosel.net sources
         Continue Task Immediately: On
         Dismiss On Click: On ]
    

New Blog Post

    Task: New Blog Post
    
    A1: Input Dialog [
         Title: New post
         Text: Enter title
         Close After (Seconds): 120
         Input Type: 540673 ]
    
    A2: Termux [
         Configuration: ~/.local/bin/task new-blog -- "%input"
         
         Working Directory ✓
         Stdin ✕
         Custom Log Level null
         Terminal Session ✕
         Wait For Re
         Timeout (Seconds): 10
         Structure Output (JSON, etc): On ]
    
    A3: JavaScriptlet [
         Code: var uri = "content://net.dinglisch.android.taskerm.fileprovider/storage/emulated/0/Documents/markor/foosel.github.io/" + stdout.trim();
         Auto Exit: On
         Timeout (Seconds): 45 ]
    
    A4: Send Intent [
         Cat: None
         Mime Type: text/markdown
         Data: %uri
         Package: net.gsantner.markor
         Class: net.gsantner.markor.activity.DocumentActivity
         Target: Activity ]

New TIL Post

    Task: New TIL Post
    
    A1: Input Dialog [
         Title: New TIL
         Text: Enter title
         Close After (Seconds): 120
         Input Type: 540673 ]
    
    A2: Termux [
         Configuration: ~/.local/bin/task new-til -- "%input"
         
         Working Directory ✓
         Stdin ✕
         Custom Log Level null
         Terminal Session ✕
         Wait For Res
         Timeout (Seconds): 10
         Structure Output (JSON, etc): On ]
    
    A3: JavaScriptlet [
         Code: var uri = "content://net.dinglisch.android.taskerm.fileprovider/storage/emulated/0/Documents/markor/foosel.github.io/" + stdout.trim();
         Auto Exit: On
         Timeout (Seconds): 45 ]
    
    A4: Send Intent [
         Cat: None
         Mime Type: text/markdown
         Data: %uri
         Package: net.gsantner.markor
         Class: net.gsantner.markor.activity.DocumentActivity
         Target: Activity ]

Result

I now have all these tasks available under a tag in my launcher (Kvaesitso) and can easily work on posts from my phone once more. In fact, this post was entirely written on it.

The whole pipeline is a bit slimmer than last time as well and required less bash wrappers, which I like a lot better 👍

I also decided to go a bit more commandline-centric in this iteration - git add and git commit I’ll actually run manually in Termux this time around (I rarely used the corresponding shortcuts I created last time).

Once I’m satisfied with the local preview and have committed, a git push is all that I need for publishing - the CI does the rest.

A quick web search later I fell over this repository with a guide on how to get Chromium’s WebHID connection to work to a Keychron Q5 HE under ArchLinux, and I figured that was close enough (and the steps outlined therein logical enough) to adapt. And just so I can easily find this again, I’m replicating the crucial bits here…

Apparently all I needed were some additional udev rules for both the mouse itself (when connected via the USB-C cable) as well as the 2.4GHz dongle (when connected wirelessly). So, first I figured out the relevant vendor and product IDs:

$ lsusb | grep -i keychron
Bus 005 Device 042: ID 3434:d028 Keychron Keychron Ultra-Link 8K
Bus 005 Device 062: ID 3434:d06f Keychron Keychron G5

Those turned out to be vendor 0x3434 and products 0xd06f (wired mouse) and 0xd028 (dongle). So based on the repo linked above I created /etc/udev/rules.d/50-keychron-g5.rules as follows:

# Keychron G5 (WebHID)
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="3434", ATTRS{idProduct}=="d06f", MODE="0666", TAG+="uaccess", TAG+="udev-acl"
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="3434", ATTRS{idProduct}=="d028", MODE="0666", TAG+="uaccess", TAG+="udev-acl"

then refreshed udev:

sudo udevadm control --reload-rules
sudo udevadm trigger

and replugged the mouse and restarted Chromium.

After that, the launcher page could finally connect! 🥳

However, it became a bit annoying adding new vouches to the json manually.

So today I sat down and made it get created automatically during my page build powered by Hugo, based on a list of vouches stored in a vouches.yaml data file¹.

For this I first created said data file in data/vouches.yaml:

- url: https://food.foosel.net
  date: "2026-03-14"
- url: https://chaos.social/@foosel
  date: "2026-03-14"
- url: https://octoprint.org
  date: "2026-03-14"
# ...

Then I created a new output format humanjson in my config.yaml, making sure to also add it to the home page:

outputs:
  home:
    - HTML
    - JSON
    - humanjson
  # ...

outputFormats:
  # ...
  humanjson:
    mediaType: application/json
    baseName: human
    isPlainText: true
    notAlternative: true
  # ...

Finally I created a template for that in _layout/home.humanjson.json:

{
    "version": "0.1.1",
    "url": {{ .Site.BaseURL | jsonify }},
    "vouches": [
    {{- range $index, $vouch := hugo.Data.vouches }}
    {{- with $vouch }}
        {{- if $index }},{{end}}
        {
            "url": {{ .url | jsonify }},
            "vouched_at": {{ .date | jsonify }}
        }
    {{- end }}
    {{- end }}
    ]
}

I kept the required <link rel="/human.json"> in my layouts/partials/extend_head.html file that gets included on all pages by my theme (contrary to how the linking of output formats work, which is why I went with notAlternative: true for that).

And to make it even easier to quickly add a new vouch, I also added a new task to my Taskfile:

  add-vouch:
    desc: Adds a new vouch to human.json.
    vars:
      PAGE: '{{.CLI_ARGS}}'
      FILE: 'data/vouches.yaml'
      TODAY: '{{now | date "2006-01-02"}}'
    cmds:
      - |
        cat >> {{.FILE}} <<EOF
        - url: {{.PAGE}}
          date: "{{.TODAY}}"
        EOF

Now, vouching for a page² is as easy as

task add-vouch -- https://example.com

human.json is a lightweight protocol for humans to assert authorship of their site content and vouch for the humanity of others. It uses URL ownership as identity, and trust propagates through a crawlable web of vouches between sites.

Basically, a web of trust to confirm that pages are written by actual human beings vs just LLM generated slop.

That idea certainly clicked with me and so I quickly threw together a basic human.json in this page’s static folder and linked to it from the layouts/partials/extend_head.html override file. That will get filled more over time 😊

And as reading through the spec of human.json also made me learn about the /ai slashpage I added that as well and linked it from the footer.

Those slashpages are a fun idea I’ll have to investigate further too!

The websites in question are actually on GitHub Pages and my servers are just acting as reverse proxy to resolve domain and TLS, and a look into the web server’s error.log showed that the issue in serving was that the server could no longer reach its upstream at github.io when Tailscale was active. It wasn’t a general loss of external connectivity though - IPv4 addresses still worked great, the webserver however was trying to connect to the upstream via IPv6 and this is where things failed.

I did some quick tests, pinging Google’s DNS on both IPv4 (8.8.8.8) and IPv6 (2001:4860:4860::8888) with Tailscale running, and that showed that while Tailscale was running, IPv6 connectivity just broke down completely while IPv4 continued to work:

$ sudo tailscale up && ping -c 3 8.8.8.8 && sudo tailscale down
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=3.98 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=3.69 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=3.63 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 3.631/3.771/3.986/0.162 ms

$ sudo tailscale up && ping -c 3 2001:4860:4860::8888 && sudo tailscale down
PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes

--- 2001:4860:4860::8888 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2051ms

As a next step, I checked the route that would be taken for resolving 2001:4860:4860::8888 with and without Tailscale:

$ ip route get 2001:4860:4860::8888
2001:4860:4860::8888 from :: via fe80::1 dev eth0 src aaaa:bbbb:cccc:dddd::1 metric 1024 pref medium

$ sudo tailscale up && ip route get 2001:4860:4860::8888 && sudo tailscale down
2001:4860:4860::8888 from :: via fe80::1 dev eth0 src fd7a:115c:a1e0::aaaa:bbbb metric 1024 pref medium

So, the issue was that for some reason, while Tailscale was running the system decided to use Tailscale’s internal IPv6 fd7a:115c:a1e0::aaaa:bbbb set on tailscale0 as the source IP but send the packet through the default route and eth0, and that didn’t work. It basically hijacked the IPv6 traffic, even when the Tailnet wasn’t even involved.

The routes looked fine to me and some buddies I asked also didn’t spot anything amiss:

$ ip -6 rule show
0:      from all lookup local
5210:   from all fwmark 0x80000/0xff0000 lookup main
5230:   from all fwmark 0x80000/0xff0000 lookup default
5250:   from all fwmark 0x80000/0xff0000 unreachable
5270:   from all lookup 52
32766:  from all lookup main

$ ip -6 route show table local
local ::1 dev lo proto kernel metric 0 pref medium
local aaaa:bbbb:cccc:dddd::1 dev eth0 proto kernel metric 0 pref medium
local fd7a:115c:a1e0::aaaa:bbbb dev tailscale0 proto kernel metric 0 pref medium
local fe80::5fdc:58a7:1a93:da5a dev tailscale0 proto kernel metric 0 pref medium
local fe80::9400:ff:fe0d:61a1 dev eth0 proto kernel metric 0 pref medium
multicast ff00::/8 dev eth0 proto kernel metric 256 pref medium
multicast ff00::/8 dev tailscale0 proto kernel metric 256 pref medium

$ ip -6 route show table 52
fd7a:115c:a1e0::53 dev tailscale0 metric 1024 pref medium
fd7a:115c:a1e0::/48 dev tailscale0 metric 1024 pref medium

$ ip -6 route show table main
aaaa:bbbb:cccc:dddd::/64 dev eth0 proto kernel metric 256 pref medium
fd7a:115c:a1e0::aaaa:bbbb dev tailscale0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::1 dev eth0 metric 1024 pref medium

From what I could see, firing up Tailscale would add the following new rules to the routing table:

$ ip route show table all > ts-off.txt
$ sudo tailscale up && ip route show table all > ts-on.txt && sudo tailscale down
$ diff ts-off.txt ts-on.txt
0a1,2
> 100.a.b.c dev tailscale0 table 52
> 100.100.100.100 dev tailscale0 table 52
3a6
> local 100.x.y.z dev tailscale0 table local proto kernel scope host src 100.x.y.z
12a16,17
> fd7a:115c:a1e0::53 dev tailscale0 table 52 metric 1024 pref medium
> fd7a:115c:a1e0::/48 dev tailscale0 table 52 metric 1024 pref medium
13a19
> fd7a:115c:a1e0::aaaa:bbbb dev tailscale0 proto kernel metric 256 pref medium
17a24
> local fd7a:115c:a1e0::aaaa:bbbb dev tailscale0 table local proto kernel metric 0 pref medium

I still have not figured out what is actually going on there, and a reproduction on a fresh server so far also wasn’t successful. The problem is that packets are being sent with the wrong source IPv6, but that’s just a symptom of the underlying cause.

Thankfully, my buddy Jub came up with the workaround to change the default route to use a fixed IPv6 source address - the correct one - and that solved the issue (by fixing the symptom):

ip -6 route replace default via fe80::1 dev eth0 src aaaa:bbbb:cccc:dddd::1

I put that on a new post-up line into the network setup in /etc/network/interface.d/50-cloud-init.cfg

auto eth0:0
iface eth0:0 inet6 static
    address aaaa:bbbb:cccc:dddd::/64
    gateway fe80::1
    post-up route add -net :: netmask 0 gw fe80::1%eth0 || true
    post-up ip -6 route replace default via fe80::1 dev eth0 src aaaa:bbbb:cccc:dddd::1 || true
    pre-down route del -net :: netmask 0 gw fe80::1%eth0 || true

A reboot confirmed that this works as a workaround.

But as I mentioned, I still can’t make any sense of the underlying issue. I found one open bug report in Tailscale’s bug tracker that sounded familiar, but it didn’t fully match my situation. I also have to admit that my administration skills kinda get a bit fuzzy when it comes to full blown route analysis & debugging - so should you have any ideas at all what is actually causing this behaviour here, please get in touch on Mastodon - I’d love to see this mystery solved, but am out of my depth here 😅

I thankfully already have an instance of rest980 running in my homelab anyhow, and it is still happily chatting with the bot. And tbh, I might just block cloud access again as having everything local is better anyhow.

In any case, I wanted to disable the schedule currently set on it internally to switch to scheduling stuff from my home automation, but without the app working I wasn’t sure on how. So I went hunting through rest980’s source - as the README didn’t tell me what I was looking for - and found that I could program the weekly schedule with some easy curl magic via the /api/local/config/week endpoint.

Firing off a GET against that, this is the data structure I received:

{
  "cycle": [
    "none",
    "start",
    "start",
    "start",
    "start",
    "start",
    "none"
  ],
  "h": [
    9,
    15,
    15,
    15,
    15,
    15,
    9
  ],
  "m": [
    0,
    0,
    0,
    0,
    0,
    0,
    0
  ]
}

cycle seems to be the on/off button from Sunday at index 0 to Saturday on index 6. start schedules a cleaning run, none disables it. h is the hours on which to start each day, and m the minute.

What I wanted to do was to set all of the days to off, and this I achieved with this combined GET/POST call with some jq manipulation in the middle:

curl $REST980_URL/api/local/config/week | \
    jq '.cycle[] = "none"' | \
    curl --json @- $REST980_URL/api/local/config/week

Another problem - hopefully - solved! I’ll see tomorrow if this really disabled the schedule 😅 but I’m optimistic!

You might remember from a previous TIL that I had my Steamdeck configured to push my screenshots into a custom album on Google Photos. Obviously I had to change that now as well, but sadly couldn’t use the existing rclone-based setup for it.

My first idea was to utilize immich-go, as I have just successfully used that for the three day long import of over 50000 pictures from my Google Photos takeout into immich. But that turned out to not be the right tool here: in order to not even try to upload already existing files it will fetch an asset list from immich first, and while that really improves performance for large batch imports, it takes way too long for uploading a single new screenshot.

So instead I went with something self-built which utilizes immich’s API.

A custom upload script

The first part is this little bash script that will take a file as input, upload it to a pre-configured immich instance and also add it to a pre-defined album (which already has to exist). This lives in ~/.local/bin/immich-upload.sh:

#!/bin/bash
set -e

IMMICH_SERVER="https://immich.example.com"
IMMICH_KEY="your api key goes here"
IMMICH_ALBUM="your album id goes here"

INPUT="$1"
if [ "$INPUT" == "" ]; then
    echo "immich-upload.sh <file>"
    exit 0
fi

file_modified=$(stat -c %Y "$INPUT" | date --iso-8601=seconds)
name=$(basename "$INPUT")

# ---

echo "Uploading $INPUT to immich..."

upload=$(curl -sL --request POST "$IMMICH_SERVER/api/assets" \
    -H "Content-Type: multipart/form-data" \
    -H "Accept: application/json" \
    -H "X-API-Key: $IMMICH_KEY" \
    -F "deviceId=\"curl/steamdeck\"" \
    -F "deviceAssetId=\"$name-$file_modified\"" \
    -F "fileCreatedAt=\"$file_modified\"" \
    -F "fileModifiedAt=\"$file_modified\"" \
    -F "assetData=@\"$INPUT\"")

id=$(echo "$upload" | jq -r .id)

echo "Uploaded file, asset id is $id"

# ---

echo "Adding file to album $IMMICH_ALBUM..."

payload=$(jq -n --arg id $id '{ids:[$ARGS.named.id]}')
album=$(curl -sL --request PUT "$IMMICH_SERVER/api/albums/$IMMICH_ALBUM/assets" \
    -H "Content-Type: application/json" \
    -H "Accept: application/json" \
    -H "X-API-Key: $IMMICH_KEY" \
    -d "$payload")

echo "... done"

Reacting to new screenshots

I use watchexec to listen for changes in my custom screenshot folder (see this TIL post on how to set that up) and calling the upload script with the correct file name. I downloaded a release build of watchexec and threw it into ~/.local/bin, then created another script ~/.local/bin/sync-screenshots that takes care of setting all of the correct parameters¹:

#!/usr/bin/env bash

WATCHEXEC="${HOME}/.local/bin/watchexec"
FOLDER="${HOME}/.steam_screenshots"

${WATCHEXEC} --exts jpg,png,mp4 --fs-events create --emit-events-to environment -w $FOLDER -o queue -p -v -- '/home/deck/.local/bin/immich-upload.sh "$WATCHEXEC_COMMON_PATH/$WATCHEXEC_CREATED_PATH"'

Putting it all together

Finally, a new systemd unit in ~/.config/systemd/user/sync-screenshots.service takes care of starting this bash script and keeping it running:

[Unit]
Description=Sync Steam Screenshots

[Service]
ExecStart=%h/.local/bin/sync-screenshots
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

I enabled and started that:

systemctl --user enable sync-screenshots
systemctl --user start sync-screenshots

Then I took a screenshot and confirmed that the script had run:

Mar 25 15:17:03 steamdeck sync_screenshots[77135]: [Running: /home/deck/.local/bin/immich-upload.sh "$WATCHEXEC_COMMON_PATH/$WATCHEXEC_CREATED_PATH"]
Mar 25 15:17:03 steamdeck sync_screenshots[77188]: Uploading /home/deck/.steam_screenshots/7_20250325151703_1.png to immich...
Mar 25 15:17:04 steamdeck sync_screenshots[77188]: Uploaded file, asset id is 141dc605-edef-48f1-83b5-00bd9d72b13e
Mar 25 15:17:04 steamdeck sync_screenshots[77188]: Adding file to album 0ce35e68-a564-4e26-921e-c486cd9e4725...
Mar 25 15:17:05 steamdeck sync_screenshots[77188]: ... done
Mar 25 15:17:05 steamdeck sync_screenshots[77135]: [Command was successful]

And indeed, upon checking my immich instance, I was also looking at the freshly uploaded screenshot. Mission accomplished!

VirtualBox can’t operate in VMX root mode. Please disable the KVM kernel extension, recompile your kernel and reboot (VERR_VMX_IN_VMX_ROOT_MODE).

A quick web search for “fedora update virtualbox vboxisomaker” gave me this forum post and consequently this bug report, in which I found the solution: I just had to add the kernel parameter kvm.enable_virt_at_load=0 to disable KVM - which comes enabled by default since Kernel 6.12. I accomplished that with grubby:

sudo grubby --update-kernel=ALL --args="kvm.enable_virt_at_load=0"

After a reboot, VirtualBox started again.

Given how often VirtualBox breaks for me on updates, long term I think I really need to find a different solution… And yes, I also really need to upgrade to Fedora 41, I know 😉

So far the latter was always quite annoying: We have only the names of the gnomes in our influx data, and adding the location/deployment status to the graph thus meant having something like this for every single graph:

import "strings"
import "dict"

locations = [
    "Bashful": "Uptime Bar",
    "Dopey": "c3cat",
    "Grumpy": "Späti",
    "Happy": "Kidspace",
    "Hefty": "HASS Assembly",
    "Moopsy": "Chaospost",
    "Kinky": "Eventphone",
    "Nerdy": "House of Tea",
    "Sleepy": "DDOS Bar",
    "Sneezy": "Wohnzimmer"
]

from(bucket: "datagnome")
  [...]
  |> map(fn: (r) => ({r with device: r.device + " (" + dict.get(dict: locations, key: r.device, default: "?") + ")"}))

Which of course means that I had to update this locations dict for every single panel, on every single deployment, at least twice (start and end of the event).

I finally decided I had to solve this differently and just now figured out how to keep the deployment info in a JSON file on our git repo and then querying that from the graphs, instead of manually keeping the lookup data updated in more than one place:

import "strings"
import "dict"
import "http/requests"
import "experimental/json"

response = requests.get(url: "https://raw.githubusercontent.com/romses/Datenzwerg/refs/heads/main/docs/deployment.json")
data = json.parse(data: response.body)
locations = dict.fromList(pairs: data)

from(bucket: "datagnome")
  [...]
  |> map(fn: (r) => ({r with device: r.device + " (" + dict.get(dict: locations, key: r.device, default: "?") + ")"}))

So far seems to work well, and I’m very happy to be able to do this faster now (and also more easily from my phone, should I need to).

Next step: Figuring out how to use that JSON file to also keep the event box on the home page updated. But that’s for another day :)