homelab

hugoboss

Sat, 02 May 2026 00:00:00 +0000

hugoboss#

What Was Established#

hugoboss (192.168.1.237) is a lightweight Ubuntu server dedicated to Hugo static site development. It serves as the authoring and scaffolding machine for all Hugo-based sites in the homelab. A full machine audit was conducted 2026-05-01; repos were synced and organised 2026-05-02.

Identity#

Hostname: hugoboss
IP: 192.168.1.237 (VLAN Gandalf)
OS: Ubuntu 24.04.3 LTS (Noble Numbat), kernel 6.8.0-88-generic
User: iluvatar
Disk: 63G total, ~12G used, 49G free
Memory: 3.8G total, ~2.7G available

Hugo Installation#

Hugo is installed via Homebrew (linuxbrew), not via apt or direct binary download.

Wiki Pipeline Scripts

Sat, 02 May 2026 00:00:00 +0000

Wiki Pipeline Scripts#

What Was Established#

Eight Python scripts in /opt/wiki/homelab/scripts/ implement the full wiki pipeline: file conversion, document ingestion, conversation crystallization (standard, DeepSeek, and Claude formats), shared LLM infrastructure, wiki health-checking, and knowledge-graph integration. All scripts were ported from the work wiki pipeline (itself developed 2026-04-21 → 2026-04-26) with homelab-specific infrastructure baked in.

crystallize.py (Claude format) uses a two-step LLM approach: gemma4:e2b cleans, qwen3.6:35b crystallizes. crystallize_deepseek.py skips gemma — JSON parsing is handled deterministically in Python (load_conversation + _clean_text), so only qwen is needed.

Wiki System - Architecture

Sat, 02 May 2026 00:00:00 +0000

Wiki System - Architecture#

What Was Established#

The wiki system is designed around the LLM wiki pattern (Karpathy): raw sources (chat transcripts, notes, docs) are crystallized into structured markdown pages, embedded into pgvector, and retrieved semantically by agents in future sessions. A dedicated LXC (nk-wiki) will host the wiki VM, separating wiki infrastructure from other services.

Multi-Wiki Namespace Design#

Three wikis are planned, each with its own namespace in pgvector:

Bambu Studio Layer G-code

Fri, 01 May 2026 00:00:00 +0000

Bambu Studio Layer G-code#

What Was Established#

Methods for applying custom G-code to specific layers in Bambu Studio, including Height Range Modifiers and the Layer Range G-code interface. Specific commands for Bambu Lab printers to control infill angles, wall order, and layer pauses.

Key Decisions#

Layer Range G-code Interface: Preferred for direct layer-specific application without Height Range Modifiers.
Layer Numbering: The Layer Range G-code UI uses 1-indexed layer numbers. Conditional logic ({if layer_num == X}) uses 0-indexed numbers.
Bambu Proprietary G-code: Commands like M9000 (infill angle) and M9001 (wall order) are specific to Bambu Lab firmware.

Current Configuration#

Layer Range G-code Setup#

Slice the model.
Navigate to the G-code tab.
Scroll to Layer Range G-code in the left panel.
Click + Add.
Enter From and To layer numbers.
Enter G-code in the field.

Examples#

Layer 27 Direction Change:

Bambu Studio Print Order & Travel Optimization

Fri, 01 May 2026 00:00:00 +0000

Bambu Studio Print Order & Travel Optimization#

What Was Established#

Methods for controlling print sequence and travel paths in Bambu Studio, specifically addressing chaotic jumping when printing multiple identical objects (e.g., 64 clones) in layer-by-layer mode.

Key Decisions#

Print Sequence: Change from “By layer” to “By object” or “Sequential” to complete one item before moving to the next.
Travel Optimization: Adjusting “Order of walls”, “Avoid crossing walls”, and “Reduce infill retraction” can impact travel patterns.
Orca Slicer: Recommended for better manual control over print sequence within layers.
Post-Processing: G-code editors can manually reorder layer segments if slicer settings are insufficient.

Current Configuration#

Bambu Studio: Default slicer for Bambu Lab printers.
Orca Slicer: Alternative slicer (Bambu Studio fork) with “Sequential Printing” feature.
G-code Editors: gcode.ws, Pronterface, or custom Python scripts for manual reordering.

Historical Notes#

User reported chaotic jumping when printing 64 clones of the same STL in layer-by-layer mode.
Solutions explored included changing infill/wall order, travel optimization settings, and manual reordering.
Orca Slicer identified as the most reliable solution for true manual ordering within layers.

Open Questions#

Does “One at a time” printing significantly increase total print time for 64 clones?
Are there Bambu Studio plugins for sequential layer printing?

Sources#

ingested/chats/164-Fixing Bambu Studio Print Order Issues.md
Conversation: Fixing Bambu Studio Print Order Issues (2026-02-02)

BlueBikes API Feeds Guide

Fri, 01 May 2026 00:00:00 +0000

BlueBikes API Feeds Guide#

What Was Established#

Comprehensive breakdown of BlueBikes GBFS (General Bikeshare Feed Specification) endpoints.
JSON structure analysis for static (station_information) and real-time (station_status) feeds.
JavaScript patterns for fetching, joining, and displaying station data.

Key Decisions#

Base URL: https://gbfs.lyft.com/gbfs/1.1/bos/en/
Primary Feeds: station_information (static map/location data) and station_status (live availability) are the core feeds for real-time tracking.
Join Strategy: Match station_id fields between static and status feeds to combine location metadata with live bike/dock counts.

Current Configuration#

Core GBFS Endpoints#

Feed	Purpose
`station_information`	Static station list, names, IDs, coordinates, capacity, kiosk info
`station_status`	Real-time bike/dock counts, station active/inactive status, last reported timestamp
`system_information`	System metadata (operator, name, URLs)
`system_regions`	Regional breakdowns for color-coding/mapping
`system_hours`	Operating hours
`system_calendar`	Start/end years, holidays
`gbfs_versions`	Available GBFS versions
`free_bike_status`	Free-floating bike locations
`ebikes_at_stations`	Real-time e-bike counts per station
`system_pricing_plans`	Membership & pricing details
`system_alerts`	Current advisories

Data Structure Examples#

station_information

Cloudflare Access Setup for Protected Sections

Fri, 01 May 2026 00:00:00 +0000

Cloudflare Access Setup for Protected Sections#

What Was Established#

Methodology for securing specific website paths or subdomains using Cloudflare Zero Trust Access.
Authentication bypasses traditional .htaccess or server-side auth; Cloudflare handles it at the edge.
Prerequisites: Cloudflare domain, Paid/Zero Trust plan (free tier supports up to 50 users).

Key Decisions#

Identity Provider Choice: One-time PIN (OTP) recommended for simplicity and shared access without managing user lists. Alternatives include Google/GitHub or specific email allowlists.
Policy Structure: “Allow Authenticated Users” policy with wildcard email matching (*) or specific domain matching (*@domain.com).
Edge-Based Protection: No server-side configuration changes required; protection occurs before requests hit the origin server.

Current Configuration#

Pattern established but not yet applied to specific homelab services.
Relevant to Nginx Proxy Manager (192.168.1.222) or Proxmox (192.168.1.69) admin interfaces if routed through Cloudflare.

Historical Notes#

Conversation date: 2025-11-24.
Focuses on the Cloudflare Zero Trust dashboard workflow for self-hosted applications.
No changes to existing Cloudflare SSL/DNS integration patterns.

Open Questions#

Which homelab services will leverage Cloudflare Access for admin/protected paths?
Will static IP bypass policies be implemented for homelab admin access?

Sources#

ingested/chats/117-Setting Up Cloudflare Access for Website Protection.md
DeepSeek conversation: 2025-11-24 (Setting Up Cloudflare Access for Website Protection)

Filament Drying & Storage Guide

Fri, 01 May 2026 00:00:00 +0000

Filament Drying & Storage Guide#

What Was Established#

Drying temperatures, times, and storage practices for common 3D printing filaments (TPU, PLA). Airtight container with desiccant is the standard storage method. Fresh-from-package filament typically needs minimal drying.

Drying Reference#

Filament	Temp	Time (stored)	Time (fresh)
TPU (Inland)	60-65°C	4-6 hours	2-3 hours (or skip)
PLA	50-55°C	4-6 hours	1-2 hours (or skip)

Lower-temp drying: Some prefer 50°C for TPU to reduce deformation risk, extending time to 6-8 hours. The “lower and slower” approach is safer for sensitive filaments.

Git Push Authentication

Fri, 01 May 2026 00:00:00 +0000

Git Push Authentication#

What Was Established#

GitHub deprecated password authentication for Git over HTTPS. Even if passwords worked previously, they are now rejected with password not supported.
Personal Access Tokens (PAT) or SSH keys are required for authentication.
403 Permission Denied errors typically indicate stale cached credentials or insufficient token scopes.

Key Decisions#

Use Personal Access Tokens (PAT) for HTTPS Git operations.
Classic tokens require the repo scope for private repositories.
Fine-grained tokens require Contents (Read and write) and Metadata (Read) permissions, explicitly scoped to the target repository.

Current Configuration#

GitHub Username: NK-Iluvatar
Target Repository: MBTADashboard
Remote URL: https://github.com/NK-Iluvatar/MBTADashboard.git

Historical Notes#

Password Deprecation: GitHub enforced its 2021 policy change retroactively, blocking account passwords for Git operations over HTTPS.
403 Troubleshooting: Resolved by clearing cached credentials (git credential reject or OS credential manager) and verifying token scopes (repo for classic, Contents for fine-grained).
Token Testing: Verified token validity using curl -H "Authorization: token TOKEN" https://api.github.com/user.

Open Questions#

None.

Git Pull Strategies
Homelab Dashboard

Sources#

DeepSeek conversation (2026-02-18) regarding MBTADashboard push failures and PAT configuration.

Git Push Authentication

Fri, 01 May 2026 00:00:00 +0000

Git Push Authentication#

What Was Established#

Patterns for resolving Git push authentication issues and handling divergent branches when working across multiple machines.

Key Decisions#

Multi-machine workflow: Always git pull before starting work; commit and push when done.
Divergent branch resolution: When local and remote have diverged, use git pull --no-rebase (merge) for safety or git fetch origin && git reset --hard origin/main to discard local commits for remote-only state.

Resolving Divergent Branches#

Symptom#

hint: You have divergent branches and need to specify how to reconcile them.
fatal: Need to specify how to reconcile divergent branches.

Option 1: Merge (preserves both histories)#

git pull --no-rebase
# Or set as default:
git config pull.rebase false

Option 2: Rebase (local commits on top of remote)#

git pull --rebase
# Or set as default:
git config pull.rebase true

Option 3: Discard local, use remote only#

git fetch origin
git reset --hard origin/main

Option 4: Fast-forward only (fails if diverged)#

git pull --ff-only

Multi-Machine Workflow#

When working from multiple machines on the same repo:

Gluetun VPN Service

Fri, 01 May 2026 00:00:00 +0000

Gluetun VPN Service#

What Was Established#

Gluetun is a lightweight Docker container acting as a dedicated VPN gateway for other containers.
Implements the sidecar pattern: dependent containers (e.g., qBittorrent, nzbget, prowlarr) share Gluetun’s network namespace via network_mode: "service:gluetun".
AirVPN selected as the provider over ProtonVPN/Mullvad due to superior port forwarding support required for P2P services.
Container-level VPN on the servarr VM is architecturally separate from the network-level UniFi VPN on Helms Deep (VLAN 2).

Deployment Context#

Gluetun runs on the servarr VM (192.168.1.112) as part of the Servarr Docker Compose stack at /docker/servarr/. It is configured via .env file in that directory.

GPU Passthrough for Proxmox LXCs

Fri, 01 May 2026 00:00:00 +0000

GPU Passthrough for Proxmox LXCs#

What Was Established#

Intel GPU passthrough to Proxmox LXCs requires both host-side module loading and specific LXC device mounts.
vainfo frequently fails with X11/X server errors in headless containers; this is expected and does not indicate a broken passthrough.
intel_gpu_top requires i915 module loaded on the host and accessible debugfs/sysfs paths inside the container.

Key Decisions#

Headless VA-API Testing: When vainfo reports error: can't connect to X server!, set environment variables to bypass X11:
```
export XDG_RUNTIME_DIR=/tmp/runtime-root
export LIBVA_DRIVER_NAME=iHD
vainfo
```
Module Verification: lsmod | grep i915 confirms the driver is loaded inside the container. Presence of i915, drm_buddy, ttm, and drm_display_helper indicates successful module injection.
Device Access: intel_gpu_top failing with No device filter specified... typically points to missing debugfs mounts or host-side i915 parameters, not necessarily a broken /dev/dri/ passthrough.

Current Configuration#

Proxmox LXC Config (/etc/pve/lxc/<container-id>.conf):

Hinterflix Help Site - Cloudflare Deployment

Fri, 01 May 2026 00:00:00 +0000

Hinterflix Help Site - Cloudflare Deployment#

What Was Established#

The Hinterflix help site (help.hinterflix.com) is deployed as a static Hugo site on Cloudflare Workers. The domain is managed within the same Cloudflare account.

Key Decisions#

Hosting: Cloudflare Workers Pages (static hosting).
Domain: help.hinterflix.com (root subdomain of hinterflix.com).
DNS: CNAME record pointing to the Cloudflare Workers subdomain (*.workers.dev). Proxy status set to Proxied (orange cloud).
SSL/TLS: Automatically provisioned by Cloudflare. “Always Use HTTPS” enabled in SSL/TLS settings.

Configuration Steps#

Cloudflare DNS Setup:

Homelab Dashboard

Fri, 01 May 2026 00:00:00 +0000

Homelab Dashboard#

What Was Established#

A Node.js + Express dashboard is deployed at https://status.nbkelley.com, serving homelab monitoring data. All API calls are server-side — no internal IPs, credentials, or raw API responses reach the browser.

Deployment#

Detail	Value
Public URL	https://status.nbkelley.com
Host	proxy VM (192.168.1.222)
Port	3002
Runtime	Node.js + Express, Docker container
compose.yaml location	/home/iluvatar/compose.yaml on proxy VM
App directory	/opt/homelab-dashboard/ on proxy VM
Routing	Cloudflare Tunnel → 127.0.0.1:3002

File Structure#

/opt/homelab-dashboard/
  server.js         ← Express app, all API logic
  package.json
  package-lock.json
  dockerfile
  start.sh
  node_modules/
  public/
    index.html
    styles.css
    app.js          ← frontend render engine

compose.yaml Entry#

homelab-dashboard:
  build: /opt/homelab-dashboard
  container_name: homelab-dashboard
  restart: unless-stopped
  network_mode: host
  environment:
    - PORT=3002

network_mode: host means the app binds directly to host port 3002. The ports: mapping is ignored when using host networking.

Hugo Deployment to Cloudflare Pages - Troubleshooting

Fri, 01 May 2026 00:00:00 +0000

Hugo Deployment to Cloudflare Pages - Troubleshooting#

What Was Established#

Patterns for resolving missing assets (favicons, CSS, styling) and build failures when deploying Hugo-generated static sites to Cloudflare Pages.

