I have been quite keen about AWS S3 professionally from about ever since it debuted. And that is long time ago (2006). This post is more about my S3 at home exercise, which is not even two years old. Why S3? I’m not going to detail about that here (the at home part is the point of this blog post), but S3 has offered for two decades now pretty cool object storage. Here are some key aspects of AWS S3: ...
My home infrastructure observability stack has been relatively static (for some definition of static) for awhile. VictoriaMetrics + Loki has been ‘fine’. But I like dabbling with other alternatives, and this time it is Greptime. Greptime - what is it? https://greptime.com is basically unified storage of all observability data. I’m not trying to market it too hard here, but basically: It is Rust It handles storage in various ways local ( using Parquet format ) object storage ( no idea, not tried yet ) … It allows clients to use various APIs (this list is not exhaustive, just ones I find interesting) Prometheus Vector has built-in sinks for it pg, mysql it also has built-in GUI Integration with my infra Vector before Greptime I run Vector at home. Hard. Here’s the vector graph before Greptime: ...
My home infrastructure has been gradually more and more complex, mostly because I like testing things in home before using them in production. This describes bit more my multi-container workload handling (an earlier post in 2024 covered it briefly too, but there has been a lot of developments since). Background A lot of the software I self-host consists of single containers. For them I have rather nice pyinfra deployment script for each, which sets up the container as systemd unit, making it possible to start and stop the podman container on demand (and to start it on boot), handle upgrades, etc. in unified way. ...
As noted before, I have used kind (Kubernetes in Docker) in home for a while just as Docker compose replacement (and to tinker with some Kubernetes-only tools at home). For a while I have wanted something I could upgrade, and in general HA, and kind is not that. So I bought some hardware (see earlier post). Then I setup some software (this post). What did I want? I wanted HA tinfoil hat cluster, in other words: ...
I have been running Kubernetes at home from October 2024 onward. That exercise was single-node though, using (relatively small) part of the Frankenrouter resources. This is about next Kubernetes iteration.. or its hardware choice. Why I did not want to stick with the kind setup forever? Frankenrouter hardware (Intel N305) at least officially supports only 32GB of RAM. In addition to OpenWrt LXC container, and some native Debian processes, it is packing about 49 containers at the time of writing (give or take few, this Grafana thing is only an approximation based on unique images on podman side and pods on Kubernetes side): ...
When I wrote the first iteration of the Lixie tool about year ago (early 2024), my idea was to identify which logs were boring (most of them), interesting (very few of them) and unknown (not yet classified). At the time I chose not to use ‘AI’ (LLMs) for it, and I am still not that convinced they are the best way to approach that particular problem. Ultimately it boils down to human judgment of what is useful is much more realistic (at least in my context) than what the LLMs ‘know’ (absent fine-tuning and-or extensive example sets which I do not by definition have for my personal logs). After choosing not to use LLMs for it, it was just matching exercise - structured logging messages against an ordered set of rules. ...
Background I think I wrote about this in some earlier blog post too, but I have used various home automation solutions for awhile now. I started out with very, very early Home Assistant builds, not quite sure when, but I contributed little in 2014 to it at least (based on git log). Later in 2014 I started developing my own solution with somewhat different decentralized model ( GitHub - fingon/kodin-henki: ‘Spirit of home’ - my home automation project written in Python 2/3. ), which I used about 5 years and then switched to much less featureful but also less maintenance requiring Philips Hue system. ...
TL;DR: Unifi mesh is bad, Orbi is pricey, TP-Link is surprisingly good. Recap (2024 home wifi history) I had Netgear Orbi (75x series) for 4 years (2020-2024) Last summer, I experimented with Unifi (see earlier posts); to put it bluntly, it sucked for mesh use, and I went back to the Orbis The Orbi still did not support wifi 6E which modern Macbook Pros need for more than 1200mbps wifi phy (= more than 600mbps data rate) So, I was on the hunt for more hardware.. New challenger is found In early Black Friday deals in mid-November, I spotted a TP-Link Deco BE65 set at a quite reasonable discount. On the paper, it seemed quite promising. Why is that? ...
As noted in the previous Pulumi post, I had bit too much to write about when describing my current home infrastructure. Due to that, here’s stand-alone post about just that - Pulumi (and pyinfra) at home. Current hobby architecture To give a concrete example of how I am using Pulumi in my current hobby infrastructure, this is a simplified version of my hobby IaC architecture. There is a lot of containers both within and without Kubernetes that I am omitting for clarity from the diagram: fw pyinfra/Pulumi provisioning configures local infrastructure, and oraakkeli Pulumi stack (and two pyinfra configurations) handle my VPSes in Oracle Cloud. ...
Now that we have used it for couple of weeks (Unifi U6 Mesh + Unifi Express + Unifi Flex Mini switch), in one sentence our experience can be summarized as: ‘Do not buy Unifi for mesh networking’. What is wrong with it? Backhaul, or lack of it To elaborate on it, it seems that none of their access points have dedicated backhaul radios, and that means that you are dealing with same congested 5GHz radio band being used both by the client to AP, as well as AP to AP traffic. ...