Differences

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

--- foundation:automationserver [2025/12/19 23:06] – created - external edit 127.0.0.1
+++ foundation:automationserver [2025/12/20 01:25] (current) – privacyl0st
@@ Line 1: / Line 1: @@
+====== 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.