Logbook

running Tailscale's golink on fly.io

I am using golink from Tailscale to manage bookmarks for commonly used services. At its simplest, it remaps a URL of something like go/gmail/ to https://mail.google.com . At the most complicated, it will do a limited amount of address rewriting based on the path you give. The application is small and has modest needs, enough so that it fits easily on a Raspberry Pi 4 that has other things going on.

https://github.com/tailscale/golink

I had previously heard of fly.io as a place to host containerized applications. You get a teeny tiny Firecracker based microVM connected to a Wireguard network, hosted by a network that's in multiple data centers around the world. If you need performance in multiple regions, you can leverage their Anycast infrastructure. It's pretty nifty all in all.

https://fly.io/docs/reference/architecture/

golink helpfully comes with instructions on how to run on fly.io. They assume a little bit of familiarity with the system, which is easy to gain by poking at it a little. Very helpfully, the combination of the application and Tailscale means that you can deploy this microVM without a globally routed IPv4 address, and then access the golink service on it over your Tailscale network. It's a nice way to extend your private Tailnet one function at a time, and the golink service very easily fits into the free tier offering with lots of room to spare.

https://github.com/tailscale/golink/issues/63

The one catch: how do you migrate your data into this system? Helpfully, golink has a REST based API both for downloading an existing database and for creating new links. What was missing was an export-import or clone function that was based on the API.

jq -c '[.Short,.Long]' go.export.json | sed -e 's/^\[/curl -d short=/' -e 's/,/ -d long=/' -e 's/\]$/ go-1/' > import.sh

The above code takes an export file from golink and munges it into a script that can be run to import the data into your new instance. Caveat: you will lose reference counts, you'll lose link attribution if you have more than one user, and basically you'll be starting over. But if that's OK this is a quick restart to get going again.

fly.io has nice charts and graphs to keep you as aware as you want to be able application system usage. It has a comprehensive CLI, flyctl, which looks like it should let you script pretty much anything you'd want to handle from the command line. An hour into my effort I had something running and working within the free trial tier. I'll be looking for more sorts of services to host this way.

My next small, hackable computer - a Steam Deck?

For the longest time the Raspberry Pi has been my go to for a small, inexpensive, easy to buy and hackable computer. I have a few of them running, powering a DMR gateway and an ADS-B receiver. Software support is good, third party peripheral support is good, and lots of people have gone to some substantial efforts to get workable tools running on arm64.

However;

The Pi has gotten very hard to buy over the past year, with most of the production inventory diverted to industrial and OEM clients. There is good supply of the RP2040 microcontroller, and the Pi folks seem to have diverted their "here, have a cheap and cheerful device to learn from" to systems built around that chip. That's great, don't get me wrong, but not my focus of interest right now.

This brings me to the subject line. What if the next obvious target for a small and hackable computer is not a Pi, but instead is a game machine? The Steam Deck runs all the Steam games, but it's Linux based, and it's easy to drop into a Linux environment. There's a built in display and a built in battery and easy ways to connect to external devices. And the form factor - a "cyberdeck" and not a bare board - is appealing.

Yes, it costs more; way more, to be honest. As of this writing there's still a queue for ordering so it will take a little while to ship. One per customer, please, so you're not going to see insane clusters of these things.

Some interesting reading:

Putting Tailscale on the Steam Deck, from Tailscale's Xe Iaso. Some of the trickier bits of systemd work you need to do in order to get the Tailscale VPN software running on the Steam Deck. You'll learn about systemd-sysext, which uses an overlay filesystem (overlayfs) to install components "on top of" an underlying immutable filesystem.

Running KrakenSDR on the Steam Deck, RTL-SDR Blog. KrakenSDR is a multi-device coherent software defined radio, with applications like direction finding for radio signals ("fox hunting"). The blog notes that the Steam deck "is essentially a powerful handheld computer with s creen and good battery life, so it makes an excellent mobile SDR computing platform too." For this particular application you'd want an external battery pack to power the SDR.

