Exploring a few changes to how, and where, I host my own data, I revisited my backup strategy.

For years I’ve been using SpiderOak ONE and my main complain was the pricing slide. At 500GB backed up, I can’t be at the 400GB plan, so end up forking over US$150 a year for a 2TB plan.

I probably don’t need those 500GB, as I know from their UI that it once backed up some useless data like logs and save games. The tool did a great job on data de-duplication, only counting once for every copy of the same file across multiple devices.

Following up from the previous work gathering Temperature, I finally got around setting up some monitoring.

Thanks to the good write-ups by alfaexploit.com, namely Monitoring Jail Resources in FreeBSD with Prometheus and Prometheus/Grafana Monitoring System on FreeBSD.

There’s also a document by the FreeBSD Foundation, Monitoring and Trending with Prometheus, still reasonably up-to-date for a reader in 2024.

I’ve not really used Prometheus before, previously having worked on very old school Nagios-based systems, then push-based solutions like Graphite and Riemann, to finally very Enterprise-focused tools like NewRelic. It’s fair to say I wasn’t a big fan of pull-based solutions because, on the old days, they incurred a cost in keeping a central database up-to-date and there was always a new host that someone would forget to add to the configuration.

Summer is upon us, temperature is rising, and I’m curious how my little server cabinet is faring.

A few years ago I bought an Elitech RC-4 Temperature Data logger for keeping an eye at the temperature at the office I used to work at.

It’s a pretty good device, you can leave it recording by itself, battery-backed, then read the data using the USB connector.

There’s even a Python elitech-datareader unofficial library, which did the job pretty nicely.

Just finished reading The five dysfunctions of a team by Patrick Lencioni.

At first I was worried that the fable of Kathryn, a new CEO working to get the leadership team of a fictional start-up, was going to take the entire 280 pages of the book. The fable was good to set the talking points and did not get in the way of the message, easing my worries.

At the fable concluded, the book had already explained a lot of how the framework, or method, for identifying and correcting these five dysfunctions. Even better as then the book went into a more in-depth, more formal explanation around how to identify, what’s the impact of letting the dysfunction take place, and suggestions for mitigating them.

Back to basics today, writing from scratch some templates. ConfigMap, Pod, Service, Ingress, stitching them together, seeing the kubectl patch on a selector or on a metadata getting injected and magic happening on the ingress controller.

I was writing documentation, so going to the basics is important for clarity. Unfortunately, flipping a selector on a Service to match a new set of Pods isn’t a long-term solution, as you still have to figure out when to get rid of the old set of Pods you are trying to replace, and I don’t think kubectl patch without a more encompassing solution is sustainable.

A reminder to self that sticking to the topmost priority the entire day pays off.

Working on Operations roles naturally has us jumping around, today was a good day when all was going as expected, had the time and focus to get an item on the top line of the Kanban completed, which also meant closing several other pieces of work that were pending action.

Feels good!

Reviewing a vendor’s code, learnt about the use of exclamation mark (!) on a variable.

Bash 5 documentation states:

If the first character of parameter is an exclamation point (!), and parameter is not a nameref, it introduces a level of indirection. Bash uses the value formed by expanding the rest of parameter as the new parameter; this is then expanded and that value is used in the rest of the expansion, rather than the expansion of the original parameter. This is known as indirect expansion. (…)

Today at the day job we found out that one of our tests failed to capture a situation. That doesn’t mean our tests failed, it means we learnt one more scenario to test.

It is pretty comforting situation to even have a test to improve, rather than allowing ourselves to fail the same way in the future.

Some time ago, my eldest and I started playing Minecraft together.

As you would expect from a sysadmin at heart, we soon had a server running on the Linux-based home server.

That went well but I wasn’t very happy running everything on my own user account on that server. Any backdoor on that server, maybe an admin command that allowed a remote shell, and an attacker would have same access as myself.

Writing some “Quality of Life” helpers today. Finance wanted a breakdown of usage, but data on monitoring database was recording only the id of each application, not their name or to which business they belonged to.

Started writing something that queried the database, soon realised it was going to be an uphill battle. Needing a library with a binary, making it boring to deploy on a Lambda, or needing to figure out database access if running from our centralised GitHub Actions runners, all sorts of complications.