Key Decisions#

Build Configuration: Set build command to hugo, output directory to public, and explicitly match the local Hugo version in Cloudflare Pages settings.
Static Asset Placement: Ensure all static files (e.g., favicon.ico, CSS) reside in the static/ directory root or theme-specific static folders.
Rebuild Enforcement: Use hugo --cleanDestinationDir or manually remove the public/ directory to force Hugo to regenerate all assets and detect changes.
Cache Management: Clear both Cloudflare Pages deployment cache and browser cache to prevent stale asset delivery.
Verification Workflow: Validate locally via hugo server, inspect the generated public/ directory, review Cloudflare deployment logs, and confirm full Git commits.

Current Configuration#

Build Command: hugo
Output Directory: public
Static Directory: static/
Config File: config.toml / config.yaml (verify baseURL matches target domain)

Obsidian Integration for Hugo Date Format#

Hugo expects ISO 8601 dates with timezone offset: 2025-11-22T23:11:12-05:00

Hugo Git Submodule Extraction Pattern

Fri, 01 May 2026 00:00:00 +0000

Hugo Git Submodule Extraction Pattern#

What Was Established#

Hugo themes installed as Git submodules (e.g., git submodule add <url> themes/theme-name) carry their own Git history. When you want to customize the theme beyond configuration, extracting the submodule into the main repository gives you full control over theme files without managing a separate submodule repository.

The Pattern#

Remove the submodule registration:

git submodule deinit themes/theme-name
git rm themes/theme-name

Re-add the theme as regular files:

git clone <theme-url> /tmp/theme-temp
cp -r /tmp/theme-temp/* themes/theme-name/
git add themes/theme-name/
git commit -m "Extract theme-name from submodule into main repo"

Result: Theme files are now tracked directly in the main repository.

When to Use#

You need to modify theme templates, layouts, or partials beyond what config allows
The upstream theme is stable and you don’t need to pull updates
You want simpler CI/CD without recursive submodule clones

When Not to Use#

The theme receives frequent updates you want to track
You only need CSS overrides (use assets/ or static/ instead)

Git Push Authentication, Ilmarë Website, Self-Hosted CMS Options & Landscape

Ilmarë Website

Fri, 01 May 2026 00:00:00 +0000

Ilmarë Website#

What Was Established#

Static Hugo site hosted on Varda (192.168.1.131).
Features CSS Grid layout, hamburger menu, and parallax hero.

Development Patterns#

Conditional Title Suffixes#

Goal: Append a suffix (e.g., /home) to the page title only on the index page.
Implementation: Leverage Hugo’s .IsHome boolean within template conditionals.

Pattern:

{{ if .IsHome }}{{ .Site.Title }}/home{{ else }}{{ .Title }}{{ end }}

or using a variable for cleaner syntax:

{{ $suffix := "" }}
{{ if .IsHome }}{{ $suffix = "/home" }}{{ end }}
{{ if .IsHome }}{{ .Site.Title }}{{ $suffix }}{{ else }}{{ .Title }}{{ end }}

Context: Applied to layouts/index.html or base templates to differentiate the root URL from inner pages.

Current Configuration#

Host: Varda (192.168.1.131)
Stack: Hugo static site generation
Template Engine: Go templates

Historical Notes#

Conversation dated 2025-11-24. Pattern confirmed for Hugo static site generation.

Open Questions#

None.

Sources#

ingested/chats/115-Adding -home to index page conditionally.md

Jellyfin Docker Compose Reference

Fri, 01 May 2026 00:00:00 +0000

Jellyfin Docker Compose Reference#

Canonical copy of /docker/jellyfin/compose.yaml on the servarr VM (192.168.1.112).

Jellyfin and Jellyseerr run in a separate compose file from the main Servarr stack, on their own Docker network (jellyfin_default, 172.18.0.0/16).

compose.yaml#

services:
  jellyfin:
    image: lscr.io/linuxserver/jellyfin:latest
    container_name: jellyfin
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/Los_Angeles
      - JELLYFIN_PublishedServerUrl=http://192.168.1.112 #optional
    volumes:
      - ./config:/config
      - /data:/data
      - ./jellyfin-web/config.json:/usr/share/jellyfin/web/config.json
    devices:
      - /dev/dri:/dev/dri #Use for Intel QuickSync
    ports:
      - 8096:8096
      - 7359:7359/udp #Service Discovery
      - 1900:1900/udp #Client Discovery
    restart: unless-stopped
    labels:
      - deunhealth.restart.on.unhealthy=true
    healthcheck:
      test: curl -f http://localhost:8096/health || exit 1
      interval: 60s
      retries: 3
      start_period: 30s
      timeout: 10s
# Remove the Jellyfin service if installed directly on system.

  jellyseerr:
    container_name: jellyseerr
    image: fallenbagel/jellyseerr:latest
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/Los_Angeles
    volumes:
      - ./jellyseerr:/app/config
    ports:
      - 5055:5055
    restart: unless-stopped

Key Details#

Network: Uses the auto-created jellyfin_default bridge network (172.18.0.0/16). Jellyseerr reaches the *arr services via the host IP (192.168.1.112) and their exposed ports.
GPU Passthrough: /dev/dri:/dev/dri enables Intel QuickSync hardware-accelerated transcoding.
PUID/PGID: Hardcoded to 1000 (unlike the servarr stack which uses .env variables).
TZ: America/Los_Angeles (note: servarr stack uses America/New_York).
Healthcheck: Already configured with deunhealth label — auto-restarts on unhealthy.
Custom web config: ./jellyfin-web/config.json is bind-mounted into the container for UI customization (e.g., the Hinterflix help link).

Directory Layout#

/docker/jellyfin/
├── compose.yaml
├── config/          # Jellyfin server config
├── jellyfin-web/
│   └── config.json  # Custom web UI config
└── jellyseerr/      # Jellyseerr app config

Jellyfin Help Link Integration

Fri, 01 May 2026 00:00:00 +0000

Jellyfin Help Link Integration#

What Was Established#

Goal: Integrate a persistent, user-facing help link directly into the Jellyfin UI for logged-in users, directing them to the Hinterflix documentation.
Methods Evaluated: Custom Login Message (pre-login only), Custom CSS (Dashboard > General), Reverse Proxy HTML injection (Nginx), Custom JavaScript, and Plugin-based solutions.
Selected Approach: Custom CSS injected via the Jellyfin Dashboard. It provides immediate visibility without requiring external dependencies or server restarts.

Key Decisions#

Placement: Prioritized persistent in-interface links over pre-login messages. Options included header navigation, floating action button, and sidebar integration.
Implementation Path: Chose Dashboard > General > Custom CSS for its simplicity and zero-dependency nature compared to reverse proxy modifications or plugin development.
Target URL: The CSS href attributes should point to the deployed Hinterflix help site (e.g., https://status.nbkelley.com or the specific docs subdomain).

Current Configuration#

Location: Jellyfin Web UI → Dashboard → General → Custom CSS
Active Selectors:
- headerTabs::after for top navigation bar integration
- body::after for a fixed floating action button (FAB)
- sidebarBox:last-child::after for sidebar menu integration
Dependencies: None. Relies entirely on Jellyfin’s built-in CSS injection capability.

Historical Notes#

Conversation dated 2025-11-22.
Jellyfin’s frontend framework (Ember.js/React hybrid) frequently updates CSS class names. Selectors like headerTabs and sidebarBox may break after major Jellyfin version upgrades, requiring CSS updates.
The sub_filter Nginx approach was considered but discarded in favor of native dashboard configuration to avoid proxy overhead and cache invalidation issues.

Open Questions#

Has the chosen CSS snippet been applied and verified against the current Jellyfin version running on the homelab?
Are there any specific UX guidelines or family-user constraints that dictate the preferred placement (header vs. floating vs. sidebar)?

Sources#

ingested/chats/128-Add User to Sudoers Group Guide.md
ingested/chats/113-Adding Help Link to Jellyfin Server.md
ingested/chats/028-Basic Header with Hamburger Menu Design.md
DeepSeek conversation: “Adding Help Link to Jellyfin Server” (2025-11-22)

Jellyfin LXC GPU Passthrough & Hardware Acceleration

Fri, 01 May 2026 00:00:00 +0000

Jellyfin LXC GPU Passthrough & Hardware Acceleration#

What Was Established#

Successfully configured Intel UHD Graphics 630 GPU passthrough to a Jellyfin LXC container on Proxmox for hardware-accelerated transcoding via Intel QuickSync (QSV).

Key Decisions#

GPU Passthrough Method: LXC container-level GPU device mapping (not full VM passthrough)
Hardware Acceleration: Intel QuickSync (QSV) selected over VAAPI for Jellyfin’s native support
Monitoring Constraints: Accepted that LXC container restrictions prevent full GPU monitoring tools (dmesg, intel_gpu_top) from functioning; validated functionality through actual transcoding tests instead

Current Configuration#

Host GPU Details#

GPU: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630]
PCI Address: 00:02.0
Driver: i915 (loaded)
Related Modules: drm_buddy, ttm, drm_display_helper, cec, i2c_algo_bit, video

LXC Container GPU Devices#

/dev/dri/card0 — character special (major 226, minor 0)
/dev/dri/renderD128 — character special (major 226, minor 128)
Permissions: crw-rw---- root:video (226/0 and 226/128)

Jellyfin Configuration#

User Group Assignment: jellyfin user added to video group (usermod -a -G video jellyfin)
Dashboard → Playback Settings:
- Hardware Acceleration: Intel QuickSync (QSV)
- Enable hardware encoding: Yes
- Enable hardware decoding: Yes
- Enable tone mapping: Yes
- Allow encoding in HEVC: Yes
- Allow encoding in AV1: Yes (if supported)

Validation Commands#

# Verify GPU device accessibility
ls -la /dev/dri/

# Check if processes are using GPU during playback
lsof /dev/dri/renderD128

# Monitor Jellyfin logs for hardware acceleration
sudo journalctl -u jellyfin -f | grep -i "hardware\|qsv\|quicksync\|vaapi"

# Check active transcoding sessions in Jellyfin UI
# Dashboard → Active Devices → look for (HW) indicator

Historical Notes#

dmesg restriction: dmesg: read kernel buffer failed: Operation not permitted — expected in LXC containers without full device access
intel_gpu_top limitation: GPU monitoring tools that require kernel debugfs access will not work inside the LXC; validated via actual transcoding performance and log inspection instead
i915 driver loaded: Confirmed via lsmod | grep i915 showing 3,928,064 bytes loaded
No GPU debug info: /sys/kernel/debug/dri not available in container — accepted limitation

Open Questions#

Does AV1 hardware encoding actually work on Coffee Lake-S (Gen 9.5) — typically limited to H.264/H.265
Performance baseline: what CPU load reduction is observed with QSV vs software transcoding?
Can GPU passthrough be extended to other LXC containers (e.g., Plex, if migrated)

Plex Transcoding LXC — similar GPU passthrough patterns for Plex
Proxmox LXC Configuration — LXC container setup patterns
Servarr - Media Automation Stack — media server ecosystem

Gluetun VPN Service

KVM Input Switch Sleep Issues

Fri, 01 May 2026 00:00:00 +0000

KVM Input Switch Sleep Issues#

What Was Established#

Switching inputs on a KVM switch can trigger connected PCs to enter sleep mode and fail to wake up. This is typically caused by EDID handshake interruptions or power management settings reacting to display signal loss when the KVM switches away from a connected machine.

Key Decisions & Troubleshooting Steps#

Hardware Model: Inland Dual 4K Display KVM Switch/Dock.
EDID Emulation: The most critical fix. Ensure the KVM is configured for EDID emulation (often via dip switches or firmware settings) to maintain a persistent display handshake and prevent the host OS from detecting a disconnected monitor.
Firmware Updates: Check manufacturer resources (e.g., Micro Center for Inland) for firmware updates to improve display handshake compatibility.
Windows Power Management:
- Set ‘Screen’ and ‘Sleep’ to ‘Never’ in Power & Sleep settings.
- Adjust NVIDIA Control Panel power management to ‘Prefer Maximum Performance’.
- Use Group Policy (gpedit.msc) to disable video/display power saving templates.
Linux Mint Power Management:
- Configure /etc/X11/xorg.conf to disable blank/standby/suspend/off times (ServerFlags section).
- Add xset s off and xset -dpms to startup applications.
- Modify GRUB cmdline (/etc/default/grub) with video=vesafb:off video=eefb:off drm_kms_helper.edid_firmware=edid/1920x1080.bin.
Hardware Checks: Use high-quality/shorter HDMI/DisplayPort cables, ensure direct monitor connections to KVM outputs, and utilize the KVM’s built-in USB hub for peripherals.
Workaround: Manual wake via brief power button press or keyboard input if automatic wake fails due to lost display signal.

Historical Notes#

Conversation date: 2025-11-29.
Specific to Inland Dual 4K KVM dock behavior.
EDID emulation is consistently the primary resolution for this class of KVM-induced sleep issues.

Open Questions#

Does the specific Inland dock model have a known firmware revision that fully resolves this behavior?
Are external EDID emulators required if built-in emulation remains insufficient?

wiki/hardware/monitor-standards.md
wiki/infrastructure/gpu-passthrough-lxc.md

Sources#

ingested/chats/122-KVM Input Switch Causes PC Sleep Issue.md

MBTA Dashboard - Frontend Implementation

Fri, 01 May 2026 00:00:00 +0000

MBTA Dashboard - Frontend Implementation#

What Was Established#

A portrait-mode (1080x1920) transit dashboard displaying real-time MBTA departures, commuter rail, weather, news, and a static transit map. Hosted on PLT-MBTADisplay (192.168.168.42), served via Nginx with a Node/Express proxy that handles all external API calls server-side. Target display is a 1080p vertical screen driven by Anthias on a Raspberry Pi 3B+.

Design Evolution#

The dashboard went through several major design iterations:

Initial: Line-based cards with MBTA colors, horizontal layout for 1080p TV
Minimalist redesign: White background, grey dividers, MBTA colors only on small abbreviated line pills (RL, OL, BL, GL-B/C/D/E), smaller station-only headers with walk time
Station-based cards: Cards grouped by station (South Station, State Street, Park Street) rather than by line, with all routes listed per station
Final portrait layout: 2-column CSS Grid, flex column containers, flat time-sorted departure list with line pills, full-width static map image at bottom

Layout (1080x1920 Portrait)#

2-column, 3-row card grid above a full-width static map image
Cards flex with content height (no preset card height)
CSS Grid with grid-template-columns: 1fr 1fr

Key Features#

CSS Ticker/Marquee#

Header text that overflows its container scrolls seamlessly in a ticker
Uses CSS animation with transform: translateX() — no JavaScript
Animation speed set slow for readability

Station-Based Grouping#

Cards grouped by physical station: South Station, State Street, Park Street
Each station card shows all lines serving that station
Departures sorted by time, each with abbreviated line pill (RL, OL, BL, GL-B, etc.)
Filtered to show departures within 10 minutes walking distance

Server-Side Proxy Architecture#

All API calls proxied through Node/Express on localhost:3000
Client fetches single /api/data endpoint — no direct browser-to-MBTA calls
API keys stored in environment variables, never exposed to browser
Server-side caching with TTL to reduce upstream API calls

News Ticker#

Pulls from multiple RSS feeds (MassLive Boston, State House News)
Displays first 3 items from each feed as <title> - <description>
Modular RSS feed configuration for easy addition of new sources

Static Map#

Originally Leaflet.js with OpenStreetMap and hardcoded markers
Replaced with static image for performance on Raspberry Pi
Generated via Snazzy Maps + PowerPoint, served as local webp file
Full-width, placed below the card grid

Performance & Optimization#

Memory Constraints (Raspberry Pi 3B+)#

Total system memory: 788MB
Dockerized Anthias viewer consumes significant resources
Strategies employed:
- Server-side proxy: Eliminates duplicate API calls from browser
- Lazy loading: Defer non-critical rendering
- DOM optimization: Remove unused elements, minimize reflows
- Image optimization: Convert to WebP, use static image over dynamic map
- Cache management: Server-side cache with periodic clearing
- Swap avoidance: Swap degrades SD card — keep memory footprint below physical RAM

Font Standardization#

Default to Arial for cross-platform consistency
Helvetica Neue as preferred fallback
Qt WebEngine (Anthias) renders fonts differently than desktop Chrome

Current Configuration#

Host: PLT-MBTADisplay (192.168.168.42)
Web root: /var/www/MBTADisplay/public
Proxy: /opt/mbta-proxy/server.js (Node/Express, port 3000)
Process manager: pm2 with systemd service (pm2-administrator)
Deployment: Git push → GitHub → manual pull on server
Access URLs: http://transit.intra.plgt.com (internal), https://mbtadash.nbkelley.com (Cloudflare)

Historical Notes#

Conversation dates: 2026-03-12 to 2026-04-12.
Collaborative workflow: Claude AI (creative/prompt engineering) → Claude Code (implementation).
Blue Bikes section was added, then fully removed when GBFS feed deprecated.
Ferry panel configuration evolved significantly — seasonal routes removed seasonally.
Several Claude Code UI hallucinations corrected by user during Bambu Studio discussion.

Sources#

ingested/chats/159-Create MBTA Train Dashboard with API.md
Claude Code conversation: “MBTADashboard - Prompt Maker” (chat 24)

MBTA Dashboard - Kiosk Mode

Fri, 01 May 2026 00:00:00 +0000

MBTA Dashboard - Kiosk Mode#

What Was Established#

The MBTA dashboard runs as a 24/7 kiosk display on a Raspberry Pi 3B+ using Anthias (formerly Screenly OSE) in Docker. The display is portrait 1080x1920. The Pi has severe memory constraints (788MB total) requiring aggressive optimization.

Anthias Deployment#

Hardware#

Device: Raspberry Pi 3B+ (788MB RAM)
Display: 1080x1920 portrait screen
Software: Anthias (Docker-based digital signage)

Display Configuration#

Dashboard page set as primary asset
Splash page appears for 1 minute every 11 hours 59 minutes as a refresh cycle
Page refreshes via cron job to prevent memory leaks

Cron Refresh#

# Refresh the kiosk page periodically to clear memory
0 */6 * * * docker restart screenly-anthias-viewer-1

