About

Why i3wm The i3 window manager (i3wm) is a tiling window manager focused on efficiency and productivity. It was first developed in 2009 by German developer Michael Stapelberg to address the limitations of the wmii window manager. The name “i3” stands for “improved tiling wm.” Written in C with roughly 10,000 lines of concise code, i3 is lightweight while still offering powerful functionality. It has become popular among developers, system administrators, and power users who prefer keyboard-driven workflows with minimal mouse use. It is especially common among users of distributions such as Arch Linux, Gentoo, and NixOS. ...

When memory runs low, Linux pushes rarely used pages out to swap. The problem is that swap usually lives on disk. The moment disk swap gets busy, the system noticeably stutters. zram puts that swap in compressed RAM instead of on disk: rather than writing pages to disk, it compresses and keeps them in RAM. The trade is simple. You spend a little extra CPU compressing and decompressing, and in return you turn disk I/O into RAM access. Text-like data typically compresses 2:1 to 4:1, so you get back the physical RAM that pages would have consumed, at less than half the cost. ...

A host that receives an ARP reply has no way to check whether the reply is real. Broadcast “what is the MAC of gateway 192.168.1.1?” and whoever answers, that answer gets written straight into the cache. No authentication, no integrity check. ARP even accepts a reply nobody asked for (a Gratuitous ARP) and overwrites the existing cache entry with it. An attacker puts a fake reply into that gap. Tell the victim “the gateway’s MAC is mine” and the gateway “the victim’s MAC is mine” at the same time, and all traffic between the two routes through the attacker. It is a textbook man-in-the-middle (MITM) attack, reproduced below in an isolated lab. ...

Overview In the previous post, I pulled together the overall IDP structure using Helm chart-based project templates and ArgoCD ApplicationSet. This post covers how I added Prometheus and Grafana for metrics, plus Loki for centralized log collection and analysis. Together, they form the monitoring stack for the homelab Kubernetes cluster. The Need for Monitoring When operating a homelab Kubernetes cluster, I need to keep an eye on node and pod status, resource usage such as CPU and memory, whether applications are behaving normally, and the logs that help explain failures. For that, I used the following tools. ...

Overview In the previous post, I set up Harbor container registry, Argo Events, and Argo Workflows as the foundation of the IDP. This post covers integrating those components with ArgoCD and designing Helm chart-based project templates to turn them into an Internal Developer Platform (IDP) that can deploy projects from a single YAML file. What Is an Internal Developer Platform? What is an Internal Developer Platform (IDP)? ...

Overview In the previous post, we installed HashiCorp Vault to build a secure secrets management system. This post covers the foundational pieces I set up before the internal developer platform itself: Harbor container registry, Argo Events, and Argo Workflows. Foundation Components for the IDP For the IDP I had in mind, I first needed the following core components: Container Registry: A central repository for storing and distributing built container images, enabling self-management of images without depending on public registries like Docker Hub. Event Processing System: Responsible for detecting various events such as code changes in Git repositories and webhook receipts, and triggering subsequent tasks in response. Workflow Engine: An engine for defining and executing actual CI/CD tasks such as code building, test execution, and container image creation. GitOps Deployment System: A system that automatically synchronizes the desired state defined in Git repositories to the cluster. ArgoCD, which was installed in an earlier post in this series, handles this role. In this post, I set up the container registry, event processing system, and workflow engine using Harbor, Argo Events, and Argo Workflows. In the next post, I connect these pieces to ArgoCD and the project template structure so they start to behave like an actual IDP. ...

Overview In the previous post, we configured DDNS and port forwarding to enable external internet access to services running in the homelab Kubernetes cluster. This post covers how to install and configure HashiCorp Vault to securely manage sensitive information like passwords, API keys, and certificates in the Kubernetes cluster. Limitations of Default Kubernetes Secrets Secret management was the biggest challenge while building the homelab environment using GitOps methodology. Several limitations became clear when using default Kubernetes Secrets. ...

Overview In the previous post, we installed the Traefik ingress controller and configured secure access to management interfaces by separating internal and external services. This post covers how to configure DDNS and port forwarding to enable external internet access to services running in the homelab Kubernetes cluster. Network Architecture Summary First, let’s briefly summarize the network architecture configured in the previous post: Internal Load Balancer (192.168.0.200): Exposes only management interfaces like ArgoCD, Longhorn, and Traefik dashboard, accessible only from within the internal network. External Load Balancer (192.168.0.201): Exposes only public services like blogs and personal projects, accessible from the external internet through router port forwarding. ...

Overview In the previous post, we installed the Longhorn distributed storage system to build a persistent storage environment where data is retained even when pods restart or move to different nodes. This post covers installing the Traefik ingress controller on a homelab Kubernetes cluster and configuring secure access to management interfaces from the internal network. Choosing an Ingress Controller There are several methods for exposing Kubernetes services externally in a homelab environment: ...

Overview In the previous post, I set up a GitOps environment by installing ArgoCD. This post covers how I installed and configured the Longhorn distributed storage system in my homelab Kubernetes cluster, along with what I learned from comparing storage options and why persistent storage turned out to be necessary. Storage Challenges in a Homelab Environment One of the biggest challenges when building a homelab Kubernetes cluster was configuring storage. Most practical applications such as databases, monitoring tools, and backup systems require persistent storage that maintains data even when pods restart or move to different nodes. ...