foundation:requestserver
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| foundation:requestserver [2025/12/19 23:06] – created - external edit 127.0.0.1 | foundation:requestserver [2025/12/20 15:20] (current) – privacyl0st | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ====== Requests Server VM (Overseerr) ====== | ||
| + | This virtual machine is the **request hub** of the Trash Panda ecosystem. It handles user requests, monitors media availability, | ||
| + | |||
| + | This page covers **only the VM setup and deployment**. Installation and configuration of Overseerr itself are covered in their own guide.\\ | ||
| + | |||
| + | ===== Role of This VM in the Ecosystem ===== | ||
| + | The Overseerr VM: | ||
| + | * Handles user media requests | ||
| + | * Communicates with Plex for library updates | ||
| + | * Interfaces indirectly with download/ | ||
| + | * Lives in the DMZ to allow controlled external access | ||
| + | |||
| + | By isolating this service into a dedicated VM, we: | ||
| + | * Reduce risk if exposed services are compromised | ||
| + | * Simplify troubleshooting | ||
| + | * Avoid interference with internal automation services | ||
| + | * Gain predictable performance characteristics | ||
| + | |||
| + | This VM should operate quietly in the background and remain **reachable but contained**. | ||
| + | |||
| + | ===== Base Operating System ===== | ||
| + | * **Ubuntu Server 24.04 LTS** | ||
| + | * Minimal installation (no desktop environment) | ||
| + | * Automatic security updates enabled | ||
| + | |||
| + | Ubuntu LTS provides: | ||
| + | * Long-term security support | ||
| + | * Strong community documentation | ||
| + | * Stability for long-running services | ||
| + | |||
| + | This VM should run **headless** and be administered via SSH. | ||
| + | |||
| + | ===== Virtual Hardware Allocation ===== | ||
| + | |||
| + | ==== Memory (RAM) ==== | ||
| + | * **4 GB RAM (fixed allocation)** | ||
| + | |||
| + | Why 4 GB? | ||
| + | * Overseerr is lightweight but benefits from headroom during API polling | ||
| + | * Prevents swap pressure when processing multiple simultaneous requests | ||
| + | |||
| + | Avoid memory overcommit to maintain responsiveness. | ||
| + | |||
| + | ==== CPU Allocation ==== | ||
| + | * **2 vCPUs** | ||
| + | |||
| + | Request handling is: | ||
| + | * Light and bursty | ||
| + | * Sensitive to latency | ||
| + | * Not CPU-intensive for sustained periods | ||
| + | |||
| + | Two vCPUs provide sufficient parallelism without wasting host resources. | ||
| + | |||
| + | ==== Storage Allocation ==== | ||
| + | * **30 GB virtual disk** | ||
| + | * Thin provisioned (recommended) | ||
| + | |||
| + | This storage is used for: | ||
| + | * OS and system packages | ||
| + | * Overseerr application and dependencies | ||
| + | * Configuration, | ||
| + | |||
| + | **No media is stored here.** Media resides on NAS storage accessed via internal automation services. | ||
| + | |||
| + | ===== Network Configuration ===== | ||
| + | This VM requires **one network interface**, | ||
| + | |||
| + | ==== NIC 1 — DMZ VLAN ==== | ||
| + | Purpose: | ||
| + | * Serve web interface to internal and (optionally) external users | ||
| + | * Communicate with Plex and automation VMs | ||
| + | * Outbound access for updates and API calls | ||
| + | |||
| + | Characteristics: | ||
| + | * Standard MTU (1500) | ||
| + | * Routed through firewall | ||
| + | * Static IP or DHCP reservation recommended | ||
| + | |||
| + | Placing the VM in the DMZ ensures: | ||
| + | * Isolation from internal LAN services | ||
| + | * Controlled exposure to users | ||
| + | * Minimal attack surface | ||
| + | |||
| + | ===== VMware Workstation Pro Configuration Notes ===== | ||
| + | Assuming VMware Workstation Pro 17: | ||
| + | * Attach a single virtual network adapter | ||
| + | * Bind to the physical NIC connected to the DMZ VLAN | ||
| + | * Disable unnecessary virtual hardware (sound, USB, etc.) | ||
| + | * Use VMXNET3 adapters for best performance | ||
| + | |||
| + | Do **not** connect this VM to the Primary LAN VLAN. | ||
| + | |||
| + | ===== Design Philosophy Recap ===== | ||
| + | This VM is designed to be: | ||
| + | * Quiet | ||
| + | * Predictable | ||
| + | * Disposable if needed | ||
| + | * Easy to rebuild | ||
| + | |||
| + | If it ever fails, you should be able to: | ||
| + | 1. Recreate the VM\\ | ||
| + | 2. Restore Overseerr configuration\\ | ||
| + | 3. Resume request handling | ||
| + | |||
| + | No irreplaceable data should live on the VM itself. | ||
| + | |||
| + | ===== What Comes Next ===== | ||
| + | Once the VM is deployed and reachable: | ||
| + | * Install Overseerr (native to OS) | ||
| + | * Configure firewall rules for DMZ exposure | ||
| + | * Integrate with Plex and automation VMs | ||
| + | * Configure backups and monitoring | ||
| + | |||
| + | Each of these topics is covered in their respective guides.\\ | ||
| + | |||
| + | A well-configured Overseerr VM **does its job quietly** — even if users never notice it. | ||
foundation/requestserver.1766185596.txt.gz · Last modified: by 127.0.0.1
