|
|
@@ -0,0 +1,29 @@
|
|
|
+## Context
|
|
|
+
|
|
|
+The playbook has three host groups: `relay`, `landing`, and a `localhost` play for generating client configs. Trojan variables (`trojan_domain`, `trojan_port`, `trojan_password`, `trojan_fallback_port`) live in `group_vars/landing.yml`, scoped only to the `landing` group. The Surge template on `localhost` references these variables, but `localhost` is not in the `landing` group, so the variables are undefined.
|
|
|
+
|
|
|
+## Goals / Non-Goals
|
|
|
+
|
|
|
+**Goals:**
|
|
|
+- Make trojan variables available to the `localhost` play without duplicating values
|
|
|
+- Keep server-side variables (TLS cert paths, allowed ports) scoped to `landing` only
|
|
|
+
|
|
|
+**Non-Goals:**
|
|
|
+- Restructuring the entire inventory or variable hierarchy
|
|
|
+- Changing the Surge template itself
|
|
|
+
|
|
|
+## Decisions
|
|
|
+
|
|
|
+**Move trojan variables to `group_vars/all.yml`**
|
|
|
+
|
|
|
+These variables are consumed by two consumers: the `landing` server role and the `localhost` template render. `group_vars/all.yml` is the simplest way to share them. The alternative approaches considered:
|
|
|
+
|
|
|
+1. **Add `vars:` inline to the localhost play** — would duplicate values already in `landing.yml`
|
|
|
+2. **Use `hostvars[groups['landing'][0]]` in the template** — works but makes the template harder to read and debug
|
|
|
+3. **Add `localhost` to the `landing` group** — semantically wrong, localhost isn't a landing server
|
|
|
+
|
|
|
+Moving to `all.yml` is the cleanest: single source of truth, no duplication, template stays readable.
|
|
|
+
|
|
|
+## Risks / Trade-offs
|
|
|
+
|
|
|
+- [Variable scope broadening] → Only the four trojan connection variables move; TLS paths and firewall rules stay in `landing.yml` to avoid polluting unrelated plays
|