Listening to HAM radio on my Steam Deck, /u/freeloz on Reddit. A demo with video of SDR reception using an AirSPY HF+, a loop antenna, and the Gqrx software.

Flathub is a home for "flatpaks", a portable software installation format supported natively on SteamOS. This lets you develop your own applications and package them for easy use on the platform, and also opens up a library of software from the Linux world that's easier to install.

Of course, the main market for the Steam Deck is games, either brand new titles or old games via emulation.

updates and later additions

Direction-finding with help from the Steam Deck, Hackaday, 2022. Aaron (cemaxecuter) demonstrates radio direction finding with KrakenSDR and a Steam Deck as a portable controller in marine operations on a boat on Lake Redwine in Georgia. Like and subscribe to his Youtube channel for more information about DragonOS Focal, a software distribution for SDR applications.

Using BindToDevice in systemd socket files to serve network-specific content

It's summer, and that means the attic gets hot. I'm looking to get some kind of easy way to check the attic temperature from afar, so that I can keep tabs on it, and so that I can adjust the fans and the windows appropriately. This is really basic telemetry, a task that has been done many times before, using nearly every network protocol ever invented.

I decided for 2021 that I wanted to do this monitoring with some old-fashioned protocols, so the query tool of choice is "finger". I found a very nice modern implementation called finger2020 from Michael Lazar (mozz), which is designed for single-user systems. This runs under systemd, which makes it easy to install.

A simple crontab pulls temperature data from wherever it can find it, which on a Linux system could be lots of things. From past experience I have found that simply tracking the /sys/class/thermal values from the kernel give you CPU temperature for whatever computer you're running on, and that if your computer is hot, the rest of your space is probably hot too. As a bonus it's easy to grab with no additional external sensors needed.

I'm running Tailscale, which means there's a trustable inside network on tailscale0, and an untrusted outside network on ethernet or wifi or whatever interfaces are exposed. This led to the question: can you deliver different content to the world depending on which interface the traffic comes in on, without putting any of that logic into the program serving up the data?

After some spelunking through the systemd documentation and not a lot of searchable examples from the net, I came up with either a brilliant hack or an awful kludge to make this work. systemd has a BindToDevice directive in its socket files that lets you associate a socket with an interface (not just its address, which could change, but the interface itself). So I took the unit files from finger2020, replicated them three ways, and for each one added an appropriate BindToDevice=tailscale0 or whatever interface I had and then created a service file that pointed to that socket.

The slightly weird part is that if you are on a machine querying itself, even if you specify an IP address of an external interface, you'll get packets on the loopback (lo) interface. So one socket handles loopback, one handles eth0 (for queries on a public network), and one handles tailscale0 (for queries on the private VPN).

A more elegant approach if you want to change your server is to look up the address from Tailscale, using the function tailscale.WhoIs. An example of this logic is in the hello service run by Tailscale which switches on the results of the WhoIs call and lets you further serve individual content because you know not just the interface the user is coming in on but the user name! So very handy if you have more than one user on your network.

The BindToDevice approach should work for any VPN you are using, and it should also let you do deliver services that are reachable only from private addresses and that don't ever show up on the public Internet, even if the code you are running is ignorant of that distinction.

Brilliant hack or awful kludge? Hard to say yet.

bringing up gitea

Gitea is "Git with a cup of tea", a self-hosted Git repository that's very reminiscent of Github. It has repos, issues, all of the familiar stuff you'd expect from a first glance.

Install instructions for Gitea running under Docker are straightforward. The one tweak I added was that because I'm running Tailscale on this system (a Pi 4 with SSD) that I am binding the external address of the container to a Tailscale address, e.g.

- "100.108.39.122:13000:3000"

instead of

- "3000:3000"

This ensures for the moment that I have to connect via the VPN, and that I can connect via the VPN, and it means also that I have access to this private Gitea from my phone without any extra fuss.

The next challenge looks like backups, since if I'm going to commit anything to this device that I want to keep indefinitely, I'll want to save it or sync it somewhere offsite. But first I think I need to use it for a while to get my tally board more green.