Merox

The Axios Supply Chain Attack

Wed, 01 Apr 2026 00:00:00 GMT

StepSecurity identified and published a full technical breakdown of a supply chain attack against axios on March 30. Malwarebytes picked it up the next day. I came across the Malwarebytes report first, then went back to read StepSecurity’s analysis — then checked whether this site is exposed. Axios is the most downloaded JavaScript HTTP client on npm, around 100 million weekly downloads.

What Happened

A compromised maintainer account was used to push two malicious axios versions to npm: axios@1.14.1 and axios@0.30.4. Neither version exists in the axios GitHub repository — no commits, no tags. The attack happened entirely at the npm registry level.

Both versions were live for under three hours on March 31 before npm took them down. The window was short, but exposure wasn’t limited to developers who explicitly installed axios — anyone who ran npm install with either version already in their package.json, or with a dependency that pulled axios transitively, got the poisoned package.

The injection was precise: the only difference between the clean and malicious releases was the addition of a single hidden dependency called plain-crypto-js — a package that doesn’t exist anywhere in the real axios source code. Its only job was to run a script at install time.

What the Attack Does

When you install the compromised axios, plain-crypto-js runs automatically as part of the install process. It contacts a command-and-control server (sfrclak.com) and downloads a Remote Access Trojan specific to your operating system — macOS, Windows, or Linux. After delivering the payload, the malicious script erases itself and replaces its own metadata with a clean-looking file to avoid detection.

Warning

This means running npm audit after the fact shows nothing suspicious. The evidence is gone. If the install happened, assume the machine is compromised.

The attack was also pre-planned: 18 hours before the poisoned axios versions went live, the attacker published a clean, innocent-looking version of plain-crypto-js to establish account history — specifically to avoid “brand new package” alarms from security scanners. The malicious version followed later that night, minutes before the axios releases.

Checking This Project

This site runs on Astro and doesn’t use axios. But “not in my package.json” isn’t enough — a dependency of a dependency can pull it in without you knowing. I ran four checks:

npm ls axios
# astro-erudite@1.6.3
# └── (empty)

grep -i "axios" package-lock.json
# (no output)

ls node_modules/plain-crypto-js
# NOT FOUND

ls -la /Library/Caches/com.apple.act.mond
# NOT FOUND

Axios isn’t present anywhere in the dependency tree or lockfile. The plain-crypto-js directory doesn’t exist. The macOS RAT artifact isn’t on this machine. I also ran npm audit — 5 moderate vulnerabilities unrelated to this incident, zero mentions of axios or plain-crypto-js.

That folder check matters more than the version number, because the malware replaces its own package.json with a clean decoy after running — so npm list will show 4.2.0 instead of the malicious 4.2.1. If the directory exists at all, the dropper ran.

What to Do If You Use Axios

Check which version you have installed. The affected versions are 1.14.1 and 0.30.4. If you’re on either, or if you ran any npm install on March 31 between 00:21 and 03:15 UTC with axios anywhere in your dependency tree, treat the machine as compromised.

The persistent files left behind by the RAT differ by platform:

macOS — /Library/Caches/com.apple.act.mond
Linux — /tmp/ld.py
Windows (persistent) — %PROGRAMDATA%\wt.exe
Windows (temp, self-deletes) — %TEMP%\6202033.vbs, %TEMP%\6202033.ps1

If any of those exist on a machine where axios was recently installed, rotate every credential that was accessible on that machine: npm tokens, SSH keys, cloud credentials, API keys, anything stored or loaded in the shell environment.

Warning

Don’t try to clean in place. Reformat and rebuild from a known-good state, then rotate secrets from a separate clean machine.

Indicators of Compromise

For incident response or detection tooling. If you use axios and ran npm install on March 31 between 00:21–03:15 UTC, these are the signals to check.

Packages — malicious vs safe

Package	Version	SHA1	Status
`axios`	`1.14.1`	`2553649f2322049666871cea80a5d0d6adc700ca`	malicious
`axios`	`0.30.4`	`d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71`	malicious
`plain-crypto-js`	`4.2.1`	`07d889e2dadce6f3910dcbc253317d28ca61c766`	malicious
`axios`	`1.14.0`	`7c29f4cf2ea91ef05018d5aa5399bf23ed3120eb`	safe

Network

C2 domain sfrclak.com · IP 142.11.206.73 · URL http://sfrclak.com:8000/6202033

POST body by OS: macOS → packages.npm.org/product0, Windows → product1, Linux → product2

File system artifacts

Platform	Path
macOS	`/Library/Caches/com.apple.act.mond`
Windows (persistent)	`%PROGRAMDATA%\wt.exe`
Windows (temp)	`%TEMP%\6202033.vbs`, `%TEMP%\6202033.ps1`
Linux	`/tmp/ld.py`

Broader sweep commands

# installs during attack window
grep -i "npm install" ~/.zsh_history | grep "2026-03-31"

# all lockfiles referencing malicious versions
find ~ -name "package-lock.json" -exec grep -l "1\.14\.1\|0\.30\.4" {} \;

# active C2 connection
lsof -i | grep sfrclak

Attacker accounts

jasonsaayman — compromised axios maintainer; email changed to ifstap@proton.me
nrwise — attacker-created (nrwise@proton.me); published plain-crypto-js

The Broader Takeaway

What made this attack harder to catch than most is the preparation. The attacker staged the malicious dependency nearly a day in advance to build a credible history. Both the modern 1.x and legacy 0.x release branches were hit within 39 minutes. And the payload self-destructs, so post-infection inspection looks clean.

The one signal that doesn’t lie is the npm registry metadata: every legitimate axios release is published through GitHub Actions with a verified OIDC token tied to a specific workflow run. The malicious versions were published manually with a stolen account token — no workflow link, no corresponding GitHub commit. That mismatch is checkable for any package before you trust a version.

Resources

Running OpenClaw as a Homelab Infrastructure Agent

Fri, 20 Mar 2026 00:00:00 GMT

At 2am when a pod crashes, I don’t want to open a laptop. I want to send a message on Telegram and get an answer.

A few weeks ago I wrote about deploying OpenClaw on Proxmox — that post was mostly exploratory, testing the install process and seeing how it behaves as a generalist assistant. What I actually wanted was to replace merox-agent — my custom Python bot that handles the actual infrastructure.

merox-agent worked fine. But maintaining a custom Telegram bot, FastAPI server, session management, and systemd service across server migrations gets old. This consolidates all of it into one thing.

What it does

Send a message, get a result:

what pods are down? → kubectl get pods -A, filtered
show traefik logs → last 50 lines
reconcile flux-system → flux reconcile, output back to you
how much disk is left? → df -h, memory, load
what changed in the infra repo? → git log
restart jellyfin → asks for confirmation, then does it

It responds in whatever language you write in.

Infrastructure status

Jellyfin logs

Confirmation before destructive ops

How it’s set up

1
Phone / Laptop
2
    │
3
    └── Telegram ──────────────────────► OpenClaw Gateway (loopback:18789)
4
                                                  │
5
                                         Tailscale Serve (tailnet)
6
                                                  │
7
                                        Claude API (Anthropic)
8
                                                  │
9
                                          infra skill (SKILL.md)
10
                                                  │
11
                               ┌──────────────────┴──────────────────┐
12
                           kubectl / flux                     docker / git

OpenClaw runs directly on the VPS. The Gateway binds to loopback only — no public port. Tailscale Serve exposes the Control UI on my tailnet. The Telegram bot connects directly to Telegram’s API.

This instance runs directly on the VPS with shell access to the infra. That’s it — single purpose, nothing else.

Prerequisites

A VPS with Ubuntu 22.04+
Tailscale on the server and your devices
Node.js 24 (22.16+ minimum)
An Anthropic API key
A Telegram bot token from @BotFather

Warning

OpenClaw uses the Anthropic API directly — not the Claude Code CLI OAuth flow that merox-agent used. You need a separate API key and pay per token. For a personal infra assistant with a few queries a day it’s around $1–3/month on claude-sonnet-4-6.

Setup

1. Install Node.js 24 + OpenClaw

curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt install -y nodejs
sudo npm install -g openclaw@latest

openclaw --version

2. Configure secrets

mkdir -p ~/.openclaw && chmod 700 ~/.openclaw

cat > ~/.openclaw/.env << 'EOF'
ANTHROPIC_API_KEY=sk-ant-...
TELEGRAM_BOT_TOKEN=123456:AAAA...
TELEGRAM_USER_ID=123456789
EOF

chmod 600 ~/.openclaw/.env

To find your Telegram user ID: start OpenClaw, send a message to your bot, check the gateway logs with journalctl -u openclaw-gateway -f and look for from.id.

3. Configure the Gateway

Create ~/.openclaw/openclaw.json:

1
{
2
  agents: {
3
    defaults: {
4
      model: {
5
        primary: "anthropic/claude-sonnet-4-6",
6
      },
7
      workspace: "/root/.openclaw/workspace",
8
    },
9
  },
10

11
  channels: {
12
    telegram: {
13
      botToken: "${TELEGRAM_BOT_TOKEN}",
14
      dmPolicy: "allowlist",
15
      allowFrom: ["${TELEGRAM_USER_ID}"],
16
    },
17
  },
18

19
  gateway: {
20
    bind: "loopback",
21
    auth: {
22
      mode: "token",
23
    },
24
    tailscale: {
25
      mode: "serve",
26
    },
27
  },
28
}

chmod 600 ~/.openclaw/openclaw.json

dmPolicy: "allowlist" with your numeric user ID means only you can talk to it. Same as the old TELEGRAM_USER_ID check in merox-agent.

4. Write the infra skill

Skills are Markdown files that tell the agent what it’s managing. This is the direct equivalent of prompt.py from merox-agent — same idea, different format.

Create ~/.openclaw/workspace/skills/infra/SKILL.md:

1
---
2
name: infra
3
description: Kubernetes and Docker infrastructure management for merox.dev homelab
4
---
5

6
You are an infrastructure assistant for merox.dev homelab.
7

8
## Kubernetes Cluster
9

10
Stack: Talos Linux nodes + FluxCD GitOps.
11
Manifests: /srv/kubernetes/infrastructure
12

13
Common operations:
14
- kubectl get nodes
15
- kubectl get pods -A
16
- flux check
17
- cd /srv/kubernetes/infrastructure && task reconcile
18

19
## VPS Docker Services
20

21
Managed via Ansible. Services: Traefik, Pi-hole, Portainer, Homepage, Netdata, Garage S3.
22
- cd /srv/kubernetes/infrastructure/cloudlab-infrastructure && make health-check
23
- make setup  # full redeploy, idempotent
24

25
## Rules
26

27
- Confirm before destructive operations (delete, reset, drain, rollout)
28
- Prefer GitOps over direct kubectl apply for persistent changes
29
- Check pod health before and after changes
30
- Never touch: age.key, *.sops.yaml, kubeconfig, .env files

Verify it loaded:

openclaw skills list | grep infra

The skill is versioned in the same git repo as the infra manifests it describes. Moving servers means copying one Markdown file.

5. Start as a system service

cat > /etc/systemd/system/openclaw-gateway.service << 'EOF'
[Unit]
Description=OpenClaw Gateway
After=network-online.target tailscaled.service
Wants=network-online.target

[Service]
Type=simple
User=root
EnvironmentFile=/root/.openclaw/.env
ExecStart=/usr/bin/openclaw gateway --port 18789
Restart=on-failure
RestartSec=5
WorkingDirectory=/root

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable openclaw-gateway
systemctl start openclaw-gateway

6. Security audit

openclaw security audit
openclaw doctor

For a single-user allowlist setup you should see 0 critical issues. Fix any warnings before leaving it running.

7. Tailscale Serve

Exposes the Control UI on your tailnet — not the public internet:

tailscale serve https / proxy 18789

Skills vs prompt.py

The old merox-agent had a prompt.py that built a system prompt injected into every Claude session. It hardcoded server IPs, service names, kubeconfig paths, and rules.

OpenClaw’s SKILL.md does the same thing. The difference: it’s a file you can edit without touching the agent, it’s hot-reloaded without a service restart, and it lives in git alongside the manifests it describes.

merox-agent vs OpenClaw

I used merox-agent for months and it worked. Here’s what actually changed:

Better:

No Telegram bot boilerplate to maintain (grammY session handling, polling, message editing)
Security model is explicit and auditable (openclaw security audit)
Active project with regular releases — someone else fixes the bugs

Worse:

Requires a separate Anthropic API key — merox-agent used Claude Code’s OAuth, included in Claude Pro. Real cost difference, worth knowing upfront
Heavier install (Node.js ecosystem) vs merox-agent’s handful of Python packages

Same:

Single tool for all infra ops (kubectl, docker, flux, git)
Tailscale for network isolation
Confirm before destructive ops

If you want zero extra API cost and don’t mind maintaining a custom bot, merox-agent is still valid. If you want something that survives server migrations without code changes, OpenClaw is worth the few dollars a month.

What to back up

Agent config template + skill → in infra git repo ✅
Gateway secrets → ~/.openclaw/.env ⚠️ back up manually
AGE key → /srv/kubernetes/infrastructure/age.key ⚠️ losing it = losing all SOPS secrets

Rebuilding from scratch: install openclaw, copy config from repo, restore .env, start service.

Config template and infra skill: github.com/meroxdotdev/infrastructure/agent/

Want to see how OpenClaw installs and behaves as a generalist assistant? See the Proxmox deployment guide.

Proxmox GPU Passthrough Guide

Fri, 06 Mar 2026 00:00:00 GMT

GPU passthrough lets you dedicate a physical GPU to a virtual machine with near-native performance — useful for gaming VMs, remote workstations, or AI inference inside an isolated environment.

What you need: a CPU with IOMMU support (Intel VT-d or AMD-Vi), a motherboard BIOS that exposes it, Proxmox VE 8.x, and ideally a secondary GPU for the Proxmox host. Intel integrated graphics on the host while passing a discrete GPU to the VM is the cleanest setup.

Step 1: Enable IOMMU

In BIOS/UEFI: Intel → enable VT-d. AMD → enable AMD-Vi or IOMMU.

Edit /etc/default/grub:

Intel:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"

AMD:

GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"

iommu=pt reduces overhead for devices not being passed through — leave it in regardless of vendor.

update-grub && reboot

Verify after reboot:

dmesg | grep -e DMAR -e IOMMU

Intel should show DMAR: IOMMU enabled, AMD shows AMD-Vi: Supported feature. Nothing means IOMMU isn’t active — go back to BIOS.

Also verify interrupt remapping is enabled — passthrough won’t work without it:

dmesg | grep 'remapping'

You should see AMD-Vi: Interrupt remapping enabled or DMAR-IR: Enabled IRQ remapping. If not, and your hardware doesn’t support it, you can allow unsafe interrupts as a workaround:

echo "options vfio_iommu_type1 allow_unsafe_interrupts=1" > /etc/modprobe.d/iommu_unsafe_interrupts.conf

Check IOMMU Groups

for d in /sys/kernel/iommu_groups/*/devices/*; do
    n=${d#*/iommu_groups/*}; n=${n%%/*}
    printf 'IOMMU Group %s ' "$n"
    lspci -nns "${d##*/}"
done

Your GPU and its audio device need to be in the same IOMMU group, ideally isolated. If they share a group with a SATA controller or USB hub, see ACS override in the troubleshooting section.

Step 2: Load VFIO Modules

Add to /etc/modules:

1
vfio
2
vfio_iommu_type1
3
vfio_pci
4
vfio_virqfd

update-initramfs -u -k all && reboot

Step 3: Bind the GPU to VFIO

Find your GPU’s PCI IDs:

lspci -nn | grep -iE "nvidia|amd|vga|3d"

Output example:

1
01:00.0 VGA compatible controller [0300]: NVIDIA GeForce RTX 3080 [10de:2206]
2
01:00.1 Audio device [0403]: NVIDIA HD Audio [10de:1aef]

Bind both the GPU and its audio device to VFIO:

echo "options vfio-pci ids=10de:2206,10de:1aef disable_vga=1" > /etc/modprobe.d/vfio.conf
update-initramfs -u -k all && reboot

Verify:

lspci -nnk -d 10de:2206

Look for Kernel driver in use: vfio-pci. If you see nvidia or nouveau instead, blacklist them:

echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
echo "blacklist nvidia*" >> /etc/modprobe.d/blacklist.conf
update-initramfs -u -k all && reboot

Step 4: Create the VM

