It recently occurred that I had the need to route all traffic by a certain application through a VPN. While premade solutions for this exist using Docker (especially in combination with BitTorrent clients), I preferred looking for something that really just isolates what is needed and leaves the rest alone.
During writing of the last post I actually bricked my home router after installing a custom image. At the same time I didn't manage to get TFTP recovery working [1] so I started searching for ways to restore my home network for now to worry about fixing the router later.
The choice fell on using an ARM board to run OpenWrt, which required some creative workarounds. This post documents them.
This post contains Q&A-style notes on compiling software for OpenWrt or compiling OpenWrt itself.
With Raspbian (now named Raspberry Pi OS) having been released as 64-bit, I can finally write a proper sequel to the previous post that dealt with virtualizing ARM/Linux distributions headlessly using QEMU.
You can read the original article here: Virtualizing Raspbian (or any ARM/Linux distro) headless using QEMU. Since the process is the same I will skip detailed explanations here.
Installing an Unifi controller on a Raspberry Pi seems like a straightforward task until you notice the section with system requirements.
The software requires a MongoDB version before 4.0. The last version that satisfies this is 3.7.9 which is almost four years old at the time of writing. You may find old versions packaged on the MongoDB website or in other repositories but certainly not for ARM. The second problem is that MongoDB dropped 32-bit support in version 3.4 so the latest we can actually use is 3.2.22 (also 4 years old).
In the end I was unable to find a build of MongoDB 3.2 that could run on a Pi which leaves only the option of compiling from source. This is what I ended up doing, it required lots of trial and error [1] before it succeeded. To (hopefully) save someone else time I put up the final Debian package for download.
Smokeping is a nifty tool that continuously performs network measurements (such as ICMP ping tests) and graphs the results in a web interface. It can help you assess performance and detect issues in not only your own but also upstream networks.
A few months ago I wanted to test something that involved OpenVPN on an old, small VPS I rented.
At this point it would've been easier to give up or temporarily rent another VPS, but I really wanted to run the test on this particular one.
The gist of it is that glibc began to make use of the new faccessat2 syscall,
which when running under older systemd-nspawn is filtered to return EPERM.
This misdirects glibc into assuming a file or folder cannot be accessed,
when in reality nspawn just doesn't know the syscall.
A fix was submitted to systemd [1] but it turned out this didn't only affect nspawn, but also needed to be fixed in various container runtimes and related software [2] [3] [4] [5]. Hacking around it in glibc [6] or the kernel [7] was proposed, with both (rightfully) rejected immediately.
I pondered what an awful bug that was and was glad I didn't have to deal with this mess.
Since the development stages of Windows 10, Microsoft has been releasing a version of Windows that runs on 64-bit ARM (AArch64) based CPUs. Despite some hardware shipping with Windows 10 ARM [1] [2] [3] this port has received little attention and you can barely find programs that run on it.
Naturally, I wanted to try this out to see if it worked. And it turned out it does!