Kernels and Integrations and DynDNS, oh my!
Let me explain. No, there is too much. Let me sum up.
I have been meaning to write some articles about things I’ve been doing for a while, but it turns out that I keep putting them off in favor of actually doing things, and then the next thing you know, you have a huge backlog that’s exactly the sort of thing you don’t want to tackle, and the cat vacuuming goes on endlessly.
So, judging that many of them have one or more of their own readme files and/or self-explanatoriness about them, I decided to instead write a brief summary post, and let you go looking at whatever interested you specifically on your own time.
Efficiency!
Kernel 7.0.0 for WSL
While I haven’t needed to produce a specific custom kernel for WSL use for some time, I recently bit the bullet and decided to leap over the current Microsoft kernel (6.18.33) and charge right into compiling a 7.0.0 for WSL use.
This isn’t all that much like my old custom kernels; it contains specific things I need (AppArmor, NFS 4.2, USB/IP support, etc.), but the main theme of the exercise has been seeing what, mostly in the realm of curious driver support choices, I could cut out to make a lean-and-mean 7.0.0 kernel that would be perfectly functional in WSL.
And now it’s done, it works1, and I’m running on it now.
Apt packages are available in the wsl-transdebian repository as per usual, but in deference to current WSL packaging preferences, you can also download a kernel binary and modules.vhdx for it. If you’re interested in this sort of thing, I’d appreciate it if you gave it a whirl and let me know how well it works for you. I have tested it reasonably comprehensively, but I only have my hardware to test it on, so there may be some lacunae in areas like GPU passthrough support.
If you want the details of what’s in there, you can get the config file here, and poke around my build scripts and patches in the cerebrate/WSL-Kernel-Configuration repo.
Also, if anyone knows how the various virtio/virtio9p/virtiofs options are supposed to work in recent WSL iterations - drop me a line?
ha-dev-to-bin
That’s one thing, on to the next thing. Which is a Home Assistant integration.
Specifically, it was inspired by having added some new devices to my Unifi wireless network, and running once again into the issue that it - and many other integrations - surface the is-this-device-online information as a device tracker
Which, I have to admit, is a perfectly reasonable design decision given that lots of people use them as proxies for the physical presence of the person carrying said device. For network monitoring, however, it’s a real pain in the byte that you get device trackers instead of what you want, which is binary sensors of device class “connectivity”.
The accepted solution for this is to create a template binary sensor for each device tracker that does the conversion for you. Well, that may be the accepted solution, but it’s also the annoying solution. Especially since Home Assistant core already includes a helper called Change device type of switch, used when a switch is actually the switch on a light, cover, etc., that does roughly what we want.
Enter my shamelessly vibe-coded2 solution for a helper that changes device trackers into binary sensors and hides the original device trackers just like Change device type of switch does for switches. Trivial? Yes. Quicker than copy-paste-modifying templates every time? Also yes.
Get it here:
arkane-systems/ha-dev-to-bin: A Home Assistant helper to convert device trackers to binary sensors.
azure-ddns, Redux
What’s next? Why, revisiting an old project with new hardware and a new approach, of course, the old post in question being 2022’s:
Tempora mutantur; et nos mutamur in illis. (Although curiously the actual IP address assigned to my border router does not, meaning that I am updating this project not because it does, but because I have no technical guarantee that one day it won’t, thus adding a certain frisson to the whole exercise.
But I have a new border router, a perfectly cromulent Unifi Express 7, and support for the original PowerShell functions I wrote back in that article was rapidly drifting towards obsolete, so a new solution was needed.
This new solution comprises a C# Azure Function App to update my Azure-hosted DNS zones. It comes with Bicep deployment infrastructure ready to be fed some parameters and go, now supports DynDNS v2-style endpoints as well as the same custom endpoints that my original functions used, smoke-test scripts to make sure it’s working post-deployment, and a Python DDNS client you can install on your Unifi router, should you have one, to work around the deplorable limitation that the built-in DDNS client won’t handle IPv6, only IPv4.
But enough. More details are in its own documentation, which you can find in the repo here:
arkane-systems/azure-ddns: Azure Functions-based dynamic DNS updater for Azure DNS
ha-signal-light
Still with me? Next up is another Home Assistant integration in the early stages, and wanting of testers. It exists because I have at various places in my home full-color Hue bulbs, collectively referred to as “accent lights”, which I want to use for three separate purposes:
In the short term, to signal various conditions (person at the door, Alexa has a notification for me, the house is on fire) which need to be addressed.
In the medium term, to adopt various accents depending on the situation. At the short end, add a dim and cozy look to movie-watching sessions. At the longer end, run festive lighting routines for holidays. That sort of thing.
And in the long term, just be a light doing what lights do and blending into the rest of the lighting system.
The problem, of course, is the vexing question when all of these things are going on at once is, well, who owns the light right now? Which is to say, which automations are in charge, and how do they know if there’s someone else who will want it back after they’ve done their thing, and so forth.
Managing all this manually with a cluster of scripts, automations, and helpers is what one might refer to, in technical terms, as a clusterfuck.
And unto this, my Signal Light integration, which is basically a centralized coordinator for such lights. It sets up a three-layer model, with a base light entity that you use to set what the light should be doing by default, with an accent layer on top of that, and a signal layer on top of that.
(The accent layer uses a priority stack and the signal layer a priority queue such that you can specify which accents or signals should take priority over others. For the former, for example, movie-watching mode should obviously be prioritized over decoration routines; while for the latter someone’s-at-the-door needs more immediate attention than Alexa-has-a-notification, and the-house-is-on-fire has priority over everything.)
And the coordinator takes care of all the ensuring that these things all happen in the right order, high priority over low, signals over accents over base settings, and that when one terminates, control of the light is handed back to the appropriate signal/accent routine/base settings depending on what the situation is now3.
Anyway, if this sounds useful to you in your Home Assistant lighting adventures, grab it and take a look. It and its documentation can be found here:
arkane-systems/ha-signal-light: A Home Assistant extension to coordinate signal/accent lights.
Going for a Kruise
This is the last one, I promise, and it’s just a quick hack.
I use, as I may have mentioned, OpenKruise on my k8s cluster for a variety of tasks. It has many marvelous and useful features for the beleaguered Kubernetes administrator, of which some of my favorites are BroadcastJob and AdvancedCronJob, ImagePullJob, ResourceDistribution, PersistentPodState, and ContainerLaunchPriority.
But a couple of months ago, in the course of attempting a routine upgrade, it broke!
(Well, to be fair, I broke it. The exact details of this oops are really quite uninteresting to anyone who is not the little voice in my head named “imposter syndrome”, so I will spare you them, but the point is that it should not reflect on the OpenKruise software.)
But before I figured it out, I found myself assembling a collection of hacks to make it appear that its jobs were still being done to keep the cluster happy in the interim. The only one I actually got finished before finding the issue and thus not needing to work on any more is a manual script version of ResourceDistribution, but should you ever find yourself needing such a thing, here it is:
cerebrate/kruise-substitutes: Scripts to do Kruise's ResourceDistribution job while it's down on my cluster.
Still no strict confinement for snaps, although for a different reason this time. Sigh. Not having to patch the kernel for that was one reason to try compiling a 7.0.0 kernel in the first place.
Except not, because I used to do this for a living and don’t just mindlessly merge whatever the agent spits out. I read through, nod, make hrm-ing noises, and then mindfully merge whatever the agent spits out.
Which will usually, but not always, be the previous thing. If the movie ended while you were answering the door, Signal Light will understand that movie-watching mode has ended and not try to reinstate it. For example. I could make up more complex examples all day, but you get the idea.