mirror of
https://github.com/skoelle/moonweb-site.git
synced 2026-09-18 01:10:25 +00:00
Remove all em-dashes from website content and documentation
Replace ' — ' with ', ' across 40 files. Hyphens (-) untouched. timecapsule, stefankoelle, LICENSE, CSS comments left as-is.
This commit is contained in:
@@ -11,10 +11,10 @@ layout: base.njk
|
||||
|
||||
<p>The homelab uses a layered backup approach, split into two independent
|
||||
tracks: NAS user content, and Proxmox VM/LXC backups. Both follow a
|
||||
3-2-1-style rule — multiple copies, multiple media types, at least one
|
||||
3-2-1-style rule, multiple copies, multiple media types, at least one
|
||||
copy on a different machine.</p>
|
||||
|
||||
<h2>NAS user content — four layers</h2>
|
||||
<h2>NAS user content, four layers</h2>
|
||||
<table>
|
||||
<tr><th>Layer</th><th>Target</th><th>Frequency</th><th>Purpose</th></tr>
|
||||
<tr><td>Snapshots</td><td>Synology, built-in</td><td>Hourly</td><td>Fast recovery of accidentally deleted files</td></tr>
|
||||
@@ -23,17 +23,17 @@ copy on a different machine.</p>
|
||||
<tr><td>Cloud archive</td><td>Cloud storage</td><td>Continuous</td><td>Off-site copy for worst-case scenarios (fire, theft)</td></tr>
|
||||
</table>
|
||||
|
||||
<h2>Proxmox VM/LXC backups — three copies, two machines</h2>
|
||||
<h2>Proxmox VM/LXC backups, three copies, two machines</h2>
|
||||
<table>
|
||||
<tr><th>Copy</th><th>Target</th><th>Frequency</th></tr>
|
||||
<tr><td>1 — original</td><td>Proxmox host itself</td><td>Daily</td></tr>
|
||||
<tr><td>2 — primary offsite</td><td>Synology NAS (different machine)</td><td>Daily, right after copy 1</td></tr>
|
||||
<tr><td>3 — secondary offsite</td><td>Raspberry Pi backup target, different room</td><td>Daily (skipped one day/week to avoid network contention with the weekly NAS sync)</td></tr>
|
||||
<tr><td>1, original</td><td>Proxmox host itself</td><td>Daily</td></tr>
|
||||
<tr><td>2, primary offsite</td><td>Synology NAS (different machine)</td><td>Daily, right after copy 1</td></tr>
|
||||
<tr><td>3, secondary offsite</td><td>Raspberry Pi backup target, different room</td><td>Daily (skipped one day/week to avoid network contention with the weekly NAS sync)</td></tr>
|
||||
</table>
|
||||
|
||||
<h2>Design principles</h2>
|
||||
<ul>
|
||||
<li>Backups always cross at least one machine boundary — nothing is considered "backed up" if it only lives on the source machine's local disk.</li>
|
||||
<li>Backups always cross at least one machine boundary, nothing is considered "backed up" if it only lives on the source machine's local disk.</li>
|
||||
<li>Weekly and daily jobs are scheduled to avoid saturating the internal power-line network link used by the offsite backup target.</li>
|
||||
<li>All scheduled jobs ping a dead-man's-switch monitoring service; a missed backup triggers an alert.</li>
|
||||
<li>Power to the offsite drive is only switched on for the duration of its weekly sync, to save power and extend disk life.</li>
|
||||
|
||||
@@ -9,29 +9,29 @@ layout: base.njk
|
||||
<h1>Xubuntu Dev VM</h1>
|
||||
<div class="detail-content">
|
||||
|
||||
<p>This is a Xubuntu virtual machine on <a href="/proxmox/">Proxmox pve2</a> in the study that serves as my main development environment, replacing the need for a dedicated physical workstation. It's designed to be lightweight, remotely accessible from anywhere, and — most importantly — completely disposable, which is what makes it a safe place to let AI coding agents operate with far more autonomy than I'd otherwise allow.</p>
|
||||
<p>This is a Xubuntu virtual machine on <a href="/proxmox/">Proxmox pve2</a> in the study that serves as my main development environment, replacing the need for a dedicated physical workstation. It's designed to be lightweight, remotely accessible from anywhere, and, most importantly, completely disposable, which is what makes it a safe place to let AI coding agents operate with far more autonomy than I'd otherwise allow.</p>
|
||||
|
||||
<h2>Why a disposable VM is the biggest advantage</h2>
|
||||
<ul>
|
||||
<li><strong>Daily backups as a safety net</strong> — the VM is backed up once a day through Proxmox. If an AI agent breaks the system, misconfigures something critical, or deletes the wrong files, I simply restore yesterday's snapshot rather than manually debugging the damage.</li>
|
||||
<li><strong>No irreplaceable local data</strong> — nothing important lives only on this VM. All actual project code lives in Git repositories, so after a restore I just <code>git pull</code> everything back and I'm exactly where I left off, minus whatever the agent broke.</li>
|
||||
<li><strong>Higher trust, more autonomy for AI agents</strong> — because the worst-case outcome is "restore a snapshot and re-pull," I can give coding agents like OpenCode much broader permissions on this machine than I would on a system holding unique, unbacked-up state. The blast radius of a mistake is capped at "lose a few hours of uncommitted work," never at "lose data."</li>
|
||||
<li><strong>Cheap to rebuild from scratch</strong> — if the VM ever gets into a truly bad state, standing up a fresh Xubuntu VM and re-cloning repos is a short, well-understood process rather than an emergency.</li>
|
||||
<li><strong>Daily backups as a safety net</strong>, the VM is backed up once a day through Proxmox. If an AI agent breaks the system, misconfigures something critical, or deletes the wrong files, I simply restore yesterday's snapshot rather than manually debugging the damage.</li>
|
||||
<li><strong>No irreplaceable local data</strong>, nothing important lives only on this VM. All actual project code lives in Git repositories, so after a restore I just <code>git pull</code> everything back and I'm exactly where I left off, minus whatever the agent broke.</li>
|
||||
<li><strong>Higher trust, more autonomy for AI agents</strong>, because the worst-case outcome is "restore a snapshot and re-pull," I can give coding agents like OpenCode much broader permissions on this machine than I would on a system holding unique, unbacked-up state. The blast radius of a mistake is capped at "lose a few hours of uncommitted work," never at "lose data."</li>
|
||||
<li><strong>Cheap to rebuild from scratch</strong>, if the VM ever gets into a truly bad state, standing up a fresh Xubuntu VM and re-cloning repos is a short, well-understood process rather than an emergency.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Remote workflow via SSH</h2>
|
||||
<ul>
|
||||
<li><strong><a href="https://herdr.dev/">Herdr</a></strong> — manages my development workspaces over SSH, letting me organize and switch between multiple project contexts on the VM without manually juggling terminal sessions.</li>
|
||||
<li><strong><a href="https://opencode.ai/de">OpenCode</a></strong> — the AI coding agent I run inside these workspaces; it's the main reason the VM's disposability matters, since it can act with elevated freedom knowing any damage is trivially reversible.</li>
|
||||
<li><strong><a href="https://github.com/jesseduffield/lazygit">lazygit</a></strong> — terminal UI for Git, used for fast commit/branch/diff workflows directly inside the SSH session without leaving the terminal.</li>
|
||||
<li><strong><a href="https://herdr.dev/">Herdr</a></strong>, manages my development workspaces over SSH, letting me organize and switch between multiple project contexts on the VM without manually juggling terminal sessions.</li>
|
||||
<li><strong><a href="https://opencode.ai/de">OpenCode</a></strong>, the AI coding agent I run inside these workspaces; it's the main reason the VM's disposability matters, since it can act with elevated freedom knowing any damage is trivially reversible.</li>
|
||||
<li><strong><a href="https://github.com/jesseduffield/lazygit">lazygit</a></strong>, terminal UI for Git, used for fast commit/branch/diff workflows directly inside the SSH session without leaving the terminal.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Graphical fallback via Chrome Remote Desktop</h2>
|
||||
<ul>
|
||||
<li><strong>Full desktop access</strong> — when a GUI IDE is preferable to terminal-based editing, Chrome Remote Desktop connects straight into the Xubuntu desktop from any device.</li>
|
||||
<li><strong>WebStorm</strong> — used for TypeScript projects that benefit from a full IDE (refactoring tools, debugging, integrated test runners).</li>
|
||||
<li><strong>PyCharm</strong> — used the same way for Python projects.</li>
|
||||
<li><strong>Full desktop access</strong>, when a GUI IDE is preferable to terminal-based editing, Chrome Remote Desktop connects straight into the Xubuntu desktop from any device.</li>
|
||||
<li><strong>WebStorm</strong>, used for TypeScript projects that benefit from a full IDE (refactoring tools, debugging, integrated test runners).</li>
|
||||
<li><strong>PyCharm</strong>, used the same way for Python projects.</li>
|
||||
</ul>
|
||||
|
||||
<p class="redacted-note">This setup deliberately treats the dev VM as ephemeral infrastructure, not a pet — the philosophy is: keep state in Git, keep the VM replaceable, and let daily backups absorb the risk of giving an AI agent real write access to the system.</p>
|
||||
<p class="redacted-note">This setup deliberately treats the dev VM as ephemeral infrastructure, not a pet, the philosophy is: keep state in Git, keep the VM replaceable, and let daily backups absorb the risk of giving an AI agent real write access to the system.</p>
|
||||
</div>
|
||||
+29
-29
@@ -9,62 +9,62 @@ layout: base.njk
|
||||
<h1>Docker Container Strategy</h1>
|
||||
<div class="detail-content">
|
||||
|
||||
<p>My homelab runs almost entirely on Docker, spread across three dedicated Debian VMs instead of installing containers directly on bare metal or on the NAS operating system itself. Each VM is a clean, disposable Docker host that can be snapshotted and backed up as a whole through Proxmox, and every service is defined declaratively as a Docker Compose file living under <code>/docker-data/compose/<service>/</code>. This keeps the setup portable, reproducible, and easy to document — if a host dies, restoring a VM snapshot brings every container definition back with it.</p>
|
||||
<p>My homelab runs almost entirely on Docker, spread across three dedicated Debian VMs instead of installing containers directly on bare metal or on the NAS operating system itself. Each VM is a clean, disposable Docker host that can be snapshotted and backed up as a whole through Proxmox, and every service is defined declaratively as a Docker Compose file living under <code>/docker-data/compose/<service>/</code>. This keeps the setup portable, reproducible, and easy to document, if a host dies, restoring a VM snapshot brings every container definition back with it.</p>
|
||||
|
||||
<h2>The three Docker hosts</h2>
|
||||
<ul>
|
||||
<li><strong>docker-host-pve</strong> — Debian VM on the main Proxmox server (PVE). This is the primary target for almost all container deployments, including my own images pulled from GHCR. Fully covered by Proxmox VM backups, so the whole host can be restored in one shot.</li>
|
||||
<li><strong>docker-host-nas</strong> — Debian VM running directly on the Synology (via Virtual Machine Manager). Identical setup and folder structure to the PVE host, but used specifically for containers that need direct access to NAS storage volumes, such as media-processing tools that read and write large file libraries.</li>
|
||||
<li><strong>docker-host-pve2</strong> — Debian VM on the secondary Proxmox server (pve2), which lives in the study and is treated as a pure test/dev environment. New containers and compose setups get trialed here before being promoted to docker-host-pve.</li>
|
||||
<li><strong>docker-host-pve</strong>, Debian VM on the main Proxmox server (PVE). This is the primary target for almost all container deployments, including my own images pulled from GHCR. Fully covered by Proxmox VM backups, so the whole host can be restored in one shot.</li>
|
||||
<li><strong>docker-host-nas</strong>, Debian VM running directly on the Synology (via Virtual Machine Manager). Identical setup and folder structure to the PVE host, but used specifically for containers that need direct access to NAS storage volumes, such as media-processing tools that read and write large file libraries.</li>
|
||||
<li><strong>docker-host-pve2</strong>, Debian VM on the secondary Proxmox server (pve2), which lives in the study and is treated as a pure test/dev environment. New containers and compose setups get trialed here before being promoted to docker-host-pve.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Standardized layout</h2>
|
||||
<ul>
|
||||
<li><strong>/docker-data/compose/</strong> — one subfolder per service, each containing its own <code>docker-compose.yml</code> (and <code>.env</code> where needed).</li>
|
||||
<li><strong>/docker-data/volumes/</strong> — persistent container data, kept outside the compose folders so it survives redeploys.</li>
|
||||
<li><strong>/docker-data/backups/</strong> — local backup staging before data is pulled into the wider backup chain.</li>
|
||||
<li><strong>Same convention everywhere</strong> — because all three hosts follow this identical structure, moving a service between hosts or rebuilding a host from scratch is just a matter of copying the compose folder and running <code>docker compose up -d</code>.</li>
|
||||
<li><strong>/docker-data/compose/</strong>, one subfolder per service, each containing its own <code>docker-compose.yml</code> (and <code>.env</code> where needed).</li>
|
||||
<li><strong>/docker-data/volumes/</strong>, persistent container data, kept outside the compose folders so it survives redeploys.</li>
|
||||
<li><strong>/docker-data/backups/</strong>, local backup staging before data is pulled into the wider backup chain.</li>
|
||||
<li><strong>Same convention everywhere</strong>, because all three hosts follow this identical structure, moving a service between hosts or rebuilding a host from scratch is just a matter of copying the compose folder and running <code>docker compose up -d</code>.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Own GitHub projects</h2>
|
||||
<ul>
|
||||
<li><strong>icloud-contacts-sync</strong> — syncs contact data between iCloud and other systems.</li>
|
||||
<li><strong>calendar-sync</strong> — keeps calendars synchronized across sources.</li>
|
||||
<li><strong>mvg-departures</strong> — pulls Munich public transport (MVG) departure data for local dashboards.</li>
|
||||
<li><strong>wetter-api</strong> — a small weather API/worker pair, built from a custom GHCR image and updated automatically via Watchtower.</li>
|
||||
<li><strong>icloud-contacts-sync</strong>, syncs contact data between iCloud and other systems.</li>
|
||||
<li><strong>calendar-sync</strong>, keeps calendars synchronized across sources.</li>
|
||||
<li><strong>mvg-departures</strong>, pulls Munich public transport (MVG) departure data for local dashboards.</li>
|
||||
<li><strong>wetter-api</strong>, a small weather API/worker pair, built from a custom GHCR image and updated automatically via Watchtower.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Infrastructure containers</h2>
|
||||
<ul>
|
||||
<li><strong>mosquitto-mqtt</strong> — central MQTT broker for smart-home and sensor messaging.</li>
|
||||
<li><strong>grafana, prometheus, influxdb</strong> — the monitoring and metrics stack for dashboards and time-series data.</li>
|
||||
<li><strong>healthchecks, uptime-kuma, cadvisor</strong> — service and container health/uptime monitoring.</li>
|
||||
<li><strong>dyndns-updater</strong> — keeps DNS pointed at the home connection; my own project, see <a href="https://github.com/skoelle/dyndns-updater">skoelle/dyndns-updater</a> on GitHub.</li>
|
||||
<li><strong>watchtower</strong> — automatically checks for and applies container image updates on a daily schedule.</li>
|
||||
<li><strong>authelia, nginx-proxy-manager</strong> — authentication layer and reverse proxy for exposing internal services safely.</li>
|
||||
<li><strong>postfix</strong> — internal mail relay used by other containers (e.g. Watchtower notifications) to send email.</li>
|
||||
<li><strong>portainer</strong> — web UI for managing containers across hosts.</li>
|
||||
<li><strong>exporters</strong> — Prometheus exporters for Fritz!Box, Zyxel switches, Nginx, and SNMP devices, feeding the Grafana/Prometheus stack.</li>
|
||||
<li><strong>mosquitto-mqtt</strong>, central MQTT broker for smart-home and sensor messaging.</li>
|
||||
<li><strong>grafana, prometheus, influxdb</strong>, the monitoring and metrics stack for dashboards and time-series data.</li>
|
||||
<li><strong>healthchecks, uptime-kuma, cadvisor</strong>, service and container health/uptime monitoring.</li>
|
||||
<li><strong>dyndns-updater</strong>, keeps DNS pointed at the home connection; my own project, see <a href="https://github.com/skoelle/dyndns-updater">skoelle/dyndns-updater</a> on GitHub.</li>
|
||||
<li><strong>watchtower</strong>, automatically checks for and applies container image updates on a daily schedule.</li>
|
||||
<li><strong>authelia, nginx-proxy-manager</strong>, authentication layer and reverse proxy for exposing internal services safely.</li>
|
||||
<li><strong>postfix</strong>, internal mail relay used by other containers (e.g. Watchtower notifications) to send email.</li>
|
||||
<li><strong>portainer</strong>, web UI for managing containers across hosts.</li>
|
||||
<li><strong>exporters</strong>, Prometheus exporters for Fritz!Box, Zyxel switches, Nginx, and SNMP devices, feeding the Grafana/Prometheus stack.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Smart home containers</h2>
|
||||
<ul>
|
||||
<li><strong>Home Assistant</strong> — only used for homematicIP integration to mqtt.</li>
|
||||
<li><strong>Home Assistant</strong>, only used for homematicIP integration to mqtt.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Application containers</h2>
|
||||
<ul>
|
||||
<li><strong>SearXNG</strong> — self-hosted, privacy-respecting metasearch engine that aggregates results from multiple search providers without leaking queries to any of them. Used as the default search backend for local browsing and AI tools.</li>
|
||||
<li><strong>Open WebUI</strong> — chat interface for locally hosted LLMs.</li>
|
||||
<li><strong>Stirling PDF</strong> — self-hosted PDF toolkit for merging, splitting, converting, compressing, and editing documents without uploading them to external services.</li>
|
||||
<li><strong>ArchiveBox</strong> — personal web archiving of bookmarked pages.</li>
|
||||
<li><strong>TubeSync / TubeArchivist [NAS]</strong> — download and archive YouTube content directly onto NAS storage; these run on docker-host-nas specifically because they need direct volume access to the Synology's disks.</li>
|
||||
<li><strong>Music Stretto</strong> — music streaming server for the local MP3 library on the Synology, accessible from the home dashboard.</li>
|
||||
<li><strong>SearXNG</strong>, self-hosted, privacy-respecting metasearch engine that aggregates results from multiple search providers without leaking queries to any of them. Used as the default search backend for local browsing and AI tools.</li>
|
||||
<li><strong>Open WebUI</strong>, chat interface for locally hosted LLMs.</li>
|
||||
<li><strong>Stirling PDF</strong>, self-hosted PDF toolkit for merging, splitting, converting, compressing, and editing documents without uploading them to external services.</li>
|
||||
<li><strong>ArchiveBox</strong>, personal web archiving of bookmarked pages.</li>
|
||||
<li><strong>TubeSync / TubeArchivist [NAS]</strong>, download and archive YouTube content directly onto NAS storage; these run on docker-host-nas specifically because they need direct volume access to the Synology's disks.</li>
|
||||
<li><strong>Music Stretto</strong>, music streaming server for the local MP3 library on the Synology, accessible from the home dashboard.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Development tools</h2>
|
||||
<ul>
|
||||
<li><strong>Gitea</strong> — self-hosted Git server acting as a mirror of my GitHub repositories, giving me a local fallback and faster internal access.</li>
|
||||
<li><strong>Gitea</strong>, self-hosted Git server acting as a mirror of my GitHub repositories, giving me a local fallback and faster internal access.</li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "Homelab Infrastructure — Proxmox, Docker & Networking | moonweb"
|
||||
title: "Homelab Infrastructure, Proxmox, Docker & Networking | moonweb"
|
||||
section: "infra"
|
||||
tags: "infra"
|
||||
description: "Homelab infrastructure overview: Proxmox hosts, Synology NAS, Docker VMs and Setup-Guides."
|
||||
|
||||
+15
-15
@@ -9,36 +9,36 @@ layout: base.njk
|
||||
<h1>LXC Container Strategy</h1>
|
||||
<div class="detail-content">
|
||||
|
||||
<p>Alongside the Docker-based setup, I run a small number of Linux Containers (LXC) directly on the main Proxmox host (PVE). An LXC is an OS-level virtualization container — unlike a Docker container, which packages a single application and its dependencies, an LXC behaves like a full lightweight Linux system with its own init process, systemd services and package manager, but without the overhead of a full virtual machine. Proxmox manages LXCs natively as first-class citizens, right next to VMs, with their own snapshotting, backup and resource-limit tooling. I use far fewer LXCs than Docker containers, reserving them for cases where a persistent, OS-like environment or tight integration with Proxmox itself makes more sense than a containerized app.</p>
|
||||
<p>Alongside the Docker-based setup, I run a small number of Linux Containers (LXC) directly on the main Proxmox host (PVE). An LXC is an OS-level virtualization container, unlike a Docker container, which packages a single application and its dependencies, an LXC behaves like a full lightweight Linux system with its own init process, systemd services and package manager, but without the overhead of a full virtual machine. Proxmox manages LXCs natively as first-class citizens, right next to VMs, with their own snapshotting, backup and resource-limit tooling. I use far fewer LXCs than Docker containers, reserving them for cases where a persistent, OS-like environment or tight integration with Proxmox itself makes more sense than a containerized app.</p>
|
||||
|
||||
<h2>Why LXC instead of Docker here</h2>
|
||||
<ul>
|
||||
<li><strong>Native Proxmox integration</strong> — LXCs show up directly in the Proxmox UI with their own resource graphs, backup jobs and snapshots, without needing a Docker host VM in between.</li>
|
||||
<li><strong>Lower overhead than a VM</strong> — an LXC shares the host kernel, so it starts almost instantly and uses less RAM/CPU than a full Debian VM, while still feeling like a real, persistent Linux machine.</li>
|
||||
<li><strong>Better fit for system-level services</strong> — some services (like a DNS resolver or a database server) benefit from being a stable, always-on OS process with predictable networking, rather than an ephemeral, frequently-redeployed container.</li>
|
||||
<li><strong>Simplicity for infrequently-changed services</strong> — these three services rarely change their configuration, so the extra flexibility of Compose-based redeployment isn't needed; a straightforward apt-installed service is easier to reason about long-term.</li>
|
||||
<li><strong>Native Proxmox integration</strong>, LXCs show up directly in the Proxmox UI with their own resource graphs, backup jobs and snapshots, without needing a Docker host VM in between.</li>
|
||||
<li><strong>Lower overhead than a VM</strong>, an LXC shares the host kernel, so it starts almost instantly and uses less RAM/CPU than a full Debian VM, while still feeling like a real, persistent Linux machine.</li>
|
||||
<li><strong>Better fit for system-level services</strong>, some services (like a DNS resolver or a database server) benefit from being a stable, always-on OS process with predictable networking, rather than an ephemeral, frequently-redeployed container.</li>
|
||||
<li><strong>Simplicity for infrequently-changed services</strong>, these three services rarely change their configuration, so the extra flexibility of Compose-based redeployment isn't needed; a straightforward apt-installed service is easier to reason about long-term.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Pi-hole</h2>
|
||||
<ul>
|
||||
<li><strong>Purpose</strong> — network-wide DNS sinkhole and ad/tracker blocking for every device on the home network.</li>
|
||||
<li><strong>Why LXC</strong> — DNS resolution needs to be rock-solid and always reachable at a fixed IP; running it as a lean, dedicated LXC avoids depending on the Docker host VM being up, and keeps it isolated from Docker networking quirks that could interfere with DNS.</li>
|
||||
<li><strong>Advantage</strong> — near-zero overhead, boots in seconds after a Proxmox host reboot, and its stability is decoupled from whatever is happening on the Docker hosts.</li>
|
||||
<li><strong>Purpose</strong>, network-wide DNS sinkhole and ad/tracker blocking for every device on the home network.</li>
|
||||
<li><strong>Why LXC</strong>, DNS resolution needs to be rock-solid and always reachable at a fixed IP; running it as a lean, dedicated LXC avoids depending on the Docker host VM being up, and keeps it isolated from Docker networking quirks that could interfere with DNS.</li>
|
||||
<li><strong>Advantage</strong>, near-zero overhead, boots in seconds after a Proxmox host reboot, and its stability is decoupled from whatever is happening on the Docker hosts.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Ubuntu-Worker</h2>
|
||||
<ul>
|
||||
<li><strong>Purpose</strong> — a general-purpose Ubuntu LXC used as a flexible worker/utility machine for ad-hoc scripts, cron jobs and small maintenance tasks that don't warrant their own container image.</li>
|
||||
<li><strong>Why LXC</strong> — it needs to behave like a normal Linux box (full package manager, cron, shell access) rather than a single-purpose containerized app, which makes an LXC a much better fit than wrapping everything in Docker.</li>
|
||||
<li><strong>Advantage</strong> — quick to spin up, snapshot and roll back via Proxmox, and useful as a lightweight sandbox for testing shell scripts or automation before productionizing them elsewhere.</li>
|
||||
<li><strong>Purpose</strong>, a general-purpose Ubuntu LXC used as a flexible worker/utility machine for ad-hoc scripts, cron jobs and small maintenance tasks that don't warrant their own container image.</li>
|
||||
<li><strong>Why LXC</strong>, it needs to behave like a normal Linux box (full package manager, cron, shell access) rather than a single-purpose containerized app, which makes an LXC a much better fit than wrapping everything in Docker.</li>
|
||||
<li><strong>Advantage</strong>, quick to spin up, snapshot and roll back via Proxmox, and useful as a lightweight sandbox for testing shell scripts or automation before productionizing them elsewhere.</li>
|
||||
</ul>
|
||||
|
||||
<h2>MariaDB</h2>
|
||||
<ul>
|
||||
<li><strong>Purpose</strong> — central relational database instance, currently used by services such as nginx-proxy-manager, reachable over the network at a fixed internal IP.</li>
|
||||
<li><strong>Why LXC</strong> — a database benefits from direct, persistent disk access and predictable performance without the extra storage-driver indirection of Docker volumes; running it as an unprivileged LXC keeps it isolated while still feeling like a native MariaDB install.</li>
|
||||
<li><strong>Advantage</strong> — simple backup via <code>mysqldump</code>, straightforward remote access configuration (bind-address, dedicated service users per consuming application), and one central database that multiple Docker containers on other hosts can connect to over the network instead of each running their own database container.</li>
|
||||
<li><strong>Purpose</strong>, central relational database instance, currently used by services such as nginx-proxy-manager, reachable over the network at a fixed internal IP.</li>
|
||||
<li><strong>Why LXC</strong>, a database benefits from direct, persistent disk access and predictable performance without the extra storage-driver indirection of Docker volumes; running it as an unprivileged LXC keeps it isolated while still feeling like a native MariaDB install.</li>
|
||||
<li><strong>Advantage</strong>, simple backup via <code>mysqldump</code>, straightforward remote access configuration (bind-address, dedicated service users per consuming application), and one central database that multiple Docker containers on other hosts can connect to over the network instead of each running their own database container.</li>
|
||||
</ul>
|
||||
|
||||
<p class="redacted-note">All three LXCs run exclusively on the main Proxmox host (PVE), not on pve2 or the Synology — they're intentionally kept centralized since they're few in number and don't need the multi-host redundancy that the Docker setup has. IPs, credentials and specific VMIDs are omitted here; only the reasoning behind the LXC-vs-Docker choice is shown.</p>
|
||||
<p class="redacted-note">All three LXCs run exclusively on the main Proxmox host (PVE), not on pve2 or the Synology, they're intentionally kept centralized since they're few in number and don't need the multi-host redundancy that the Docker setup has. IPs, credentials and specific VMIDs are omitted here; only the reasoning behind the LXC-vs-Docker choice is shown.</p>
|
||||
</div>
|
||||
@@ -11,15 +11,15 @@ layout: base.njk
|
||||
|
||||
<p>Prometheus and Grafana form the central monitoring stack for the whole
|
||||
homelab, running as Docker containers on the NAS. Every machine in the
|
||||
flat — Proxmox host, Docker VM, Synology NAS, and Raspberry Pi devices —
|
||||
flat, Proxmox host, Docker VM, Synology NAS, and Raspberry Pi devices,
|
||||
feeds metrics into this central instance.</p>
|
||||
|
||||
<h2>What's monitored</h2>
|
||||
<ul>
|
||||
<li><strong>Proxmox host metrics</strong> — a PVE exporter reports node-level and per-VM/LXC CPU, memory, and disk metrics into a dedicated Grafana dashboard.</li>
|
||||
<li><strong>Host metrics everywhere</strong> — a node exporter runs on the NAS, the Docker host, and every Raspberry Pi, feeding basic CPU/RAM/disk/network stats.</li>
|
||||
<li><strong>Container metrics</strong> — cAdvisor runs on both the Docker host and the NAS, breaking down resource usage per container.</li>
|
||||
<li><strong>Network hardware via SNMP</strong> — an SNMP exporter polls a network-attached printer for toner level, page count, and status, proving the same pattern works for any SNMP-capable device.</li>
|
||||
<li><strong>Proxmox host metrics</strong>, a PVE exporter reports node-level and per-VM/LXC CPU, memory, and disk metrics into a dedicated Grafana dashboard.</li>
|
||||
<li><strong>Host metrics everywhere</strong>, a node exporter runs on the NAS, the Docker host, and every Raspberry Pi, feeding basic CPU/RAM/disk/network stats.</li>
|
||||
<li><strong>Container metrics</strong>, cAdvisor runs on both the Docker host and the NAS, breaking down resource usage per container.</li>
|
||||
<li><strong>Network hardware via SNMP</strong>, an SNMP exporter polls a network-attached printer for toner level, page count, and status, proving the same pattern works for any SNMP-capable device.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Dashboards</h2>
|
||||
@@ -50,7 +50,7 @@ temperature thresholds) are planned but not yet implemented.</p>
|
||||
<h2>Open items</h2>
|
||||
<ul>
|
||||
<li>Alerting rules are not yet configured for most services.</li>
|
||||
<li>The secondary (test) Proxmox host isn't monitored yet — it's usually powered off.</li>
|
||||
<li>The secondary (test) Proxmox host isn't monitored yet, it's usually powered off.</li>
|
||||
<li>Retention policy for Prometheus data hasn't been tuned.</li>
|
||||
<li>Monitoring data itself isn't currently backed up.</li>
|
||||
</ul>
|
||||
|
||||
@@ -9,13 +9,13 @@ layout: base.njk
|
||||
<h1>OpenWrt Multi-WAN Router</h1>
|
||||
<div class="detail-content">
|
||||
|
||||
<p>The study has historically suffered from unreliable network connectivity. To solve this, I set up an OpenWrt router that combines two WAN paths — WiFi and a dedicated Powerline link back to the server room — with automatic failover between them.</p>
|
||||
<p>The study has historically suffered from unreliable network connectivity. To solve this, I set up an OpenWrt router that combines two WAN paths, WiFi and a dedicated Powerline link back to the server room, with automatic failover between them.</p>
|
||||
|
||||
<h2>Multi-WAN setup</h2>
|
||||
<ul>
|
||||
<li><strong>WAN 1 — WiFi (802.11ac)</strong> — higher throughput but less stable, used for bulk transfers and general traffic.</li>
|
||||
<li><strong>WAN 2 — Powerline (Ethernet backhaul)</strong> — lower throughput but rock-solid, carries latency-sensitive traffic like VPN tunnels and Teams calls.</li>
|
||||
<li><strong>Failover</strong> — both paths are active simultaneously; if one drops, traffic automatically shifts to the remaining path. This provides redundancy in both directions.</li>
|
||||
<li><strong>WAN 1, WiFi (802.11ac)</strong>, higher throughput but less stable, used for bulk transfers and general traffic.</li>
|
||||
<li><strong>WAN 2, Powerline (Ethernet backhaul)</strong>, lower throughput but rock-solid, carries latency-sensitive traffic like VPN tunnels and Teams calls.</li>
|
||||
<li><strong>Failover</strong>, both paths are active simultaneously; if one drops, traffic automatically shifts to the remaining path. This provides redundancy in both directions.</li>
|
||||
</ul>
|
||||
|
||||
<p>Traffic is routed intelligently based on connection quality: VPN and real-time communication prefer the stable Powerline path, while everything else benefits from the higher WiFi throughput when available.</p>
|
||||
@@ -28,7 +28,7 @@ layout: base.njk
|
||||
</ul>
|
||||
|
||||
<h2>IoT VLAN 189</h2>
|
||||
<p>A dedicated, isolated network segment for IoT devices, running on a separate small WiFi access point on a different channel. This keeps smart home hardware — including the balcony sensors and light controller — off the main network while maintaining full connectivity to the homelab services.</p>
|
||||
<p>A dedicated, isolated network segment for IoT devices, running on a separate small WiFi access point on a different channel. This keeps smart home hardware, including the balcony sensors and light controller, off the main network while maintaining full connectivity to the homelab services.</p>
|
||||
<ul>
|
||||
<li><strong>VLAN ID:</strong> 189</li>
|
||||
<li><strong>Purpose:</strong> Isolate IoT/smart home devices from general network traffic.</li>
|
||||
|
||||
+16
-16
@@ -9,35 +9,35 @@ layout: base.njk
|
||||
<h1>Proxmox Virtualization</h1>
|
||||
<div class="detail-content">
|
||||
|
||||
<p>Proxmox VE (Virtual Environment) is a free, open-source virtualization platform that combines KVM-based full virtual machines with lightweight LXC containers in a single web-managed system. It's built on top of Debian, includes ZFS storage management, backup/restore, clustering and monitoring out of the box, and is the foundation my entire homelab runs on — both the <a href="/docker/">Docker</a> hosts and the standalone <a href="/lxc/">LXC services</a> live as guests on top of it.</p>
|
||||
<p>Proxmox VE (Virtual Environment) is a free, open-source virtualization platform that combines KVM-based full virtual machines with lightweight LXC containers in a single web-managed system. It's built on top of Debian, includes ZFS storage management, backup/restore, clustering and monitoring out of the box, and is the foundation my entire homelab runs on, both the <a href="/docker/">Docker</a> hosts and the standalone <a href="/lxc/">LXC services</a> live as guests on top of it.</p>
|
||||
|
||||
<h2>Hardware</h2>
|
||||
<ul>
|
||||
<li><strong>PVE (main server)</strong> — a Beelink Mini-PC, running as the primary Proxmox host. It has a 500GB SSD for VM and container storage, and connects to the network via the server-room Zyxel switch.</li>
|
||||
<li><strong>pve2 (test server)</strong> — a second Proxmox host, physically located in the study and connected via the OpenWRT-side Zyxel switch. It's dedicated purely to testing and development, running the third <a href="/docker/">Docker host VM (docker-host-pve2)</a> plus experimental setups without risking the production environment.</li>
|
||||
<li><strong>Backups</strong> — nightly VM backups from PVE run at 00:30 to an NFS share on the Synology (<code>nas:/volume1/backup</code>), with retention of the last 3 daily, 3 monthly and 1 yearly backup.</li>
|
||||
<li><strong>PVE (main server)</strong>, a Beelink Mini-PC, running as the primary Proxmox host. It has a 500GB SSD for VM and container storage, and connects to the network via the server-room Zyxel switch.</li>
|
||||
<li><strong>pve2 (test server)</strong>, a second Proxmox host, physically located in the study and connected via the OpenWRT-side Zyxel switch. It's dedicated purely to testing and development, running the third <a href="/docker/">Docker host VM (docker-host-pve2)</a> plus experimental setups without risking the production environment.</li>
|
||||
<li><strong>Backups</strong>, nightly VM backups from PVE run at 00:30 to an NFS share on the Synology (<code>nas:/volume1/backup</code>), with retention of the last 3 daily, 3 monthly and 1 yearly backup.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Advantages</h2>
|
||||
<ul>
|
||||
<li><strong>Mixed virtualization</strong> — full KVM virtual machines and lightweight LXC containers run side by side on the same host, so I can pick whichever fits a service best.</li>
|
||||
<li><strong>Web-based management</strong> — the entire cluster, its VMs, containers, storage and backups are managed from one browser UI via Authelia/Nginx, no separate tooling needed.</li>
|
||||
<li><strong>Built-in ZFS support</strong> — snapshots, checksumming and pool management are native, making disk setup and VM protection straightforward.</li>
|
||||
<li><strong>Native backup/restore</strong> — scheduled backups to an external NFS target are configured directly in Proxmox, without third-party backup software.</li>
|
||||
<li><strong>No licensing cost</strong> — the platform is fully usable without a subscription by switching to the no-subscription repository, which matters for a homelab that isn't running on enterprise support contracts.</li>
|
||||
<li><strong>Mixed virtualization</strong>, full KVM virtual machines and lightweight LXC containers run side by side on the same host, so I can pick whichever fits a service best.</li>
|
||||
<li><strong>Web-based management</strong>, the entire cluster, its VMs, containers, storage and backups are managed from one browser UI via Authelia/Nginx, no separate tooling needed.</li>
|
||||
<li><strong>Built-in ZFS support</strong>, snapshots, checksumming and pool management are native, making disk setup and VM protection straightforward.</li>
|
||||
<li><strong>Native backup/restore</strong>, scheduled backups to an external NFS target are configured directly in Proxmox, without third-party backup software.</li>
|
||||
<li><strong>No licensing cost</strong>, the platform is fully usable without a subscription by switching to the no-subscription repository, which matters for a homelab that isn't running on enterprise support contracts.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Open-source edition</h2>
|
||||
<ul>
|
||||
<li><strong>Proxmox VE Community/no-subscription</strong> — the enterprise repositories are disabled and the host is switched to the free "no-subscription" package repository, giving full functionality identical to the paid tiers minus vendor support and the enterprise-only repo.</li>
|
||||
<li><strong>License</strong> — Proxmox VE itself is open source (AGPLv3); the subscription only adds official support and access to the more conservative enterprise update channel.</li>
|
||||
<li><strong>Proxmox VE Community/no-subscription</strong>, the enterprise repositories are disabled and the host is switched to the free "no-subscription" package repository, giving full functionality identical to the paid tiers minus vendor support and the enterprise-only repo.</li>
|
||||
<li><strong>License</strong>, Proxmox VE itself is open source (AGPLv3); the subscription only adds official support and access to the more conservative enterprise update channel.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Setup process</h2>
|
||||
<ul>
|
||||
<li><strong>Bootstrap</strong> — on new Beelink hardware, an initial OS (Windows) needs to be cleared first; entering the BIOS (DEL key) to set the boot order to USB-first allows booting the Proxmox installer.</li>
|
||||
<li><strong>Base install</strong> — Proxmox VE installed directly from ISO, then updated after disabling the enterprise repo and enabling the no-subscription repo.</li>
|
||||
<li><strong>Storage</strong> — an additional SSD is partitioned (GPT via <code>parted</code>) and turned into a ZFS pool through the Disks → ZFS section of the web UI.</li>
|
||||
<li><strong>Networking/backup target</strong> — an NFS share from the Synology is mounted for backup storage, and a nightly backup job is scheduled per VM.</li>
|
||||
<li><strong>Guest creation</strong> — VMs (like the Debian Docker-host VMs) and LXCs (Pi-hole, Ubuntu-Worker, MariaDB) are created through the web UI, with ISO images uploaded to local storage beforehand.</li>
|
||||
<li><strong>Bootstrap</strong>, on new Beelink hardware, an initial OS (Windows) needs to be cleared first; entering the BIOS (DEL key) to set the boot order to USB-first allows booting the Proxmox installer.</li>
|
||||
<li><strong>Base install</strong>, Proxmox VE installed directly from ISO, then updated after disabling the enterprise repo and enabling the no-subscription repo.</li>
|
||||
<li><strong>Storage</strong>, an additional SSD is partitioned (GPT via <code>parted</code>) and turned into a ZFS pool through the Disks → ZFS section of the web UI.</li>
|
||||
<li><strong>Networking/backup target</strong>, an NFS share from the Synology is mounted for backup storage, and a nightly backup job is scheduled per VM.</li>
|
||||
<li><strong>Guest creation</strong>, VMs (like the Debian Docker-host VMs) and LXCs (Pi-hole, Ubuntu-Worker, MariaDB) are created through the web UI, with ISO images uploaded to local storage beforehand.</li>
|
||||
</ul>
|
||||
+10
-10
@@ -13,24 +13,24 @@ layout: base.njk
|
||||
|
||||
<h2>Storage</h2>
|
||||
<ul>
|
||||
<li><strong>Bays</strong> — 4 drive slots, populated with a mix of large-capacity HDDs rather than a single uniform set, which SHR was specifically chosen to support.</li>
|
||||
<li><strong>RAID type</strong> — SHR (Synology Hybrid RAID), giving single-drive fault tolerance while allowing disks of different sizes to be mixed and later upgraded one at a time without rebuilding the whole array from scratch.</li>
|
||||
<li><strong>Snapshots</strong> — Btrfs snapshot replication is used for file versioning instead of the classic recycle bin, taken hourly with a retention schedule of 7 days, 3 weeks, 3 months and 1 year.</li>
|
||||
<li><strong>Bays</strong>, 4 drive slots, populated with a mix of large-capacity HDDs rather than a single uniform set, which SHR was specifically chosen to support.</li>
|
||||
<li><strong>RAID type</strong>, SHR (Synology Hybrid RAID), giving single-drive fault tolerance while allowing disks of different sizes to be mixed and later upgraded one at a time without rebuilding the whole array from scratch.</li>
|
||||
<li><strong>Snapshots</strong>, Btrfs snapshot replication is used for file versioning instead of the classic recycle bin, taken hourly with a retention schedule of 7 days, 3 weeks, 3 months and 1 year.</li>
|
||||
</ul>
|
||||
|
||||
<h2>What runs on it today</h2>
|
||||
<ul>
|
||||
<li><strong>Docker host VM</strong> — a dedicated Debian VM (docker-host-nas) runs on the NAS's virtualization layer, hosting containers that specifically need direct access to NAS storage volumes.</li>
|
||||
<li><strong>File storage & backup target</strong> — the core role of the NAS remains classic network storage, plus acting as the backup destination for scheduled Proxmox VM backups from the rest of the homelab.</li>
|
||||
<li><strong>Legacy packages removed</strong> — unused DSM packages (like a web/photo/media package, an old drive-sync service and unused indexing) were uninstalled to reduce background load and disk writes.</li>
|
||||
<li><strong>Docker host VM</strong>, a dedicated Debian VM (docker-host-nas) runs on the NAS's virtualization layer, hosting containers that specifically need direct access to NAS storage volumes.</li>
|
||||
<li><strong>File storage & backup target</strong>, the core role of the NAS remains classic network storage, plus acting as the backup destination for scheduled Proxmox VM backups from the rest of the homelab.</li>
|
||||
<li><strong>Legacy packages removed</strong>, unused DSM packages (like a web/photo/media package, an old drive-sync service and unused indexing) were uninstalled to reduce background load and disk writes.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Main strengths</h2>
|
||||
<ul>
|
||||
<li><strong>Central storage hub</strong> — single source of truth for files and backups that every other host in the network (Proxmox VMs, exporters, workstations) can write to or read from.</li>
|
||||
<li><strong>Built-in snapshotting</strong> — Btrfs-based snapshots give point-in-time recovery without the overhead of a separate versioning package.</li>
|
||||
<li><strong>Flexible RAID</strong> — SHR allows disks to be swapped and capacity to grow over time without needing matched drive sizes from day one.</li>
|
||||
<li><strong>Lightweight virtualization</strong> — running a single purpose-built Docker VM on the NAS keeps storage-adjacent workloads close to the data, without turning the NAS itself into a general-purpose application server.</li>
|
||||
<li><strong>Central storage hub</strong>, single source of truth for files and backups that every other host in the network (Proxmox VMs, exporters, workstations) can write to or read from.</li>
|
||||
<li><strong>Built-in snapshotting</strong>, Btrfs-based snapshots give point-in-time recovery without the overhead of a separate versioning package.</li>
|
||||
<li><strong>Flexible RAID</strong>, SHR allows disks to be swapped and capacity to grow over time without needing matched drive sizes from day one.</li>
|
||||
<li><strong>Lightweight virtualization</strong>, running a single purpose-built Docker VM on the NAS keeps storage-adjacent workloads close to the data, without turning the NAS itself into a general-purpose application server.</li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
Reference in New Issue
Block a user