//nbkelley /homelab

Git Push Authentication

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.

Sources#

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

Git Push Authentication

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:

Hugo Deployment to Cloudflare Pages - Troubleshooting

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

KVM Input Switch Sleep Issues

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

Mobile Hotspot & Proton VPN Troubleshooting

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

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?

Sources#

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

Proxy Management & Cloudflare Tunnels

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

Servarr - Media Automation Stack

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 Stack - Gluetun VPN Troubleshooting

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

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)