Differences

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

--- foundation:automationserver [2026/01/02 20:14] – privacyl0st
+++ foundation:automationserver [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
@@ Line 1: / Line 1: @@
-{{htmlmetatags>
-metatag-description=(Complete Plex automation guide using Sonarr, Radarr, Prowlarr, Jackett, Overseerr, Unmanic, and NVENC-enabled NVIDIA GPUs)
-metatag-robots=(index,follow)
-metatag-og:title=(Plex Automation and NVENC Hardware Transcoding Guide – Trash Panda Wiki)
-metatag-og:description=(Step-by-step Plex automation and NVENC encoding guide)
-}}
-====== Automation Services VM (ARR Suite) ======
-This virtual machine is the **engine room** of the Trash Panda ecosystem. It is responsible for media discovery, indexing, acquisition, and post-processing automation. While none of these services are internet-facing directly, they are active, chatty, and I/O intensive — which makes **proper VM design critical** to long-term stability.\\
-This page covers **only the VM setup and deployment**. Installation and configuration of Prowlarr, Sonarr, Radarr, the torrent client, and other applications are covered in their own guides.\\
-===== Role of This VM in the Ecosystem =====
-The Automation Services VM:\\
-  * Centralizes all acquisition and automation tooling
-  * Communicates with indexers and trackers
-  * Interfaces with the NAS for file access
-  * Communicates with Plex and Unmanic indirectly
-  * Remains **non-internet-exposed** by design
-By isolating these services into a dedicated VM, we:\\
-  * Reduce blast radius if something misbehaves
-  * Simplify troubleshooting
-  * Avoid polluting Plex or reverse proxy environments
-  * Gain predictable performance characteristics
-This VM lives quietly in the background — and when configured correctly, you should rarely need to touch it.
-===== 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 over bleeding-edge features
-This VM should run **headless** and be administered via SSH.
-===== Virtual Hardware Allocation =====
-==== Memory (RAM) ====
-  * **8 GB RAM (fixed allocation)**
-Why 8 GB?\\
-  * ARR applications are memory-light individually
-  * Combined workloads (indexing, parsing, API polling) benefit from headroom
-  * Prevents swap pressure during burst activity
-Avoid memory overcommit. Stable automation depends on consistent memory availability.
-==== CPU Allocation ====
-  * **2 vCPUs**
-Automation services are:\\
-  * Bursty rather than sustained
-  * Light on raw compute
-  * More sensitive to latency than throughput
-Two vCPUs provide sufficient parallelism without wasting host resources.
-==== Storage Allocation ====
-  * **50 GB virtual disk**
-  * Thin provisioned (recommended)
-This storage is used for:\\
-  * OS and system packages
-  * Application installation (native to OS)
-  * Application configuration and metadata
-  * Logs and temporary files
-**No media is stored here.** All downloads, staging, and final media storage should occur on the NAS via the NFS VLAN. NFS mount configuration is assumed to be handled by the builder.
-===== Network Configuration =====
-This VM requires **two network interfaces**, each with a very specific purpose.\\
-==== NIC 1 — LAN VLAN ====
-Purpose:\\
-  * Administrative access (SSH)
-  * API communication with Overseerr, Plex, and other internal services
-  * General outbound internet access (via firewall rules)
-  * VPN client for secure indexer and tracker access (to be installed and configured by the builder)
-Characteristics:\\
-  * Standard MTU (1500)
-  * Routed
-  * Allowed to initiate outbound connections
-This is the VM’s **control plane**.
-==== NIC 2 — NFS VLAN ====
-Purpose:\\
-  * High-speed file access to the NAS
-  * Media staging, imports, and file operations
-Characteristics:\\
-  * Layer 2 only
-  * Jumbo Frames enabled (9000 MTU)
-  * No routing to LAN or internet
-Segregating file I/O from control traffic ensures:\\
-  * Predictable performance
-  * Reduced latency
-  * Strong isolation from higher-risk services
-===== VMware Workstation Pro Configuration Notes =====
-Assuming VMware Workstation Pro 17:\\
-  * Attach two virtual network adapters
-  * Bind each adapter to its corresponding physical NIC
-  * Disable unnecessary virtual hardware (sound, USB, etc.)
-  * Use VMXNET3 adapters for best performance
-Do **not** bridge both NICs to the same network.
-===== Why This VM Is Not in the DMZ =====
-Automation services:\\
-  * Do not need inbound internet access
-  * Communicate outward only
-  * Interact with internal services via APIs
-Placing this VM outside the DMZ:\\
-  * Reduces attack surface
-  * Simplifies firewall rules
-  * Keeps noisy automation traffic away from exposed services
-If indexers or trackers are unreachable without a VPN, that concern should be addressed **at the network or firewall layer**, not by exposing this VM.
-===== Design Philosophy Recap =====
-This VM is designed to be:\\
-  * Quiet
-  * Predictable
-  * Disposable if needed
-  * Easy to rebuild
-If it ever breaks, you should be able to:\\
-. Recreate the VM\\
-. Restore configuration\\
-. Resume automation\\
-No irreplaceable data should live here.
-===== What Comes Next =====
-Once the VM is deployed and reachable:\\
-  * Application installation (native to the OS)
-  * Configure NFS mounts to the NAS
-  * Configure VPN on NIC1 (LAN VLAN) to enable secure indexer/tracker access
-  * Configure and start automation applications
-Each of these topics is covered in their respective guides.\\
-If this VM feels boring once it’s running — that means it’s doing its job.