In the Proxmox web UI, these settings matter:

Machine: q35 — required for PCIe passthrough
BIOS: OVMF (UEFI) — add an EFI disk when prompted
CPU type: host — don’t use kvm64 or default
Memory: disable ballooning, set a fixed amount
OS: for Windows, add the VirtIO drivers ISO as a second CD-ROM

Add the GPU

Hardware → Add → PCI Device, then check:

All Functions — passes GPU + audio together
Primary GPU — if this GPU handles the VM’s display output
PCI-Express — enables PCIe bandwidth
ROM-Bar — required for NVIDIA cards

Warning

If “Primary GPU” is checked, set vga: none in the VM config — otherwise the VM may boot to the virtual display instead of the GPU.

Step 5: NVIDIA — Fix Error 43

Note

NVIDIA drivers 465 and newer no longer trigger Error 43 in VMs. If you’re on a recent driver, skip this step. Only apply it if you’re on an older driver or still seeing the error.

Older consumer NVIDIA drivers detect virtualization and refuse to initialize. Hide the hypervisor by editing /etc/pve/qemu-server/[VMID].conf:

1
cpu: host,hidden=1
2
args: -cpu 'host,hv_vendor_id=NV43FIX,kvm=off'

hv_vendor_id can be any 12-character string. kvm=off hides the KVM signature from the driver.

For Windows VMs with NVIDIA GeForce Experience or other GPU software that crashes the VM, add:

echo "options kvm ignore_msrs=1 report_ignored_msrs=0" > /etc/modprobe.d/kvm.conf

Step 6: Tesla P40 for AI Workloads

The P40 is a datacenter card — 24GB GDDR5, no display output, pure compute. Around €100–150 used, it’s the best value-per-GB option for homelab AI workloads.

Key differences from gaming GPU passthrough:

No display output — don’t check “Primary GPU”; the VM uses VNC for management
No Error 43 workaround needed — datacenter drivers load cleanly in VMs
Passive cooling — no fan, relies on chassis airflow; in a desktop case point active airflow at the card
250W TDP — full-length, full-height; verify your slot and PSU

Warning

The P40 has 24GB VRAM. With OVMF, the default 32GB MMIO window isn’t enough and the driver will fail with a BAR0 error. Using CPU type host (already recommended in Step 4) fixes this automatically — OVMF adjusts the MMIO window based on host CPU info. If you use a different CPU type, run: qm set VMID --cpu x86-64-v2-AES,phys-bits=host,flags=+pdpe1gb

Install CUDA drivers inside the VM (Ubuntu 22.04):

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update && sudo apt install -y cuda-toolkit-12-4 nvidia-driver-550-server

Reboot and verify:

nvidia-smi
# Tesla P40 | 24576MiB | ...

Troubleshooting

Black Screen After VM Boot

GPU not bound to vfio-pci — confirm Kernel driver in use: vfio-pci with lspci -nnk
Machine type isn’t q35
“Primary GPU” checked but vga: none not set (or vice versa)
Wrong PCIe slot — some boards only expose IOMMU correctly on specific slots

Error 43 Still Showing

If the fix in Step 5 doesn’t work, check that you’re not mixing cpu: and args: across multiple lines — Proxmox only supports one args entry. Also try changing the hv_vendor_id string.

GPU Hangs After VM Shutdown (Reset Bug)

Some NVIDIA cards can’t complete a PCIe reset — the GPU hangs and the host needs a full reboot. Fix with vendor-reset:

apt install pve-headers-$(uname -r) build-essential git
git clone https://github.com/gnif/vendor-reset
cd vendor-reset && make && make install
echo "vendor-reset" >> /etc/modules
update-initramfs -u -k all && reboot

Bad IOMMU Groups

Warning

ACS override weakens IOMMU isolation. Use only if you understand the security implications.

Add to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub:

1
pcie_acs_override=downstream,multifunction

update-grub && reboot

Resources

Synology HyperBackup to Oracle Cloud

Mon, 02 Feb 2026 00:00:00 GMT

Oracle Cloud’s Always Free tier gives you 4 OCPUs, 24GB RAM, and 200GB block storage — enough for a solid off-site backup target at zero cost. Getting Synology HyperBackup to work with rsync over SSH has one non-obvious blocker: Oracle Cloud uses SSH config includes that override your main sshd_config, and HyperBackup needs password auth for initial setup.

Note

This guide assumes you already have an Oracle Cloud Always Free instance running Ubuntu and Tailscale configured. If you’re new to Tailscale, their homelab docs are a good starting point.

Ubuntu Server Setup

Install Packages and Create Backup User

sudo apt update
sudo apt install rsync openssh-server -y
sudo systemctl enable ssh
sudo systemctl start ssh

sudo useradd -m -s /bin/bash synology-backup
sudo passwd synology-backup

sudo mkdir -p /backup/synology
sudo chown synology-backup:synology-backup /backup/synology
sudo chmod 750 /backup/synology

df -h /

Fix Oracle Cloud SSH Configuration

This is the part most guides miss. Oracle Cloud places an override file in /etc/ssh/sshd_config.d/ that disables password auth regardless of what you set in the main config. Without fixing this, you’ll get:

synology-backup@100.72.22.38: Permission denied (publickey).

Check for override files:

ls -la /etc/ssh/sshd_config.d/
sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf

Change:

PasswordAuthentication no

to:

PasswordAuthentication yes

Also verify /etc/ssh/sshd_config has:

PasswordAuthentication yes
PubkeyAuthentication yes
KbdInteractiveAuthentication yes
UsePAM yes
PermitRootLogin no

sudo systemctl restart ssh

Verify the active config (not just the file):

sudo sshd -T | grep passwordauthentication
# Must show: passwordauthentication yes

If it still shows no, grep for any other overrides:

sudo grep -r "PasswordAuthentication" /etc/ssh/

Configure rsync Daemon

HyperBackup’s UI integrates better with rsync daemon mode than SSH-based rsync.

`rsyncd.conf`

1
uid = synology-backup
2
gid = synology-backup
3
use chroot = no
4
max connections = 10
5
pid file = /var/run/rsyncd.pid
6
log file = /var/log/rsyncd.log
7
timeout = 300
8

9
[synology_backup]
10
path = /backup/synology
11
comment = Synology HyperBackup Storage
12
read only = no
13
list = yes
14
auth users = synology-backup
15
secrets file = /etc/rsyncd.secrets
16
hosts allow = 100.0.0.0/8

hosts allow = 100.0.0.0/8 restricts access to Tailscale IPs only.

`rsyncd.secrets`

1
synology-backup:YOUR_STRONG_PASSWORD_HERE

sudo chmod 600 /etc/rsyncd.secrets
sudo chown root:root /etc/rsyncd.secrets

sudo systemctl enable rsync
sudo systemctl start rsync
sudo ss -tlnp | grep 873

Test from Synology

# List available modules
rsync synology-backup@100.72.22.38::
# Should show: synology_backup    Synology HyperBackup Storage

export RSYNC_PASSWORD='YOUR_PASSWORD'
rsync -avz --dry-run /volume1/homes/merox/ synology-backup@100.72.22.38::synology_backup/test/

Configure HyperBackup

Open HyperBackup → + → Folders and packages → rsync → rsync-compatible server.

Connection settings:

Server IP: your Tailscale IP (e.g. 100.72.22.38)
Port: 873
Transfer encryption: Disabled (Tailscale already encrypts at network level)
Username: synology-backup
Password: from /etc/rsyncd.secrets
Backup module: select synology_backup

Warning

When using rsync daemon on port 873, transfer encryption must be disabled. The encryption option attempts SSH, which doesn’t apply to port 873. Tailscale handles encryption at the network layer.

Backup settings:

Compress backup data: enabled
Schedule: daily at 2–3 AM
Integrity check: weekly
Client-side encryption: enabled — if someone gets access to your Oracle Cloud instance, they can’t read the backups without your encryption password

Rotation: Smart Recycle with 3–5 versions. With ~136GB free and smart rotation, 50–100GB of source data with multiple versions is comfortable.

Monitoring

