From 14c1ea925d3a5df0ca228855e28331db7e6122da Mon Sep 17 00:00:00 2001 From: angel Date: Wed, 1 Apr 2026 19:55:55 -0400 Subject: [PATCH] Infrastructure explanation --- pages/infrastructure.md | 54 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 pages/infrastructure.md diff --git a/pages/infrastructure.md b/pages/infrastructure.md new file mode 100644 index 0000000..3e44d7b --- /dev/null +++ b/pages/infrastructure.md @@ -0,0 +1,54 @@ +# Infrastructure Overview: The "Ben's Cloud" Ecosystem + +## The Philosophy +My infrastructure is a testament to adaptability. While "server-room best practices" often dictate specific hardware and wired connectivity, real-world constraints require thinking outside the box. This setup prioritizes resource efficiency, hardware longevity, and ease of management. + +--- + +## Physical Hardware Stack + +### Workstations +I rely on the reliability of the Lenovo ThinkPad line for my daily drivers: +* **ThinkPad W540:** Primary mobile workstation. +* **ThinkPad T460s:** Lightweight secondary workstation. +* **OS:** Linux Mint (Cinnamon). + +### Server Hosts +* **Dell OptiPlex 9020 (Tower):** Primary server host. +* **ThinkPad W540 (Laptop):** A retired workstation repurposed as a secondary server. Despite a failing keyboard and screen, its internal specs remain highly capable. +* **OS:** Linux Mint. I use Mint on the hosts to simplify wireless driver management and to handle the legacy Nvidia hardware (currently running **Nouveau** drivers to remain Wayland-ready). + +--- + +## The Networking Challenge: "Taboo" Wi-Fi +Both server hosts operate via Wi-Fi. In the server world, wireless is often considered "taboo," which presents a specific technical hurdle: **Layer 2 Bridging** (or a "Network Bridge") typically doesn't work over Wi-Fi. This means VMs cannot pull unique IP addresses directly from my router's DHCP server. + +### The Solution: Tailscale & NAT +To bypass this limitation and maintain a professional workflow, I use a dual-layered approach: +1. **NAT Networking:** The VMs live on a private internal network behind the host. +2. **Tailscale Mesh:** I install Tailscale on each virtual machine. This allows me to connect directly to every VM using its own unique IP/hostname, completely bypassing the host's NAT limitations and providing seamless access across my entire environment. + +--- + +## The Hypervisor & OS Strategy + +### Virtualization Layer +I have moved away from VirtualBox and Vagrant in favor of a more robust, integrated stack: +* **KVM/QEMU:** The core hypervisor. +* **Virt-Manager & Cockpit-Machines:** Primary tools for management and monitoring. +* **Snapshots:** I utilize native KVM snapshots to preserve system states rather than maintaining heavy templates. + +### Guest OS Policy +* **Standardization:** For headless virtual machines, I generally use **Ubuntu LTS**. This ensures consistency in package versions and management across my production services. +* **Docker Integration:** Most services are deployed via Docker. I typically run one large "utility" VM for lightweight stacks (e.g., Vaultwarden, Jellyfin) and dedicated VMs for complex applications like Nextcloud. + +--- + +## Distro Agnosticism +While Mint and Ubuntu form the production backbone, I maintain a diverse lab to stay "distro-literate." My environment includes: +* **Enterprise:** RHEL (Developer Edition), AlmaLinux, Rocky Linux, and CentOS. +* **Community & Rolling:** Fedora Server, openSUSE, Alpine, and even a few Arch installations. + +--- + +> **Note:** This lab is built on the principle of using every available resource—even a battered laptop—to its fullest potential. \ No newline at end of file