I recently wanted to create an endpoint on a development machine that could return my external IP address. Normally I would use one of a handful of services https://canhazip.com/ or https://ifconfig.ca/, but I wanted to see how easy it would be to make my own. As it turns out, it's incredibly easy, and doesn't even require leaving the reverse proxy. Using nginx, we can just create a block like this.

I just solved what was becoming a very aggravating issue thanks to the help from the folks in the #weechat channel in Libera.Chat. On OpenBSD, my weechat client would put a question mark to separate the nicks and the messages sent with a question mark instead of a pipe-looking character like it should. It looks like this was caused by opening weechat without having the correct locale set. By default, OpenBSD uses a locale of C, which only supports ASCII characters.

This post will cover creating a second encrypted drive on Fedora that automatically decrypts on boot and mounts to a set location. I had finally run out of room on my SSD. I went to the store to buy another so I could increase the amount of storage space in my PC. I got home and installed it. Then I thought. My main drive in encrypted and setup by the Fedora installer, so my second should be too right?

I recently found a bin of SD cards from a JVC camcorder I used years ago for school projects. I wanted to import the videos into DigiKam to catalog them with the other photos and videos I've taken with other cameras. When trying to complete this I quickly ran into an issue. The camcorder recorded videos into a combination of MOD and MOI files, which most software doesn't recognize.

A couple of years ago I published a blog post about creating an OpenBSD VPN gateway using OpenVPN. I've recently switched from an OpenVPN-based VPN provider to one that uses Wireguard. As a result I've had to redo my VPN gateway. I'll only be highlighting the things I've changed since the last setup in this post, so please refer to the previous post for more details. One advantage this iteration has over the previous one is that it no longer requires third party software to be installed on the OpenBSD router.

I was just working on a bash completion for my repo management tool (link) and came across a completion problem I couldn't find an answer to. In my tool, all repositories are stored under a root source directory ~/src, and are three directories deep under that. The top directory is the website, the second is the user, and the third is the repo itself. For example github.com/zig/ziglang. My tool repo has a command repo cd <spec>, which will try to find a project matching the path you specify.

A couple years ago a new device silently entered the OpenBSD source tree. The dt(4) device first appearing in OpenBSD 6.7 with very sparse information. In the releases since, it's gained quite a bit of functionality and now has tools to manipulate it properly. The documentation has gotten better over the last couple years, but there isn't much info about how to leverage it to do anything useful. The dt pseudo device driver is connected to /dev/dt, which is used to interact with the device through ioctl calls.

While poking around in IRB and looking at the autocompletion results, I found some functions that I didn't recognize and decided to take a look at what they do. I found some pretty interesting stuff. It looks like some of these commands have been added recently to come up to par with pry, and others have been kicking around for a while and just flying under the radar. You can find them all defined in this file in the IRB source code.

If you're in the default testing environment your rails cache is ActiveSupport::Cache::NullStore which will always succeed but it doesn't actually store or return anything. There's an almost completely undocumented method called with_local_cache on NullStore that lets you run a block with a MemoryStore instead of a NullStore for the duration of the block. This happens because it prepends the ActiveSupport::Cache::Strategy::LocalCache class. This lets you test one or two things that require caching without enabling it on all tests and slowing everything down.

This is something that took me a while longer to figure out than I'd like admit, and I was only able to figure it out because of a forum post. For whatever reason, I'm only able to mount the share if used the TCP option. I'm not sure if this is a me issue, an OpenBSD issue, or a FreeBSD issue, but I'm putting it out there in case anyone else runs into the same problem.