Tag - updates

Entries feed - Comments feed

31 Jan 2025

Short updates - new keyboard and SSDs

By Adam on 31 Jan 2025, 07:35 - Homelab

New Keyboard

I picked up a Feker Alice98 in an attempt to get something a little more "ergonomic" than my previous keyboard. It's an "Alice" layout, with the interesting distinction of having two "B" keys.
This keyboard is also compatible with VIA, making keymapping, backlighting, and macros easy to manage. This keyboard isn't listed on VIA's website, though, so it requires manually importing the keyboard definition file (attached to this post). Hopefully VIA will add it officially, eventually.  

"New" SSDs for the cluster

I also picked up some gently-used Intel TLC SSDs for my main Proxmox nodes.

I had noticed before that the IO delay [1] on my nodes would creep in to the 80%+ range when running any reasonably write-intensive task, like a system update. I also received feedback that this blog seemed slow, which I suspected might be caused by the same issue.  While the consumer QLC SSDs I was previously using seem fast for normal desktop use, their short-comings become quite noticeable when running multiple VMs. Here's a screen shot of the IO delay during fairly normal use before, compared to the the IO delay now while running updates:

(blue is the IO delay)

While the old ones would routinely creep in to the 50% or higher range while running fairly simple tasks, the new SSDs peaked around 5%, even when under load.

 

Note(s)

  1. ^ Amount of time that the CPU hangs idle while waiting for IO tasks (reading or writing to a drive) to complete.

one attachment

23 Nov 2024

Caching Apt with Apt-Cacher NG

By Adam on 23 Nov 2024, 19:44 - Homelab

It recently occurred to me that as I update each Linux container or VM, I'm downloading a lot of the same files over and over again.  While the downloads aren't huge, it still seems wasteful to request the same files from the repo mirrors so many times... So why not just download the update once and then distribute it locally to each of my systems?  

That's the purpose of a caching proxy.

I chose apt-cacher ng as it's very simple to setup and use, so I spun up a dedicated LXC and installed apt-cacher ng via apt. Once it was up and running, it was just a matter of following the included documentation to point all of my other systems to that cache.

After upgrading just a couple of systems, I can already see the cache doing it's job:

Those "hits" are requests that were able to be fulfilled locally from the cache instead of needing to download  the files from the repo again. Since this is caching every request, it actually becomes more efficient the more that it's used, so hopefully the efficiency will increase even more over time.

So what exactly is happening?

First, this is not a full mirror of the Debian repos. Rather, apt-cacher ng acts as a proxy and cache. When a local client system wants to perform an update, it requests the updated packages from apt-cacher instead of the Debian repo directly. If the updated package is available in apt-cacher's local cache already, it simply provides the package to the requesting client. If the package is not in the local cache, then the proxy requests the package from the repo, provides that package to the client, and then saves a copy of the package to the cache. Now it has a local copy in case another system requests the same package again.

Some packages, like Crowdsec, are only installed on a single machine on my network, so the cache won't provide a benefit there. However, since most of my systems are all running Debian, even through they may be running some different services,  they will still all request a lot of the same packages as each other every time they update, like openssh or Python.  These will only have to be downloaded the very first time they're requested, and all of the subsequent requests can be filled from the proxy's local cache.

Do you use a cache in your homelab? Let me know below!