FailedProxy/Varaverk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Platform adapter: rename System_Essentials, add Plugin/unraid/adapter.sh, wire call sites

Browse Source 
- Rename unRAID_Essentials/ → System_Essentials/ (git detects as rename)
- Add Plugin/unraid/adapter.sh: 13 platform_*() functions providing OS-agnostic API
  for storage health, service management, mover, user scripts, notifications,
  disk temps, and platform command validation
- Update load_config.sh: detect PLATFORM (unraid/truenas/unknown), export SCRIPTS_DIR,
  auto-source Plugin/$PLATFORM/adapter.sh after common.sh
- Wire all call sites: replace direct rc.d, pgrep/pkill, var.ini, dynamix.cfg,
  disks.ini, and validate_unraid_cmd calls with platform_*() functions across
  watchdogs, orchestrators, and System_Essentials scripts
- Update all documentation: rename refs, update webgui escalation logic,
  add platform adapter section to Plugin README, update main README with
  portability vision and corrected self-healing stack description
This commit is contained in:
Gmer4Lfe
2026-06-04 18:14:34 -04:00
parent de50a01ab2
commit 369a9e6c19
73 changed files with 522 additions and 228 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+51 -14
View File
@@ -2,18 +2,24 @@
# 🏠 VARAVERK
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
**A complete self-healing, self-maintaining, mutually-redundant two-server unRAID
**A complete self-healing, self-maintaining, mutually-redundant two-server home server
ecosystem.** One codebase runs on both servers. Both servers run their own lives
independently. When one goes down the other covers it — not because of conventional
fallback infrastructure, but because both servers already have copies of everything
that matters and both know how to run it.
> **This is not conventional failover.** There is no primary and standby. There is no
> shared storage. There is no cluster manager. There are two fully independent unRAID
> servers, living in different locations on different power utilities, each running
> their own household's media stack — and a layer of scripts that keeps them
> synchronised, coordinated, and mutually covering. The goal is minimal disruption to
> a media stack, not enterprise high availability.
> shared storage. There is no cluster manager. There are two fully independent servers,
> living in different locations on different power utilities, each running their own
> household's media stack — and a layer of scripts that keeps them synchronised,
> coordinated, and mutually covering. The goal is minimal disruption to a media stack,
> not enterprise high availability.
**Started on Unraid, built for portability.** The ecosystem runs on Unraid today. The
platform adapter layer (`Plugin/unraid/adapter.sh`) isolates every OS-specific call so
bash scripts stay clean. A `Plugin/truenas/adapter.sh` or `Plugin/ubuntu/adapter.sh`
provides the same function names — `load_config.sh` detects the OS and sources the
correct adapter. The scripts themselves never branch on the OS.
---
@@ -481,7 +487,15 @@ varaverk/
│ ├── host1.conf ← HOST1-specific: share lists, container names, API keys
│ └── host2.conf ← HOST2-specific: same structure, different values
├── common.sh ← Shared library — all functions used by every script
├── load_config.sh ← Sources Configurations/ and common.sh at startup
├── load_config.sh ← Detects OS platform → sources Configurations/, common.sh, adapter
│
├── Plugin/ ← Platform adapters + Unraid web UI
│ └── unraid/
│ ├── adapter.sh ← Unraid adapter: platform_*() functions (rc.d, emhttp, dynamix)
│ ├── api/ ← PHP API endpoints
│ ├── include/ ← PHP business logic
│ ├── pages/ ← Per-tab page includes
│ └── ... ← Full web UI (scheduler, monitor, docker, arrs, fallback)
│
├── Orchestrators/ ← Scheduled job runners — what Varaverk scheduler executes
│ README: README-Orchestrators.md
@@ -498,8 +512,8 @@ varaverk/
├── Docker_Essentials/ ← Container lifecycle: restarts, updates, networks
│ README: README-Docker_Essentials.md
│
├── unRAID_Essentials/ ← Server-level: WebGUI, log hygiene, kernel tuning
│ README: README-Unraid_Essentials.md
├── System_Essentials/ ← Server-level: WebGUI recovery, log hygiene, kernel tuning, reboot
│ README: README-System_Essentials.md
│
├── Media/ ← Library health + behavior-driven discovery: permissions, junk cleanup, orphan removal, weekly arr adds
│ README: README-Media.md
@@ -529,6 +543,13 @@ varaverk/
# All three conf files live in Configurations/. load_config.sh sources them.
# Sparse checkout ensures each server only receives its own host*.conf.
#
# load_config.sh does five things in order:
# 1. Detects OS platform (/etc/unraid-version → PLATFORM=unraid)
# 2. Sources master.conf
# 3. Auto-discovers and sources all host*.conf present
# 4. Sources common.sh
# 5. Sources Plugin/$PLATFORM/adapter.sh (platform_*() functions)
#
# master.conf — shared across both servers
# Everything that applies equally to both: thresholds, schedules, profile
# definitions, watchdog settings, arr cleanup config, DDNS timing, etc.
@@ -547,6 +568,11 @@ varaverk/
# Aliases HOST2_DAILY_SYNC_SHARES → DAILY_SYNC_SHARES (if on HOST2)
# Every script uses the unprefixed name. The same script on either server
# automatically uses the correct values. No hostname comparisons in scripts.
#
# Plugin/$PLATFORM/adapter.sh — OS-specific function implementations
# Scripts call platform_restart_service(), platform_storage_healthy(), etc.
# The adapter maps those to rc.d scripts, emhttp commands, and dynamix files
# on Unraid — or to systemctl, mount checks, etc. on a future platform.
# ─────────────────────────────────────────────────────────────────────────────
```
@@ -667,8 +693,8 @@ Problem: RAM drops to 3GB
→ If RAM drops to 4GB AND 3+ OOM kills: bypass strikes → reboot
Problem: Docker daemon hung
→ stability_watchdog.sh Tier 1: attempt /etc/rc.d/rc.docker restart
→ If still hung: immediate reboot (no strikes needed — daemon can't be managed)
→ docker_watchdog.sh: attempt platform_restart_service docker (rc.d on Unraid)
→ If still hung: sets daemon_confirmed_down flag → stability_watchdog escalates → reboot
Problem: HOST1 loses power
→ fallback.sh on HOST2 detects at next 2-minute check
@@ -677,7 +703,7 @@ Problem: HOST1 loses power
```
**→ Container healing: [README-Docker_Essentials.md](Docker_Essentials/README-Docker_Essentials.md)**
**→ System stability: [README-Unraid_Essentials.md](unRAID_Essentials/README-Unraid_Essentials.md)**
**→ System stability: [README-System_Essentials.md](System_Essentials/README-System_Essentials.md)**
---
@@ -795,15 +821,15 @@ If you're setting this up from scratch on two servers:
|--------|---------------|
| [README-Fallback.md](Fallback/README-Fallback.md) | DDNS sequencing, tiered fallback, handback, split brain prevention, fallback_test.sh |
| [README-Docker_Essentials.md](Docker_Essentials/README-Docker_Essentials.md) | Two-tier container watchdog, memory limits, dependency ordering, skip list, daily/weekly restarts |
| [README-Unraid_Essentials.md](unRAID_Essentials/README-Unraid_Essentials.md) | Three-tier system watchdog, WebGUI recovery, inotify tuning, PHP-FPM, log hygiene |
| [README-System_Essentials.md](System_Essentials/README-System_Essentials.md) | WebGUI recovery, inotify tuning, PHP-FPM, log hygiene, mover/reboot/rsync stop |
| [README-Orchestrators.md](Orchestrators/README-Orchestrators.md) | What runs when, execution order, daily/weekly windows, adding jobs |
| [README-Media.md](Media/README-Media.md) | Permissions model, junk cleanup, arr orphan removal, safety layers, behavior-driven discovery, testing procedure |
| [README-Transcoding.md](Transcodes/README-Transcoding.md) | Ramdisk design, symlink architecture, Docker mount requirement, SSD fallback |
| [README-Monitors.md](Monitors/README-Monitors.md) | Cert monitoring, SMART health, bandwidth tracking, health digest profiles |
| [README-Partnership.md](Partnership/README-Partnership.md) | Auth stack sharing, onboard/offboard/transfer lifecycle, deferred offboard |
| [README-Plugin.md](Plugin/README-Plugin.md) | Platform adapter API, Unraid web UI, scheduler/monitor/docker pages |
| [Manual.md](Manual.md) | Complete setup guide — Tailscale, SSH keys, git clone, master.conf, Varaverk scheduler |
| [README-Tools.md](Tools/README-Tools.md) | fallback_state_reset, skip list manager, emby_database_repair, container export |
| [README-Unraid_Essentials.md](unRAID_Essentials/README-Unraid_Essentials.md) | `git_pull_execute.sh`, `server_reboot.sh`, `mover_stop.sh`, `user_scripts_stop.sh` |
---
@@ -848,6 +874,17 @@ Things that are different from what you might expect:
# lidarr_cleanup.sh, sonarr_cleanup.sh, radarr_cleanup.sh permanently delete
# orphaned files. Safety layers prevent catastrophic runs but always test with
# --dry-run --log first on a new system. README-Media.md has the full procedure.
# 9. Scripts never call OS commands directly.
# All platform-specific operations go through plugin_*() functions defined in
# Plugin/$PLATFORM/adapter.sh. rc.d scripts, emhttp, dynamix, disks.ini — all
# isolated in the adapter. This is what makes the codebase portable.
# Adding a new OS = writing one adapter file, not patching dozens of scripts.
# 10. System_Essentials/ is platform-agnostic at the script level.
# Scripts like server_reboot.sh, mover_stop.sh, and webgui_watchdog.sh call
# adapter functions (platform_is_mover_running, platform_restart_service, etc.)
# The adapter handles what those mean on the actual OS. The scripts are clean.
# ─────────────────────────────────────────────────────────────────────────────
```