Merox

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.

`/etc/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.

`/etc/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

Option 1: Official Installer (Recommended)

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

Telegram (Easiest)

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

`/srv/docker/garage/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.

`/srv/docker/garage/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.

Complete Homelab Tour 2026

Wed, 02 Jul 2025 00:00:00 GMT

Hardware

Power Protection

Device	Model	Protected Equipment	Capacity
UPS #1	CyberPower	Dell R720	1500VA
UPS #2	CyberPower	Mini PCs + Network	1000VA

Network Stack

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

Compute

Note

On-Premise Hardware

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

Tip

Cloud Infrastructure

Provider	Instance	Specs	Location	Purpose
Hetzner	CX22	4vCPU/8GB/80GB	Germany	Off-site Backup
Oracle	Ampere A1	4vCPU/24GB/200GB	USA	Docker Test

Network Architecture

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, Hetzner, and Oracle all appear on the same mesh.

Tip

Both VPS instances double as Tailscale exit nodes, so I can route traffic through EU (Hetzner) or US (Oracle) for geo-restricted content or lower latency to specific regions.

Infrastructure

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.

UPS Power Management

The CyberPower 1000VA 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

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
Current	Backup Target	4× 960GB RAID-Z2, weekly MinIO sync

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 would cost ~€20/month in electricity. Instead: Wake-on-LAN 1–2× weekly, pull MinIO backups from Hetzner, done.

Warning

Still constantly changing my mind about what to run here.

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.

Current VMs:

VM	Purpose	Specs	Notes
3× Talos Kubernetes	K8s nodes	4vCPU/16GB/1TB	Intel iGPU passthrough
meroxos	Docker host	4vCPU/8GB/500GB	For simpler services
Windows Server 2019	AD Lab	4vCPU/8GB/100GB	Active Directory experiments
Windows 11	Remote desktop	4vCPU/8GB/50GB	Always-ready Windows machine
Home Assistant	Home automation	2vCPU/4GB/32GB
Kali Linux	Security testing	2vCPU/4GB/50GB	To be restored from backup
GNS3	Network lab	4vCPU/8GB/100GB	To be restored from backup

Home Assistant is intentionally minimal for now. The most interesting automation: location-based Dell R720 fan control — quieter when I’m home, ramped up when away. Details →

Cloud

All managed through a single Portainer instance at cloud.merox.dev:

cloud-de (Hetzner CX22, ~€4/month) — always-on, external monitoring for when the homelab is down:

Service	Purpose
Grafana + Prometheus + Alertmanager	External homelab monitoring
Pi-hole	Dedicated Tailscale split-DNS
Traefik	SSL for all VPS services
Guacamole	Remote access via Cloudflare Tunnel
Firefox container	GUI access via Guacamole

homelab-ro (local Docker) — the escape hatch when Kubernetes complexity becomes too much:

Service	Purpose
ARR Stack	Quick restore when Kubernetes fails
Netboot.xyz	PXE / network boot
Portainer Agent	Remote Docker management

Because sometimes you just need things to work without debugging YAML manifests at 2 AM.

cloud-usa (Oracle Free Tier) — test ground for experimental images and US Tailscale exit node. Not in Portainer — hit the 5-node limit with 3× Kubernetes + 2× Docker.

Talos & 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

The custom Talos image includes Linux driver tools, iSCSI-tools for network storage, and Intel iGPU drivers for Proxmox passthrough.

GitOps structure:

1
infrastructure/kubernetes/apps/
2
├── storage/          # Longhorn configuration
3
├── observability/    # Prometheus, Grafana, Loki (WIP)
4
└── default/          # Production workloads

Day-to-day management with Lens:

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	⚠️ Use v5.0.4 for GUI config
Jellyseer	Request management	Public via Cloudflare
Jellyfin	Media server	Intel QuickSync enabled
Homepage	Dashboard	Still organizing…

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.

Backup Strategy

Longhorn PVCs → daily backup to MinIO on R720

MinIO on R720 → weekly sync to Hetzner Storagebox

Complete 3-2-1 across local, on-prem, and offsite. For full details on the backup chain and recovery procedures, see Safeguarding My Critical Data.

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

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 --now 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 samba-client \
    cifs-utils policycoreutils-python-utils

sudo systemctl enable --now chrony
sudo systemctl enable --now sssd

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

sudo systemctl restart chronyd
chrony sources -v
timedatectl status

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
    kdc = FILE:/var/log/krb5/krb5kdc.log
24
    admin_server = FILE:/var/log/krb5/kadmind.log
25
    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

Step 5: 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
# Disable for consistent UIDs across servers
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
33
cache_first = True

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

Step 6: NSS Configuration

`/etc/nsswitch.conf`

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

Step 7: 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@company.com, @itstaff@company.com
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@company.com
43
    force group = dataaccess
44
    create mask = 0660
45
    directory mask = 0770