Qt WebEngine Quirks#

Anthias uses Qt WebEngine for rendering, which differs from desktop Chrome:

MBTA Dashboard - Setup

Fri, 01 May 2026 00:00:00 +0000

MBTA Dashboard - Setup#

What Was Established#

Office transit dashboard deployed on a self-hosted Debian VM (PLT-MBTADisplay, 192.168.168.42). Nginx serves static files from /var/www/MBTADisplay/public and proxies /api/ requests to a Node/Express caching proxy on port 3000. API keys are stored server-side and never exposed to the browser. Process managed via pm2 with a systemd service.

Architecture#

Browser (Anthias/Desktop)
    → Nginx (:80) → / → static files (/var/www/MBTADisplay/public)
                   → /api/ → Node/Express proxy (:3000)
                                → MBTA v3 API
                                → OpenWeatherMap API
                                → RSS feeds
                                → Caches responses

Nginx Configuration#

server {
    listen 80;
    server_name transit.intra.plgt.com 192.168.168.42;

    root /var/www/MBTADisplay/public;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }

    location /api/ {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Node/Express Proxy#

Setup#

mkdir -p /opt/mbta-proxy
cd /opt/mbta-proxy
npm init -y
npm install express node-fetch

API Key Management#

API keys stored in /opt/mbta-proxy/.env
Loaded via process.env.MBTA_API_KEY in server.js
pm2 started with --env flag to load .env file
Critical: API key must survive server.js overwrites from GitHub syncs

pm2 Process Manager#

pm2 start server.js --name mbta-proxy
pm2 save
pm2 startup systemd

systemd Service (`/etc/systemd/system/pm2-administrator.service`)#

[Unit]
Description=PM2 process manager
After=network.target

[Service]
Type=forking
User=administrator
ExecStart=/usr/local/bin/pm2 resurrect
ExecReload=/usr/local/bin/pm2 reload all
ExecStop=/usr/local/bin/pm2 kill
Restart=on-failure

[Install]
WantedBy=multi-user.target

GitHub Deployment#

Repository#

Repo: https://github.com/bich-nguyen/MBTADisplay.git
Cloned to /var/www/MBTADisplay
Static files in public/ subdirectory
Server files in /opt/mbta-proxy/ (separate from web root)

Ownership#

sudo chown -R administrator:administrator /var/www/MBTADisplay

Note: www-data ownership breaks git operations from administrator user.

Mobile Hotspot & Proton VPN Troubleshooting

Fri, 01 May 2026 00:00:00 +0000

Mobile Hotspot & Proton VPN Troubleshooting#

What Was Established#

A PC connected to a mobile hotspot will always display a local/private IP address (e.g., 192.168.43.x) to communicate with the phone acting as the gateway/router.
Enabling Proton VPN on the mobile device does not automatically extend the encrypted tunnel to connected hotspot devices by default. This is due to app-level vs. system-level routing, separate network interfaces, and carrier/OS restrictions.
Public IP verification and DNS leak tests are required to confirm whether hotspot traffic is actually being routed through the VPN tunnel.

Key Decisions#

Local IP vs Public IP: Local IPs are expected and required for LAN communication; privacy and security are determined by the public IP and DNS resolution, not the local address.
VPN Extension Methods:
- Enable “Always-on VPN” and “VPN passthrough” in the phone’s hotspot/tethering settings.
- Install Proton VPN directly on the PC for guaranteed tunneling, kill switch functionality, and split tunneling control.
- Use USB tethering instead of Wi-Fi hotspot if Wi-Fi passthrough fails or is blocked by the carrier.
Order of Operations: Disabling and re-enabling the hotspot after establishing the VPN connection can force the routing table to update and apply the tunnel correctly.

Current Configuration#

N/A (General networking troubleshooting pattern applicable to remote management of homelab infrastructure like Isengard (192.168.1.69) or Legolas (192.168.1.45) via mobile data).

Historical Notes#

Conversation dated 2025-12-13.
Proton VPN mobile app behavior varies significantly by OS (iOS/Android) and mobile carrier; some devices natively block VPN over hotspot.
This pattern is relevant for remote homelab administration or travel scenarios where mobile data serves as the primary internet source.

Open Questions#

Does the specific mobile carrier or OS version in use support native VPN passthrough for hotspots without third-party apps?
Are there specific Proton VPN mobile app settings that consistently bypass carrier restrictions for tethering?

Sources#

ingested/chats/130-PC Local IP While Hotspot with VPN.md
DeepSeek conversation: PC Local IP While Hotspot with VPN (2025-12-13)

PLA Filament Troubleshooting & Calibration

Fri, 01 May 2026 00:00:00 +0000

PLA Filament Troubleshooting & Calibration#

What Was Established#

Switching PLA filament colors can cause functional failures even with identical models due to subtle differences in pigment, viscosity, shrinkage rates, and surface finish.
Whistle functionality is highly sensitive to airway geometry, fipple edge sharpness, and internal surface smoothness.
Top surface ironing in Bambu Studio can cause “dimple” pits due to over-melting, insufficient underlying support, or incorrect flow/speed ratios.

Key Decisions#

Functional Failure (Color Switch)#

Dimensional Accuracy: Different pigments cause varying shrinkage. A 0.1-0.2mm variance in airway width or fipple can kill sound.
- Fix: Run a Temperature Tower and Flow Rate/Extrusion Multiplier Calibration for the new color.
Surface Finish & Friction: Viscosity differences affect interior surface smoothness.
- Fix: Lower print temperature by 5-10°C to reduce glossiness and sharpen the fipple edge. Max cooling fan (100%) during ironing/printing.
Moisture: New filament rolls may absorb ambient moisture, causing bubbling and inconsistent extrusion.
- Fix: Dry filament at 45-50°C for 4-6 hours.
Retraction/Oozing: Viscosity changes can cause stringing inside the airway.
- Fix: Increase retraction distance by 0.5-1mm or increase speed. Enable “Retract on Layer Change”.
Post-Processing: Critical for fipple edges.
- Fix: Use folded printer paper or a precision knife to manually deburr and sharpen the internal fipple edge. Probe airway with thin filament to check for obstructions.

Surface Pitting (Ironing)#

Over-Ironing: Excessive ironing flow or low nozzle height displaces molten plastic, creating waves that solidify into pits.
- Fix: Reduce Ironing Flow by half (e.g., 10% -> 5%). Increase Ironing Speed by 20-30%. Adjust Ironing Line Spacing wider (e.g., 0.1mm -> 0.15mm).
Insufficient Support: Too few top layers or low infill density causes the top surface to deflect into the infill pattern.
- Fix: Increase Top Layers to 4-6. Increase Infill Density to 20-25% using Gyroid or Rectilinear patterns.
Temperature Sensitivity: Blue PLA may be more heat-sensitive.
- Fix: Set Ironing Temperature 5-10°C lower than normal print temp. Ensure 100% fan cooling during the ironing pass.

Alternative Approach (Skip Ironing)#

Ironing is aesthetic and unnecessary for functional parts like whistle bodies.
Fix: Rely on standard top layer settings: Top Layer Flow at 105-110%, smaller Top Layer Line Width (e.g., 0.3mm on 0.4mm nozzle), and sufficient Infill Overlap (15-20%).

Current Configuration#

Baseline Ironing Settings (Clean Ironing):
- Top Layers: 5
- Infill Density: 25% (Gyroid)
- Ironing: Enabled
- Ironing Flow: 5%
- Ironing Speed: 100 mm/s (or 1.5x normal top layer speed)
- Ironing Temperature: -5°C from base print temp
- Fan during Ironing: 100%
Standard Top Layer Fallback:
- Top Layer Flow: 105-110%
- Top Layer Line Width: 0.3mm (on 0.4mm nozzle)
- Infill Overlap: 15-20%

Historical Notes#

Conversation date: 2026-02-01.
Specific to Bambu Studio slicer settings and PLA filament behavior.
No specific hardware or software versions mentioned beyond standard PLA and Bambu Studio ironing features.
No known changes to filament manufacturing standards or slicer algorithms since this date.

Open Questions#

Does the specific blue PLA brand have known shrinkage characteristics compared to the green PLA?
Are there slicer profiles or G-code modifiers specifically tuned for whistle geometries?

Bambu Studio Layer G-code

Sources#

ingested/chats/163-Troubleshooting Blue PLA 3D Printed Whistles.md
Historical DeepSeek conversation (2026-02-01) on 3D printed whistle troubleshooting.

PowerShell Local PC Scripting Patterns

Fri, 01 May 2026 00:00:00 +0000

PowerShell Local PC Scripting Patterns#

What Was Established#

A collection of PowerShell scripting patterns for local PC automation tasks, including folder renaming from CSV data, and basic system administration.

Key Decisions#

CSV-driven automation: Use Import-Csv with Rename-Item for bulk folder renaming driven by spreadsheet data.
Path validation: Always Test-Path before operating to avoid errors on missing sources or existing destinations.
Error handling: Wrap rename operations in conditional checks; log warnings rather than failing silently.

Folder Renaming from CSV#

CSV format (folder_renaming.csv):

Proxmox LXC Storage Mounts

Fri, 01 May 2026 00:00:00 +0000

Proxmox LXC Storage Mounts#

What Was Established#

SMB/CIFS shares can be integrated into Proxmox via CLI or the Web GUI.
GUI integration is recommended for Proxmox-native features (backups, ISOs, templates) and automatic retention management.
LXC containers can directly mount Proxmox storage paths using mp0/mp1 directives in the container config file.
Separate CIFS storages should be used for media vs. backups to maintain clean separation of concerns.

Key Decisions#

Storage Content Types: For media-only CIFS shares, select Container templates, ISO images, or Disk image. Explicitly avoid Containers and VZDump backup file to prevent Proxmox from treating the media share as a system storage.
Subdirectory Configuration: Leave the Proxmox storage subdirectory field blank to mount the root of the SMB share, enabling flexible navigation to specific subfolders (e.g., Documents/Movies).
Jellyfin Path Targeting: Point Jellyfin directly to the specific media subfolder (e.g., /media/synology/Documents/Movies) rather than the mount root.

Current Configuration#

LXC Config Path: /etc/pve/lxc/<CT-ID>.conf (e.g., /etc/pve/lxc/100.conf).
Mount Syntax: mp0: /mnt/pve/<Storage-ID>,mp=/media/<mount-name>

Permission Mapping (for unprivileged containers):

lxc.idmap: u 0 100000 65536
lxc.idmap: g 0 100000 65536
lxc.idmap: u 1000 1000 1
lxc.idmap: g 1000 1000 1
lxc.idmap: u 1001 101001 64535
lxc.idmap: g 1001 101001 64535

Jellyfin Setup: Dashboard → Libraries → Add Media Library → Folders: /media/synology/Documents/Movies.

Historical Notes#

Conversation date: 2025-11-07.
Focuses on resolving LXC mount visibility and permission issues for Jellyfin on a Synology NAS.
No major infrastructure changes flagged; patterns remain valid for Proxmox 8.x.

Open Questions#

None.

Sources#

ingested/chats/092-Mount NAS Storage to LXC Containers.md
ingested/chats/091-Mount Synology SMB to Proxmox Guide.md
ingested/chats/090-Mount SMB Share on Proxmox Guide.md
DeepSeek conversation: Mount NAS Storage to LXC Containers (2025-11-07)

Sources#

ingested/chats/092-Mount NAS Storage to LXC Containers.md
ingested/chats/091-Mount Synology SMB to Proxmox Guide.md
ingested/chats/090-Mount SMB Share on Proxmox Guide.md
Historical DeepSeek conversation: “Mount SMB Share on Proxmox Guide” (2025-11-07)

Proxmox Storage Management, Proxmox Systemd Mounts

Proxmox NVMe Partition Management

Fri, 01 May 2026 00:00:00 +0000

Proxmox NVMe Partition Management#

What Was Established#

Advanced manual partitioning strategy for separating OS and VM/Container data on a single NVMe drive.
Recommended for test clusters where OS reinstalls are expected without risking data loss on the storage partition.
Uses sgdisk to create distinct partitions that Proxmox treats as independent storage targets.

Key Decisions#

Partition Layout: EFI (1GB), OS (~100GB), Data (remaining ~399GB).
Tooling: sgdisk for GPT partitioning, mkfs.ext4/mkfs.fat for formatting, manual mounting for data.
Storage Integration: Data partition mounted at /mnt/data and added as a Directory storage in Proxmox.

Current Configuration#

Target Hardware: 3x Laptops with 500GB NVMe drives.
Partition Scheme:
- /dev/nvme0n1p1: 1GB EFI System Partition (FAT32)
- /dev/nvme0n1p2: ~100GB Proxmox OS (ext4)
- /dev/nvme0n1p3: ~399GB VM/Container Data (ext4)
Post-Install Mount: Data partition mounted at /mnt/data and auto-mounted via /etc/fstab.

Historical Notes#

As of 2026-02-28, the user opted for the “complex” manual partitioning approach over the installer’s built-in LVM/ZFS options to ensure OS and data appear as totally separate drives.
This method requires dropping to a shell during installation and manually launching proxinstall.

Open Questions#

How does this partitioning scheme interact with future ZFS pool expansions if the laptops are clustered?
Are there specific sgdisk flags needed for NVMe drives in UEFI mode?

Proxmox Storage Management
Proxmox ZFS Storage & Installation Patterns
Proxmox ZFS Storage Setup

Sources#

ingested/chats/013-Set Up Proxmox with LVM and ZFS.md
DeepSeek conversation: Proxmox OS and Storage Separation Guide (2026-02-28)

Proxmox Storage Management

Fri, 01 May 2026 00:00:00 +0000

Proxmox Storage Management#

title: Proxmox Storage Management version: 1.2 date: 2026-04-30 namespace: general wiki: homelab tags: [proxmox, storage, smb, cifs, zfs, backups] changes: Crystallized from historical DeepSeek conversation historical: true#

Proxmox Storage Management#

What Was Established#

SMB/CIFS shares can be integrated into Proxmox via CLI or the Web GUI.
GUI integration is recommended for Proxmox-native features (backups, ISOs, templates) and automatic retention management.
Local disk inspection (e.g., sda2) requires verifying mount status and filesystem type to avoid conflicts with active root partitions.

CLI Mounting (Persistent)#

Install utilities: apt update && apt install cifs-utils
Create credentials file: /etc/smb-credentials with chmod 600.
Add to /etc/fstab: //server/share /mnt/smb-share cifs credentials=/etc/smb-credentials,uid=0,gid=0,file_mode=0660,dir_mode=0770,iocharset=utf8 0 0
Test mount: mount -a

GUI Mounting (Proxmox Native)#

Navigate to Datacenter → Storage → Add → SMB/CIFS.
Required Fields: ID, Server, Share, Username, Password.
Content Types (select based on use case):
- ISO images
- Container templates
- VZDump backup files
Advanced Options: Max Backups, Prune Backups, SMB Version (e.g., 3.0), Domain.
Verification: Green checkmark in Storage list indicates active status. Use “Test Connection” if available.

Local Disk Inspection#

Check status: lsblk, blkid /dev/sda2, mount | grep sda2.
Mount temporarily: mount /dev/sda2 /mnt/sda2.
Inspect: ls -la /mnt/sda2, df -h, du -sh /mnt/sda2/*.
Note: sda2 is typically the root partition on Proxmox hosts; avoid modifying if already mounted at /.

Open Questions#

Specific purpose of sda2 on Isengard (192.168.1.69)? (Likely root, but verify with lsblk/blkid).
SMB share usage for LonelyMountain (192.168.1.137) backups vs ISOs? (GUI method preferred for VZDump retention).

Proxmox Systemd Mounts — systemd mount units for NAS shares Proxmox LXC Storage Mounts — LXC bind mounts and permission mapping Proxmox ZFS Storage & Installation Patterns Proxmox NVMe Partition Management TrueNAS (Vairë) - Storage & Backup Server

Proxmox Systemd Mounts

Fri, 01 May 2026 00:00:00 +0000

Proxmox Systemd Mounts#

What Was Established#

SMB/CIFS shares can be integrated into Proxmox via CLI or the Web GUI.
GUI integration is recommended for Proxmox-native features (backups, ISOs, templates) and automatic retention management.
System-level mounts (e.g., at /media/synology) are distinct from Proxmox Storage and are used for general file operations accessible by the host OS.
Proxmox automatically mounts SMB shares under /mnt/pve/<storage_id> when configured via the GUI.

Key Decisions#

Maintain both a Proxmox Storage entry (for VM disks/backups) and a system-level mount (for general file access).
Extract credentials from /etc/pve/storage.cfg to avoid hardcoding passwords in multiple places.
Use pvesm status to verify existing storage mounts and avoid conflicts.

Current Configuration#

Synology NAS (LonelyMountain): 192.168.1.137
Proxmox Storage: Configured via Datacenter > Storage (SMB/CIFS) for VM-related content.
System Mount: Targeted at /media/synology for general file operations.

System-Level Mount Methods#

1. Extract Credentials & Create System Mount#

Check existing Proxmox storage: pvesm status
Extract server/share info from /etc/pve/storage.cfg

Create credentials file:

nano /root/.smbcredentials
# Add: username=your_username, password=your_password
chmod 600 /root/.smbcredentials

Add to /etc/fstab:

//192.168.1.137/share_name /media/synology cifs credentials=/root/.smbcredentials,uid=0,gid=0,file_mode=0660,dir_mode=0770,iocharset=utf8 0 0

Test: mount -a

2. Systemd Mount Unit (Recommended for robustness)#

Create /etc/systemd/system/media-synology.mount:

Proxmox VM Boot Troubleshooting

Fri, 01 May 2026 00:00:00 +0000

Proxmox VM Boot Troubleshooting#

What Was Established#

Ubuntu VMs can hang during the boot process at apparmor.service (displayed as “staring apparmor.service - L:oad appArmor profiles…”).
In Proxmox, this specific hang was caused by an iGPU (…)

Coffee Lake iGPU Passthrough Freeze & Recovery#

Issue: Coffee Lake iGPU passthrough to an Ubuntu VM causes the Proxmox VM to freeze on boot.
Immediate Recovery Steps (run from Proxmox host console):
1. Stop the frozen VM: qm stop <VMID> --force or kill -9 <PID> via ps aux | grep qemu.
2. Remove iGPU from VM config: Edit /etc/pve/qemu-server/<VMID>.conf and remove hostpci lines and GPU-related args: lines.
3. Reset host iGPU state: Edit /etc/modprobe.d/pve-blacklist.conf and comment out blacklist i915.
4. Reboot host: update-initramfs -u -k all && reboot.
5. Verify host recovery: lspci | grep -i vga and lsmod | grep i915.
Proper Re-configuration Steps:
1. Enable IOMMU: Update /etc/default/grub with GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt", then update-grub && reboot.
2. Verify IOMMU Groups: find /sys/kernel/iommu_groups/ -type l.
3. Add iGPU via UI: VM → Hardware → Add PCI Device → Select iGPU → Check “All Functions” & “PCI-Express” → DO NOT check “Primary GPU”.
Advanced/Alternative Configuration:
- GRUB Parameters: quiet intel_iommu=on iommu=pt pcie_acs_override=downstream,multifunction nofb nomodeset video=efifb:off
- Host Blacklist: echo "blacklist i915" >> /etc/modprobe.d/pve-blacklist.conf
- VM Config (args):
```
args: -device vfio-pci,host=00:02.0,addr=0x18,x-igd-gms=1,driver=vfio-pci
args: -device vfio-pci,host=00:02.1,addr=0x18.1,driver=vfio-pci
args: -global ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off
args: -set device.vga.ramfb=off
args: -set device.vga.driver=vfio-pci
```
- VM Hardware Requirements: Machine q35, BIOS OVMF (UEFI), Display Default (not SPICE).
- Ubuntu VM Guest: Install Intel graphics drivers, add i915.enable_guc=2 to kernel parameters, ensure early KMS start.

Sources#

ingested/chats/103-Troubleshooting Coffee Lake iGPU Passthrough on Proxmox.md
ingested/chats/101-Troubleshooting Slow Ubuntu VM Boot.md

Proxy Management & Cloudflare Tunnels

Fri, 01 May 2026 00:00:00 +0000

Proxy Management & Cloudflare Tunnels#

What Was Established#

There are multiple layers of proxying available in the homelab, ranging from edge protection (Cloudflare) to local routing (OPNsense/Nginx Proxy Manager).

Nginx Proxy Manager (NPM) Troubleshooting#

Redirect Loops & Timeouts: Often caused by misconfigured upstream servers or aggressive timeout settings in NPM’s web UI. Resolving a redirect loop may expose underlying connectivity issues that manifest as timeouts.
Docker Compose Pattern: NPM is deployed with network_mode: host to bind directly to host ports (80, 443, 81), bypassing Docker’s NAT for direct host network access.
Verification Steps:
1. Check container health: docker ps | grep nginx-proxy-manager (ensure healthy status).
2. Verify port bindings: sudo netstat -tulpn | grep :80 / :443 (requires net-tools package).
3. Inspect NPM Web UI: Access at http://<host-ip>:81 to review Proxy Host settings, specifically timeout values and upstream server addresses.
Port Conflicts: Use netstat to identify which container owns a specific port (e.g., docker-proxy vs nginx: master). In this setup, port 8000 was observed bound to docker-proxy, indicating another service in the compose stack.
Co-located Services: The same Docker Compose stack hosts cloudflare-ddns (for dynamic IP updates) and netbird (for mesh networking), requiring careful port management to avoid conflicts.

Key Decisions#

Use network_mode: host for NPM to simplify port mapping and ensure direct access to host network interfaces.
Rely on net-tools (netstat) for quick port binding verification in host-networked Docker containers.

Current Configuration#

Docker Host: iluvatar@proxy (192.168.1.208)
NPM Web UI: http://192.168.1.208:81
Ports: 80 (HTTP), 443 (HTTPS), 81 (NPM Admin UI)

Historical Notes#

Troubleshooting session from 2025-11-17 resolved a redirect loop that subsequently turned into a timeout issue.
net-tools installation was required to diagnose port bindings on the host.

Open Questions#

Specific timeout values configured in NPM for upstream services.
Whether netbird or cloudflare-ddns requires dedicated port exposure or can share the host network.

Uptime Kuma - Configuration & Integrations

Self-Hosted CMS Options & Landscape

Fri, 01 May 2026 00:00:00 +0000

Self-Hosted CMS Options & Landscape#

What Was Established#

User seeks a self-hosted CMS for an Ubuntu VM, explicitly rejecting WordPress due to business practices.
Preference for tools respected by the web development and self-hosting communities.
Exploration of CMS categories: Monolithic, Flat-file, Static Site Generators (SSG), Headless CMS, and Custom.

Key Decisions#

Rejected WordPress: Cited business practices as a dealbreaker.
Favoring Developer-Respected Alternatives: Leaned towards headless or modern flat-file CMS options.
Top Contenders Identified: Directus (Headless), Strapi (Headless), Kirby (Flat-file), Payload CMS (Headless/TS), Ghost (Blogging).

CMS Landscape & Options#

Monolithic CMS#

WordPress: Dominant (60% market), huge ecosystem, but rejected by user.
Drupal: Flexible, steep learning curve.
Joomla: Balanced ease/power, smaller community.

Flat-file CMS (No Database)#

Grav: Fast, simple, file-based.
Kirby: Beautiful UI, file-based, commercial license (~$129), highly respected by designers/devs.

Static Site Generators (SSG)#

Jekyll: GitHub Pages compatible.
Hugo: Blazing fast, Go-based.
Eleventy: Flexible, JS-based.
Next.js: React-based, hybrid.

Headless CMS (API-Driven)#

Directus: Community favorite. Node.js/Vue.js. Provides REST/GraphQL APIs, beautiful admin UI. Excellent for full frontend control.
Strapi: Most popular headless. Node.js/React. Strong plugin ecosystem.
Payload CMS: Rising star. TypeScript-first, excellent DX.
Ghost: Primarily for blogging/publishing. Markdown-native.
Contentful/Sanity: Enterprise/Developer friendly, but often cloud-hosted (though self-hostable options exist).

Custom / Build-Your-Own#

The Guardian’s “Composer”: Fully custom-built in Scala/Play Framework. Not recommended for small projects.
Server-Side: PHP includes, Python (Django/Flask), Node.js (Express).

Recommended Stack for Ubuntu#

For Maximum Control & Flexibility: Directus or Payload CMS.
For Content-Focused Sites: Kirby or Statamic.
For API-Driven Projects: Strapi.

Quick Start (Directus on Ubuntu):

curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt-get install -y nodejs
npm create directus-project@latest my-cms
cd my-cms
npm install
npx directus start

Historical Notes#

Conversation date: 2025-11-17.
User explicitly stated a preference against WordPress due to business practices.
Focus remains on self-hosted, developer-respected tools.
Note: Directus and Strapi have evolved significantly since late 2025; verify current self-hosting requirements, licensing, and Docker compatibility for homelab deployment.

Hugo-Specific Configuration#

Project Structure#

myblog/
├── config.toml   -- Main configuration (baseURL, languageCode, title, theme)
├── content/      -- Blog posts in Markdown
├── themes/       -- Installed themes (git submodules)
├── static/       -- Static assets (images, JS, CSS)
└── public/       -- Generated static files (deployed to Nginx)

Key config.toml Settings#

baseURL — Domain URL (e.g., https://blog.nbkelley.com)
theme — Must match theme folder name in themes/
buildDrafts — true during development, false for production
paginate — Posts per page

Creating Posts#

hugo new posts/my-post.md  # Draft in content/posts/
hugo -D                     # Build including drafts
hugo                        # Production build to public/

Deployment Options#

Manual rsync: rsync -avz --delete public/ user@server:/var/www/html/blog
Git webhook: Server-side script that git pull && hugo && cp -r public /var/www/html/blog on push
Cloudflare Pages: Push Hugo source to GitHub, Cloudflare builds and deploys automatically

Comments for Static Sites#

Utterances — GitHub issues-based, no backend
Disqus — Traditional, JS-based
Hyvor Talk — Self-hostable alternative

Sources#

ingested/chats/106-Beginner Guide to Building Websites with Ubuntu.md
ingested/chats/036-Setting Up Self-Hosted Blogs with Nginx.md
DeepSeek conversation: “Self-Hosted Websites on Ubuntu Server” (historical)
DeepSeek conversation: “Setting Up Self-Hosted Blogs with Nginx” (chat 036)

Servarr - Media Automation Stack

Fri, 01 May 2026 00:00:00 +0000

Servarr - Media Automation Stack#

Overview#

Servarr is a full VM at 192.168.1.112 (hostname: servarr) running a Docker Compose media automation stack. All services depend on a NAS mount at /data for media storage. Download clients (qbittorrent, nzbget) and indexer (prowlarr) route through a Gluetun VPN container via network_mode: service:gluetun.

Note: This VM is distinct from Varda (192.168.1.131), which is a separate web server hosting ilmare.nbkelley.com.

VM Specs#

Detail	Value
Hostname	`servarr`
IP	`192.168.1.112`
OS	Ubuntu 24.04.4 LTS (Noble)
Kernel	6.8.0-107-generic
CPU	QEMU Virtual CPU, 4 vCPUs
RAM	7.8 GB
Disk	63 GB root (`/dev/sda2` ext4, 38% used)
Hypervisor	Proxmox (Minas Tirith)

Container Inventory#

Servarr Stack (`/docker/servarr/compose.yaml`)#

Network: servarrnetwork (172.39.0.0/24)

Servarr Docker Compose Reference

Fri, 01 May 2026 00:00:00 +0000

Servarr Docker Compose Reference#

Canonical copy of /docker/servarr/compose.yaml on the servarr VM (192.168.1.112).

compose.yaml#

# Compose file for the *arr stack. Configuration files are stored in the
# directory you launch the compose file on. Change to bind mounts if needed.
# All containers are ran with user and group ids of the main user and
# group to aviod permissions issues of downloaded files, please refer
# the read me file for more information.

#############################################################################
# NOTICE: We recently switched to using a .env file. PLEASE refer to the docs.
# https://github.com/TechHutTV/homelab/tree/main/media#docker-compose-and-env
#############################################################################

networks:
  servarrnetwork:
    name: servarrnetwork
    ipam:
      config:
        - subnet: 172.39.0.0/24

services:
  # airvpn recommended (referral url: https://airvpn.org/?referred_by=673908)
  gluetun:
    image: qmcgaw/gluetun
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun # If running on an LXC see readme for more info.
    networks:
      servarrnetwork:
        ipv4_address: 172.39.0.2
    ports:
      - ${FIREWALL_VPN_INPUT_PORTS}:${FIREWALL_VPN_INPUT_PORTS} # airvpn forwarded port, pulled from .env
      - 8080:8080 # qbittorrent web interface
      - 6881:6881 # qbittorrent torrent port
      - 6789:6789 # nzbget
      - 9696:9696 # prowlarr
    volumes:
      - ./gluetun:/gluetun
    # Make a '.env' file in the same directory.
    env_file:
      - .env
    healthcheck:
      test: ping -c 1 www.google.com || exit 1
      interval: 20s
      timeout: 10s
      retries: 5
    restart: unless-stopped

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    restart: unless-stopped
    labels:
      - deunhealth.restart.on.unhealthy=true
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - WEBUI_PORT=8080 # must match "qbittorrent web interface" port number in gluetun's service above
      - TORRENTING_PORT=${FIREWALL_VPN_INPUT_PORTS} # airvpn forwarded port, pulled from .env
    volumes:
      - ./qbittorrent:/config
      - /data:/data
    depends_on:
      gluetun:
        condition: service_healthy
        restart: true
    network_mode: service:gluetun
    healthcheck:
      test: ping -c 1 www.google.com || exit 1
      interval: 60s
      retries: 3
      start_period: 20s
      timeout: 10s

  # See the 'qBittorrent Stalls with VPN Timeout' section for more information.
  deunhealth:
    image: qmcgaw/deunhealth
    container_name: deunhealth
    network_mode: "none"
    environment:
      - LOG_LEVEL=info
      - HEALTH_SERVER_ADDRESS=127.0.0.1:9999
      - TZ=${TZ}
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

  nzbget:
    image: lscr.io/linuxserver/nzbget:latest
    container_name: nzbget
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./nzbget:/config
      - /data:/data
    depends_on:
      gluetun:
        condition: service_healthy
        restart: true
    restart: unless-stopped
    network_mode: service:gluetun

  prowlarr:
    image: lscr.io/linuxserver/prowlarr:latest
    container_name: prowlarr
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./prowlarr:/config
    restart: unless-stopped
    depends_on:
      gluetun:
        condition: service_healthy
        restart: true
    network_mode: service:gluetun

  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    restart: unless-stopped
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./sonarr:/config
      - /data:/data
    ports:
      - 8989:8989
    networks:
      servarrnetwork:
        ipv4_address: 172.39.0.3

  radarr:
    image: lscr.io/linuxserver/radarr:latest
    container_name: radarr
    restart: unless-stopped
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./radarr:/config
      - /data:/data
    ports:
      - 7878:7878
    networks:
      servarrnetwork:
        ipv4_address: 172.39.0.4

  lidarr:
    container_name: lidarr
    image: lscr.io/linuxserver/lidarr:latest
    restart: unless-stopped
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./lidarr:/config
      - /data:/data
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    ports:
      - 8686:8686
    networks:
      servarrnetwork:
        ipv4_address: 172.39.0.5

  bazarr:
    image: lscr.io/linuxserver/bazarr:latest
    container_name: bazarr
    restart: unless-stopped
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./bazarr:/config
      - /data:/data
    ports:
      - 6767:6767
    networks:
      servarrnetwork:
        ipv4_address: 172.39.0.6

# Newer additions to this stack feel. Remove the '#' to add the service.

  ytdl-sub:
    image: ghcr.io/jmbannon/ytdl-sub-gui:latest
    container_name: ytdl-sub
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - DOCKER_MODS=linuxserver/mods:universal-cron
    volumes:
      - ./ytdl-sub:/config
      - /data/youtube:/youtube
    networks:
      servarrnetwork:
        ipv4_address: 172.39.0.8
    restart: unless-stopped

#  jellyseerr:
#    container_name: jellyseerr
#    image: fallenbagel/jellyseerr:latest
#    environment:
#      - PUID=${PUID}
#      - PGID=${PGID}
#      - TZ=${TZ}
#    volumes:
#      - ./jellyseerr:/app/config
#    ports:
#      - 5055:5055
#    networks:
#      servarrnetwork:
#        ipv4_address: 172.39.0.9
#    restart: unless-stopped

Network Architecture#

172.39.0.0/24 (servarrnetwork)
├── 172.39.0.2  gluetun (VPN gateway)
│   ├── qbittorrent  (network_mode: service:gluetun)
│   ├── nzbget       (network_mode: service:gluetun)
│   └── prowlarr     (network_mode: service:gluetun)
├── 172.39.0.3  sonarr
├── 172.39.0.4  radarr
├── 172.39.0.5  lidarr
├── 172.39.0.6  bazarr
└── 172.39.0.8  ytdl-sub

Key Patterns#

VPN routing: qbittorrent, nzbget, and prowlarr use network_mode: service:gluetun to route all traffic through the VPN. They are NOT directly on servarrnetwork.
Static IPs: Media managers (sonarr, radarr, lidarr, bazarr) use static IPs on servarrnetwork for predictable inter-container communication.
.env file: Secrets (PUID, PGID, TZ, FIREWALL_VPN_INPUT_PORTS, VPN credentials) are stored in .env in the same directory.
deunhealth: Monitors container health via Docker socket and restarts unhealthy containers with the deunhealth.restart.on.unhealthy=true label.
Config persistence: Each service’s config is stored in a subdirectory of /docker/servarr/ (e.g., ./sonarr, ./radarr).
Media storage: All containers bind-mount /data (SMB share from NAS at 192.168.1.137) for media access.
jellyseerr: Commented out here — deployed in /docker/jellyfin/compose.yaml instead.

Servarr Stack - Gluetun VPN Troubleshooting

Fri, 01 May 2026 00:00:00 +0000

Servarr Stack - Gluetun VPN Troubleshooting#

Historical note: This session was conducted on a machine at 192.168.1.30 (hostname possibly “Varda” at the time, directory ~/home/nbkelley/docker/servarr). The current production Servarr stack lives on the servarr VM at 192.168.1.112, directory /docker/servarr/. See Servarr - Media Automation Stack for current configuration. The troubleshooting patterns documented here remain applicable.

What Was Established#

This session documents the deployment and troubleshooting of the Servarr media automation stack (Sonarr, Prowlarr, qBittorrent) behind a Gluetun VPN container. The stack relies on network_mode: service:gluetun to route all container traffic through AirVPN.

SSH Host Key Management & Troubleshooting

Fri, 01 May 2026 00:00:00 +0000

SSH Host Key Management & Troubleshooting#

What Was Established#

Standard procedures for resolving SSH REMOTE HOST IDENTIFICATION HAS CHANGED warnings, which occur when a host’s SSH fingerprint differs from the locally stored known_hosts entry. This typically happens after a server reinstall, OS upgrade, or SSH key regeneration.

Key Decisions & Commands#

Verify Legitimacy: Always confirm with a system administrator or check server logs if a key change is unexpected, as it could indicate a man-in-the-middle attack.
Remove Stale Keys: Use ssh-keygen -R <hostname> to safely remove the outdated entry from ~/.ssh/known_hosts.
Targeted Removal: If the error specifies a line number (e.g., line 9), you can remove it via sed -i '' '9d' ~/.ssh/known_hosts or manually edit the file.
Pre-populate Keys: In managed environments, use ssh-keyscan <host> >> ~/.ssh/known_hosts to automate key acceptance.
Security Best Practice: Prefer certificate-based authentication in sensitive environments to bypass host key checking entirely.

Current Configuration#

Host Encountered: proxy (192.168.1.222, Nginx Proxy Manager)
User Context: Commands executed from macOS (NK---Galadriel) as user natekelley.
Fingerprint Example: SHA256:k5j8V356rpQXapznIs12MeBEWHfZYwfeicXdNNWFyOI (ED25519)

Historical Notes#

Initial troubleshooting documented on 2025-11-17. The proxy host likely had its underlying VM/container rebuilt or its SSH configuration reset, triggering the warning.

Open Questions#

Should SSH host keys be version-controlled or managed via a configuration management tool (e.g., Ansible) to prevent future mismatches?

Sources#

ingested/chats/111-Check and Install Git, Go, Dart Sass on Ubuntu.md
ingested/chats/104-SSH Host Key Change Warning and Fix.md
Historical DeepSeek conversation: SSH Host Key Change Warning and Fix (2025-11-17)

Uptime Kuma - Configuration & Integrations

Fri, 01 May 2026 00:00:00 +0000

Uptime Kuma - Configuration & Integrations#

What Was Established#

Aruba Instant On Switch Monitoring: Confirmed that Aruba Instant On switches (specifically 1930 and 1960 series) support SNMP monitoring when configured via their local web interface, despite being primarily cloud-managed.
Microsoft Teams Webhook Integration: Established the correct method for routing Uptime Kuma alerts to Microsoft Teams using Power Automate Workflows, noting the deprecation of legacy webhook.office.com connectors.

Key Decisions#

SNMP over Ping: While basic ping monitoring is viable for switch reachability, SNMP is preferred for detailed port status and traffic metrics on supported Aruba models.
Power Automate for Teams Alerts: Migrated away from deprecated Office 365 Connectors (webhook.office.com) to Power Automate Workflows to ensure long-term compatibility with Uptime Kuma webhooks.

Current Configuration#

Aruba Instant On Switches (1930/1960 Series)#

Network Setup: Assign a static IP address to the switch via the Aruba Instant On cloud portal or local interface.
SNMP Enablement:
- Access the switch’s local web interface.
- Navigate to SNMP settings (typically under “Switching” or “Management”).
- Enable the SNMP agent.
- Configure SNMPv2c (read-only community string) or SNMPv3 (username/password with optional encryption). Restrict access by IP for security.
- Reboot the switch if required for settings to apply.
Uptime Kuma Monitor:
- Add a new monitor of type SNMP.
- Input the switch’s static IP, selected SNMP version, and credentials.
- Customize OIDs if monitoring specific interface traffic or port status beyond system uptime.

Microsoft Teams Webhook Notifications#

Notification Type: Webhook (Generic Webhook).
Post URL: Power Automate Workflow endpoint URL (e.g., https://prod-05.westus.logic.azure.com/...).
Content Type: application/json.
Testing: Use the “Test” button in Uptime Kuma notification settings to verify connectivity. A 400 error typically indicates a malformed payload or deprecated connector URL.

Historical Notes#

Legacy Connector Deprecation: Microsoft retired the old “Office 365 Connectors” on October 1, 2024. Any Uptime Kuma setups using webhook.office.com URLs will fail and require migration to Power Automate.
SNMP Availability: Early guidance incorrectly stated Aruba Instant On switches lack SNMP support. It was later confirmed that local management interfaces on 1930/1960 models fully support SNMPv2c/v3.

Open Questions#

Are there specific OIDs recommended for Aruba Instant On 1930/1960 switches to monitor port-level errors or traffic thresholds?
Has the Uptime Kuma version been verified against known bugs with Power Automate JSON payloads?

UniFi Express VPN & Network Management

Varda Server (Ubuntu)

Fri, 01 May 2026 00:00:00 +0000

Varda Server (Ubuntu)#

Overview#

Varda is an Ubuntu Server VM at 192.168.1.131 used for web hosting and development. It serves as the primary host for the ilmare.nbkelley.com website.

Note: Varda is a different VM from servarr (192.168.1.112), which runs the media automation stack. These were previously conflated in some wiki pages.

Key Details#

Hypervisor: Proxmox (Minas Tirith)
Management: Cockpit GUI (Port 9090)
Web Server: Nginx for static content
Firewall: UFW enabled (ports 22, 80, 443)
Development: VS Code Remote-SSH

Nginx Site Structure#

/var/www/ilmare.nbkelley.com/
├── Assets/
│   └── Images/  (Case-sensitive: capital I)
├── html/
│   └── index.html
├── Scripts/
│   └── scripts.js
└── Styles/
    └── styles.css

Nginx Server Block#

/etc/nginx/sites-available/ilmare.nbkelley.com:

OPNsense DMZ Firewall Rules for IoT

Thu, 30 Apr 2026 00:00:00 +0000

OPNsense DMZ Firewall Rules for IoT#

What Was Established#

A structured firewall rule set for isolating IoT devices in a DMZ zone. The rules enforce a “high-to-low trust” flow, ensuring IoT devices can reach the internet for cloud services while preventing them from initiating connections to the trusted LAN. This pattern is critical for preventing lateral movement from compromised IoT devices.

Key Decisions#

Explicit Allow / Implicit Deny: Only allow necessary outbound traffic (HTTP/HTTPS, DNS, NTP) from DMZ to WAN.
Strict Containment: Explicitly block all DMZ-initiated traffic to the LAN zone.
Controlled LAN Access: Default deny for LAN-to-DMZ, with specific allow rules only for administration or required services.
WAN Isolation: Block all unsolicited inbound traffic from WAN to DMZ.

Current Configuration#

Note: The homelab currently uses VLANs (Gandalf 192.168.1.x, Mithrandir 192.168.2.x, Tharkûn 192.168.3.x, Rivendell 192.168.4.x) managed by a UniFi Express gateway (“Olorín”, 192.168.1.1). These OPNsense zone-based rules should be adapted to the homelab’s VLAN structure or applied to a dedicated IoT VLAN (e.g., 192.168.50.x).

PowerShell Local PC Scripting Patterns

Thu, 30 Apr 2026 00:00:00 +0000

What Was Established#

Standardized PowerShell commands for local file operations and MSI package management.
A streamlined, linear pattern for automating software installation, execution, and uninstallation on local Windows hosts without over-engineering modular functions.

Key Decisions#

Prefer Get-ChildItem with wildcards (C:\Users\*\Downloads\*.msi) for rapid file discovery over manual profile loops.
Use Start-Process with msiexec.exe for silent MSI installs (/qn) to keep scripts concise for linear workflows.
Simplified error handling and removed verbose logging for basic administrative tasks, reserving complex wrappers for larger automation frameworks.

Current Configuration / Patterns#

File Listing & Discovery#

# List files recursively, sorted newest first
Get-ChildItem -Path "C:\Path" -File -Recurse | Sort-Object LastWriteTime -Descending

# Find first matching file across user profiles
Get-ChildItem "C:\Users\*\Downloads\CleanUpTool.msi" -ErrorAction SilentlyContinue | Select-Object -First 1

File Copying#

# Copy single file, force overwrite
Copy-Item -Path "Source\File.ext" -Destination "Target\" -Force

# Copy entire directory tree
Copy-Item -Path "C:\Source\*" -Destination "D:\Destination\" -Recurse

MSI Install / Run / Uninstall Pattern#

#Requires -RunAsAdministrator

# 1. Find and Install
$cleanupPath = Get-ChildItem "C:\Users\*\Downloads\CleanUpTool.msi" -ErrorAction SilentlyContinue | Select-Object -First 1
if ($cleanupPath) {
    Start-Process "msiexec.exe" -ArgumentList "/i `"$($cleanupPath.FullName)`" /qn" -Wait

    # 2. Run (locate executable in Program Files)
    $exePath = Get-ChildItem "C:\Program Files\", "C:\Program Files (x86)\" -Recurse -Filter "*CleanUpTool*.exe" -ErrorAction SilentlyContinue | Select-Object -First 1
    if ($exePath) { Start-Process $exePath.FullName -Wait }

    # 3. Uninstall
    $product = Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like "*CleanUpTool*" }
    if ($product) { $product.Uninstall() }
}

# 4. Install Next Package
$foxitPath = Join-Path $PSScriptRoot "Foxit.msi"
if (Test-Path $foxitPath) {
    Start-Process "msiexec.exe" -ArgumentList "/i `"$foxitPath`" /qn" -Wait
}

Historical Notes#

Conversation dated 2025-06-11. The simplified linear script approach was explicitly chosen over a modular function-based approach to reduce overhead for routine local PC tasks.
Get-WmiObject -Class Win32_Product is a legacy enumeration method. While functional for basic scripts, it is known to trigger package repairs and is slow on large systems. Consider migrating to Get-CimInstance -Class Win32_Product or querying HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall for production use.

Open Questions#

Does the local PC environment still rely on Get-WmiObject for software inventory, or has it migrated to Get-CimInstance / registry queries?
Are there standardized locations for MSI installers beyond user Downloads and script root for future automation?

wiki/scripts/powershell-cleanup-patterns.md
wiki/scripts/bulk-folder-rename-script.md
wiki/administration/powershell-administration-commands.md

Sources#

ingested/chats/056-List Files in Folder Using PowerShell.md
DeepSeek conversation: “List Files in Folder Using PowerShell” (2025-06-11)

UniFi Express VPN & Network Management

Thu, 30 Apr 2026 00:00:00 +0000

UniFi Express VPN & Network Management#

What Was Established#

Methodology for configuring ProtonVPN WireGuard on UniFi Express.
Kill switch implementation to prevent IP/DNS leaks when the VPN drops.
Best practices for managing Netgear managed switches via dedicated subnets and secure ports.

Key Decisions#

WireGuard Protocol: Selected over OpenVPN for superior speed and efficiency on UniFi Express.
Kill Switch Pattern: Default-deny WAN traffic; only allow forwarding through the wg0 interface.
Netgear Management: Restrict switch web GUI access to a dedicated management VLAN/subnet using HTTPS.

Current Configuration#

VPN Client: ProtonVPN (WireGuard)
Endpoint: us-123.protonvpn.net:51820 (example high-speed server)
ProtonVPN DNS: 10.2.0.1
Allowed IPs: 0.0.0.0/0 (full tunnel)
Netgear Switch Management Ports:
- HTTP: 80 (insecure, avoid)
- HTTPS: 443 (secure web GUI)
- SSH: 22 (CLI access)
- SNMP: 161 (monitoring)

Historical Notes#

Conversation dated 2025-04-14.
Gateway device referred to as UniFi Express (infrastructure list notes “UCG Express ‘Olorín’ at 192.168.1.1”).
Netgear MS308E is the managed switch in the homelab.
Kill switch and DNS leak prevention rely on iptables/nftables or UniFi OS firewall rules.

Open Questions#

Does UniFi Express support native WireGuard kill switch in the GUI, or is manual CLI firewall configuration required?
Specific UniFi OS version and exact GUI paths for VPN/kill switch implementation.
Whether split tunneling is needed for specific homelab services.

Uptime Kuma - Configuration & Integrations

UniFi UX7 & Netgear MS308E VLAN Setup

Thu, 30 Apr 2026 00:00:00 +0000

UniFi UX7 & Netgear MS308E VLAN Setup#

What Was Established#

Multi-switch VLAN topology using UniFi UCG Express (UX7) and Netgear MS308E switches.
Netgear MS308E 802.1Q Advanced configuration pattern for trunks and access ports.
Troubleshooting methodology for multi-switch chains (isolate to inter-switch trunks vs. device-specific vs. firewall).
UX7 firewall rule correction for IoT isolation (Tharkûn VLAN 3).

Key Decisions#

VLAN 1 (Gandalf): Untagged on trunks, PVID 1. Used for servers and switch management.
VLAN 2 (Mithrandir): Tagged on trunks, Untagged on access. PVID 2. Routes through UX7 VPN.
VLAN 3 (Tharkûn): Tagged on trunks, Untagged on access. PVID 3. Isolated IoT network.
Native VLAN set to 1 on trunks to ensure management traffic passes untagged and remains accessible.
UX7 Firewall: Tharkûn (VLAN 3) placed in DMZ zone. Required explicit “Allow DMZ to Internet” rule to restore IoT connectivity.

Current Configuration#

UX7 (Olorín): 192.168.1.1
- Port 1 (to Netgear Switch 1): Trunk, Native VLAN 1, Allowed VLANs 1, 2, 3.
Netgear MS308E (Switch 1): 192.168.1.239
- Port 1 (to UX7): VLAN 1 Untagged (PVID 1), VLAN 2 Tagged, VLAN 3 Tagged.
- Ports 2, 3 (to downstream switches): Same as Port 1.
- Access Ports (e.g., Port 8 to U7 AP): VLAN 3 Untagged, PVID 3.
Netgear MS308E (Switch 2):
- Trunk ports: VLAN 1 Untagged (PVID 1), VLAN 2 Tagged, VLAN 3 Tagged.
- Access Ports: VLAN 2 Untagged (PVID 2) for PCs, VLAN 3 Untagged (PVID 3) for IoT (e.g., Hue Hub).
UX7 Firewall Rules (Tharkûn/DMZ):
- Allow DMZ to Internet
- Allow DMZ to Gateway
- Block DMZ to Internal
- Block DMZ to VPN

Historical Notes#

Initial attempts to set trunk ports to “No Native VLAN” (all tagged) caused lockout because management traffic (VLAN 1) became untagged and was dropped. Reverted to Native VLAN = 1.
VLAN 2 (Mithrandir) initially failed on downstream switches due to missing tagged configuration on inter-switch trunks.
VLAN 3 (Tharkûn) failed due to missing firewall rule in UX7 Site Manager for the DMZ zone.

Open Questions#

How to handle Rivendell (VLAN 4) when deployed?
Will U7 APs require specific VLAN tagging configurations for Tharkûn WiFi?

wiki/networking/vlan_setup.md (Legacy OPNsense context)
wiki/infrastructure/network.md
wiki/networking/opnsense_dmz_iot_firewall.md

Uptime Kuma - Configuration & Integrations

OPNsense Interface Reassignment & NIC Troubleshooting

Mon, 27 Apr 2026 00:00:00 +0000

OPNsense Interface Reassignment & NIC Troubleshooting#

What Was Established#

Procedures for reassigning WAN/LAN interfaces via the OPNsense console following a system upgrade, and troubleshooting connectivity loss after a physical NIC replacement.

Key Decisions#

Console-Based Reassignment: Use the OPNsense console menu (1. Assign Interfaces) to map physical ports to WAN/LAN roles.
Network-Only Reset: If configuration is lost, use 2. Reset to factory defaults and select “Reset only the network configuration” to preserve other settings.
Manual Config Edit: Fallback to vi /conf/config.xml to manually adjust <interfaces> tags (<wan>, <lan>) if the menu fails.
NIC Troubleshooting Workflow: Verify driver recognition (vmstat -i), link status (ifconfig), and system logs (dmesg). Check NAT/Outbound and LAN firewall rules. Isolate hardware issues by reverting to the original NIC.

Current Configuration#

Gateway: UCG Express “Olorín” (OPNsense) at 192.168.1.1.
VLANs: Gandalf (192.168.1.x), Mithrandir (192.168.2.x), Tharkûn (192.168.3.x), Rivendell (192.168.4.x).
Switch: Netgear MS308E (trunk/access VLANs managed via OPNsense).

Historical Notes#

Procedures documented for OPNsense upgrades where interface assignments reset.
Troubleshooting steps refined for scenarios involving physical NIC swaps (e.g., 2.5GbE to 1GbE) causing interface loss.
Note: Driver support (Intel igb/em, Realtek) and firmware updates may be required for newer NICs.

Open Questions#

Specific driver requirements for the current UCG Express “Olorín” gateway NICs.
Automation of interface reassignment to prevent manual console steps during future upgrades.

Sources#

ingested/chats/034-Reassign WAN and LAN on OPNsense Post-Upgrade.md
Historical DeepSeek conversation on OPNsense console interface reassignment and NIC troubleshooting.

TrueNAS (Vairë) - Storage & Backup Server

Mon, 27 Apr 2026 00:00:00 +0000

TrueNAS (Vairë) - Storage & Backup Server#

What Was Established#

TrueNAS (Vairë) is deployed as a Proxmox VM to serve as the primary storage and backup server for the homelab. It handles ZFS storage pools, NFS/SMB shares for Proxmox and other VMs, and hosts Collabora Office in an iocage jail.

Key Decisions#

VM Type: Q35 with UEFI firmware (recommended for ZFS stability).
Resources: 16 GiB RAM (fixed, no ballooning) and 2 vCPUs. 32 GB boot disk separate from storage.
Storage: 4TB HDD passed through directly to the VM for ZFS data integrity and performance.
Backup Integration: NFS share (/mnt/tank/backups) configured for Proxmox backups. SMB share available for manual access.
Collabora Office: Deployed in a dedicated iocage jail on port 9980.

Current Configuration#

Hostname: Vairë
IP Address: 192.168.1.100 (NFS) / 192.168.1.133 (SMB)
Proxmox VM ID: [Pending verification]
ZFS Pool: tank (4TB HDD passthrough)
NFS Share: /mnt/tank/backups (Network: 192.168.1.0/24, Maproot: root)
SMB Share: /mnt/tank/backups (Version 3.0)
Collabora Jail: iocage jail, port 9980

Historical Notes#

The conversation notes two different IPs for TrueNAS (192.168.1.100 and 192.168.1.133). Verify which IP is currently assigned to the TrueNAS VM.
TrueNAS CORE uses iocage jails. Ensure jail templates are up to date.
Proxmox backups to NFS require hard,intr,noatime mount options in /etc/fstab.

Open Questions#

Which IP address is currently active for Vairë (192.168.1.100 or 192.168.1.133)?
Is the 4TB HDD currently formatted as a ZFS pool on Vairë?
Has Collabora Office been integrated with a Nextcloud instance?

Sources#

ingested/chats/032-TrueNas - Vairë.md
Historical DeepSeek conversation on TrueNAS VM setup and Proxmox integration.

AI Infrastructure Overview

Sun, 26 Apr 2026 00:00:00 +0000

AI Infrastructure Overview#

What Was Established#

The homelab is transitioning into a multi-node agentic architecture, utilizing a mix of existing laptops, desktops, and a future Mac Studio to handle different tiers of LLM workloads (Batch vs. Interactive).

Key Decisions#

Nodes are specialized by their hardware capabilities (VRAM and CPU/RAM) to optimize for cost and performance:

Inference Node (Batch/Heavy + Embeddings): HP Pavilion 15t-e300 — hostname nk-celebrimbor, IP 192.168.2.192. Intel i7, 32GB RAM, NVIDIA MX550 (2GB VRAM, CUDA disabled). Runs gemma4:e4b for monitoring pipeline synthesis (~15-18 t/s, CPU-only) and nomic-embed-text for wiki semantic embeddings (768-dim, via Ollama on port 11434).
Orchestrator Node: Thinkpad T480. Intel i5/i7 8th Gen, 32GB RAM. Running headless Ubuntu. Hosts n8n and lightweight models (Gemma 4 E4B) for routing and decision-making.
Interactive Node (Potential): ROG Zephyrus (GU501). Intel i7, NVIDIA GTX 1080 Max-Q (8GB VRAM). Ideal for 7B/8B models requiring high tokens-per-second for real-time chat.
Primary Reasoning Node (Deployed 2026-04-24): Mac Studio M1 Max, 64GB Unified Memory — hostname Legolas, IP 192.168.1.45. Handles all wiki pipeline LLM calls: gemma4:e2b (text cleaning), qwen3.6:35b-a3b-coding-nvfp4 (JSON crystallization), minicpm-v:8b (PDF OCR/vision). Fast interactive inference — 31B models at ~25+ t/s vs Pavilion’s ~15 t/s CPU-only. See Mac Studio.
Parallelism Nodes: Various i5 8th Gen desktops. 32GB RAM, no GPU. Used for distributed pipeline stages or additional lightweight model instances.

Current Configuration#

Legolas (Mac Studio): Ollama at 192.168.1.45:11434. Running gemma4:e2b, qwen3.6:35b-a3b-coding-nvfp4, minicpm-v:8b for wiki pipeline. Deployed 2026-04-24.
nk-celebrimbor (Pavilion): headless Ubuntu, Ollama CPU-only (CUDA disabled — MX550 2GB VRAM too small). Running gemma4:e4b at ~15-18 t/s for hourly monitoring pipeline; nomic-embed-text for wiki embeddings.
T480: planned orchestrator role not yet active.

Ollama Configuration, Open WebUI Deployment, Mac Studio, Pavilion (AI PC) Configuration

Mac Studio

Sun, 26 Apr 2026 00:00:00 +0000

Mac Studio#

What Was Established#

Mac Studio M1 Max 64GB purchased 2026-04-17 for $2,299 (used/refurbished market). Deployed 2026-04-24 as the primary AI inference node for the homelab, replacing the Pavilion as the fast interactive reasoning machine.

Hardware#

Detail	Value
Model	Mac Studio (2022, M1 Max)
Hostname	Legolas
IP	192.168.1.45
Memory	64GB Unified Memory
Memory bandwidth	~400 GB/s
Purchase price	$2,299 (used)
Status	Deployed, operational 2026-04-24

Why This Hardware#

64GB unified memory is the key spec for LLM inference on Apple Silicon. Memory bandwidth determines tokens/second — the M1 Max at ~400 GB/s delivers ~25+ t/s for 27-31B models vs the Pavilion’s ~15 t/s CPU-only for E4B. At the time of purchase, 64GB Mac Studio/Mac Mini new from Apple was backordered to late June. The used M1 Max at $2,299 was judged a reasonable buy given scarcity.

Pavilion (AI PC) Configuration

Sun, 26 Apr 2026 00:00:00 +0000

Pavilion (AI PC) Configuration#

What Was Established#

The Pavilion machine uses a USB-based or specific Ethernet interface (enx6c1f7197a66) that occasionally fails to bring the link up automatically on boot.

Current Configuration#

Netplan Configuration#

Ensure /etc/netplan/01-netcfg.yaml is correctly configured with the active interface name and permissions are set to 600.

network:
  version: 2
  ethernets:
    enx6c1f7197a66:
      dhcp4: true

Apply with:

sudo chmod 600 /etc/netplan/01-netcfg.yaml
sudo netplan apply

Boot-time Interface Fix#

If the interface remains DOWN after reboot, use a systemd service to force the link up.

PostgreSQL

Sun, 26 Apr 2026 00:00:00 +0000

PostgreSQL#

What Was Established#

PostgreSQL 16 runs as an LXC on Proxmox, serving as the central database for n8n, the monitoring pipeline, and pgvector embeddings for the wiki.

Deployment#

Detail	Value
LXC host	postgresql
Container ID	108
IP	192.168.1.57
Port	5432
Version	16.13 (Debian 16.13-1.pgdg13+1)
OS	Debian 13 (unprivileged LXC)
Disk	4 GB (App-Storage ZFS pool)
RAM	1024 MiB
CPU	1 core
Installed via	tteck Proxmox helper scripts
Web UI	Adminer — not yet installed
SSH user	iluvatar (sudo, PermitRootLogin no)

Databases and Users#

Database	User	Purpose
homelab	homelab	n8n workflows, monitoring pipeline, pgvector wiki embeddings

Setup commands (run as postgres user)#

CREATE DATABASE homelab;
CREATE USER homelab WITH PASSWORD '<password>';
GRANT ALL PRIVILEGES ON DATABASE homelab TO homelab;
GRANT ALL ON SCHEMA public TO homelab;  -- required for n8n
\q

The GRANT ALL ON SCHEMA public step is required — without it n8n fails to start with a permissions error even though the database and user exist.

wiki-llm

Sun, 26 Apr 2026 00:00:00 +0000

wiki-llm#

What Was Established#

Dedicated Ubuntu 24.04 VM for hosting the homelab wiki system and Claude Code sessions. Chosen as a VM rather than an LXC for stronger isolation (wiki infrastructure handles credentials and embeddings).

Deployment#

Detail	Value
Hostname	wiki-llm
IP	192.168.1.206
VLAN	Gandalf (192.168.1.x)
OS	Ubuntu 24.04
CPU	2 cores
RAM	4 GB
Type	VM (Proxmox)
SSH user	iluvatar (sudo, PermitRootLogin no)

Access#

VS Code Remote SSH: Primary method for Claude Code sessions — VS Code connects to wiki-llm via remote SSH, giving Claude Code native filesystem access to /opt/wiki/homelab/
Direct SSH: ssh iluvatar@192.168.1.206

Wiki File Structure#

/opt/wiki/
  homelab/        ← git repo, all homelab wiki pages and skills
  work/           ← git repo, work/princelobel wiki + pipeline scripts
  projects/       ← git repo, projects wiki (planned)
  personal/       ← git repo, personal wiki (Gemma-only)
  raw-sources/    ← symlink to /mnt/wiki-nas/LLMWiki
  skills-reference/  ← clone of vanillaflava/llm-wiki-claude-skills (reference only)

Each wiki directory is an independent git repository (git init’d) for clean version history per namespace.

Local Model Training & Fine-Tuning Guide

Thu, 23 Apr 2026 00:00:00 +0000

Local Model Training & Fine-Tuning Guide#

What Was Established#

Guide for fine-tuning local LLMs (DeepSeek) using Hugging Face transformers, with emphasis on VRAM-efficient techniques for single-GPU setups.

Key Decisions#

Framework: Hugging Face transformers + Trainer API for fine-tuning
Model: deepseek-ai/deepseek-llm-7b (example model)
Efficiency: LoRA (Low-Rank Adaptation) + 4-bit quantization via bitsandbytes to fit large models on consumer GPUs

Setup#

pip install torch transformers datasets accelerate peft bitsandbytes

Verify GPU: nvidia-smi — need CUDA 11.8+.

Windows VM Installation Troubleshooting

Thu, 23 Apr 2026 00:00:00 +0000

Windows VM Installation Troubleshooting#

What Was Established#

Troubleshooting guide for Windows installation when the local disk does not appear in the partitioning screen during setup.

Key Troubleshooting Steps#

Check disk detection in BIOS/UEFI — If the disk doesn’t appear in BIOS, it’s a hardware issue (loose cable, faulty drive, wrong SATA port).
Load storage drivers — Modern NVMe/RAID controllers may need drivers loaded during setup via Shift + F10 → “Load Driver”.

AI-Driven Monitoring Pipeline

Tue, 21 Apr 2026 00:00:00 +0000

AI-Driven Monitoring Pipeline#

What Was Established#

The monitoring pipeline is fully operational and running hourly. It collects rich structured data from four sources (Prometheus — 7 metrics, Uptime Kuma, UniFi, Synology), runs 4 parallel Ollama summarization calls, synthesises a final status report, and writes everything to Postgres. Hourly snapshots of raw UniFi and Prometheus data are stored in dedicated tables for delta computation. End-to-end runtime is ~13 minutes using gemma4:e4b CPU-only on the Pavilion — accepted as-is pending Mac Studio.

n8n

Tue, 21 Apr 2026 00:00:00 +0000

n8n#

What Was Established#

n8n is the automation and orchestration hub for the homelab. It runs as an LXC on Proxmox, connected to PostgreSQL for persistent workflow state and execution history. Community edition is sufficient for current use.

Deployment#

Detail	Value
LXC host	n8n
IP	192.168.1.169
Port	5678
URL	http://192.168.1.169:5678
Version	2.15.1 (Self Hosted)
Installed via	tteck Proxmox helper scripts
OS	Debian 13 (unprivileged LXC)
Config file	/opt/n8n.env

Configuration (/opt/n8n.env)#

N8N_SECURE_COOKIE=false
N8N_PORT=5678
N8N_PROTOCOL=http
N8N_HOST=192.168.1.169
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=192.168.1.57
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=homelab
DB_POSTGRESDB_USER=homelab
DB_POSTGRESDB_PASSWORD=<password>

After editing: systemctl restart n8n

Node Exporter Deployment

Tue, 21 Apr 2026 00:00:00 +0000

Node Exporter Deployment#

What Was Established#

node_exporter is used to expose system-level metrics (CPU, RAM, Disk, Network) from Linux hosts to the central Prometheus instance at 192.168.1.167.

Monitored Hosts#

Host	IP	Port	Prometheus job	VLAN
nk-celebrimbor (Pavilion)	192.168.2.192	9100	pavilion	mithrandir
wiki-llm	192.168.1.206	9100	wiki	gandalf

Installation#

Method A: apt (Ubuntu) — preferred for Ubuntu hosts#

sudo apt install prometheus-node-exporter
# Service auto-enabled; runs on port 9100

Method B: Manual binary (other distros)#

wget https://github.com/prometheus/node_exporter/releases/download/v1.11.1/node_exporter-1.11.1.linux-amd64.tar.gz
tar xvf node_exporter-1.11.1.linux-amd64.tar.gz
sudo cp node_exporter-1.11.1.linux-amd64/node_exporter /usr/local/bin/

Create /etc/systemd/system/node_exporter.service:

Network Infrastructure & VLANs

Tue, 14 Apr 2026 00:00:00 +0000

Network Infrastructure & VLANs#

What Was Established#

The network uses a UniFi UCG Express with a multi-VLAN setup. A recent incident involving a VPN expiry caused a routing failure on specific VLANs due to policy-based routing (PBR) without a fallback mechanism.

Key Decisions#

VLAN Segmentation:
- Gandalf: Server network (Always-on, stable, no VPN).
- Mithrandir (VLAN 2): Client/AI network. Traffic is routed through ProtonVPN via WireGuard.
- Harken (VLAN 3): General usage.
- Tharkûn (DMZ): Restricted zone (DMZ $\rightarrow$ Internal is Blocked).
- Rivendell (VLAN 4): Unused.
VPN Configuration: ProtonVPN WireGuard Client 1 is used for Mithrand/VLAN 2. Critical: Ensure “Block traffic if WireGuard is down” is enabled to prevent IP leaks.
IP Management: Use DHCP Reservations (Fixed IPs) in the UniFi Controller rather than configuring static IPs on individual hosts to prevent port-forward breakage during DHCP lease renewals.

Current Configuration#

Known Fixed IPs (DHCP Reservations):

Book Discovery Pipeline

Mon, 13 Apr 2026 00:00:00 +0000

Book Discovery Pipeline#

What Was Established#

A multi-agent, multi-node pipeline designed to identify high-prestige, upcoming literary works by analyzing critical reviews before they hit the mainstream.

Key Decisions#

Architecture: Two-tier agent system. Lightweight models (E4B) on the Orchestrator (T480) handle routing/filtering; heavier models (26B) on the Inference node (Pavilion) handle deep analysis.
Tech Stack: n8n (Orchestration), PostgreSQL (Data Storage), Hugo (Static Site Generation), Python/JS (Custom Logic).
Data Sources: RSS feeds (Literary Hub, etc.), Web Scraping (for indie blogs), and Goodreads API/Scraping for popularity comparison.

Current Configuration#

The Pipeline Chain#

Ingestion: n8n fetches RSS feeds and scrapes blogs.
Filtering (E4B): Classifies content (Review vs. News). Discards non-reviews.
Extraction (26B): Extracts title, author, publisher, and critical language.
Scoring (26B): Analyates “prestige signals” (e.g., phrases like “formally ambitious”) and compares against Goodreads popularity.
Aggregation: Aggregates data into PostgreSQL.
Publication: n8n generates a Markdown file and commits it to a Hugo repository.

Data Schema (PostgreSQL)#

sources: RSS metadata.
articles: Raw ingested content.
books: Normalized book records.
reviews: Links articles to books + extracted critical language.
prestige_scores: Historical scoring for trend tracking.

Open Questions#

How to effectively scrape Substack/paywalled content without high costs.
Determining the optimal frequency for the pipeline run (Weekly vs. Bi-weekly).

Open WebUI Deployment, Ollama Configuration, AI-Driven Monitoring Pipeline

Linux Server Optimization

Mon, 13 Apr 2026 00:00:00 +0000

Linux Server Optimization#

What Was Established#

Optimizations for headless Ubuntu servers (specifically HP Pavilion and Thinkpad T480) to prevent sleep/suspend when the lid is closed.

Key Decisions#

Modify systemd-logind to ignore lid switch events to ensure the server remains active when the laptop lid is closed.

Current Configuration#

Prevent Sleep on Lid Close#

Edit /etc/systemd/logind.conf:

sudo nano /etc/systemd/logind.conf

Ensure the following lines are uncommented and set to ignore:

HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore

Apply the changes:

Ollama Configuration

Mon, 13 Apr 2026 00:00:00 +0000

Ollama Configuration#

What Was Established#

Ollama is used as the primary model backend across the fleet. The configuration focuses on making the API accessible to other nodes (like the T480 orchestrator) and running models like Gemma 4.

Key Decisions#

To allow remote access from other machines in the homelab (e.g., from a Docker container or another PC), the Ollama service must be configured to listen on all network interfaces, not just localhost.

Open WebUI Deployment

Mon, 13 Apr 2026 00:00:00 +0000

Open WebUI Deployment#

What Was Established#

Open WebUI is deployed via Docker to provide a ChatGPT-like interface for interacting with local Ollama instances. It is configured to connect to the host’s Ollama API.

Key Decisions#

Because the WebUI runs inside a Docker container, it cannot reach localhost:11434 of the host machine directly. The OLLMA_BASE_URL must point to the host’s actual LAN IP or use the host.docker.internal gateway.

Current Configuration#

Docker Deployment#

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

Note: Replace <YOUR_HOST_IP> with the actual IP of the machine (e.g., 192.168.172.168) to ensure the container can route to the Ollama service.

VS Code Live Server Path Configuration

Mon, 31 Mar 2025 00:00:00 +0000

VS Code Live Server Path Configuration#

What Was Established#

Resolved the “Cannot GET /page-name” error in VS Code Live Server by implementing a standardized project directory structure and correct relative pathing. The core fix involves ensuring the server root is set to the project root and using ../ to traverse up from subdirectories.

Key Decisions#

Project Rooting: Always open the top-level project folder in VS Code rather than individual subfolders (like html/). This allows Live Server to correctly resolve paths relative to the project root.
Directory Separation: Adopted a structured hierarchy to separate assets, logic, and presentation.

Current Configuration#

Project Structure#

project-root/
├── Assets/
│   ├── icons/
│   └── images/
├── html/
│   ├── index.html
│   ├── about.html
│   └── contact.html
├── scripts/
│   └── main.js
└── Styles/
    └── style.css

Pathing Rules (when working inside `html/`)#

When files are located within the html/ subdirectory, all links to external directories must use the ../ prefix to exit the html/ folder first.

Web Server Stack (Nginx + Apache)

Fri, 28 Mar 2025 00:00:00 +0000

Web Server Stack (Nginx + Apache)#

What Was Established#

In this setup, Nginx is utilized as a high-performance reverse proxy to handle incoming traffic and static content, while Apache serves as the backend for dynamic content (e.g., PHP/WordPress) due to its flexible .htaccess support.

Key Decisions#

Architecture: Nginx acts as the entry point (Port 80/443) and proxies requests to Apache running on a non-standard port (e.g., 8080).
Rationale: Leverages Nginx’s superior concurrency and static content handling with Apache’s ease of use for per-directory configuration.

Current Configuration#

Apache Backend Configuration#

Modify /etc/apache2/ports.conf to listen on a different port to avoid conflict with Nginx:

Nginx vs Apache for Static Hosting

Wed, 26 Mar 2025 00:00:00 +0000

Nginx vs Apache for Static Hosting#

What Was Established#

A comparison of Nginx and Apache for the purpose of hosting static HTML/CSS/JS files within a Proxmox LXC or VM.

Key Decisions#

Choose Nginx if: You prioritize performance, low memory footprint, and plan to use it as a reverse proxy for modern stacks (Node.js, Python).
Choose Apache if: You require .htaccess support for per-directory configuration or are working with legacy PHP/LAMP stacks.

Current Configuration#

Nginx Basic Static Config#

server {
    listen 80;
    root /var/www/html;
    index index.html;
}

Apache Basic Static Config#

<VirtualHost *:80>
    DocumentRoot /var/www/html
    DirectoryIndex index.html
</VirtualHost>

Deployment Commands (LXC)#

To create a standard Ubuntu 22.04 LXC for web hosting:

Proxmox ZFS Storage Setup

Wed, 26 Mar 2025 00:00:00 +0000

Proxmox ZFS Storage Setup#

What Was Established#

Procedures for initializing ZFS pools using multiple drives via the Proxmox Web GUI and configuring them as usable storage for Virtual Machines (VMs) and Linux Containers (LXC).

Key Decisions#

RAID Levels: Selection depends on the number of disks and redundancy requirements:
- Stripe (RAID 0): Maximum capacity, no redundancy.
- Mirror (RAID 1): Redundancy, 50% capacity loss.
- RAID-Z1/Z2: Requires 3+ disks for parity-based redundancy.
Compression: lz4 is the recommended compression algorithm for performance.
Ashift: Set to 12 for modern SSDs/NVMe to ensure proper block alignment.
Thin Provisioning: Enabled for storage pools to allow for flexible disk allocation.

Current Configuration#

1. Initialize ZFS Pools (Web GUI)#

Navigate to: Datacenter → Node → Disks → ZFS

Web Server Architecture on Proxmox

Wed, 26 Mar 2025 00:00:00 +0000

Web Server Architecture on Proxmox#

What Was Established#

High-level architectural strategies for deploying web development environments on Proxmox, focusing on balancing isolation with resource efficiency.

Key Decisions#

LXC for Services: Use LXC containers for lightweight, single-purpose services (e.g., Nginx, Databases) to minimize overhead.
VM for Complex Workloads: Use full VMs when running Docker, Kubernetes, or when custom kernel modules are required.
Reverse Proxy Pattern: Always use a reverse proxy (Nginx Proxy Manager, Traefik, or C/Caddy) to handle SSL termination and route traffic to multiple internal services.
Database Isolation: Separate databases into their own containers/VMs to improve security and facilitate independent backups.

Current Configuration#

Networking Patterns#

Bridge Mode: Default vmbr0 for services requiring LAN access.
Internal Network: Use secondary bridges (e.g., vmbr1) for isolated communication between web servers and databases.

Storage Patterns#

Local-LVM: Preferred for high-performance VM/container disks.
Directory Storage: Suitable for container volumes and simpler storage needs.

Historical Notes#

This architecture plan was established in March 2025. The preference for LXCs over VMs for simple web services was a primary driver.

Cloudflare Integration: SSL & DNS

Tue, 25 Mar 2025 00:00:00 +0000

Cloudflare Integration: SSL & DNS#

What Was Established#

Methodology for securing OPNsense and Proxmox web interfaces using Cloudflare’s Origin CA certificates and protecting the WAN via Cloudflare-specific firewall rules.

Key Decisions#

SSL Mode: Cloudflare SSL/TLS setting must be set to Full (Strict).
Security Pattern: Use Cloudflare IP Aliases on OPNsense to restrict WAN HTTPS (Port 443) access exclusively to Cloudflare’s IP ranges.
DNS Strategy: Use A records with Proxy (Orange Cloud) enabled for web services to leverage DDoS protection.

Current Configuration#

Cloudflare Origin SSL (OPNsense)#

Generate Cert: In Cloudflare, go to SSL/TLS → Origin Server and create a certificate for the domain.
Import to OPNsense:
- System → Trust → Certificates → Import existing Certificate.
- Paste PEM (Cert) and Private Key.
Assign to WebUI:
- System → Settings → Administration → Set SSL Certificate to the imported Cloudflare cert.
- Restart WebGUI: configctl webgui restart.

WAN Hardening (OPNsense)#

Create Alias: Firewall → Aliases → URL Table Alias.
- Name: Cloudflare_IPs.
- URL: https://www.cloudflare.com/ips-v4.
Firewall Rule: Firewall → Rules → WAN.
- Action: Pass.
- Source: Cloudflare_IPs.
- Destination Port: 443.
Block Rule: Add a block rule for port 443 from all other sources at the bottom of the WAN list.

Historical Notes#

Note: If the browser shows “Not Secure” after import, ensure the Cloudflare Origin CA Root Certificate is also imported into OPNsense System → Trust → Authorities.

OPNsense DHCP Configuration

Tue, 25 Mar 2025 00:00:00 +0000

OPNsense DHCP Configuration#

What Was Established#

Procedures for modifying DHCPv4 ranges and identifying other network segments where IP assignment ranges must be managed to prevent conflicts.

Key Decisions#

DHCP Scope Management: Always ensure static leases or reserved IPs (like Proxmox) are excluded from the dynamic DHCP range to prevent IP conflicts.
Subnet Alignment: DHCP ranges must reside within the defined subnet (e.g., /24 for 192.168.0.0/24).

Current Configuration#

DHCPv4 Modification#

Navigate to Services → DHCPv4 → [Interface].
Under General DHCP Options, set the Range (Start and End IP).
Save and Apply.

Other Assignment Areas to Monitor#

DHCPv6: Found under Services → DHCPv6 → [Interface].
VPNs:
- OpenVPN: VPN → Open/IPsec → [Server] (Tunnel Network).
- WireGuard: Manual assignment per peer.
VLANs: Each VLAN interface requires its own DHCP scope.

Historical Notes#

As of March 2025, this covers the standard DHCPv4/v6 setup for the LAN and VLAN interfaces.

Proxmox Network Troubleshooting

Tue, 25 Mar 2025 00:00:00 +0000

Proxmox Network Troubleshooting#

What Was Established#

Troubleshooting steps for resolving connectivity loss to Proxmox nodes, specifically addressing IP conflicts and subnet mismatches.

Key Decisions#

Static IP Reservation: Proxmox nodes should always have a static IP (e.g., 192.168.0.69) that is excluded from the OPNsense DHCP pool.

Current Configuration#

Troubleshooting Workflow#

Verify Connectivity: ping 192.168.0.69.

Check Local Config: Log in via console and verify /etc/network/interfaces:

auto vmbr0
iface vmbr0 inet static
    address 192.168.0.69/24
    gateway 192.168.0.1
    bridge-ports enp3s0

Check for IP Conflicts: Ensure no other device (via DHCP) has been assigned 192.168.0.69.
ARP Cache: Clear local ARP cache if IP conflicts are suspected: arp -d 192.168.0.69.

Historical Notes#

Identified an issue where a DHCP client was assigned 192.168.0.69, conflicting with the Proxmox static IP.

Troubleshooting DeepSeek Language Switching

Tue, 25 Mar 2025 00:00:00 +0000

Troubleshooting DeepSeek Language Switching#

What Was Established#

Local DeepSeek models may intermittently switch from English to Chinese mid-response. This is typically caused by training bias (heavy Chinese dataset influence), loss of context during long conversations, or mixed-language input prompts.

Key Decisions#

To maintain English-only responses, the following parameters and prompting strategies should be applied:

Explicit Instruction: Always include a system-level or initial prompt instruction to respond exclusively in English.
Temperature Control: Use lower temperature settings (e.g., 0.3) to make the model more deterministic and less likely to drift.
Repetition Penalty: Implement a repetition_penalty (e.g., 1.2) to discourage the model from falling into repetitive patterns that might trigger language switching.

Current Configuration#

System Message Pattern#

When using APIs or local inference engines that support system roles:

VLAN Configuration: OPNsense & Netgear MS308E

Tue, 25 Mar 2025 00:00:00 +0000

VLAN Configuration: OPNsense & Netgear MS308E#

What Was Established#

Configuration pattern for implementing tagged (trunk) and untagged (access) VLANs using OPNsense as the router and a Netgear MS308E managed switch.

Key Decisions#

VLAN Naming/ID: Example VLAN “Incánus” assigned ID 20.
Trunking Strategy: The port connecting OPNsense to the Netgear switch must be configured as a Tagged port for all active VLANs.
Access Port Strategy: Ports for end-devices must be Untagged for the specific VLAN, with the PVID (Port VLAN ID) set to match that VLAN.

Current Configuration#

OPNsense Setup#

Create VLAN: Interfaces → Other Types → VLAN (Assign Parent Interface and Tag ID).
Assign Interface: Interfaces → Assignments (Add the new VLAN interface).
Configure IP: Set a static IPv4 address (e.g., 192.168.20.1/24 for VLAN 20).
DHCP: Enable DHCPv4 under Services → DHCPv4 → [VLAN Interface].

Netgear MS308E Setup#

VLAN Membership:
- Trunk Port (to OPNsense): Set as Tagged for all VLANs (e.g., VLAN 20, 30).
- Access Port (to Device): Set as Untagged for the target VLAN.
PVID Configuration:
- For Access Ports, the PVID must be updated to match the VLAN ID (e.g., Port 1: PVID 20).

Historical Notes#

Configuration established during the rollout of the “Incánus” network segment.

Proxmox Network Configuration

Sun, 23 Mar 2025 00:00:00 +0000

Proxmox Network Configuration#

What Was Established#

Procedures for manually updating the IP address and network interface settings on a Proxmox VE host via the command line.

Key Decisions#

Network configuration is managed via the /etc/network/interfaces file. When changing network parameters, the Linux bridge (vmbr0) must be updated to point to the correct physical interface.

Current Configuration#

To modify the IP, gateway, or interface, edit the configuration file:

nano /etc/network/interfaces

Example of a static configuration for a bridge interface:

Proxmox ZFS Storage & Installation Patterns

Sun, 23 Mar 2025 00:00:00 +0000

Proxmox ZFS Storage & Installation Patterns#

What Was Established#

Procedures for managing ZFS rpool on single-disk Proxmox installations, including methods for limiting pool size and troubleshooting import failures.

Key Decisions#

Single Disk Size Limitation: When installing Proxmox on a large disk but wanting to limit the ZFS pool to a specific size (e.g., 64GB) to leave room for other partitions, use the hdsize parameter in the Proxmox installer’s Advanced Options.
Custom Partitioning Method: For complex layouts, it is possible to manually partition a drive in Debian and then upgrade the system to Proxmox VE.

Current Configuration#

ZFS Pool Creation (Manual)#

To create a ZFS pool with specific optimizations (ashift=12, compression=lz4) and a size limit:

Troubleshooting Network Interface Changes

Sun, 23 Mar 2025 00:00:00 +0000

Troubleshooting Network Interface Changes#

What Was Established#

When replacing a physical Network Interface Card (NIC)—for example, swapping a 2.5GbE card for a 1GbE card—the system will lose connectivity if the software configuration still references the old interface name.

Key Decisions#

Connectivity loss after a hardware swap is usually due to a mismatch in the bridge-ports setting within the network configuration. The new NIC will likely have a different kernel interface name (e.g., changing from enp0s1 to enp0s2).

Web Server Deployment Pattern (Beginner)

Sun, 23 Mar 2025 00:00:00 +0000

Web Server Deployment Pattern (Beginner)#

What Was Established#

For a beginner-friendly, lightweight, and scalable homelab setup, a stack consisting of Ubuntu Server LTS and Nginx is the recommended standard. This provides a balance of ease of use, extensive documentation, and low resource overhead.

Key Decisions#

Operating System: Ubuntu Server LTS (chosen for stability, community support, and ease of management).
Web Server: Nginx (chosen over Apache for being lightweight, faster for static content, and better suited for future use as a reverse proxy).
Resource Allocation (Small Site): 1-2 CPU cores, 1-2 GB RAM, 10-2/GB Disk.

Current Configuration#

Nginx Site Configuration#

Default root directory: /var/www/html

Wi-Fi Performance Optimization (U7 Lite)

Mon, 01 Jan 0001 00:00:00 +0000

Wi-Fi Performance Optimization (U7 Lite)#

What Was Established#

Diagnostic steps for addressing throughput discrepancies between wired (1 Gbps) and wireless (300 Mbps) connections on Wi-Fi 6/6E hardware.

Key Decisions#

Channel Width: For high-speed Wi-Fi 6/6E, utilize 80 MHz or 160 MHz channel widths on the 5 GHz/6 GHz bands.
Band Steering: Disable Band Steering if it causes frequent client roaming/drops.

Current Configuration#

Optimization Steps#

Verify Link Speed: Check client-side PHY rates (e.g., netsh wlan show interfaces on Windows) to ensure the client is connecting via 5 GHz/6 GHz.
AP Settings (Unifi/Ubiquiti):
- Mode: Set to HE (Wi-Fi 6) or EHT (Wi-Fi 7).
- Channel Width: Set to 80 MHz or 160 MHz.
- Minimum Data Rate: Set to 24 Mbps to disable legacy (802.11b/g) rates.
Client-Side: Disable Wi-Fi Power Saving mode on Linux clients:
```
iw dev wlan0 set power_save off
```

Historical Notes#

Addressed a specific case where a U7 Lite was capped at 300 Mbps due to potential client-side or channel width limitations.

homelab

hugoboss

hugoboss#

What Was Established#

Identity#

Hugo Installation#

Wiki Pipeline Scripts

Wiki Pipeline Scripts#

What Was Established#

Wiki System - Architecture

Wiki System - Architecture#

What Was Established#

Multi-Wiki Namespace Design#

Bambu Studio Layer G-code

Bambu Studio Layer G-code#

What Was Established#

Key Decisions#

Current Configuration#

Layer Range G-code Setup#

Examples#

Bambu Studio Print Order & Travel Optimization

Bambu Studio Print Order & Travel Optimization#

What Was Established#

Key Decisions#

Current Configuration#

Historical Notes#

Open Questions#

Related Pages#

Sources#

BlueBikes API Feeds Guide

BlueBikes API Feeds Guide#

What Was Established#

Key Decisions#

Current Configuration#

Core GBFS Endpoints#

Data Structure Examples#

Cloudflare Access Setup for Protected Sections

Cloudflare Access Setup for Protected Sections#

What Was Established#

Key Decisions#

Current Configuration#

Historical Notes#

Open Questions#

Related Pages#

Sources#

Filament Drying & Storage Guide

Filament Drying & Storage Guide#

What Was Established#

Drying Reference#

Git Push Authentication

Git Push Authentication#

What Was Established#

Key Decisions#

Current Configuration#

Historical Notes#

Open Questions#

Related Pages#

Sources#

Git Push Authentication

Git Push Authentication#

What Was Established#

Key Decisions#

Resolving Divergent Branches#

Symptom#

Option 1: Merge (preserves both histories)#

Option 2: Rebase (local commits on top of remote)#

Option 3: Discard local, use remote only#

Option 4: Fast-forward only (fails if diverged)#

Multi-Machine Workflow#

Gluetun VPN Service

Gluetun VPN Service#

What Was Established#

Deployment Context#

GPU Passthrough for Proxmox LXCs

GPU Passthrough for Proxmox LXCs#

What Was Established#

Key Decisions#

Current Configuration#

Hinterflix Help Site - Cloudflare Deployment

Hinterflix Help Site - Cloudflare Deployment#