User Tools

Site Tools


foundation:requestserver

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
foundation:requestserver [2025/12/19 23:06] – created - external edit 127.0.0.1foundation: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, and communicates with Plex to manage library additions. While it is **internet-adjacent**, it is designed to remain isolated in the DMZ for security. Proper VM design ensures **predictable performance and safe exposure**.\\  
 +
 +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/automation VMs  
 +  * 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, database, and logs  
 +
 +**No media is stored here.** Media resides on NAS storage accessed via internal automation services.  
 +
 +===== Network Configuration =====
 +This VM requires **one network interface**, purpose-built for controlled exposure.\\  
 +
 +==== 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