46

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

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)
sudo setsebool -P samba_export_all_ro=1 samba_export_all_rw=1
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 8: Join Samba to Domain

sudo net ads join -U administrator
sudo net ads testjoin
# Should return: Join is OK

# Verify user/group lookup
getent passwd testuser@company.com
id testuser@company.com
getent group linuxadmins@company.com

Step 9: Start Services and Test

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

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

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

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

Step 10: Troubleshooting

Cache

sudo sss_cache -E
sudo systemctl restart sssd

sudo net cache flush

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

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 lookup testuser
sudo net ads group info "linuxadmins"
klist -k /etc/krb5.keytab

# Winbind checks
sudo wbinfo -t  # trust secret
sudo wbinfo -u  # list users
sudo wbinfo -g  # list groups

# Active connections
sudo smbstatus

Common Errors

NT_STATUS_ACCESS_DENIED:

id username@company.com
sudo testparm -s
ls -Z /srv/shared

Users not resolving:

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

Authentication failures:

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

Firewall and SELinux

sudo firewall-cmd --permanent --add-service=samba
sudo firewall-cmd --permanent --add-port=445/tcp
sudo firewall-cmd --permanent --add-port=139/tcp
sudo firewall-cmd --reload

# SELinux booleans (RHEL/CentOS)
sudo setsebool -P samba_domain_controller=on
sudo setsebool -P use_samba_home_dirs=on
sudo setsebool -P samba_enable_home_dirs=on

Maintenance Script

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