# Backup size
du -sh /backup/synology/*

# Live during backup
watch -n 10 du -sh /backup/synology

# rsync logs
sudo tail -f /var/log/rsyncd.log

# Auth logs
sudo tail -f /var/log/auth.log | grep synology-backup

Netdata on the Oracle instance gives real-time disk I/O, Tailscale traffic, and storage trends at http://100.72.22.38:19999.

Troubleshooting

“Failed to connect to backup destination” — transfer encryption is enabled with rsync daemon. Disable it.

“Permission denied (publickey)” — Oracle’s SSH override is still blocking password auth. Run sudo sshd -T | grep passwordauthentication and check all files under /etc/ssh/sshd_config.d/.

Slow backup — the first run transfers everything and can take 8–24 hours for 100GB. Check whether Tailscale is using a relay instead of a direct connection with tailscale status. Enable compression in HyperBackup to reduce transfer size.

Running out of space:

du -h /backup/synology/ | sort -rh | head -20
df -h /

Reduce version retention or exclude large cache/temp folders from the backup task.

Security Hardening

After confirming everything works, migrate to SSH key auth:

On Synology:

ssh-keygen -t ed25519 -C "synology-hyperbackup"
cat ~/.ssh/id_ed25519.pub

On Ubuntu:

sudo su - synology-backup
mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys
# Paste Synology's public key
chmod 600 ~/.ssh/authorized_keys
exit

Then re-disable password auth:

sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf
# PasswordAuthentication no
sudo systemctl restart ssh

Firewall (if ufw enabled):

sudo ufw allow from 100.0.0.0/8 to any port 22
sudo ufw allow from 100.0.0.0/8 to any port 873

Keep the instance updated:

sudo apt update && sudo apt upgrade -y
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

Warning

If you enabled client-side encryption in HyperBackup, store the encryption password in a password manager. Without it, your backups are permanently unrecoverable.

Resources

Deploying OpenClaw on Proxmox

Sat, 31 Jan 2026 00:00:00 GMT

Update: February 2, 2026

The project has rebranded again to OpenClaw (from Moltbot/Clawdbot) to avoid trademark issues. Commands are now openclaw instead of clawdbot. The core functionality is the same, with 34+ security commits, new model support (KIMI K2.5, Xiaomi MiMo-V2-Flash), and new channels (Twitch, Google Chat). Old names are kept in searches for compatibility.

Warning

Security — read before deploying:

Exposed credentials: Bitdefender reported hundreds of misconfigured instances leaking API keys, OAuth tokens, and chat histories. Never expose the dashboard to the public internet. Use Tailscale or SSH tunnels.
Prompt injection: Attackers can exfiltrate emails or execute commands via crafted messages. Security researchers demonstrated extracting cryptocurrency private keys in under 5 minutes through email prompts. Recent updates harden this.
Shell access: Running an AI with local shell access is risky. Always deploy in an isolated Proxmox LXC or VM. Unprivileged LXC is preferred.
Moltbook: A critical database exposure on January 31, 2026 allowed anyone to hijack agents and steal API keys. Do not connect OpenClaw to Moltbook until you verify it’s properly secured.

OpenClaw is an AI agent that performs actions — clears inboxes, manages calendars, sends emails, creates tasks — and works through WhatsApp, Telegram, Slack, Twitch, and Google Chat. It’s different from a chatbot in that it actually does things rather than just answering questions.

I’m running it in an Ubuntu 22.04 LXC container on Proxmox with 4GB RAM and 2 CPU cores, which handles personal use fine. Heavier workloads or Ollama models will need 8GB+.

The Moltbook Security Incident

Danger

CRITICAL: Database Exposure (January 31, 2026)

404 Media reported that Moltbook’s entire database was exposed without authentication. Anyone could hijack any agent, access API keys and auth tokens, post content impersonating verified agents, and exfiltrate private config files. The Supabase database had no Row Level Security policies enabled — 770,000 agent records exposed.

The platform was taken offline to patch and force-reset all agent API keys.

Do not connect your OpenClaw instance to Moltbook until you’ve verified proper security measures are in place. If you do connect, use a dedicated instance with no access to sensitive credentials.

Beyond the breach, Moltbook introduces supply chain risks: researchers found skills containing active data exfiltration code, and prompt injection attacks can embed malicious instructions in posts that manipulate other agents. Thanks to persistent memory, payloads can be fragmented across multiple posts and assembled later.

Prerequisites

Proxmox with an Ubuntu 22.04 LXC or VM
An AI model provider: OpenAI API, Anthropic Claude API, or self-hosted Ollama (recommended for homelab — free and fully local)
Node.js 22+

Container Setup

Create an Ubuntu 22.04 LXC in Proxmox:

Disk: 20GB
CPU: 2 cores
Memory: 4096 MB
Network: Static IP recommended

Warning

LXC and systemd: There are known issues with systemd inside LXC — services not starting after reboot, permission errors, “Failed to connect to bus” in unprivileged containers. Fixes: enable nesting in container options; add lxc.cap.drop: sys_rawio for mount-related failures. For maximum compatibility, use a small VM instead — you trade some overhead for fewer surprises with daemons.

Install Node.js 22

apt update && apt upgrade -y
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
apt install -y nodejs
node -v   # should be v22.x
npm -v

Installing OpenClaw

Official Installer

curl -fsSL https://openclaw.ai/install.sh | bash

This installs OpenClaw globally via npm and makes the openclaw command available system-wide. For non-root installations:

curl -fsSL https://openclaw.ai/install-cli.sh | bash

After installation, the onboarding wizard starts automatically. If not:

openclaw onboard

OpenClaw also supports Docker, Ansible, Nix, and cloud platforms (Railway, Render, Northflank). See the official installation docs.

Configuration

The onboarding wizard covers:

Security warning — read and acknowledge
Onboarding mode — choose QuickStart
Model provider:
- OpenAI: OAuth (browser opens automatically)
- Anthropic: API key
- Ollama: self-hosted URL, e.g. http://your-ollama-server:11434
Channel setup:
- Telegram: bot token from @BotFather (/newbot)
- WhatsApp: QR code pairing
- Discord: bot token
- Slack: Socket Mode token
Skills and hooks — skip for now, configure later
Agent setup — configure your first agent in the TUI

Via Telegram

Message @BotFather, run /newbot, copy the token (format: 123456:ABC...), paste when prompted.

Starting OpenClaw

openclaw tui       # terminal UI (recommended)
openclaw dashboard # web UI
openclaw status    # check status

Config is stored in ~/.openclaw/openclaw.json. Logs in ~/.openclaw/logs/gateway.log.

Security Hardening

Given the attack surface, these steps are not optional for Proxmox deployments.

Network Isolation

Create a dedicated VLAN for OpenClaw in Proxmox. Container-level firewall rules:

# Allow outbound HTTPS and established connections
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -P OUTPUT DROP

# Block all inbound except from Proxmox host
iptables -A INPUT -s YOUR_PROXMOX_IP -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -P INPUT DROP

Unprivileged LXC

When creating the container in Proxmox, uncheck “Privileged container.” This maps container root to an unprivileged host UID.

Dashboard Access

Never expose the dashboard publicly. Use Tailscale in the container, an SSH tunnel (ssh -L 1455:localhost:1455 user@proxmox-host), or Nginx with HTTP basic auth behind a firewall.

Credential Management

export ANTHROPIC_API_KEY="your-key-here"
export OPENAI_API_KEY="your-key-here"
openclaw gateway start

Monitoring

tail -f ~/.openclaw/logs/gateway.log
grep -i "error\|unauthorized\|injection" ~/.openclaw/logs/gateway.log

Warning

CVE-2025-6514 (CVSS 9.6): OpenClaw deployments using mcp-remote are exposed to a command-injection RCE vulnerability. Ensure you’re running the latest version with security patches applied.

What You Can Actually Do

Email: “Clear my inbox of newsletters” / “Send an email to [person] about [topic]” / “What emails need my attention today?”

Calendar: “Schedule a meeting with [person] next Tuesday at 2 PM” / “What’s on my calendar this week?” / “Move my 3 PM meeting to tomorrow”

Tasks: “Create a task to review the quarterly report” / “What tasks are due this week?”

The main value is interacting through messaging apps you already use — no new interface to learn.

Troubleshooting

Gateway won’t start:

cat ~/.openclaw/logs/gateway.log
openclaw status
openclaw gateway restart

Telegram bot not responding:

Verify bot token
Message /start to your bot in Telegram
Confirm Gateway is running: openclaw status

OAuth issues (OpenAI):

Ensure browser can reach localhost:1455 for the callback
Paste the redirect URL manually if the callback fails

Container networking:

ping 8.8.8.8
curl http://your-ollama-server:11434/api/tags

LXC systemd issues: Enable nesting in Proxmox container options or switch to a VM.

Suspected prompt injection:

grep -E "rm -rf|curl.*sh|wget.*sh" ~/.openclaw/logs/gateway.log
openclaw skills list
# Reset API keys if compromised, then re-run onboarding

Limitations

API costs: OpenAI/Anthropic usage adds up. Set usage alerts or use Ollama for free local inference.
Privacy: External API calls still leave your homelab unless using Ollama.
Reliability: You’re responsible for uptime and troubleshooting.
Resource usage: Ollama models need significant RAM — 8GB+ for larger models.
Moltbook: Avoid until security is independently verified.

Resources

Introducing merox-erudite: My Customized Astro Blogging Theme

Fri, 05 Dec 2025 00:00:00 GMT

I started this blog on astro-erudite — a clean, minimal template. Over several months I kept adding things I needed: comments, analytics, schema markup. Eventually I had enough changes that it made more sense to publish it as a separate fork: merox-erudite.

Note

This theme was built with Cursor (AI-powered editor, paid subscription). I’m a System Administrator, not a professional developer.

Warning

Built out of passion with basic programming knowledge. It works for my use case but may contain bugs or suboptimal code. Use at your own discretion — issues and PRs welcome on GitHub.

The reason for a fork rather than contributing back: some features (AdSense) don’t fit the original theme’s minimal philosophy, and the scope of changes is too personal to be a reasonable upstream PR. astro-erudite stays minimal; merox-erudite is batteries-included.

What I Added

Giscus Comments — GitHub Discussions integration with lazy loading, Astro view transition support, and automatic dark/light theme sync. Optional: if not configured, the component doesn’t render. Requires a public GitHub repo with Discussions enabled.

Analytics — Google Analytics and Umami, both optional via environment variables:

PUBLIC_GOOGLE_ANALYTICS_ID=G-XXXXXXXXXX
PUBLIC_UMAMI_WEBSITE_ID=your-umami-id

SEO Schemas — Reusable FAQ Schema and HowTo Schema components for structured data and voice search.

Enhanced Homepage — Experience timeline, skills showcase with animated badges, and an updated hero section. The timeline is configured in src/pages/index.astro:

1
const experience: ExperienceItem[] = [
2
  {
3
    role: 'Your Role',
4
    company: 'Company Name',
5
    period: '2020 - Present',
6
    current: true,
7
    icon: 'lucide:briefcase',
8
    key: 'Your achievements and responsibilities'
9
  },
10
]

Design — Geist variable fonts, improved contrast and dark mode, better focus indicators for keyboard navigation.

Feature Comparison

Feature	astro-erudite	merox-erudite
Comments	❌	✅ Giscus (GitHub)
Analytics	❌	✅ GA & Umami
SEO Schemas	Basic	✅ FAQ & HowTo
Homepage	Standard	✅ Enhanced with timeline
Fonts	System	✅ Geist variable fonts
AdSense	❌	✅ Built-in component

Getting Started

Click “Use this template” on the merox-erudite repository

Clone and install:

git clone https://github.com/YOUR_USERNAME/YOUR_REPO_NAME.git
cd YOUR_REPO_NAME
npm install

Start dev server:
Terminal window
```
npm run dev
```
Available at http://localhost:1234
Update src/consts.ts with your site info
Configure optional features via environment variables

Warning

For the original theme’s architecture and design documentation, see the astro-erudite repository by @jktrn.

Deployment on Cloudflare Pages

Free tier, global CDN, automatic GitHub deploys, and straightforward environment variable management.

Build settings (auto-detected for Astro, but if needed):

Build command: npm run build
Output directory: dist
Node version: 20.x+

Environment variables — add in Cloudflare Dashboard → Settings → Environment Variables:

1
PUBLIC_GOOGLE_ANALYTICS_ID=G-XXXXXXXXXX
2
PUBLIC_UMAMI_WEBSITE_ID=your-umami-id
3

4
PUBLIC_GISCUS_REPO=username/repo
5
PUBLIC_GISCUS_REPO_ID=your-repo-id
6
PUBLIC_GISCUS_CATEGORY=Blog Comments
7
PUBLIC_GISCUS_CATEGORY_ID=your-category-id

Tip

Get your Giscus values from giscus.app after enabling Discussions on your repo.

Credits

astro-erudite by @jktrn — original design and architecture
Astro Micro by trevortylerlee — inspiration
Cursor — development tool

Migrating Longhorn Backup from MinIO to Garage

Mon, 27 Oct 2025 00:00:00 GMT

MinIO discontinued their Docker images and moved to a source-only distribution model, leaving many homelab installs running outdated versions with known CVEs. Garage is a self-hosted, S3-compatible distributed object storage service — lightweight, actively maintained, and a clean drop-in replacement for Longhorn backups.

Note

For restoring from Longhorn backups after this migration, see Restoring from Longhorn Backups. The process is identical regardless of whether you’re using MinIO or Garage.

Prerequisites: Ubuntu server with Docker and Docker Compose, Kubernetes cluster with Longhorn installed.

Setting Up Garage

Directory and Secrets

sudo mkdir -p /srv/docker/garage/{meta,data}
cd /srv/docker/garage

# Generate RPC secret
openssl rand -hex 32

# Generate admin token
openssl rand -hex 32

`garage.toml`

1
metadata_dir = "/var/lib/garage/meta"
2
data_dir = "/var/lib/garage/data"
3
db_engine = "lmdb"
4

5
replication_factor = 1
6

7
rpc_bind_addr = "0.0.0.0:3901"
8
rpc_public_addr = "127.0.0.1:3901"
9
rpc_secret = "YOUR_RPC_SECRET_HERE"
10

11
[s3_api]
12
s3_region = "us-east-1"
13
api_bind_addr = "0.0.0.0:3900"
14
root_domain = ".s3.garage"
15

16
[admin]
17
api_bind_addr = "0.0.0.0:3903"
18
admin_token = "YOUR_ADMIN_TOKEN_HERE"

Tip

replication_factor = 1 is fine for single-node. Use 3 for multi-node redundancy.

`docker-compose.yml`

1
version: "3"
2
services:
3
  garage:
4
    image: dxflrs/garage:v2.1.0
5
    container_name: garage
6
    network_mode: "host"
7
    restart: unless-stopped
8
    volumes:
9
      - ./garage.toml:/etc/garage.toml
10
      - ./meta:/var/lib/garage/meta
11
      - ./data:/var/lib/garage/data
12

13
  webui:
14
    image: khairul169/garage-webui:latest
15
    container_name: garage-webui
16
    restart: unless-stopped
17
    volumes:
18
      - ./garage.toml:/etc/garage.toml:ro
19
    environment:
20
      API_BASE_URL: "http://127.0.0.1:3903"
21
      S3_ENDPOINT_URL: "http://127.0.0.1:3900"
22
    network_mode: "host"

docker-compose up -d

Configure Storage

alias garage="docker exec -ti garage /garage"

garage node id

# Assign storage capacity
garage layout assign <node-id> -z default -c 100G

garage layout show
garage layout apply --version 1

# Create bucket and key
garage bucket create longhorn
garage key create longhorn-key
garage bucket allow longhorn --read --write --owner --key longhorn-key

# Note the Key ID and Secret key
garage key info longhorn-key --show-secret

Integrate with Longhorn

Kubernetes Secret

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: minio-secret
5
  namespace: longhorn-system
6
type: Opaque
7
stringData:
8
  AWS_ACCESS_KEY_ID: <Key-ID-from-garage>
9
  AWS_SECRET_ACCESS_KEY: <Secret-Key-from-garage>
10
  AWS_ENDPOINTS: http://<GARAGE_SERVER_IP>:3900
11
  AWS_REGION: us-east-1

kubectl apply -f minio-secret.yaml

HelmRelease Update

1
---
2
apiVersion: source.toolkit.fluxcd.io/v1
3
kind: HelmRepository
4
metadata:
5
  name: longhorn
6
  namespace: longhorn-system
7
spec:
8
  interval: 1h
9
  url: https://charts.longhorn.io
10
---
11
apiVersion: helm.toolkit.fluxcd.io/v2
12
kind: HelmRelease
13
metadata:
14
  name: longhorn
15
spec:
16
  interval: 1h
17
  chart:
18
    spec:
19
      chart: longhorn
20
      version: 1.10.0
21
      sourceRef:
22
        kind: HelmRepository
23
        name: longhorn
24
        namespace: longhorn-system
25
  values:
26
    defaultSettings:
27
      backupTarget: "s3://longhorn@us-east-1/"
28
      backupTargetCredentialSecret: "minio-secret"
29
      backupstorePollInterval: "300"

Warning

In Longhorn 1.10.0+, backup settings are under defaultSettings, not a separate defaultBackupStore section.

Verify

Access the Garage WebUI at http://<SERVER_IP>:3909. Then test a backup from Longhorn UI → Volume → Create Backup and confirm it appears in the longhorn bucket.

garage bucket list
garage bucket info longhorn

Troubleshooting

WebUI “Unknown Error” — confirm the [admin] section is in garage.toml and restart:

docker-compose restart
docker logs garage

Port 3903 connection refused:

netstat -tlnp | grep 3903

Longhorn can’t reach Garage:

kubectl run -it --rm debug --image=amazon/aws-cli --restart=Never -- \
  s3 ls s3://longhorn --endpoint-url http://<GARAGE_IP>:3900

Resources

SSH Hardening - Securing Your Linux Servers

Mon, 06 Oct 2025 00:00:00 GMT

The default SSH configuration on most distributions is functional but not production-safe. After managing Linux infrastructure for several years — and finding over 50,000 failed login attempts in a single day’s auth log early in my career — I apply the same hardening steps to every server I manage.

Warning

Never lock yourself out. Always test each change in a separate SSH session before closing your original connection.

Guide Structure

Key-Based Authentication — replace password auth with cryptographic keys
SSH Daemon Hardening — production-ready sshd_config
Two-Factor Authentication — TOTP on top of key auth
Host-Based Authentication — automated server-to-server trust
Security Monitoring — fail2ban, connection management, log analysis
Troubleshooting & Best Practices — common issues, compliance, maintenance

Restoring from Longhorn Backups

Thu, 11 Sep 2025 00:00:00 GMT

After redeploying my K8s cluster with Flux GitOps, I had a fresh cluster with all apps deployed but empty volumes — no configurations, no dashboards, no media metadata. Here’s the full process I used to restore 6 applications from Longhorn backups stored in MinIO.

What needed restoring:

Prometheus (45GB)
Loki (20GB)
Jellyfin (10GB)
Grafana (10GB)
qBittorrent (5GB)
Sonarr (5GB)

Prerequisites: kubectl access, Longhorn installed and connected to MinIO/S3, Longhorn UI accessible.

Step 1: Assess Current State

kubectl get deployments -A
kubectl get statefulsets -A
kubectl get pvc -A -o wide
kubectl get storageclass

Step 2: Scale Down Applications

Danger

Scale down everything before touching storage to prevent data corruption.

kubectl scale deployment jellyfin --replicas=0 -n default
kubectl scale deployment qbittorrent --replicas=0 -n default
kubectl scale deployment sonarr --replicas=0 -n default
kubectl scale deployment grafana --replicas=0 -n observability

kubectl scale statefulset loki --replicas=0 -n observability
kubectl scale statefulset prometheus-kube-prometheus-stack --replicas=0 -n observability
kubectl scale statefulset alertmanager-kube-prometheus-stack --replicas=0 -n observability

Wait for all pods to terminate before continuing.

Step 3: Delete Empty PVCs

kubectl delete pvc jellyfin -n default
kubectl delete pvc qbittorrent -n default
kubectl delete pvc sonarr -n default

kubectl delete pvc grafana -n observability
kubectl delete pvc storage-loki-0 -n observability
kubectl delete pvc prometheus-kube-prometheus-stack-db-prometheus-kube-prometheus-stack-0 -n observability

Step 4: Restore Backups via Longhorn UI

In the Longhorn UI, go to the Backup tab. For each backup, click the ⟲ restore button and configure:

Name: <app>-restored (e.g. jellyfin-restored)
Storage Class: longhorn
Access Mode: ReadWriteOnce

Repeat for all six applications.

Warning

Wait for all restore operations to complete before moving on. Monitor progress in the Longhorn UI.

Step 5: Create PersistentVolumes

For each restored volume, create a PV pointing to it. Adjust storage and volumeHandle per app:

1
# Repeat for each application
2
apiVersion: v1
3
kind: PersistentVolume
4
metadata:
5
  name: jellyfin-restored-pv
6
spec:
7
  capacity:
8
    storage: 10Gi
9
  accessModes:
10
    - ReadWriteOnce
11
  persistentVolumeReclaimPolicy: Retain
12
  storageClassName: longhorn
13
  csi:
14
    driver: driver.longhorn.io
15
    fsType: ext4
16
    volumeAttributes:
17
      numberOfReplicas: "3"
18
      staleReplicaTimeout: "30"
19
    volumeHandle: jellyfin-restored

Step 6: Create PersistentVolumeClaims

Bind each PVC to the specific PV using volumeName:

1
# Repeat for each application
2
apiVersion: v1
3
kind: PersistentVolumeClaim
4
metadata:
5
  name: jellyfin
6
  namespace: default
7
spec:
8
  accessModes:
9
    - ReadWriteOnce
10
  resources:
11
    requests:
12
      storage: 10Gi
13
  storageClassName: longhorn
14
  volumeName: jellyfin-restored-pv

Step 7: Verify Binding

kubectl get pvc -n default | grep -E "(jellyfin|qbittorrent|sonarr)"
kubectl get pvc -n observability | grep -E "(grafana|storage-loki|prometheus)"
kubectl get volumes -n longhorn-system | grep "restored"

All PVCs should show Bound and Longhorn volumes should show attached and healthy.

Step 8: Scale Applications Back Up

kubectl scale deployment jellyfin --replicas=1 -n default
kubectl scale deployment qbittorrent --replicas=1 -n default
kubectl scale deployment sonarr --replicas=1 -n default
kubectl scale deployment grafana --replicas=1 -n observability

kubectl scale statefulset loki --replicas=1 -n observability
kubectl scale statefulset prometheus-kube-prometheus-stack --replicas=1 -n observability
kubectl scale statefulset alertmanager-kube-prometheus-stack --replicas=1 -n observability

Step 9: Verify

kubectl get pods -A | grep -v Running | grep -v Completed
kubectl get volumes -n longhorn-system | grep "restored"
kubectl get pods -n default -o wide
kubectl get pods -n observability -o wide

Alternative: CLI Restore via CRD

If the UI isn’t available or you want to automate:

1
apiVersion: longhorn.io/v1beta1
2
kind: Volume
3
metadata:
4
  name: jellyfin-restored
5
  namespace: longhorn-system
6
spec:
7
  size: "10737418240"
8
  restoreVolumeRecurringJob: false
9
  fromBackup: "s3://your-minio-bucket/backups/backup-name"

The full process for 6 applications took about 30 minutes.

Update (October 2025)

Since writing this, I’ve migrated backup storage from MinIO to Garage after MinIO discontinued their Docker images. The restoration process above works identically with Garage as the backend. See Migrating Longhorn Backup from MinIO to Garage for details.

Inside My Homelab - 2026

Wed, 02 Jul 2025 00:00:00 GMT

Live Infrastructure State

ai synced

Hardware

Compute

Device	CPU	RAM	Storage	Purpose
Beelink GTi 13	i9-13900H (14C/20T)	64GB DDR5	2× 2TB NVMe	Proxmox (px-0)
OptiPlex #1	i5-6500T (4C/4T)	32GB DDR4	128GB NVMe	Proxmox (px-1)
OptiPlex #2	i5-6500T (4C/4T)	32GB DDR4	128GB NVMe	Proxmox (px-2)
Dell R720	2× E5-2697v2 (24C/48T)	192GB ECC	4× 960GB SSD	Power Testing
Synology DS223+	ARM RTD1619B	2GB	2× 2TB RAID1	NAS/Media

Network Gear

Device	Model	Specs	Purpose
ONT	Huawei	1GbE	ISP Gateway
Firewall	XCY X44	8× 1GbE	pfSense Router
WiFi	TP-Link AX3000	WiFi 6	Wireless AP
Switch	TP-Link	24-port	Core Switch

Power Protection

Device	Model	Protected Equipment	Capacity
UPS #1	CyberPower	Mini PCs (Proxmox cluster)	1500VA
UPS #2	CyberPower	Network gear	1000VA

Cloud

Provider	Instance	Specs	Location	Purpose
Oracle	Ampere A1	4vCPU/24GB/200GB (~98GB free)	USA	Docker Services + OpenClaw Agent

Network

Three dedicated physical interfaces on pfSense:

1
WAN Interface → Orange ISP (Bridge Mode)
2
LAN Interface → Homelab Network
3
WiFi Interface → Guest/IoT Isolation

Warning

WiFi clients are firewalled from homelab services, except whitelisted ones like Jellyfin.

Tailscale creates a flat network across all locations — homelab and Oracle both appear on the same mesh.

pfSense

A fanless mini PC from AliExpress (~200€) running pfSense for 3+ years: 👉 XCY X44 on AliExpress

Tailscale Subnet Router exposes the entire homelab to cloud VPS without installing Tailscale on every device. Also the solution to CGNAT — when your ISP doesn’t give you a public IP, this gets you in. Setup guide →

Unbound DNS runs as a local recursive resolver with domain overrides for *.k8s.merox.dev pointing to K8s-Gateway.

Telegraf pushes system metrics to Grafana.

Firewall rules: WiFi → LAN blocks everything except whitelisted apps; LAN → WAN allows all; WAN → Internal blocks all except explicitly exposed services.

Tip

The Oracle instance doubles as a Tailscale exit node, useful for routing traffic through the US when needed.

Virtualization

Proxmox Cluster

Three-node cluster across the mini PCs. Each node runs one Talos VM, so Kubernetes has HA across physical hosts with no single point of failure.

Nodes:

Node	Device	CPU	RAM	Role
px-0	Beelink GTi 13	i9-13900H (20T)	64GB	Primary — hosts K8s controlplane-1
px-1	OptiPlex #1	i5-6500T (4T)	32GB	K8s controlplane-2
px-2	OptiPlex #2	i5-6500T (4T)	32GB	K8s controlplane-3

Storage:

Pool	Type	Used	Total
cluster-storage	ZFS	713GB	899GB
synology-nas	NFS	985GB	1.4TB
local-data	dir	177GB	812GB

Current VMs:

VM	Purpose	Specs	Status
kubernetes-controlplane-1	K8s node (px-0)	8vCPU/24GB	Running
kubernetes-controlplane-2	K8s node (px-1)	4vCPU/16GB	Running
kubernetes-controlplane-3	K8s node (px-2)	4vCPU/16GB	Running
Windows 10	Lab / testing	4vCPU/12GB	Stopped
Windows Server 2019	AD Lab	8vCPU/14GB	Stopped
Windows 11	Remote desktop	8vCPU/16GB	Stopped

Note

Home Assistant, Kali Linux, and GNS3 are backed up to Synology NAS — restored on demand when needed, not kept running permanently.

Intel Iris Xe GPU on px-0 is passed through to the kubernetes-controlplane-1 VM for Jellyfin hardware transcoding (Intel QuickSync).

Synology DS223+

Dual purpose: NFS/SMB shares for the ARR stack (still experimenting with both protocols), and personal cloud via Synology Drive.

After 3 years of self-hosting Nextcloud, I switched. Better performance, native mobile apps that actually work, and zero maintenance. Sometimes the best self-hosted solution is the one you never have to think about.

Dell R720

The power-hungry workhorse. Its role has changed a few times:

Period	Purpose	Configuration
Phase 1	Proxmox hypervisor	24C/48T, 192GB RAM
Phase 2	AI Playground	Quadro P2200 + Ollama + Open WebUI
Phase 3	Backup Target	4× 960GB RAID-Z2, Garage S3 backend
Current	Power Testing	Occasional boots to measure idle/load consumption

The most interesting project was flashing the PERC controller to IT mode — bypasses hardware RAID so the OS sees drives directly. Fohdeesha’s crossflash guide covers H710/H310 and more.

At ~200W idle, running 24/7 costs ~€20/month in electricity. Right now it’s off most of the time — I boot it occasionally to benchmark power usage and figure out if there’s any workload that justifies keeping it on. Still undecided.

Power Management

The CyberPower UPS covers all mini PCs and network gear. When power fails, it triggers a cascading shutdown — Kubernetes nodes drain properly before Proxmox hosts go down.

Feature	Implementation	Purpose
pwrstat	USB to GTi13 Pro	Automated shutdown orchestration
SSH Scripts	Custom automation	Graceful cluster shutdown
Monitoring	Telegram alerts	Real-time power notifications

Kubernetes

Fair warning: this is where I went full “because I can” mode. If you just want to run services, Docker is the right answer. But if you want to learn enterprise-grade container orchestration in your homelab, keep reading.

The starting point: onedr0p/cluster-template

Talos OS was the first immutable, declarative OS I’d run. After a few days of troubleshooting, I was sold.

Tip

Why Talos over K3s? Immutable OS means less maintenance, GitOps-first design, declarative everything, and it’s closer to what you’d run in production.

My infrastructure repo: 👉 github.com/meroxdotdev/infrastructure

Key customizations:

Component	Modification	Reason
Storage	Longhorn CSI	Simpler PV/PVC management
Talos Patches	Custom machine config	Longhorn requirements
Custom Image	factory.talos.dev	Intel iGPU + iSCSI support

GitOps structure:

1
kubernetes/apps/
2
├── cert-manager/     # TLS automation
3
├── default/          # Production workloads
4
├── flux-system/      # Flux operator + instance
5
├── kube-system/      # Cilium, CoreDNS, NFS CSI, metrics-server
6
├── network/          # k8s-gateway, Cloudflare tunnel + DNS
7
├── observability/    # Prometheus, Grafana, Loki
8
└── storage/          # Longhorn configuration

Deployed apps:

App	Purpose	Notes
Radarr	Movie automation	NFS to Synology
Sonarr	TV automation	NFS to Synology
Prowlarr	Indexer manager	Central search
qBittorrent	Torrent client	Gluetun sidecar + SurfShark WireGuard VPN
Jellyseerr	Request management	Public via Cloudflare
Jellyfin	Media server	Intel QuickSync enabled
n8n	Workflow automation
Homepage	Dashboard
Grafana	Metrics dashboards
Prometheus + Alertmanager	Metrics collection + alerts
Loki + Promtail	Log aggregation
Netdata	Per-node system monitoring	DaemonSet — one agent per K8s node
cert-manager	TLS certificate automation	ACME via Let’s Encrypt

The live dashboard is public — current service status at inside.merox.dev.

LoadBalancer IPs are handled by Cilium’s L2 announcement — a pool of addresses (10.57.57.100–120) announced directly on the LAN via ARP, no external load balancer needed. Services like qBittorrent, k8s-gateway, and the Cloudflare tunnel endpoint each get a dedicated IP from this pool.

With this setup I can fully rebuild the cluster in 8–9 minutes — declarative config for everything, GitOps workflow with Flux, Renovate bot keeping dependencies updated.

Warning

Keep your SOPS keys backed up separately. You’ll need them to decrypt the repository when rebuilding from scratch.

For cluster deployment details, the onedr0p/cluster-template README is surprisingly well written and worth following directly.

Services

Managed through a single Portainer instance at cloud.merox.dev:

cloud-usa (Oracle Free Tier Ampere A1) — the only cloud node. Always-on, handles external access, backup target via rsync, and runs the OpenClaw infrastructure agent:

Service	Purpose
Traefik	SSL for all VPS services
Pi-hole	Dedicated Tailscale split-DNS
Portainer	Container management
Homepage	Dashboard
Guacamole	Remote access via Cloudflare Tunnel
Uptime Kuma	Service uptime monitoring
Glances	System resource monitoring
Joplin Server	Self-hosted notes sync
OpenClaw	AI infrastructure agent (Telegram → kubectl/flux/docker)
Garage S3 + WebUI	S3-compatible object storage for Longhorn backups
Rsync endpoint	Off-site backup target from Synology NAS

homelab-ro (local Docker) — lightweight services on the local Docker host:

Service	Purpose
Netboot.xyz	PXE / network boot
Portainer Agent	Remote Docker management

Note

Netdata runs as a Kubernetes DaemonSet — one child agent per node, one parent for aggregation — not as a standalone Docker container.

Tip

Full OpenClaw setup: Running OpenClaw as a Homelab Infrastructure Agent.

Backup

Longhorn PVCs → Garage S3 on Oracle Cloud (S3-compatible backup)
Synology NAS → rsync to Oracle Cloud instance (off-site copy)

1
Kubernetes PVCs
2
      │
3
      ▼
4
Garage S3 (Oracle Cloud VPS, 200GB disk)   ◄── Synology NAS rsync

Garage runs on the Oracle VPS’s single 200GB boot disk — currently ~28GB used by Garage data, ~98GB free total. Not a lot of headroom, but more than enough for compressed PVC snapshots at this scale.

MinIO was the original S3 backend until it discontinued its Docker images and moved to a source-only model with known CVEs on older builds. Garage replaced it — lightweight, S3-compatible, runs fine on the Oracle free tier. Full migration walkthrough: Migrating Longhorn Backup from MinIO to Garage.

The R720’s backup role has been retired entirely — Garage on Oracle handles Longhorn backups, Synology handles local redundancy (2× 2TB RAID1) and rsyncs off-site to the same VPS. Simpler than spinning up a 200W server for weekly sync jobs. For full details on the backup chain and recovery procedures, see Safeguarding My Critical Data.

SMB Authentication with AD on Linux

Sun, 01 Jun 2025 00:00:00 GMT

After days of configuration and research, I couldn’t find a single source that covered everything needed for this setup end to end. My job requires centralized SSSD across all Linux servers, so here’s what I got working on both RHEL 8 and OpenSUSE 15.6.

The stack: Samba for SMB/CIFS, SSSD for AD integration, Kerberos for authentication, and realmd for domain join.

What you need before starting: DNS resolving your domain controllers, NTP/Chrony running and synced, a domain admin account with join privileges, and the following info on hand — domain name (company.com), DC hostname (dc1.company.com).

Step 1: Package Installation

RHEL/CentOS/Rocky Linux

sudo dnf install -y realmd sssd oddjob oddjob-mkhomedir adcli \
    samba-common-tools krb5-workstation chrony samba samba-client \
    cifs-utils policycoreutils-python-utils

sudo systemctl enable --now chronyd
sudo systemctl enable sssd

Ubuntu/Debian

sudo apt update
sudo apt install -y realmd sssd sssd-tools libnss-sss libpam-sss \
    adcli samba-common-bin krb5-user chrony samba smbclient \
    cifs-utils

sudo systemctl enable --now chrony
sudo systemctl enable sssd

OpenSUSE Leap / Tumbleweed

sudo zypper install -y realmd sssd sssd-ad adcli \
    samba krb5-client chrony samba-client cifs-utils

sudo systemctl enable --now chronyd
sudo systemctl enable sssd

Note

SSSD is only enabled here, not started — it has no configuration yet. realm join (Step 4) will create the initial sssd.conf and start the service automatically.

Note

Ubuntu and OpenSUSE use AppArmor, not SELinux. The policycoreutils-python-utils package and semanage/restorecon commands throughout this guide are RHEL/CentOS-specific. Skip them on Debian-based and OpenSUSE systems.

Step 2: DNS and Time

`/etc/resolv.conf`

1
nameserver 192.168.1.10
2
nameserver 192.168.1.11
3
search company.com
4
domain company.com

Verify:

dig company.com
dig _ldap._tcp.company.com SRV

`/etc/chrony.conf`

1
server dc1.company.com iburst prefer
2
server dc2.company.com iburst

# RHEL/CentOS/OpenSUSE
sudo systemctl restart chronyd
# Ubuntu/Debian
sudo systemctl restart chrony

chronyc sources -v
timedatectl status

Note

Kerberos requires time to be within 5 minutes of the domain controllers. If clock skew exceeds this, authentication will fail with KRB5KRB_AP_ERR_SKEW.

Step 3: Kerberos Configuration

`/etc/krb5.conf`

1
[libdefaults]
2
    default_realm = COMPANY.COM
3
    dns_lookup_kdc = true
4
    dns_lookup_realm = false
5
    rdns = false
6
    ticket_lifetime = 24h
7
    renew_lifetime = 7d
8
    forwardable = true
9
    udp_preference_limit = 0
10

11
[realms]
12
    COMPANY.COM = {
13
        kdc = dc1.company.com
14
        admin_server = dc1.company.com
15
        default_domain = company.com
16
    }
17

18
[domain_realm]
19
    .company.com = COMPANY.COM
20
    company.com = COMPANY.COM
21

22
[logging]
23
    default = SYSLOG:NOTICE:DAEMON

Test it:

kinit administrator@COMPANY.COM
klist
kdestroy

Step 4: Domain Join

sudo realm discover company.com

sudo realm join company.com -U administrator \
    --client-software=sssd \
    --membership-software=samba

sudo realm list
net ads testjoin

Note

realm join --membership-software=samba calls net ads join internally — no need to run it again. It auto-configures /etc/sssd/sssd.conf, /etc/krb5.conf, and /etc/krb5.keytab. The custom sssd.conf in Step 6 intentionally replaces what realm join generated with a production-ready configuration.

Step 5: PAM Configuration

RHEL/CentOS/Rocky Linux

sudo authselect select sssd with-mkhomedir --force
sudo systemctl enable --now oddjobd

OpenSUSE

sudo pam-config --add --sss
sudo pam-config --add --mkhomedir

Ubuntu/Debian

pam-auth-update handles this automatically when libpam-sss is installed. No manual steps needed.

Step 6: SSSD Configuration

`/etc/sssd/sssd.conf`

1
[sssd]
2
enable_files_domain = true
3
domains = company.com
4
config_file_version = 2
5
services = nss, pam
6

7
[domain/local]
8
id_provider = files
9

10
[domain/company.com]
11
ad_domain = company.com
12
krb5_realm = COMPANY.COM
13
realmd_tags = manages-system joined-with-samba
14
cache_credentials = True
15
id_provider = ad
16
ad_update_samba_machine_account_password = True
17

18
full_name_format = %3$s\%1$s
19
use_fully_qualified_names = False
20
fallback_homedir = /home/%u
21
default_shell = /bin/bash
22

23
# Requires POSIX attributes (uidNumber, gidNumber) set in AD
24
ldap_id_mapping = False
25

26
krb5_store_password_if_offline = True
27

28
access_provider = simple
29
simple_allow_groups = linuxadmins@company.com, itstaff@company.com
30
simple_allow_users = testuser@company.com
31

32
enumerate = False

sudo chmod 600 /etc/sssd/sssd.conf
sudo systemctl restart sssd
sudo systemctl enable sssd

Note

ldap_id_mapping = False requires that all AD users and groups have POSIX attributes (uidNumber, gidNumber) configured in Active Directory. If they don’t, user lookups will fail silently. Set to True to let SSSD generate consistent IDs algorithmically instead.

Step 7: NSS Configuration

`/etc/nsswitch.conf`

1
passwd:     files sss
2
group:      files sss
3
shadow:     files sss
4
netgroup:   sss files

Note

Do not add winbind to passwd or group here. In this setup, SSSD handles all NSS resolution. Winbind runs only as an internal Samba component for ID mapping via the sss backend. Mixing sss and winbind in nsswitch causes duplicate lookups and inconsistent results.

Step 8: Samba Configuration

`/etc/samba/smb.conf`

1
[global]
2
    realm = COMPANY.COM
3
    workgroup = COMPANY
4
    security = ads
5

6
    kerberos method = secrets and keytab
7
    dedicated keytab file = /etc/krb5.keytab
8

9
    log file = /var/log/samba/log.%m
10
    log level = 2
11

12
    vfs objects = acl_xattr
13
    map acl inherit = yes
14
    store dos attributes = yes
15

16
    template homedir = /home/%U
17
    template shell = /bin/bash
18

19
    idmap config * : backend = tdb
20
    idmap config * : range = 10000-199999
21
    idmap config COMPANY : range = 200000-2147483647
22
    idmap config COMPANY : backend = sss
23

24
    client signing = mandatory
25
    server signing = mandatory
26

27
    socket options = TCP_NODELAY IPTOS_LOWDELAY
28

29
[shared]
30
    path = /srv/shared
31
    read only = no
32
    browsable = yes
33
    valid users = @linuxadmins, @itstaff
34
    force group = linuxadmins
35
    create mask = 0664
36
    directory mask = 0775
37

38
[data]
39
    path = /srv/data
40
    read only = no
41
    browsable = yes
42
    valid users = @dataaccess
43
    force group = dataaccess
44
    create mask = 0660
45
    directory mask = 0770
46

47
[homes]
48
    comment = Home Directories
49
    valid users = %S
50
    browsable = no
51
    read only = no
52
    create mask = 0700
53
    directory mask = 0700

Note

idmap config COMPANY : backend = sss tells Samba’s winbind to delegate ID mapping to SSSD for the COMPANY domain. The default tdb backend handles the * (fallback) range. The sss backend is read-only, so a writable fallback is required.

Note

Group names in valid users must match how SSSD exposes them. With use_fully_qualified_names = False, groups resolve as linuxadmins — not linuxadmins@company.com. Using the FQDN form here will silently block all access.

Validate the configuration before starting services:

sudo testparm -s

sudo mkdir -p /srv/shared /srv/data

sudo chgrp linuxadmins /srv/shared
sudo chmod 775 /srv/shared
sudo chgrp dataaccess /srv/data
sudo chmod 770 /srv/data

# SELinux (RHEL/CentOS only)
sudo setsebool -P samba_export_all_ro=1 samba_export_all_rw=1
sudo setsebool -P use_samba_home_dirs=on
sudo setsebool -P samba_enable_home_dirs=on
sudo semanage fcontext -a -t samba_share_t "/srv/shared(/.*)?"
sudo semanage fcontext -a -t samba_share_t "/srv/data(/.*)?"
sudo restorecon -R /srv/shared /srv/data

Step 9: Start Services and Test

RHEL/CentOS/Rocky Linux / OpenSUSE

sudo systemctl enable --now smb winbind
sudo systemctl status smb winbind

Ubuntu/Debian

sudo systemctl enable --now smbd winbind
sudo systemctl status smbd winbind

Verify user and group resolution

getent passwd testuser@company.com
id testuser@company.com
getent group linuxadmins@company.com

# List shares
smbclient -L localhost -U testuser@company.com

# Test share access
smbclient //localhost/shared -U testuser@company.com

From a Windows client: \\linux-server\shared

Step 10: Firewall

RHEL/CentOS/Rocky Linux / OpenSUSE

# The samba service already includes ports 137/udp, 138/udp, 139/tcp, 445/tcp
sudo firewall-cmd --permanent --add-service=samba
sudo firewall-cmd --reload

Ubuntu/Debian

sudo ufw allow samba
sudo ufw status

Step 11: Troubleshooting

Cache

sudo sss_cache -E
sudo systemctl restart sssd

sudo net cache flush

# If TDB corruption suspected
sudo systemctl stop smb winbind   # or smbd on Ubuntu
sudo rm -f /var/lib/samba/*.tdb
sudo systemctl start winbind smb  # or smbd on Ubuntu

Logs

sudo tail -f /var/log/sssd/sssd_company.com.log
sudo tail -f /var/log/samba/log.smbd

For deeper SSSD debugging, add debug_level = 9 in the [domain/company.com] section and restart sssd.

AD Connectivity and Auth

sudo net ads info
sudo net ads user info testuser
sudo net ads group info "linuxadmins"
klist -k /etc/krb5.keytab

# Winbind checks
sudo wbinfo -t        # verify trust secret
sudo wbinfo -n "COMPANY\testuser"  # resolve a specific user (safe)
# Avoid wbinfo -u / wbinfo -g in large AD environments — enumerates all
# domain users/groups and can cause significant load on domain controllers

# Active connections
sudo smbstatus

Common Errors

NT_STATUS_ACCESS_DENIED:

id username@company.com
sudo testparm -s
ls -Z /srv/shared  # SELinux context (RHEL only)

Users not resolving:

sudo sss_cache -E
sudo systemctl restart sssd winbind
getent passwd username@company.com

Authentication failures:

klist
kinit username@COMPANY.COM
chronyc sources -v
net ads testjoin

Maintenance Script

sudo nano /usr/local/bin/samba-maintenance.sh

#!/bin/bash
# SSSD manages machine account password rotation automatically via
# ad_update_samba_machine_account_password = True — do not run
# net ads changetrustpw here as it conflicts with SSSD's management.
sss_cache -E
tdbbackup /var/lib/samba/*.tdb 2>/dev/null || true
net ads testjoin
echo "Maintenance completed: $(date)"

sudo chmod +x /usr/local/bin/samba-maintenance.sh

# Weekly cron
echo "0 2 * * 0 /usr/local/bin/samba-maintenance.sh >> /var/log/samba-maintenance.log 2>&1" | sudo crontab -

Networking Specialist: My CCNA Journey

Fri, 02 May 2025 00:00:00 GMT

My path from IT basics to becoming a certified networking professional through dedication, hands-on practice, and perseverance.

From my first IT job to wanting to progress further didn’t take long. I knew I had relatively solid Linux fundamentals at that time for my first position, but I didn’t want to stay comfortable and let it become a boring routine. I started researching what knowledge I needed to become a complete sysadmin or even advance beyond that. That’s when I realized my networking foundation wasn’t quite zero, but weak enough that I didn’t even know what a VLAN was.

Tip

Tip: When planning your IT career path, don’t just focus on what you already know, identify your knowledge gaps and address them strategically.

Finding the Right Learning Path

So I began planning my networking development path, looking for courses both online on platforms like Udemy and at vocational schools in my city that offered specialization courses up to CCNP level. If you’re from Timișoara, I recommend checking out their website: https://savnet.ro/

After completing an introductory networking course on Udemy, I called the team at Savnet, who nicely explained their curriculum, including physical labs - which convinced me immediately. The fact that I could work on industrial network equipment (routers, switches, firewalls) had me asking “Can we start today? :))”

My CCNA Learning Evolution

Module 1: Starting with Packet Tracer

From there to building my first homelab versions was just a small step. Initially, I installed Cisco Packet Tracer and started doing all the exercises I received in Savnet’s lab plus homework assignments. I was so hyped that by the end of module 1, I was rushing to finish my exercises and personal troubleshooting sessions so I could help other students with their problems - probably one of the best ways to approach real IT troubleshooting scenarios.

Module 2-3: Advancing to GNS3

During that period, my schedule was something like: 10 AM - 6 PM at my first job (which I wrote about here), and three times a week from 7 PM to 10 PM I attended CCNA labs. Even that wasn’t enough for me - I had already developed a true passion. That’s when I discovered GNS3, a complete emulator where I could use real router and switch images, as well as virtual machines and even Docker containers. That was the moment when my weekends started focusing largely on extensive practice in the virtual lab I created on my laptop.

Module 4: Complex Network Projects

Starting from module 3, we received much more complex projects that we had to complete at home and verify during labs with one of our instructors.

Network Topologies & Lab Work

The exams at Savnet were challenging practical exercises, often more complex than the standard NetAcad curriculum to better prepare us. But my passion for networking extended beyond coursework - I spent countless hours building my own topologies and experimenting with different network configurations.

Lab Gallery

Certification Day

After months of labs, theory, and various tests, the time came to schedule the actual certification exam. I’ve never been more nervous for any exam - I knew how important this certification had become for me. February 18, 2020, shortly before the COVID pandemic put the world on pause.

Tip

I passed it on my first attempt! I had never felt such joy about an exam. The exam time was approximately 3 hours, containing both theoretical parts and labs with troubleshooting. I was so focused, engaged, and well-prepared that I remember submitting the final answers in about an hour and a half to learn my result.

I could certainly have done better, but I never excel in theory as much as I do in practice. It was enough - it was the moment I’d been waiting for.

The biggest bonus for my work during this period wasn’t just the certification, but the job offered to me shortly after in the Cybersecurity field - Blue team, through a recommendation from one of my former professors from CCNA module four. I’ll tell you about that job in a future blog post in this series.

Key Takeaways from My CCNA Journey

Essential Learning Points

Start with fundamentals - Even if you think you know networking, solidify the basics!
Combine learning formats - Online courses, structured programs, and hands-on labs reinforce each other
Build your own lab - Virtual environments like GNS3 or Packet Tracer accelerate learning
Help others - Troubleshooting others’ problems prepares you for real-world scenarios
Certification pays off - The CCNA opened the door to my cybersecurity career

Are you considering pursuing your CCNA? Do you have questions about the certification process or how to prepare? Let me know in the comments!

Dual Boot Guide: Windows 11 and Ubuntu 25.04

Mon, 14 Apr 2025 00:00:00 GMT

What you need: a machine with Windows 11 installed, at least 30GB of free space (50GB+ is more comfortable), an 8GB+ USB drive, and about 30–45 minutes.

Part 1: Prepare Windows

Back Up Your Data

Before touching partitions, back up anything important — Windows Backup, external drive, cloud, whatever works for you.

Check UEFI or Legacy BIOS

Press Win + R, type msinfo32, Enter. Look for “BIOS Mode” under System Summary. UEFI is the modern standard; most machines from the last decade use it.

Shrink the Windows Partition

Press Win + X → Disk Management. Right-click your C: drive → Shrink Volume. Enter the amount to shrink in MB — 30000 minimum, 50000 is comfortable, 100000 if you’re doing serious dev work. Click Shrink.

If you want to free up space first, run cleanmgr and clean up Windows Update files before shrinking.

Disable Fast Startup

Control Panel → Power Options → Choose what the power buttons do → Change settings that are currently unavailable → uncheck Turn on fast startup → Save.

Disable BitLocker (If Enabled)

manage-bde -status
manage-bde -off C:

Wait for decryption to complete before continuing.

Part 2: Create Ubuntu Installation Media

Download Ubuntu 25.04 from releases.ubuntu.com/plucky.

Verify the ISO

Get-FileHash -Algorithm SHA256 -Path path\to\ubuntu-25.04-desktop-amd64.iso

Compare the hash against the SHA256SUMS file on the download page.

Write to USB with Rufus

Download Rufus, select your USB drive, select the ISO, set partition scheme to GPT for UEFI systems, click START → Write in ISO Image mode.

Alternatively, Ventoy lets you copy multiple ISOs to one USB without re-flashing.

Part 3: Install Ubuntu

BIOS/UEFI Settings

Restart and enter BIOS (F2, F12, Del, or Esc depending on your board). Disable Secure Boot temporarily, set SATA to AHCI if using SSD, disable Intel RST if present, set USB as first boot device. Save and exit.

Boot and Install

Boot from USB, select Try or Install Ubuntu, choose your language and keyboard, connect to WiFi if needed.

Beginner: select Install Ubuntu alongside Windows Boot Manager and let the installer handle partitioning.

Manual partitioning (select Something else): in the unallocated space, create an EFI partition (512MB, EFI System Partition — skip if one already exists), a root partition (20–30GB, ext4, mount point /), a swap partition (equal to your RAM if you want hibernation), and a home partition (remaining space, ext4, mount point /home).

Confirm changes, set your timezone, create your user account, and wait 10–15 minutes for the installation to finish. Remove USB when prompted and restart.

Part 4: Post-Installation

Updates and Essentials

sudo apt update && sudo apt upgrade -y
sudo apt install ubuntu-restricted-extras

NVIDIA Drivers

sudo ubuntu-drivers autoinstall

Fix Time Sync

Windows and Linux handle hardware clock differently. Run this in Ubuntu to prevent time conflicts:

timedatectl set-local-rtc 1 --adjust-system-clock

Post-Install Script

#!/bin/bash

# Update system
sudo apt update && sudo apt upgrade -y

# Install essential software
sudo apt install -y ubuntu-restricted-extras vlc gimp libreoffice timeshift gnome-tweaks

# Fix time synchronization
timedatectl set-local-rtc 1 --adjust-system-clock

# Optimize SSD if present
if [ -d "/sys/block/nvme0n1" ] || [ -d "/sys/block/sda" ]; then
  sudo apt install -y util-linux
  sudo systemctl enable fstrim.timer
fi

# Improve battery life
sudo apt install -y tlp tlp-rdw
sudo systemctl enable tlp

# Set up auto-cleaning
echo 'APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";' | sudo tee /etc/apt/apt.conf.d/20auto-upgrades

# Performance improvements
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

# Check and repair GRUB if needed
sudo update-grub

echo "Setup complete! Reboot for changes to take effect."

chmod +x dual-boot-setup.sh
./dual-boot-setup.sh

Part 5: Managing the Dual-Boot System

Accessing Windows Files from Ubuntu

Your Windows drive shows up in the Ubuntu file manager sidebar. For write access to NTFS:

sudo apt install ntfs-3g

Accessing Ubuntu Files from Windows

Use \\wsl$\Ubuntu\home\yourusername in File Explorer after installing WSL2, or install Paragon Linux File Systems for Windows.

Change Default Boot OS

Edit GRUB:

sudo nano /etc/default/grub

Change GRUB_DEFAULT=0 to your preferred entry number, set GRUB_TIMEOUT=10 if you want more time to choose, then:

sudo update-grub

Or use the graphical tool:

sudo apt install grub-customizer

System Snapshots with Timeshift

sudo apt install timeshift
sudo timeshift --create --comments "Fresh Ubuntu installation"

Part 6: Troubleshooting

sudo os-prober
sudo update-grub

Ubuntu Won’t Boot After Windows Update

Windows updates can overwrite GRUB. Boot from the Ubuntu USB in “Try Ubuntu” mode, then:

sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt update
sudo apt install boot-repair
boot-repair

Select “Recommended repair”.

Secure Boot Issues

Disable Secure Boot in UEFI, boot into Ubuntu, then:

sudo apt install sbsigntool
sudo update-secureboot-policy

Restore Windows Bootloader

Boot from Windows installation media → Repair your computer → Troubleshoot → Advanced Options → Command Prompt:

1
bootrec /fixmbr
2
bootrec /fixboot
3
bootrec /rebuildbcd

Removing an OS

Remove Ubuntu, Keep Windows

Boot into Windows → Disk Management → delete Ubuntu partitions → expand Windows partition → repair Windows boot with installation media.

Remove Windows, Keep Ubuntu

sudo apt install gparted
sudo gparted

Delete Windows partitions, expand Ubuntu as needed, then:

sudo update-grub

From WordPress to Hugo: My Setup Explained

Mon, 07 Apr 2025 00:00:00 GMT

Note

UPDATE (November 2025): Since writing this post, I’ve migrated from Hugo to Astro with the Erudite theme. The principles here still apply — static sites are still the right call for content-focused websites.

Ten years of WordPress taught me enough to know when to leave. You start tweaking PHP configs, switching to LiteSpeed, juggling plugin updates — and for what? A blog. WordPress makes sense for e-commerce maybe, but for a simple content site it’s just overhead. Every plugin is another attack surface, and the DB adds a bottleneck you don’t need.

Known vulnerabilities tracked at wpscan.com.

Hugo

merox.dev has been running on Hugo for over six months. Static files, no backend, free hosting on GitHub Pages, everything version-controlled. Hugo is written in Go so builds are fast, and the output is clean enough that SEO scores came in above 80% without any extra work.

I went with the Blowfish theme. To track upstream updates without breaking my customizations, I forked it and added it as a submodule:

git submodule add https://github.com/YOURUSERNAME/blowfish themes/blowfish

The only real downside to Hugo is that you need to be comfortable in a terminal and working with Markdown. There’s no dashboard.

GitHub Pages + Cloudflare

Push Hugo project to a private repo
Enable GitHub Pages on a public repo (branch: gh-pages, folder: /)
In Cloudflare, add a CNAME for www.yourdomain.com → yourusername.github.io and A records for GitHub Pages IPs if needed
Add a CNAME file to your repo:

1
merox.dev

Automated Deploys with GitHub Actions

My workflow: edit in VS Code → push to private repo → GitHub Actions builds and deploys to the public repo.

Private → Public Deploy via RSA

Since I keep the source in a private repo, I wire the two together with an SSH deploy key:

Generate the key pair:

ssh-keygen -t rsa -b 4096 -C "github-deploy" -f deploy_key -N ""

Public repo: Settings → Deploy Keys → add deploy_key.pub with write access
Private repo: Settings → Secrets → add PRIVATE_KEY with the private key contents
.github/workflows/deploy.yml:

1
name: github pages
2

3
on:
4
  push:
5
    branches:
6
      - master
7

8
permissions:
9
  contents: write
10
  id-token: write
11

12
jobs:
13
  deploy:
14
    runs-on: ubuntu-22.04
15
    steps:
16
      - uses: actions/checkout@v4
17
        with:
18
          submodules: true
19
          fetch-depth: 0
20

21
      - name: Setup Hugo
22
        uses: peaceiris/actions-hugo@v3
23
        with:
24
          hugo-version: 'latest'
25
          extended: true
26

27
      - name: Build
28
        run: hugo --minify
29

30
      - name: Deploy
31
        uses: peaceiris/actions-gh-pages@v3
32
        with:
33
          deploy_key: ${{ secrets.PRIVATE_KEY }}
34
          external_repository: meroxdotdev/merox.dev
35
          publish_branch: gh-pages
36
          publish_dir: ./public

SEO Results

No extra configuration — Hugo’s clean output just scores well out of the box.

From freetools.seobility.net and seositecheckup.com

Inside Google's Offices

Mon, 17 Mar 2025 00:00:00 GMT

Source: Google Warsaw HUB Reception Image. The image is external, as I forgot to take a photo of the reception myself.

Here’s an inside look at their workspace, from panoramic views to relaxation zones.

A Business Trip Turned Into a Tech Adventure

My trip to Warsaw originally revolved around discussions on the design of HPC (High-Performance Computing) infrastructure at my company. However, it also turned into an exciting experience when a friend working at Google invited me to visit their Warsaw HUB offices. This was an opportunity I couldn’t pass up!

Google’s Expansion in Warsaw

Google has heavily invested in Poland, establishing Google Cloud’s first Central and Eastern European region in Warsaw. The Google Warsaw HUB spans 14 floors of the Warsaw HUB skyscraper complex, reinforcing the city’s status as a key tech hub in Europe. (source)

Stepping Into Google’s Office

Upon arrival, I received a guest badge, which allowed me to move freely within designated areas.

The Elevators: More Than Just Transportation

The elevator hall was eye-catching, illuminated in Google’s signature colors. Inside the elevator, a screen displayed the building’s floor plan, showing which Google departments were located at each level.

The Coffee Corner: A Relaxing Break Area

One of the standout spaces was the Coffee corner, a relaxed environment where employees could grab free snacks and drinks. The space even had mixing stations with DJ equipment!

The Restaurant: A Missed Opportunity

Google provides free meals for employees and, on some occasions, even for visitors. Unfortunately, by the time I got there, the restaurant had closed for the day.

The View from the 30th Floor

Reaching the 30th floor, I was greeted by an incredible panoramic view of Warsaw’s skyline, highlighting the city’s technological district.

Work and Play: Unique Office Amenities

Google’s focus on employee well-being was evident throughout the office. Among the highlights:

Power nap rooms for quick relaxation
Gaming rooms featuring both modern and retro games
A fully-equipped gym on the top floor, available to all employees

Conclusion: A Workplace Designed for Productivity and Comfort

Visiting Google’s Warsaw HUB was an eye-opening experience. The combination of cutting-edge technology, modern workspace design, and thoughtful employee perks made it clear why Google is considered one of the best places to work.

Special Thanks

I’d like to express my gratitude to Dorian Verna for making this visit possible and showing me around Google’s impressive workspace.

3-2-1 Backup Strategy for Your Homelab

Sat, 01 Mar 2025 00:00:00 GMT

Data Loss is catastrophic whether you’re running a homelab or managing production infrastructure. The 3-2-1 rule is the simplest framework that covers most failure scenarios.

The 3-2-1 Rule

3 copies of your data
2 different storage media/locations
1 offsite copy

In practice for a homelab: your original data + a local backup (NAS, backup server) + one copy somewhere geographically separate (cloud VPS, object storage, StorageBox).

Common Mistakes

The ones that make backups useless when disaster strikes:

Never testing restores — a backup you haven’t restored from is a backup you don’t actually have
Storing backups on the same system as the data
No encryption on backup data
No versioning — ransomware encrypts your “backup” too if it’s just a live mirror
No offsite copy — a house fire takes out everything local

Danger

Modern ransomware actively targets and encrypts backup files. Without versioning or an air-gapped copy, recovery is impossible.

Mitigations worth implementing: snapshot protection with retention policies, at least one offline or air-gapped copy, MFA on backup systems, alerting on backup job failures.

A Typical Homelab 3-2-1 Stack

Layer	Example	Purpose
Primary	Proxmox + Longhorn / local disks	Working data
Local backup	Synology NAS / Proxmox Backup Server	Fast local restore
Offsite	Cloud VPS, Hetzner StorageBox, S3-compatible storage	Geographic redundancy

The specific tools don’t matter much — what matters is that the three copies exist, are tested, and the offsite one is encrypted.

Proxmox Backup Server Scripts

If you’re running PBS, these scripts handle the backup and restore flow from any Linux host.

Backup to PBS

#!/bin/bash

export PBS_PASSWORD='token-secret-from-PBS'
export PBS_USER_STRING='token-id-from-PBS'
export PBS_SERVER='PBS-IP'
export PBS_DATASTORE='DATASTORE_PBS'
export PBS_REPOSITORY="${PBS_USER_STRING}@${PBS_SERVER}:${PBS_DATASTORE}"
export PBS_HOSTNAME="$(hostname -s)"
export PBS_KEYFILE='/root/pbscloud_key.json'

echo "Running PBS backup for $PBS_HOSTNAME ..."

proxmox-backup-client backup \
  srv.pxar:/srv \
  volumes.pxar:/var/lib/docker/volumes \
  etc.pxar:/etc \
  scripts.pxar:/usr/local/bin \
  --keyfile "$PBS_KEYFILE" \
  --skip-lost-and-found \
  --repository "$PBS_REPOSITORY"

proxmox-backup-client list --repository "$PBS_REPOSITORY"
echo "Done."

Restore from PBS

#!/bin/bash

export PBS_PASSWORD='token-secret-from-PBS'
export PBS_USER_STRING='token-id-from-PBS'
export PBS_SERVER='PBS_IP'
export PBS_DATASTORE='DATASTORE_FROM_PBS'
export PBS_KEYFILE='/root/pbscloud_key.json'
export PBS_REPOSITORY="${PBS_USER_STRING}@${PBS_SERVER}:${PBS_DATASTORE}"

SNAPSHOT_PATH="$1"
ARCHIVE_NAME="$2"
RESTORE_DEST="$3"

if [[ -z "$SNAPSHOT_PATH" || -z "$ARCHIVE_NAME" || -z "$RESTORE_DEST" ]]; then
  echo "Usage: $0 <snapshot_path> <archive_name> <destination>"
  echo "Example: $0 \"host/cloud/2025-01-22T15:19:17Z\" srv.pxar /root/restore-srv"
  exit 1
fi

mkdir -p "$RESTORE_DEST"

echo "=== PBS Restore ==="
echo "Snapshot:    $SNAPSHOT_PATH"
echo "Archive:     $ARCHIVE_NAME"
echo "Destination: $RESTORE_DEST"
echo "==================="

proxmox-backup-client restore \
  "$SNAPSHOT_PATH" \
  "$ARCHIVE_NAME" \
  "$RESTORE_DEST" \
  --repository "$PBS_REPOSITORY" \
  --keyfile "$PBS_KEYFILE"

[[ $? -eq 0 ]] && echo "Restore completed." || echo "Restore failed (exit $?)."

Note

For restoring Longhorn PVC backups specifically, see Restoring from Longhorn Backups.

Disaster Recovery Scenarios

Local NAS failure

Data still exists on your backup server and offsite copy. Replace hardware, reconfigure RAID, restore from whichever copy is accessible, verify the next scheduled job completes.

Offsite target failure

Provision a new instance, redeploy the backup client, restore your encryption key from your password manager, re-run the backup script to verify connectivity, confirm the cron job is active.

Backup server failure

Reinstall the backup server software, restore the datastore config and mount point, confirm the datastore directory structure is intact (.chunks, backup namespaces), then pull data from whichever surviving copy is closest — local NAS or offsite.

What to Keep in Your Password Manager

When disaster strikes you’ll need these immediately:

Encryption key file (e.g. pbscloud_key.json)
PBS/backup system token credentials
Backup directory paths for each layer
Cron job definitions to rebuild automation from scratch

Maintenance

Monthly: integrity check on a random subset of files, review backup logs for silent failures. Quarterly: full test restore of at least one backup, document how long it took.

Real-time: alert on any backup job failure and on storage capacity thresholds — running out of space is the most common way a backup silently stops working.

How to Set Up a K3S Cluster in 2025

Tue, 11 Feb 2025 00:00:00 GMT

My first Kubernetes clusters are gone. This time I want a proper HA setup — if any machine goes down, the cluster keeps running. The target layout across my hardware:

1× DELL R720 → k3s-master-1 and k3s-worker-1
1× DELL Optiplex Micro 3050 → k3s-master-2 and k3s-worker-2
1× DELL Optiplex Micro 3050 → k3s-master-3 and k3s-worker-3

Six VMs total on a Proxmox cluster: 3 Ubuntu 22.04 master nodes, 3 Ubuntu 22.04 worker nodes.

DNS and IP Addressing

Before creating any VMs, get your IP and DNS situation sorted.

For IP assignment, you have two options: assign addresses outside your DHCP range (what I do — network stays stable even if DHCP goes down), or use static MAC→IP mappings in your DHCP server.

I’m using 10.57.57.30/24 through 10.57.57.35/24 for the six VMs, with an A record in Unbound on pfSense for each:

VM Deployment with Cloud-Init

Rather than clicking through the Proxmox UI six times, I wrote a bash script that handles template creation, VM deployment, and teardown. If you’d prefer a Packer/Terraform approach, see Homelab as Code.

Warning

This script can create or destroy VMs. Keep backups of anything critical before running option 3.

Prerequisites: Proxmox up and running, SSH public key at /root/.ssh/id_rsa.pub on the Proxmox host.

The script has three modes:

Option 1 — Create Cloud-Init Template: Downloads the Ubuntu 24.04 cloud image, creates a VM, configures cloud-init, and converts it to a template.

Option 2 — Deploy VMs: Clones the template N times, sets IPs, gateway, DNS, search domain, SSH keys, CPU, RAM, and disk size per VM. Prompts for a name on each one.

Option 3 — Destroy VMs: Stops and removes VMs by ID range.

#!/bin/bash

# Function to get user input with a default value
get_input() {
    local prompt=$1
    local default=$2
    local input
    read -p "$prompt [$default]: " input
    echo "${input:-$default}"
}

# Ask the user whether they want to create a template, deploy or destroy VMs
echo "Select an option:"
echo "1) Create Cloud-Init Template"
echo "2) Deploy VMs"
echo "3) Destroy VMs"
read -p "Enter your choice (1, 2, or 3): " ACTION

if [[ "$ACTION" != "1" && "$ACTION" != "2" && "$ACTION" != "3" ]]; then
    echo "❌ Invalid choice. Please run the script again and select 1, 2, or 3."
    exit 1
fi

# === OPTION 1: CREATE CLOUD-INIT TEMPLATE ===
if [[ "$ACTION" == "1" ]]; then
    TEMPLATE_ID=$(get_input "Enter the template VM ID" "300")
    STORAGE=$(get_input "Enter the storage name" "local")
    TEMPLATE_NAME=$(get_input "Enter the template name" "ubuntu-cloud")
    IMG_URL="https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img"
    IMG_FILE="/root/noble-server-cloudimg-amd64.img"

    echo "📥 Downloading Ubuntu Cloud image for cloud-init setup..."
    cd /root
    wget -O $IMG_FILE $IMG_URL || { echo "❌ Failed to download the image"; exit 1; }

    echo "🖥️ Creating VM $TEMPLATE_ID..."
    qm create $TEMPLATE_ID --memory 2048 --cores 2 --name $TEMPLATE_NAME --net0 virtio,bridge=vmbr0

    echo "💾 Importing disk to storage ($STORAGE)..."
    qm disk import $TEMPLATE_ID $IMG_FILE $STORAGE || { echo "❌ Failed to import disk"; exit 1; }

    echo "🔗 Attaching disk..."
    qm set $TEMPLATE_ID --scsihw virtio-scsi-pci --scsi0 $STORAGE:vm-$TEMPLATE_ID-disk-0

    echo "☁️ Adding Cloud-Init drive..."
    qm set $TEMPLATE_ID --ide2 $STORAGE:cloudinit

    echo "🛠️ Configuring boot settings..."
    qm set $TEMPLATE_ID --boot c --bootdisk scsi0

    echo "🖧 Adding serial console..."
    qm set $TEMPLATE_ID --serial0 socket --vga serial0

    echo "📌 Converting VM to template..."
    qm template $TEMPLATE_ID

    echo "✅ Cloud-Init Template created successfully!"
    exit 0
fi

# === OPTION 2: DEPLOY VMs ===
if [[ "$ACTION" == "2" ]]; then
    TEMPLATE_ID=$(get_input "Enter the template VM ID" "300")
    START_ID=$(get_input "Enter the starting VM ID" "301")
    NUM_VMS=$(get_input "Enter the number of VMs to deploy" "6")
    STORAGE=$(get_input "Enter the storage name" "dataz2")
    IP_PREFIX=$(get_input "Enter the IP prefix (e.g., 10.57.57.)" "10.57.57.")
    IP_START=$(get_input "Enter the starting IP last octet" "30")
    GATEWAY=$(get_input "Enter the gateway IP" "10.57.57.1")
    DNS_SERVERS=$(get_input "Enter the DNS servers (space-separated)" "8.8.8.8 1.1.1.1")
    DOMAIN_SEARCH=$(get_input "Enter the search domain" "merox.dev")
    DISK_SIZE=$(get_input "Enter the disk size (e.g., 100G)" "100G")
    RAM_SIZE=$(get_input "Enter the RAM size in MB" "16384")
    CPU_CORES=$(get_input "Enter the number of CPU cores" "4")
    CPU_SOCKETS=$(get_input "Enter the number of CPU sockets" "4")
    SSH_KEY_PATH=$(get_input "Enter the SSH public key file path" "/root/.ssh/id_rsa.pub")

    if [[ ! -f "$SSH_KEY_PATH" ]]; then
        echo "❌ Error: SSH key file not found at $SSH_KEY_PATH"
        exit 1
    fi

    for i in $(seq 0 $((NUM_VMS - 1))); do
        VM_ID=$((START_ID + i))
        IP="$IP_PREFIX$((IP_START + i))/24"
        VM_NAME=$(get_input "Enter the name for VM $VM_ID" "ubuntu-vm-$((i+1))")

        echo "🔹 Creating VM: $VM_ID (Name: $VM_NAME, IP: $IP)"

        if qm status $VM_ID &>/dev/null; then
            echo "⚠️ VM $VM_ID already exists, removing..."
            qm stop $VM_ID &>/dev/null
            qm destroy $VM_ID
        fi

        if ! qm clone $TEMPLATE_ID $VM_ID --full --name $VM_NAME --storage $STORAGE; then
            echo "❌ Failed to clone VM $VM_ID, skipping..."
            continue
        fi

        qm set $VM_ID --memory $RAM_SIZE \
                      --cores $CPU_CORES \
                      --sockets $CPU_SOCKETS \
                      --cpu host \
                      --serial0 socket \
                      --vga serial0 \
                      --ipconfig0 ip=$IP,gw=$GATEWAY \
                      --nameserver "$DNS_SERVERS" \
                      --searchdomain "$DOMAIN_SEARCH" \
                      --sshkey "$SSH_KEY_PATH"

        qm set $VM_ID --delete ide2 || true
        qm set $VM_ID --ide2 $STORAGE:cloudinit,media=cdrom
        qm cloudinit update $VM_ID

        echo "🔄 Resizing disk to $DISK_SIZE..."
        qm resize $VM_ID scsi0 +$DISK_SIZE

        qm start $VM_ID
        echo "✅ VM $VM_ID ($VM_NAME) created and started!"
    done
    exit 0
fi

# === OPTION 3: DESTROY VMs ===
if [[ "$ACTION" == "3" ]]; then
    START_ID=$(get_input "Enter the starting VM ID to delete" "301")
    NUM_VMS=$(get_input "Enter the number of VMs to delete" "6")

    echo "⚠️ Destroying VMs from $START_ID to $((START_ID + NUM_VMS - 1))..."
    for i in $(seq 0 $((NUM_VMS - 1))); do
        VM_ID=$((START_ID + i))

        if qm status $VM_ID &>/dev/null; then
            echo "🛑 Stopping and destroying VM $VM_ID..."
            qm stop $VM_ID &>/dev/null
            qm destroy $VM_ID
        else
            echo "ℹ️ VM $VM_ID does not exist. Skipping..."
        fi
    done
    echo "✅ Specified VMs have been destroyed."
    exit 0
fi

After running option 2, verify the VMs appear in Proxmox and SSH in:

ssh ubuntu@k3s-master-01

Guide Structure

Follow these in order:

K3s Installation with Ansible — automated cluster deployment
Traefik Setup and SSL — ingress controller with Let’s Encrypt
Cluster Management — Rancher for management, Longhorn for storage
Advanced Resources — monitoring, NFS, ArgoCD, upgrades

Homelab as Code: Packer + Terraform + Ansible

Tue, 17 Dec 2024 00:00:00 GMT

Warning

Experimental — not actively maintained. This post documents an older approach from late 2024. The current infrastructure has moved to Talos + FluxCD GitOps for Kubernetes workloads. The Packer + Terraform + Ansible pipeline still works for spinning up standalone Docker VMs on Proxmox, but it’s no longer the primary deploy method and the repo may be behind on dependencies. Treat this as a reference, not a production guide.

This project automates a full homelab deployment — Packer builds the VM template, Terraform provisions it on Proxmox, and Ansible handles everything inside: Docker, Portainer, Traefik, and optional services like a media stack and Homepage dashboard.

Requirements

Note

This project deploys an Ubuntu VM with Docker, Portainer, Media Stack, Traefik, and more. You’ll need:

Proxmox VE for VM management
A fresh LXC to run the deploy script
A DNS server configured for your service domains

Architecture and Source Code

Source: meroxdotdev/homelab-as-code

What’s in the Repository

The repo covers everything needed to go from zero to a running VM with services:

Deploy script — installs dependencies (git, curl, ansible, packer, terraform), clones the repo, and runs the full pipeline
ansible/ — roles for Docker, Portainer, Traefik, and optional NFS mounts
configs/docker/ — pre-configured services: Homepage, Traefik, media stack
packer/ — builds an optimized Ubuntu template for Proxmox
terraform/ — VM provisioning with networking and storage, based on the Packer template

Quick Start

Run this on a clean LXC:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/meroxdotdev/homelab-as-code/refs/heads/master/deploy_homelab.sh)"

What the Script Does

The script first asks whether your repository is public or private. For private repos, it generates an SSH key and prompts you to add it as a deploy key in your repo settings. For the public tutorial repo, use https://github.com/meroxdotdev/homelab-as-code.git directly.

Next, it asks whether you’ve already edited the required config files. Type yes to proceed with the Packer → Terraform → Ansible pipeline, or no to exit and review the guides below first.

Downloaded config files land in /home/homelab/.

Configuration Guides

The setup is split across four subposts — go through them in order before running the script:

Ansible Setup — inventory, roles, optional NFS mounts
Services Configuration — Homepage, Media Stack, Traefik
Infrastructure Setup — Packer and Terraform
Deployment & Verification — final steps and checks

My First Steps in IT Career

Fri, 25 Oct 2024 00:00:00 GMT

I was 20, second year of Computer Science, skipping most classes, and convinced I didn’t know enough to apply for anything. What I kept forgetting is that I’d been messing around with servers and databases since I was 11 or 12, back in 2008–2009. That background counts for something — it just took a push from the right person to make me see it.

Tip

I want to take a moment to thank @Dacian for giving me that much-needed push to get going.

Dacian practically dragged me out of bed to put together a CV. My first one was written in Notepad. I even printed it out just in case sending it online wasn’t enough — I genuinely had no idea how job applications worked at that point.

He’d seen a System Administrator listing at a company called Netex. Most people in IT around here equate the field with programming, so a sysadmin role was rare enough to get excited about. He knew I was into that side of things — we’d run an online gaming community together back in 2012 — so he didn’t hesitate to push me into it.

The Interview

At the company’s headquarters I handed in my CV and was told HR would follow up. I almost forgot it had happened, then got a call about a week later to schedule an interview.

The interview was in a conference room with an HR rep and the head of the IT department. They introduced the company, then asked me to talk about my experience and what I was looking for. I had the logic but not always the right vocabulary — which actually made for a more relaxed conversation than I expected.

Warning

I realized I had the logic but perhaps not the appropriate tech vocabulary. Nevertheless, this logic led to a pleasant and relaxed conversation.

The Questions

If you’re a beginner, try to answer these before checking.

Q: What is the administrator user in Linux?

Show Answer

Note

A: root

Q: How do you view open ports locally on a Linux machine?

Show Answer

Note

A: netstat -tulpen

Q: How do you view open ports on a remote Linux machine?

Show Answer

Note

A: nmap

Q: What are the basic file permissions in Linux?

Show Answer

Note

A: r - read (4), w - write (2), x - execute (1)

Q: What are the ports for https, ssh, imap, smtp, dns, etc.?

Show Answer

Note

A: http - 80; https - 443; ssh - 22; for the rest I don’t have them memorized, but I can find any of them quickly: cat /etc/services | grep -i mysql

Answers like that last one tend to land well — they show you understand the logic rather than just having facts memorized.

Q: What is /etc/shadow?

Show Answer

Note

A: A file containing local users and their encrypted passwords on Linux systems, readable only by root.

The Offer

The next day I actually went to a class — I was in Timișoara where I was enrolled, commuting from my hometown, and not attending much. I don’t recommend that approach; I think university is a real advantage, it just wasn’t clicking for me at the time.

Tip

I’d barely finished that first class when I got the call — I got the job.

The offer was slightly above minimum wage in Romania. I wasn’t focused on salary; I just wanted to be doing something real. I accepted on the spot.

The rest of that journey is on my about: merox.dev/about/. I learned a lot there and made some good friends — I still grab a beer with my former department head occasionally.

Gallery

Some nostalgic photos from that period

Smart Home Journey

Mon, 30 Sep 2024 00:00:00 GMT

It started with wanting to control lights from my phone. It turned into automating most of my apartment. Here’s what I’m running and how it works.

Devices

Amazon Alexa — in every room, handles voice control for most devices
Home Assistant — running in a VM on my Dell server, handles complex automations and scripts
Broadlink RM4 Pro — RF/IR bridge for roller blinds and non-smart appliances
Philips Hue & Govee — mood lighting, synced to specific routines
Roborock vacuum, Resideo thermostat, and AC units
Smart roller blinds — controlled via Broadlink RF

Cameras and a Yale smart lock are next on the list.

How Alexa and Home Assistant Work Together

Alexa handles most of the voice layer, but Home Assistant is where the logic lives. Automations run based on GPS location, outside weather, and custom scripts. When I leave, motion sensors activate and all roller blinds close. When I get back, the blinds open, temperature adjusts based on outside conditions, and night lights turn on along the path through the apartment.

Automations

Morning and Night Routines

Good Morning opens the blinds to a set level to bring in natural light. Good Night shuts off all lights, closes the blinds, and sets everything up for sleep. Both run on schedule and don’t require any manual input.

Movie and Gaming Time

Movie Time: living room blinds close, TV turns on to Netflix, soundbar switches to cinema mode, AC turns on in summer, ambient lighting around the TV adjusts.

Gaming Time: same setup, but the TV input switches to PlayStation 5 and the lighting shifts accordingly.

Security

Motion sensors activate when I leave. If anything unusual happens — significant temperature change, unexpected motion — I get a notification through both Alexa and Home Assistant.

Integrating Broadlink RM4 Pro with Alexa

Step 1: Set Up the RM4 Pro

Download the Broadlink app, connect the device to your Wi-Fi, and register it in the app.

Step 2: Learn RF Signals

In the app, go to Add Remote → RF Appliance. Put it in learning mode, press the button on your original remote, and save the code. Test it before moving on.

Step 3: Connect to Alexa

Enable the Broadlink skill in the Alexa app, link your Broadlink account, and let Alexa discover the devices. After that, voice commands like “Alexa, close the blinds” work out of the box.

Running Linux Scripts from Home Assistant

The trickiest part was getting Home Assistant to execute shell commands over SSH based on my GPS location. I use this to control server fan speeds remotely — slower when I’m home, faster when I’m away.

/root/homeassistant/configuration.yaml:

#!/bin/bash
# Adjust server fan speed based on external temperature
shell_command:
  set_fans_home: 'ssh -i /config/ssh/id_rsa -o StrictHostKeyChecking=no root@10.10.10.10 /usr/bin/ipmitool -I lanplus -H 10.10.10.200 -U root -P SuperSecretPassword raw 0x30 0x30 0x02 0xff 0x14'
  set_fans_away: 'ssh -i /config/ssh/id_rsa -o StrictHostKeyChecking=no root@10.10.10.10 /usr/bin/ipmitool -I lanplus -H 10.10.10.200 -U root -P SuperSecretPassword raw 0x30 0x30 0x02 0xff 0x28'

More Automations

Credits

How to Set Up Your Own AI at Home

Fri, 16 Aug 2024 00:00:00 GMT

I wanted to see what my R720 could do with AI workloads — no GPU, just dual 6-core Xeons and 192GB of RAM. I ended up running three tools: Ollama for LLM inference, Stable Diffusion for image generation, and OpenWebUI to tie them together into a single interface. Here’s how I set it all up.

Ollama

I ran this on an Ubuntu 22.04 VM in Proxmox, allocated 20 cores and 64GB of RAM.

Install

curl -fsSL https://ollama.com/install.sh | sh

Pull and Run Llama3

ollama pull llama3
ollama run llama3

That’s it — you’ll drop into an interactive CLI session. As a sanity check I asked it something from Interstellar:

Note

Question: How does the concept of time dilation in Interstellar relate to Einstein’s theory of relativity?

Tip

Answer: The concept of time dilation in Interstellar is directly related to Albert Einstein’s theory of special relativity, specifically the concept of time dilation. Here’s how: In the movie, a wormhole allows Cooper’s spaceship to travel at incredibly high speeds, approaching relativistic velocities. As they approach the speed of light (0.99c), time appears to slow down for them relative to Earth. This is precisely what Einstein predicted in his theory…

Stable Diffusion

Setup follows the AUTOMATIC1111 WebUI repo.

Install Dependencies

Debian/Ubuntu:

sudo apt install wget git python3 python3-venv libgl1 libglib2.0-0

Red Hat:

sudo dnf install wget git python3 gperftools-libs libglvnd-glx

openSUSE:

sudo zypper install wget git python3 libtcmalloc4 libglvnd

Download and Run

wget -q https://raw.githubusercontent.com/AUTOMATIC1111/stable-diffusion-webui/master/webui.sh
./webui.sh

CPU-Only Configuration

Since I have no GPU, I added the following to webui-user.sh:

export COMMANDLINE_ARGS="--lowvram --precision full --no-half --skip-torch-cuda-test"

--lowvram reduces memory pressure, --precision full and --no-half avoid half-precision issues on CPU, and --skip-torch-cuda-test skips CUDA checks that would fail anyway.

Expose on Network

By default it binds to localhost. To make it reachable by OpenWebUI:

./webui.sh --listen

This binds to 0.0.0.0:7860.

OpenWebUI

OpenWebUI gives you a ChatGPT-style interface on top of Ollama and Stable Diffusion. Easiest part of the whole setup.

Install with Docker

Ollama on the same host:

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

Ollama on a different server:

docker run -d -p 3000:8080 -e OLLAMA_BASE_URL=https://example.com \
  -v open-webui:/app/backend/data --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

With Nvidia GPU:

docker run -d -p 3000:8080 --gpus all --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:cuda

Connect Ollama

Go to http://ip_server_openwebui:3000/admin/settings/, then Models → Manage Ollama Models and enter your Ollama server URL.

Connect Stable Diffusion

Go to Images, find the AUTOMATIC1111 Base URL field, enter your Stable Diffusion server URL, and hit the refresh button to verify. Save if it checks out. You can then set a default model under Set Default Model.

Performance on CPU-Only

Running LLMs without a GPU is slow. Here’s what the numbers look like with Llama3 on dual Xeon E5-2620 v2s:

Metric	Value
Response Token/s	0.46
Prompt Token/s	1.99
Total Duration	1072376.46 ms (~17 min 52 sec)
Load Duration	61347.1 ms
Prompt Eval Count	33
Prompt Eval Duration	16571.72 ms
Eval Count	457
Eval Duration	994411.07 ms

Functional, but not something you’d want to use interactively. I’m planning to add an NVIDIA Tesla P40 to the R720 — once I do, I’ll post an updated guide covering GPU configuration.

Credits

TechnoTim — AI setup tutorial
Sean Zheng — Running Llama 3 with NVIDIA GPU

Setting Up Dell R720 Server in the Home Lab

Sat, 13 Jul 2024 00:00:00 GMT

I recently picked up a Dell PowerEdge R720 at a good price. Here’s how I got it running in my homelab — cooling, firmware, Proxmox migration, storage, and UPS.

Specs

Form factor: 2U rack
RAM: 192GB ECC DDR3
CPUs: Dual Intel Xeon E5-2697v2 (12 cores / 24 threads total)
iDRAC: iDRAC7 Enterprise
Storage: 2× 2TB SSD (RAID 1) + 6× 300GB SAS 6Gb/s (RAID 10)
Network: Dual-port integrated Gigabit Ethernet
PSU: Dual redundant (750W each)

Idle power draw with this config (192GB RAM, dual CPUs, SSDs) sits around 120–150W. Under load it goes to 200–250W, peaking around 300W on heavy workloads.

Delivery Issue

The server arrived with the front backplane disconnected — the included mini SAS cable was too short. I needed a 59cm cable, which I found here:

i-Service - MiniSAS Cable

Fan Control with IPMItool

The R720 runs loud out of the box. IPMItool lets you take manual control of fan speeds over the network via iDRAC.

Install

sudo apt-get install ipmitool

Enable Manual Fan Control

ipmitool -I lanplus -H ip_addr -U username -P password raw 0x30 0x30 0x01 0x00

Restore Automatic Fan Control

ipmitool -I lanplus -H ip_addr -U username -P password raw 0x30 0x30 0x01 0x01

Set Fan Speed

ipmitool -I lanplus -H ip_addr -U username -P password raw 0x30 0x30 0x02 0xff 0x14

The last byte is the speed in hex. Reference:

Percent	Hex	RPM
10%	0x0A	~3,300 RPM
16%	0x10	~3,900 RPM
20%	0x14	~4,000 RPM
25%	0x19	~4,700 RPM
30%	0x1E	~5,400 RPM
40%	0x28	~7,300 RPM
50%	0x32	~8,000 RPM
60%	0x3C	~9,400 RPM
70%	0x46	~10,800 RPM
80%	0x50	~12,100 RPM
90%	0x5A	~13,300 RPM
100%	0x64	15,000 RPM

Monitor Fan Status

ipmitool sensor | grep -i fan

Firmware Update

Find Your Server Generation

Check Wikipedia’s Dell PowerEdge list — the R720 is gen 12 (g12).

Update via iDRAC FTP

Go to Maintenance > System Update in the iDRAC web interface
Select FTP and use these settings:
- Address: ftp.updateyodell.net
- User: dell
- Password: calvin
- Path: g12
Click Check for Updates and apply

Proxmox Migration

I migrated my existing Proxmox cluster to the R720 using an NFS share on my Synology DS223. Nothing complicated — mount the share, restore from the existing dumps.

mount -t nfs <synology_ip>:/path/to/nfs /mnt/pve/nfs

Restore VMs

pct restore <vmid> /mnt/pve/nfs/dump/dump.tar

Storage Configuration

Two 2TB SSDs in RAID 1 for the OS and primary applications. Six 300GB SAS drives in RAID 10 for data — gives you the read performance of striping with redundancy against single drive failures. Configured through the PERC controller during initial setup.

UPS Integration with PowerPanel

I’m using a CyberPower UPS and opted for PowerPanel instead of NUT.

Install

curl -o cyberpowerpowerpanel.deb https://www.cyberpower.com/tw/en/File/GetFileSampleByType?fileId=SU-18070001-06&fileType=Download%20Center&fileSubType=FileOriginal
dpkg -i cyberpowerpowerpanel.deb

Configure Shutdown Policy

pwrstat -lowbatt -runtime 300 -capacity 35 -active on -cmd /etc/pwrstatd-lowbatt.sh -duration 1 -shutdown on

This triggers a graceful shutdown when runtime drops below 300 seconds or battery capacity falls under 35%, with a 1-minute delay before executing. The script at /etc/pwrstatd-lowbatt.sh handles any pre-shutdown tasks you want to run.

References

Dell & HP Server Manual Fan Control
Kenneth Finnegan — Update your old ass Dell servers
NOiSEA — CyberPower PowerPanel on Proxmox Forum

Tailscale site-to-site pfSense - Linux

Sat, 06 Apr 2024 00:00:00 GMT

I’m setting up cloud-based monitoring for my homelab using a Hetzner VM, and I wanted the cloud VM to be the single entry point to my infrastructure. For that I’m using Tailscale — not just client-to-site, but site-to-site so both subnets can reach each other without exposing anything publicly.

Note

Site-to-site L3 networking connects two subnets on your Tailscale network. Each subnet needs a subnet router, but individual devices don’t need Tailscale installed. This applies to Linux subnet routers only.

Warning

This won’t work with overlapping CIDR ranges or 4via6 subnet routing.

Network Layout

Two private subnets with no existing connectivity between them:

Subnet 1 — Homelab: 10.57.57.0/24, router at 10.57.57.1 (pfSense)
Subnet 2 — Cloudlab: 192.168.57.0/24, router at 192.168.57.254 (Linux VM)

pfSense Setup (Subnet 1)

pfSense runs on FreeBSD, and Tailscale’s support for it is more limited than other platforms, so there are a few rough edges.

Install Tailscale

Go to System > Package Manager > Available Packages, search for tailscale, and install it.

Configure Tailscale

Navigate to VPN > Tailscale.

Generate an auth key at https://login.tailscale.com/admin/settings/keys and paste it in.

Settings to apply:

Enable Tailscale ✅
Listen port: leave default
Accept Subnet Routes ✅
Advertise Exit Node ✅ (optional)
Advertised Routes: 10.57.57.0/24

Outbound NAT Rules

Navigate to Firewall > NAT > Outbound and set the mode to Hybrid Outbound NAT, then create a manual mapping:

Interface: Tailscale
Address Family: IPv4+IPv6
Protocol: Any
Source: 10.57.57.0/24
Destination: Any

Warning

As of pfSense 23.09.1, the NAT Alias field is broken — it’s missing from the UI. Workaround: under Translation, set Address to “Network or Alias” and enter your Tailscale IP directly as 100.xx.xx.xx/32.

Linux VM Setup (Subnet 2)

Install Tailscale and Enable IP Forwarding

# Install tailscale
curl -sSL https://tailscale.com/install.sh | sh

# Activate routing for IPv4
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf

# Activate routing for IPv6
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.conf

# Apply routing configuration at kernel level
sudo sysctl -p /etc/sysctl.conf

Advertise Routes

On the 192.168.57.254 device:

tailscale up --advertise-routes=192.168.57.0/24 --snat-subnet-routes=false --accept-routes

What each flag does: --advertise-routes exposes the subnet to the rest of your Tailscale network. --snat-subnet-routes=false disables source NAT so the destination machine sees the actual LAN IP of the originating host rather than the subnet router — this is required for routing across multiple networks. --accept-routes tells this node to accept routes advertised by other subnet routers, including the pfSense side.

Approve Routes in the Admin Console

Note

Skip this if you’re using autoApprovers.

Open the Machines page in the Tailscale admin console. Find your subnet routers (look for the Subnets badge or filter by property:subnet), click the ellipsis menu on each, select Edit route settings, and approve the advertised routes.

Tip

That’s it — the Tailscale side is done.

Credits

Tailscale Documentation
Christian McDonald — pfSense Tailscale setup walkthrough

Deploying a Kubernetes-Based Media Server

Wed, 06 Mar 2024 00:00:00 GMT

This is the setup I use to run a full media automation stack on my Kubernetes cluster. It covers Jellyfin for streaming, Radarr and Sonarr for media management, Prowlarr for indexers, qBittorrent for downloads, and Gluetun for VPN tunneling. Config lives on Longhorn; media is stored on a Synology NAS DS223 mounted via NFS 4.1 as a PersistentVolume.

Components

Application	Role
Jellyfin	Media streaming
Radarr	Movie library management
Sonarr	TV show management
Prowlarr	Torrent indexer manager
qBittorrent	Download client
Gluetun	VPN sidecar for qBittorrent

Synology NAS NFS Setup

If you’re using a Synology NAS, this is the NFS share rule I use — applied before mounting on the Kubernetes side.

PersistentVolumes and PVCs

Media Storage

Create nfs-media-pv-and-pvc.yaml:

1
apiVersion: v1
2
kind: PersistentVolume
3
metadata:
4
  name: jellyfin-videos
5
spec:
6
  capacity:
7
    storage: 400Gi
8
  accessModes:
9
    - ReadWriteOnce
10
  nfs:
11
    path: /volume1/server/k3s/media
12
    server: storage.merox.cloud
13
  persistentVolumeReclaimPolicy: Retain
14
  mountOptions:
15
    - hard
16
    - nfsvers=4.1
17
  storageClassName: ""
18
---
19
apiVersion: v1
20
kind: PersistentVolumeClaim
21
metadata:
22
  name: jellyfin-videos
23
  namespace: media
24
spec:
25
  accessModes:
26
    - ReadWriteOnce
27
  resources:
28
    requests:
29
      storage: 400Gi
30
  volumeName: jellyfin-videos
31
  storageClassName: ""

kubectl apply -f nfs-media-pv-and-pvc.yaml

Download Storage

Create nfs-download-pv-and-pvc.yaml:

1
apiVersion: v1
2
kind: PersistentVolume
3
metadata:
4
  name: qbitt-download
5
spec:
6
  capacity:
7
    storage: 400Gi
8
  accessModes:
9
    - ReadWriteOnce
10
  nfs:
11
    path: /volume1/server/k3s/media/download
12
    server: storage.merox.cloud
13
  persistentVolumeReclaimPolicy: Retain
14
  mountOptions:
15
    - hard
16
    - nfsvers=4.1
17
  storageClassName: ""
18
---
19
apiVersion: v1
20
kind: PersistentVolumeClaim
21
metadata:
22
  name: qbitt-download
23
  namespace: media
24
spec:
25
  accessModes:
26
    - ReadWriteOnce
27
  resources:
28
    requests:
29
      storage: 400Gi
30
  volumeName: qbitt-download
31
  storageClassName: ""

kubectl apply -f nfs-download-pv-and-pvc.yaml

Longhorn PVC for App Configs

Create app-config-pvc.yaml (repeat for each app):

1
apiVersion: v1
2
kind: PersistentVolumeClaim
3
metadata:
4
  name: app # radarr for example
5
  namespace: media
6
spec:
7
  accessModes:
8
    - ReadWriteOnce
9
  storageClassName: longhorn
10
  resources:
11
    requests:
12
      storage: 5Gi

kubectl apply -f app-config-pvc.yaml

Danger

You need a separate PVC for each application: Jellyfin, Sonarr, Radarr, Prowlarr, and qBittorrent.

Deployments

Jellyfin

Create jellyfin-deployment.yaml:

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: jellyfin
5
  namespace: media
6
spec:
7
  replicas: 1
8
  selector:
9
    matchLabels:
10
      app: jellyfin
11
  template:
12
    metadata:
13
      labels:
14
        app: jellyfin
15
    spec:
16
      containers:
17
      - name: jellyfin
18
        image: jellyfin/jellyfin
19
        volumeMounts:
20
        - name: config
21
          mountPath: /config
22
        - name: videos
23
          mountPath: /data/videos
24
        ports:
25
        - containerPort: 8096
26
      volumes:
27
      - name: config
28
        persistentVolumeClaim:
29
          claimName: jellyfin-config
30
      - name: videos
31
        persistentVolumeClaim:
32
          claimName: jellyfin-videos

kubectl apply -f jellyfin-deployment.yaml

Sonarr

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: sonarr
5
  namespace: media
6
spec:
7
  replicas: 1
8
  selector:
9
    matchLabels:
10
      app: sonarr
11
  template:
12
    metadata:
13
      labels:
14
        app: sonarr
15
    spec:
16
      containers:
17
      - name: sonarr
18
        image: lscr.io/linuxserver/sonarr
19
        env:
20
        - name: PUID
21
          value: "1057"
22
        - name: PGID
23
          value: "1056"
24
        volumeMounts:
25
        - name: config
26
          mountPath: /config
27
        - name: videos
28
          mountPath: /tv
29
        - name: downloads
30
          mountPath: /downloads
31
        ports:
32
        - containerPort: 8989
33
      volumes:
34
      - name: config
35
        persistentVolumeClaim:
36
          claimName: sonarr-config
37
      - name: videos
38
        persistentVolumeClaim:
39
          claimName: jellyfin-videos
40
      - name: downloads
41
        persistentVolumeClaim:
42
          claimName: qbitt-download

Radarr

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: radarr
5
  namespace: media
6
spec:
7
  replicas: 1
8
  selector:
9
    matchLabels:
10
      app: radarr
11
  template:
12
    metadata:
13
      labels:
14
        app: radarr
15
    spec:
16
      containers:
17
      - name: radarr
18
        image: lscr.io/linuxserver/radarr
19
        env:
20
        - name: PUID
21
          value: "1057"
22
        - name: PGID
23
          value: "1056"
24
        volumeMounts:
25
        - name: config
26
          mountPath: /config
27
        - name: videos
28
          mountPath: /movies
29
        - name: downloads
30
          mountPath: /downloads
31
        ports:
32
        - containerPort: 7878
33
      volumes:
34
      - name: config
35
        persistentVolumeClaim:
36
          claimName: radarr-config
37
      - name: videos
38
        persistentVolumeClaim:
39
          claimName: jellyfin-videos
40
      - name: downloads
41
        persistentVolumeClaim:
42
          claimName: qbitt-download

Prowlarr

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: prowlarr
5
  namespace: media
6
spec:
7
  replicas: 1
8
  selector:
9
    matchLabels:
10
      app: prowlarr
11
  template:
12
    metadata:
13
      labels:
14
        app: prowlarr
15
    spec:
16
      containers:
17
      - name: prowlarr
18
        image: lscr.io/linuxserver/prowlarr
19
        env:
20
        - name: PUID
21
          value: "1057"
22
        - name: PGID
23
          value: "1056"
24
        volumeMounts:
25
        - name: config
26
          mountPath: /config
27
        ports:
28
        - containerPort: 9696
29
      volumes:
30
      - name: config
31
        persistentVolumeClaim:
32
          claimName: prowlarr-config

qBittorrent (standalone)

Warning

qBittorrent v5 renamed the API endpoints /torrents/pause and /torrents/resume to /torrents/stop and /torrents/start. If you use any scripts or integrations that call the qBittorrent API directly, update them before upgrading from v4.

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: qbittorrent
5
  namespace: media
6
spec:
7
  replicas: 1
8
  selector:
9
    matchLabels:
10
      app: qbittorrent
11
  template:
12
    metadata:
13
      labels:
14
        app: qbittorrent
15
    spec:
16
      containers:
17
      - name: qbittorrent
18
        image: lscr.io/linuxserver/qbittorrent
19
        resources:
20
          limits:
21
            memory: "2Gi"
22
          requests:
23
            memory: "512Mi"
24
        env:
25
        - name: PUID
26
          value: "1057"
27
        - name: PGID
28
          value: "1056"
29
        volumeMounts:
30
        - name: config
31
          mountPath: /config
32
        - name: downloads
33
          mountPath: /downloads
34
        ports:
35
        - containerPort: 8080
36
      volumes:
37
      - name: config
38
        persistentVolumeClaim:
39
          claimName: qbitt-config
40
      - name: downloads
41
        persistentVolumeClaim:
42
          claimName: qbitt-download

qBittorrent with Gluetun

If you want to route qBittorrent traffic through a VPN, use this version instead — Gluetun runs as a sidecar and shares the network namespace.

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: qbittorrent
5
  namespace: media
6
spec:
7
  replicas: 1
8
  selector:
9
    matchLabels:
10
      app: qbittorrent
11
  template:
12
    metadata:
13
      labels:
14
        app: qbittorrent
15
    spec:
16
      containers:
17
        - name: qbittorrent
18
          image: lscr.io/linuxserver/qbittorrent
19
          resources:
20
            limits:
21
              memory: "2Gi"
22
            requests:
23
              memory: "512Mi"
24
          env:
25
           - name: PUID
26
             value: "1057"
27
           - name: PGID
28
             value: "1056"
29
          volumeMounts:
30
            - name: config
31
              mountPath: /config
32
            - name: downloads
33
              mountPath: /downloads
34
          ports:
35
            - containerPort: 8080
36

37
        - name: gluetun
38
          image: ghcr.io/qdm12/gluetun:v3.40.0
39
          env:
40
            - name: VPN_SERVICE_PROVIDER
41
              value: "surfshark"
42
            - name: VPN_TYPE
43
              value: "wireguard"
44
            - name: SERVER_COUNTRIES
45
              value: "Netherlands"
46
            - name: WIREGUARD_ADDRESSES
47
              value: "10.14.0.2/16"  # from SurfShark WireGuard config — Address field
48
            - name: FIREWALL_INPUT_PORTS
49
              value: "50413,8080"  # torrent port + web UI port
50
            - name: FIREWALL_OUTBOUND_SUBNETS
51
              value: "10.0.0.0/8"
52
            - name: DNS_KEEP_NAMESERVER
53
              value: "on"
54
            - name: DOT
55
              value: "off"
56
            - name: WIREGUARD_PRIVATE_KEY
57
              valueFrom:
58
                secretKeyRef:
59
                  name: surfshark-secret
60
                  key: WIREGUARD_PRIVATE_KEY
61
          securityContext:
62
            capabilities:
63
              add:
64
                - NET_ADMIN
65
          volumeMounts:
66
            - name: tun
67
              mountPath: /dev/net/tun
68

69
      volumes:
70
        - name: config
71
          persistentVolumeClaim:
72
            claimName: qbitt-config
73
        - name: downloads
74
          persistentVolumeClaim:
75
            claimName: qbitt-download
76
        - name: tun
77
          hostPath:
78
            path: /dev/net/tun

Note

I use SurfShark with WireGuard — faster than OpenVPN and natively supported by Gluetun. Generate your WireGuard key from the SurfShark dashboard under VPN → Manual Setup → WireGuard. Note: SurfShark does not support port forwarding, so peers cannot initiate inbound connections — downloads still work fine but may be slower without seeding peers.

ClusterIP Services

Each app needs a ClusterIP service so Traefik can route to it internally. Create app-service.yaml per application:

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: app # radarr for example
5
  namespace: media
6
spec:
7
  type: ClusterIP
8
  ports:
9
    - port: 80
10
      targetPort: 7878
11
  selector:
12
    app: app # radarr for example

kubectl apply -f app-service.yaml

Traefik Middleware

Create default-headers-media.yaml:

1
apiVersion: traefik.io/v1alpha1
2
kind: Middleware
3
metadata:
4
  name: default-headers-media
5
  namespace: media
6
spec:
7
  headers:
8
    browserXssFilter: true
9
    contentTypeNosniff: true
10
    forceSTSHeader: true
11
    stsIncludeSubdomains: true
12
    stsPreload: true
13
    stsSeconds: 15552000
14
    customFrameOptionsValue: SAMEORIGIN
15
    customRequestHeaders:
16
      X-Forwarded-Proto: https

kubectl apply -f default-headers-media.yaml

IngressRoutes

Create app-ingress-route.yaml per application:

1
apiVersion: traefik.io/v1alpha1
2
kind: IngressRoute
3
metadata:
4
  name: app # radarr for example
5
  namespace: media
6
  annotations:
7
    kubernetes.io/ingress.class: traefik-external
8
spec:
9
  entryPoints:
10
    - websecure
11
  routes:
12
    - match: Host(`movies.merox.cloud`) # change to your domain
13
      kind: Rule
14
      services:
15
        - name: app # radarr for example
16
          port: 80
17
    - match: Host(`movies.merox.cloud`) # change to your domain
18
      kind: Rule
19
      services:
20
        - name: app # radarr for example
21
          port: 80
22
      middlewares:
23
        - name: default-headers-media
24
  tls:
25
    secretName: mycert-tls # change to your cert name

kubectl apply -f app-ingress-route.yaml

Danger

Add the hostname declared in your IngressRoute to your DNS server before applying.

Manifest Files

All manifests are available here — copy and deploy what you need:

All manifest files 🔗