#!/bin/bash
net ads changetrustpw
sss_cache -E
tdbbackup /var/lib/samba/*.tdb
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

Questions?

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

From 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.

Safeguarding My Critical Data

Sat, 01 Mar 2025 00:00:00 GMT

Data loss is catastrophic whether you’re running a homelab or managing production infrastructure. This is my personal disaster recovery strategy — what I run, how it’s automated, and how I’d recover from each failure scenario.

Common Backup Mistakes

Warning

Even with a structured backup plan, common mistakes can make backups useless when disaster strikes.

The ones I see most often: never testing restores, storing backups on the same system as the data, no encryption, no versioning (so ransomware encrypts your backups too), and no offsite copy.

Danger

Modern ransomware actively seeks and encrypts backup files. Recovery becomes impossible without preventive measures.

Mitigations I use: PBS snapshot protection (note — users with sufficient permissions can still remove this; see Proxmox Forum), at least one air-gapped or offline copy, MFA on backup systems, and alerting on backup job failures.

Infrastructure Stack

Components

Primary storage: Synology DS223, 2×2TB in RAID1

Backup server: Proxmox Backup Server, 4× Intel D3-S4510 SSDs in RAIDz2

Offsite: Hetzner VPS + StorageBox

Key management: KeePass on iOS/macOS, storing all encryption keys

3-2-1 in Practice

3 copies: original + PBS + Hetzner
2 storage types: local NAS and cloud
1 offsite: Hetzner StorageBox

Backup Schedule

All three jobs run on Saturday:

02:00 — VM/LXC → PBS: encrypted backup of all virtual machines and containers
06:00 — PBS → Synology: rsync via crontab, RAID1 protection against single drive failure
08:00 — Synology → Hetzner: offsite copy for geographic redundancy

Scripts

PBS to Synology (crontab on PBS server)

0 6 * * 6 rsync -av --delete --progress /mnt/datastore/ /mnt/hyperbackup/ >> /var/log/rsync_backup.log 2>&1

`backup-pbs.sh` — Backup to Cloud PBS

#!/bin/bash

# 1) Export token secret as "PBS_PASSWORD"
export PBS_PASSWORD='token-secret-from-PBS'

# 2) Define user@pbs + token
export PBS_USER_STRING='token-id-from-PBS'

# 3) PBS IP/hostname
export PBS_SERVER='PBS-IP'

# 4) Datastore name
export PBS_DATASTORE='DATASTORE_PBS'

# 5) Build complete repository
export PBS_REPOSITORY="${PBS_USER_STRING}@${PBS_SERVER}:${PBS_DATASTORE}"

# 6) Get local server shortname
export PBS_HOSTNAME="$(hostname -s)"

# 7) ENCRYPTION KEY
export PBS_KEYFILE='/root/pbscloud_key.json'

echo "Run pbs backup for $PBS_HOSTNAME ..."

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

# List existing backups
proxmox-backup-client list --repository "${PBS_REPOSITORY}"

echo "Done."

`backup-pbs-restore.sh` — Restore from PBS

#!/bin/bash

# Global configs
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}"

# Input parameters
SNAPSHOT_PATH="$1"
ARCHIVE_NAME="$2"
RESTORE_DEST="$3"

# Parameter validation
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

# Create destination if needed
mkdir -p "$RESTORE_DEST"

# Summary display
echo "=== PBS Restore ==="
echo "Snapshot:      $SNAPSHOT_PATH"
echo "Archive:       $ARCHIVE_NAME"
echo "Destination:   $RESTORE_DEST"
echo "Repository:    $PBS_REPOSITORY"
echo "Encryption key $PBS_KEYFILE"
echo "====================="

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

EXIT_CODE=$?

if [[ $EXIT_CODE -eq 0 ]]; then
  echo "=== Restore completed successfully! ==="
else
  echo "Restore error (code $EXIT_CODE)."
fi

exit $EXIT_CODE

Disaster Recovery Scenarios

Scenario 1: Synology NAS Failure

Data remains in two places — PBS (RAIDz2) and Hetzner StorageBox. Recovery steps:

Replace failed hardware
Reconfigure RAID1 on the new NAS
Restore HyperBackup schedule (Saturday 08:00)
Verify first backup cycle completes successfully

Scenario 2: Hetzner VPS/StorageBox Failure

Provision a new VPS
Install proxmox-backup-client:
- Ubuntu: community guide
- Debian: standard package installation
Retrieve /root/pbscloud_key.json from KeePass and place it on the new VPS
Deploy backup-pbs.sh and backup-pbs-restore.sh
Test backup and restore
Restore crontab:

0 2 * * * /usr/local/bin/backup-pbs.sh >> /var/log/backup-cloud.log 2>&1

Scenario 3: PBS Server Failure

Install the latest PBS ISO
Restore datastore config:

datastore: raidz2
        comment
        gc-schedule sat 03:30
        notification-mode notification-system
        path /mnt/datastore

Verify /etc/fstab mount point:

#raidz2
/dev/sdb /mnt/datastore ext4 defaults 0 2

Note

/dev/sdb here is the RAIDz2 array — in this setup PBS runs as a VM and /dev/sdb is a second disk attached from the RAIDz2 pool.

Confirm the datastore structure is intact: .chunks, vm, .gc-status, ct, host
Data can be pulled from any of three sources:
- Original RAIDz2 array (if drives survived)
- Hetzner StorageBox at /mnt/storagebox/Storage_1
- Synology at /volume1/Backup/Proxmox/hyperbackup
Import VM/LXC encryption key from KeePass into the new PVE environment

What to Keep Stored Securely

Always have these accessible from KeePass (iOS/macOS):

/root/pbscloud_key.json
PBS VM/LXC encryption key
PBS config: /etc/proxmox-backup/datastore.cfg
Backup locations:
- PBS: /mnt/datastore
- Synology: /volume1/Backup/Proxmox/hyperbackup
- Hetzner: /mnt/storagebox/Storage_1

Ongoing Maintenance

Monthly integrity checks on random files, checksum validation for bit rot, and log review for failures. Quarterly test restores with documented timing. Real-time alerting on backup process failures and storage capacity trends.

A backup you’ve never restored from is a backup you don’t actually have.

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.

Chapter 1: 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:

Chapter 2: Automated 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

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

Disable Manual Fan Control (back to automatic)

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 via UpdateYODell.net

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.

Credits

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, Jackett 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
Jackett	Torrent indexer proxy
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=3
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=3
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, Jackett, 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: 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: 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

Jackett

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: jackett
5
  namespace: media
6
spec:
7
  replicas: 1
8
  selector:
9
    matchLabels:
10
      app: jackett
11
  template:
12
    metadata:
13
      labels:
14
        app: jackett
15
    spec:
16
      containers:
17
      - name: jackett
18
        image: linuxserver/jackett
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: 9117
29
      volumes:
30
      - name: config
31
        persistentVolumeClaim:
32
          claimName: jackett-config

qBittorrent (standalone)

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: 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: 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: qmcgaw/gluetun
39
          env:
40
            - name: VPNSP
41
              value: "protonvpn"
42
            - name: OPENVPN_USER
43
              valueFrom:
44
                secretKeyRef:
45
                  name: protonvpn-secrets
46
                  key: PROTONVPN_USER
47
            - name: OPENVPN_PASSWORD
48
              valueFrom:
49
                secretKeyRef:
50
                  name: protonvpn-secrets
51
                  key: PROTONVPN_PASSWORD
52
            - name: COUNTRY
53
              value: "Germany"
54
          securityContext:
55
            capabilities:
56
              add:
57
                - NET_ADMIN
58
          volumeMounts:
59
            - name: gluetun-config
60
              mountPath: /gluetun
61

62
      volumes:
63
        - name: config
64
          persistentVolumeClaim:
65
            claimName: qbitt-config
66
        - name: downloads
67
          persistentVolumeClaim:
68
            claimName: qbitt-download
69
        - name: gluetun-config
70
          persistentVolumeClaim:
71
            claimName: gluetun-config

Note

I use ProtonVPN — no-logs policy, solid speeds, and reasonably priced.

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.containo.us/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.containo.us/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 🔗