feat: seed god_admin + docker plugin, fix ldap-client enrollment, roll up sso v1.26.0 + theta-agent v1.3.0 (v1.36.0) (#161)

- bootstrap: seed god_admin into the admin's groups; seed a docker-local discovery plugin
- setup.sh: generate ldap-client/ldap.vars from the stack config so LDAP enrollment works
- docs: GROUPS.md site-slug convention (verbatim, kind in resource slug)
- gitlinks: sso-manager-node 8a9de94 (v1.26.0), theta-agent 52379c2 (v1.3.0)

CHANGELOG.md

@@ -1,8 +1,3 @@
-# v1.31.0
-- feat: Integrate full suite CI/CD
-- feat: Update plugins ecosystem documentation
-- chore: Bump all submodules to latest tags
-
 # Changelog
 
 All notable changes to this project are documented here. Format loosely
@@ -13,6 +8,132 @@ orchestration code; see each submodule's own `CHANGELOG.md`
 [sso-manager-node](https://github.com/theta42/sso-manager-node/blob/master/CHANGELOG.md))
 for what changed inside the apps it composes.
 
+## [v1.36.0] - 2026-08-04
+
+### Added
+- **`god_admin` seeded + site groups auto-provisioned** (sso v1.26.0) — `god_admin` exists from first boot; every site gets `{site}_super_admin`, `{site}_hosts_*`/`{site}_apps_*` aggregates and `{site}_everyone`; per-resource groups (`{site}_{slug}_{level}`) nest into the site aggregates (the inheritance lattice now exists in LDAP, not just the resolver). See the sso changelog for the full group-model completeness + server-side naming enforcement + Directory god_admin management.
+- **Docker discovery plugin configured out of the box** — the bootstrap seeds a `docker-local` plugin instance pointed at `/var/run/docker.sock`, so a fresh stack discovers its own containers into the Directory immediately (idempotent; an operator-created instance is left alone).
+
+### Fixed
+- **ldap-client enrollment no longer fails** — `setup.sh` was calling `ldap-client/index.sh`, which refuses to run without a gitignored `ldap.vars` that nothing ever created (the "ldap.vars file not found!" + "enrollment failed" you saw). It now generates `ldap-client/ldap.vars` from the stack's own config (LDAPS host, base DN, `cn=ldapclient` bind + service password, SSO URL, site name) before enrolling; an operator-provided `ldap.vars` is always kept.
+- **theta-agent no longer logs `Unknown command type: heartbeat_ack`** every minute — the server's ack of the agent's own heartbeat is now silently ignored instead of falling through to the unknown-command handler (which also answered with a spurious error).
+
+### Changed
+- **Roll up sso v1.26.0 + theta-agent v1.3.0** — gitlinks point at the version-tagged commits for both submodules (sso-manager-node → 8a9de94, theta-agent → 52379c2). Full changelogs: [sso](https://github.com/theta42/sso-manager-node/blob/master/CHANGELOG.md), [theta-agent](https://github.com/theta42/theta-agent/blob/master/CHANGELOG.md).
+
+## [v1.35.18] - 2026-08-04
+
+### Changed
+- **Sync proxy + jump-host gitlinks to their version-tagged commits** — proxy v1.33.0 and jump-host v1.18.0 bumped their package.json to match their tags; this release picks up those corrected gitlinks so a fresh deploy reports the matching versions.
+
+## [v1.35.17] - 2026-08-04
+
+### Added
+- **Group & Permission Model spec** — canonical documentation of the hierarchical group schema (`god_admin`, `{site}_super_admin`, per-site/per-resource host+app `admin`/`access`/`<capability>` groups, meta `everyone`/`{site}_everyone`), the inheritance resolver, Directory-only group management, multi-site isolation, host-side SSSD GID mapping (groups are `groupOfNames`, no `gidNumber`), downstream-app consumption, and migration from the legacy `app_*` groups. See [GROUPS.md](GROUPS.html).
+- **sso v1.25.0** — the resolver + schema implemented in the SSO (see its changelog); the standalone Groups page removed.
+
+## [v1.35.16] - 2026-08-04
+
+### Added
+- **theta-proxy + theta-jump as first-class managed host resources** — the bootstrap now seeds them as managed `host`-kind resources in the Directory (in addition to the existing stack host and its service entries), so a fresh install shows them as hosts.
+
+## [v1.35.15] - 2026-08-04
+
+### Fixed
+- **theta-agent re-install failed with "Text file busy"** — setup.sh copied the prebuilt binary over a running agent service, which cp refuses. It now stops the service before copying.
+
+## [v1.35.14] - 2026-08-04
+
+### Fixed
+- **The recurring `/vault` 403 "permission denied" is actually dead this time — it was never a policy problem.** sso's `/api/vault` proxy declared its request hook with http-proxy-middleware **v3** syntax (`on: { proxyReq }`) while the app installs HPM **v2**, which silently ignores the unknown key — so `X-Vault-Token` was never injected and every vault call reached OpenBao unauthenticated. All the policy work of v1.35.10/v1.31.1 was correct and is unchanged; the requests just never carried a token. Ships as **sso v1.23.0** (see its changelog for the companion `fixRequestBody` header-ordering fix and the initORM schema heal that unbreaks the plugin scheduler on upgraded databases).
+
+### Added
+- **OpenBao token lifecycle — nothing expires by surprise anymore.**
+  - New **`theta-svc` token role** (periodic 768h): `SSO/PROXY/JUMP_VAULT_TOKEN` are now minted through it instead of as plain orphan tokens with a hard ~32-day death date. `ensure_token` renews periodic tokens on every `setup.sh` re-run and detects, revokes, and re-mints valid-but-non-periodic tokens from older installs (detection is the token's `role` — OpenBao token lookup does not expose a `period` field).
+  - New **`bao-renewer` sidecar** (docker-compose): renews the three service tokens every 12h while the stack runs, logging each result. Recreated on every `setup.sh` run so it always holds the current tokens.
+  - New **`sso-app` token role** (periodic 768h): external-app tokens minted from the vault UI go through it instead of the broker's 24h role, and sso now stores each app token's *accessor* and auto-renews it (boot + every 6h) — a downstream app's credential stays valid as long as sso runs, with no renewal code in the downstream app.
+  - `sso-broker` policy gained `update` on `auth/token/create/sso-app` and `auth/token/renew-accessor`/`revoke-accessor`/`lookup-accessor`.
+  - `docs/secrets.md` rewritten around the new lifecycle (roles table, renewal layers, disaster recovery).
+
+## [v1.35.13] - 2026-08-04
+
+### Added
+- **sso v1.22.0** — new **Agents** page (live list of connected theta-agent hosts with CPU/RAM/disk/ZFS/GPU telemetry + online status) and a security fix gating the `/api/agent` REST routes. Bumped the sso-manager-node gitlink to v1.22.0.
+
+## [v1.35.12] - 2026-08-04
+
+### Fixed
+- **theta-agent crash-looped (`cannot unmarshal !!bool 'true' into []string`)** — setup.sh's "full control" edit wrote `service_control: true`, but that field is a `[]string` allowlist, so the agent failed to decode the config and restart-loop. Removed the invalid edit; `service_control` now stays as its allowlist (default `[]` = deny all) and the operator can list specific services.
+
+## [v1.35.11] - 2026-08-04
+
+### Fixed
+- **`setup.sh` aborted with `UNSEAL_KEY: unbound variable` on re-runs** — when OpenBao was already unsealed, the unseal block was skipped and `UNSEAL_KEY` was never set, so the later `if [[ -n "$UNSEAL_KEY" ]]` crashed under `set -u`. Guarded with `${UNSEAL_KEY:-}`.
+
+## [v1.35.10] - 2026-08-04
+
+### Added
+- **`--reset-openbao`** — full clean OpenBao reset for clearing stale policies/tokens (re-inits the store, flushes the Redis vault-token cache). Use when the vault UI shows a recurring `403 permission denied` on the secrets list.
+- **sso v1.21.0** — shared secrets: users publish secrets to `secret/shared/<owner>/<slug>` and grant read access to other users and apps; plus a durable fix for the recurring vault 403 (broker now always reconciles policy content before serving a cached token). Bumped the sso-manager-node submodule gitlink to v1.21.0.
+
+### Fixed
+- **theta-agent was never installed** — `setup.sh` tried to `go build` from an incomplete source-file list (omitting `executor.go`/`telemetry.go`), which failed silently and skipped install. It now installs the prebuilt `theta-agent-linux-amd64` binary from the submodule and writes config to `/etc/theta42/agent.yml` (the path the agent actually reads).
+
+## [v1.35.9] - 2026-08-03
+
+### Fixed
+- **sso & proxy version strings now match their release tags** — The v1.20.2 / v1.32.0 release tags were created but their `nodejs/package.json` version fields were left behind (1.20.1 / 1.14.3), so the deployed apps' update-check banner falsely reported a newer version. Bumped submodules to the corrected commits so `buildVersion` matches the deployed tag.
+
+## [v1.35.2] - 2026-08-03
+
+### Fixed
+- **Unbound `CFG_CREATE_ALL_HTTP` variable in `setup.sh`** — Fixed unbound variable error during host registration in `setup.sh` when `ensure_secrets_files()` is skipped on pre-configured installations.
+
+## [v1.35.1] - 2026-08-03
+
+### Fixed
+- **Directory & Configuration UI enhancements** — Live Cytoscape graph update on parent/child edge modifications, improved discovery reconciler host matching, updated configuration sidebar layout, relocated discovery and messaging plugins to Directory and Configuration pages.
+- **Managed Host Target Filter** — Filter SSH connection targets in Jump Host to managed hosts only.
+
+## [v1.35.0] - 2026-08-02
+
+### Added
+- **Non-interactive theta-agent configuration** — Added three `setup.env` variables
+  to control theta-agent installation and configuration without interactive prompts:
+  - `CFG_THETA_AGENT_ENABLE` (default: 1) — Enable theta-agent installation
+  - `CFG_THETA_AGENT_LDAP_AUTH` (default: 1) — Configure LDAP authentication via ldap-client
+  - `CFG_THETA_AGENT_FULL_CONTROL` (default: 1) — Enable all agent capabilities
+
+### Changed
+- **`setup.sh`**: Made theta-agent setup fully non-interactive, driven by `setup.env`
+  variables. Defaults preserve existing behavior (all features enabled).
+
+## [v1.34.0] - 2026-08-02
+
+### Added
+- **theta-agent**: Added the agent submodule and C2 WebSocket endpoint integrations to the suite.
+- **PKI Certificates**: Integrated PKI certificate generation and management capabilities.
+
+### Changed
+- **Submodules bumped**:
+  - `sso-manager-node` updated to `v1.19.2` (Includes Discovery graph merge fix).
+  - `proxy` updated to `v1.14.1` (Removed invalid documentation copy from Dockerfile).
+  - `jump-host` updated to `v1.16.1`.
+- **`setup.sh`**: Added robust `|| true` fallback to Redis `LASTSAVE` and `CONFIG GET` commands to gracefully bypass snapshoting if the target container is in a crash-loop.
+- **Docs**: Removed all standalone deployment documentation to officially deprecate standalone mode.
+- **CI/CD**: Removed redundant submodule unit test jobs from the main orchestration pipeline.
+
+## [v1.33.0] - 2026-08-02
+
+### Changed
+- **Submodules bumped** for OpenBao secret integration.
+
+## [v1.32.0] - 2026-08-01
+
+### Added
+- **CI/CD**: Added robust GitHub Actions CI/CD workflows for the suite.
+- **Docs**: Updated plugin ecosystem documentation.
+
 ## [v1.31.1] - 2026-08-01
 
 Pairs the sso v1.17.2 post-deploy fixes with the theta-suite half of the
@@ -1525,3 +1646,12 @@ First tagged release. Establishes the `vX.Y.Z` tag convention going forward.
 [1.1.2]: https://github.com/theta42/theta-suite/compare/v1.1.1...v1.1.2
 [1.1.1]: https://github.com/theta42/theta-suite/compare/v1.1.0...v1.1.1
 [1.1.0]: https://github.com/theta42/theta-suite/releases/tag/v1.1.0
+
+## [1.34.4] - 2026-08-02
+### Changed
+- Updated `sso-manager-node` submodule to `v1.19.6` to pull in a fix for the Vault API 403 error on the Secrets List.
+
+## [1.34.5] - 2026-08-02
+### Added
+- Automatically build and install `theta-agent` on the host system as a systemd service during `setup.sh`.
+- Added `CFG_CREATE_ALL_HTTP` option to `setup.env` to create all default proxy host entries with `forcessl=false`.

README.md

@@ -140,8 +140,7 @@ Optional extra ports (only if you need them):
 
 ### 4. Docker + Docker Compose
 
-Any recent Docker with Compose — the v2 plugin (`docker compose`) or the v1
-standalone (`docker-compose`) both work.
+You must use the modern Docker Compose v2 plugin (`docker compose`). The older v1 standalone (`docker-compose`) is not compatible with the BuildKit images generated by this suite and will fail with a `ContainerConfig` KeyError during deployment.
 
 ---
 

bootstrap/bootstrap.js

@@ -89,7 +89,12 @@ const CLIENT_NAME = 'theta-proxy';
 
 const ADMIN_DN  = `cn=${ADMIN_UID},ou=people,${BASE_DN}`;
 const SVC_DN    = `cn=ldapclient,ou=people,${BASE_DN}`;
-const ADMIN_GROUPS = ['app_sso_admin', 'app_sso_oauth_admin'];
+// god_admin is the global super group (docs/GROUPS.md §2); the bootstrapped
+// admin is its first member. app_sso_admin / app_sso_oauth_admin are the legacy
+// per-console admin groups still used by the SSO UI. god_admin is nested into
+// app_super_admin by docker-entrypoint.sh, so LDAP-level consumers (SSSD, sudo)
+// resolve it transitively.
+const ADMIN_GROUPS = ['god_admin', 'app_sso_admin', 'app_sso_oauth_admin'];
 
 const log  = (...a) => process.stderr.write('[bootstrap] ' + a.join(' ') + '\n');
 const out  = (k, v) => process.stdout.write(`${k}=${v}\n`);
@@ -423,15 +428,46 @@ async function seedDirectory(token, clientId, jumpClientId) {
 	const host = await ensure('host', HOST_FACTS.name || 'Stack host', hostSlug, site.id, {
 		subType: 'linux',
 		ip: HOST_FACTS.ip,
+		address: HOST_FACTS.ip,
 		macAddress: HOST_FACTS.mac,
 		os: HOST_FACTS.os,
 		kernel: HOST_FACTS.kernel,
+		sshPort: 22,
+		managed: true,
 	}, ['stack-host']);
+
+	// theta-proxy and theta-jump are first-class managed host resources (their
+	// names match the OAuth client identities the proxy/jump apps use). They
+	// appear as hosts in the Directory; the per-app services below still carry
+	// the OAuth-client + reachability detail.
+	const jumpHostAddr = process.env.CFG_JUMP_HOST || (DOMAIN ? `jump.${DOMAIN}` : '');
+	await ensure('host', 'theta-proxy', 'host_theta-proxy', site.id, {
+		subType: 'linux',
+		address: `https://${PROXY_HOST}`,
+		port: 3000,
+		gitRepo: 'https://github.com/theta42/proxy',
+		icon: 'mdi:server-network',
+		tagline: 'Reverse proxy and API gateway (node management UI).',
+		managed: true,
+	});
+	await ensure('host', 'theta-jump', 'host_theta-jump', site.id, {
+		subType: 'ssh',
+		address: jumpHostAddr ? `https://${jumpHostAddr}` : '',
+		port: 3002,
+		gitRepo: 'https://github.com/theta42/jump-host',
+		icon: 'mdi:ssh',
+		tagline: 'Secure SSH jump host.',
+		managed: true,
+	});
+
 	await ensure('service', 'SSO Manager', 'sso-manager', host.id, {
 		address: `https://${SSO_HOST}`,
 		port: 3001,
 		gitRepo: 'https://github.com/theta42/sso-manager-node',
 		subType: 'web',
+		icon: 'mdi:shield-account',
+		tagline: 'Home-lab identity and access management.',
+		requestable: false,
 	});
 	// Proxy = the node management UI; OpenResty = the data plane every hostname
 	// in the stack actually flows through (80/443). Two faces, two entries.
@@ -440,6 +476,9 @@ async function seedDirectory(token, clientId, jumpClientId) {
 		port: 3000,
 		gitRepo: 'https://github.com/theta42/proxy',
 		subType: 'web',
+		icon: 'mdi:server-network',
+		tagline: 'Reverse proxy and API gateway.',
+		requestable: false,
 	});
 	// OpenLDAP is independently consumed — Linux hosts authenticate against it
 	// (PAM/SSSD, sudoRole, sshPublicKey) and LDAP-native apps bind directly
@@ -451,8 +490,12 @@ async function seedDirectory(token, clientId, jumpClientId) {
 		address: `ldaps://${LDAPS_HOST}:636`,
 		port: 389,
 		externalPort: 636,
+		portMappings: [{ proto: 'tcp', external: 636, internal: 389, comment: 'LDAPS' }],
 		gitRepo: 'https://github.com/theta42/sso-manager-node',
 		subType: 'openldap',
+		icon: 'mdi:book-open-outline',
+		tagline: 'LDAP directory for identity.',
+		requestable: false,
 	});
 	// Wildcard address: OpenResty fronts every host under the domain (same
 	// */** wildcard convention the proxy's Host records use). Its config lives
@@ -462,6 +505,9 @@ async function seedDirectory(token, clientId, jumpClientId) {
 		port: 443,
 		gitRepo: 'https://github.com/theta42/proxy',
 		subType: 'openresty',
+		icon: 'mdi:router-network',
+		tagline: 'Data plane.',
+		requestable: false,
 	});
 
 	// SSH jump host service (core component — always registered).
@@ -473,6 +519,9 @@ async function seedDirectory(token, clientId, jumpClientId) {
 			port: 3002,
 			gitRepo: 'https://github.com/theta42/jump-host',
 			subType: 'ssh',
+			icon: 'mdi:ssh',
+			tagline: 'Secure SSH jump host.',
+			requestable: false,
 		});
 	}
 
@@ -493,6 +542,59 @@ async function seedDirectory(token, clientId, jumpClientId) {
 	await linkOauthClient(jumpClientId, jumpSvc, 'jump-host');
 }
 
+// ── Plugin instances ────────────────────────────────────────────────────────
+// Seed a sensible default set of plugin instances so the stack is usable the
+// moment it boots, without the operator having to add them by hand. The setup
+// stack runs on Docker, so the single biggest win is a Docker discovery plugin
+// pointed at the local daemon socket: containers that make up the stack (and
+// any others on the host) get discovered into the Directory automatically.
+// Idempotent per slug: an instance an operator already created is left alone.
+async function seedPlugins(token) {
+	async function pluginGet(path) {
+		const res = await fetch(`${SSO_INTERNAL}/api/plugins/${path}`, {
+			headers: { 'auth-token': token },
+		});
+		if (!res.ok) throw new Error(`GET /api/plugins/${path} failed (${res.status})`);
+		return res.json();
+	}
+	async function pluginPost(body) {
+		const res = await fetch(`${SSO_INTERNAL}/api/plugins/`, {
+			method: 'POST',
+			headers: { 'auth-token': token, 'Content-Type': 'application/json' },
+			body: JSON.stringify(body),
+		});
+		if (!res.ok) {
+			const text = await res.text().catch(() => '');
+			throw new Error(`POST /api/plugins failed (${res.status}): ${text}`);
+		}
+		return res.json();
+	}
+
+	async function ensurePlugin({ pluginType, name, slug, config }) {
+		const existing = ((await pluginGet('')).results) || [];
+		if (existing.some((i) => i.slug === slug)) {
+			log(`  plugins: '${slug}' exists — keeping`);
+			return;
+		}
+		await pluginPost({ pluginType, name, slug, config });
+		log(`  plugins: created '${slug}' (${pluginType})`);
+	}
+
+	try {
+		// The Docker daemon the setup stack itself runs under. The socket must be
+		// mounted into the sso container for discovery to reach it; if it isn't,
+		// discovery simply errors non-fatally until it is.
+		await ensurePlugin({
+			pluginType: 'docker',
+			name: 'Local Docker daemon',
+			slug: 'docker-local',
+			config: { socketPath: '/var/run/docker.sock' },
+		});
+	} catch (e) {
+		log(`WARNING: plugin seed failed (${e.message || e}) — continuing`);
+	}
+}
+
 // Write the OAuth client creds back into /config/proxy-secrets.js so the proxy
 // (which reads that file) can use them. Only the clientId/clientSecret lines
 // are touched; the rest of the file (operator edits, comments) is preserved.
@@ -573,7 +675,6 @@ function writeJumpSecrets(apiToken, oidc, localAdminPass) {
 // sshPublicKey attribute (key injection); for a hardened deployment use a
 // scoped account with an sshPublicKey write-ACL instead (see jump-host README).
 module.exports = {
-\tname: ${JSON.stringify(sso.name || 'SSO Manager')},
 \tldap: {
 \t\t// ldaps:// (636), not ldap:// (389): @simpleworkjs/ldap's client always
 \t\t// sets tlsOptions (see jump-host's models/user_ldap.js), and ldapts
@@ -743,6 +844,15 @@ async function provisionJumpHost(token) {
 			log(`WARNING: directory seed failed (${e.message || e}) — continuing`);
 		}
 
+		// Seed default plugin instances (Docker discovery) — same warn-and-go
+		// policy; a stack without plugins is still usable.
+		try {
+			log('Seeding default plugins...');
+			await seedPlugins(token);
+		} catch (e) {
+			log(`WARNING: plugin seed failed (${e.message || e}) — continuing`);
+		}
+
 		log('Done.');
 		process.exit(0);
 	} catch (e) {

docker-compose.yml

@@ -238,6 +238,42 @@ services:
       - ./config/ldap-test-host.vars:/config/ldap.vars:ro
       - ./config/ldap-ca.crt:/config/ldap-ca.crt:ro
 
+  # Renews the three periodic service tokens (theta-svc role, 768h period)
+  # every 12h. Periodic tokens live forever ONLY while something renews them —
+  # this sidecar is that something, so the stack survives arbitrarily long
+  # uptimes and the tokens in .env never silently expire. If a token is missing
+  # or already dead it just logs and moves on (setup.sh re-mints on next run).
+  bao-renewer:
+    image: quay.io/openbao/openbao:latest
+    container_name: bao-renewer
+    restart: unless-stopped
+    depends_on:
+      - openbao
+    environment:
+      - BAO_ADDR=http://openbao:8200
+      - SSO_VAULT_TOKEN=${SSO_VAULT_TOKEN:-}
+      - PROXY_VAULT_TOKEN=${PROXY_VAULT_TOKEN:-}
+      - JUMP_VAULT_TOKEN=${JUMP_VAULT_TOKEN:-}
+    entrypoint: ["/bin/sh", "-c"]
+    command:
+      - |
+        renew() {
+          if [ -z "$$2" ]; then return 0; fi
+          if BAO_TOKEN="$$2" bao token renew > /dev/null 2>&1; then
+            echo "[bao-renewer] renewed $$1"
+          else
+            echo "[bao-renewer] FAILED to renew $$1 (expired/revoked? re-run setup.sh to re-mint)"
+          fi
+        }
+        while true; do
+          renew SSO_VAULT_TOKEN "$$SSO_VAULT_TOKEN"
+          renew PROXY_VAULT_TOKEN "$$PROXY_VAULT_TOKEN"
+          renew JUMP_VAULT_TOKEN "$$JUMP_VAULT_TOKEN"
+          sleep 43200
+        done
+    networks:
+      - theta-net
+
   openbao:
     image: quay.io/openbao/openbao:latest
     container_name: openbao

docs/GROUPS.md

@@ -0,0 +1,323 @@
+---
+layout: default
+title: Group & Permission Model
+nav_order: 3
+---
+
+# Theta42 Group & Permission Model
+
+This is the canonical reference for how **groups and permissions work** across the
+theta42 suite (SSO Manager, Proxy, Jump-Host) and how **downstream apps and Linux
+hosts** should read and use them. It is written to be implementable by both humans
+and LLM agents.
+
+Everything below assumes LDAP is the single source of truth for identity and group
+membership. Group membership is managed in the **SSO Manager Directory**, generated
+from adopted resources — there is **no standalone "Groups" page**.
+
+---
+
+## 1. Principles
+
+1. **Groups are a projection of the resource graph.** Every adopted host and app
+   in the Directory gets its own groups, auto-created from its identity. Group
+   membership is managed on the resource's modal.
+2. **Two orthogonal resource namespaces: `host` and `app`.** A host administers
+   hosts; an app administers apps. They do not inherit from each other.
+3. **Three levels per resource: `admin`, `access`, and opaque `capability`.**
+   `admin` implies `access`. Capabilities are explicit and never implied by
+   `admin`.
+4. **Multi-site by prefix.** Each site's groups are fully independent, scoped by
+   the site slug.
+5. **Hosts map, LDAP stays clean.** Directory groups are `groupOfNames` (RBAC)
+   with **no `gidNumber`**. A Linux host uses SSSD to import only the groups it
+   needs and generate their GIDs on the fly (see §8) — no mass import, no GID
+   bloat. Only the meta groups are never imported by hosts.
+6. **The directory is the only place groups are created.** `god_admin` is the sole
+   group that does not belong to a resource or site.
+
+---
+
+## 2. Group schema
+
+`S` = site slug (see §7 for normalization). `<host>`/`<app>` = the resource slug.
+`<capability>` = an opaque, app-defined capability token (see §4).
+
+| Group | Scope | Meaning |
+| :--- | :--- | :--- |
+| `god_admin` | global | **Everything, everywhere** (all sites, hosts, apps, consoles, all capabilities). The only non-site group. |
+| `S_super_admin` | site | Everything on site `S` (all hosts, apps, consoles, all capabilities at `S`). |
+| `S_hosts_admin` | site | Admin on **all hosts** at `S`. |
+| `S_hosts_access` | site | Access to **all hosts** at `S`. |
+| `S_hosts_<capability>` | site | Capability `<capability>` on **all hosts** at `S`. |
+| `S_host_<host>_admin` | host | Admin on host `<host>`. |
+| `S_host_<host>_access` | host | Access to host `<host>`. |
+| `S_host_<host>_<capability>` | host | Capability `<capability>` on host `<host>`. |
+| `S_apps_admin` | site | Admin on **all apps** at `S`. |
+| `S_apps_access` | site | Access to **all apps** at `S`. |
+| `S_apps_<capability>` | site | Capability `<capability>` on **all apps** at `S`. |
+| `S_app_<app>_admin` | app | Admin on app `<app>`. |
+| `S_app_<app>_access` | app | Access to app `<app>`. |
+| `S_app_<app>_<capability>` | app | Capability `<capability>` on app `<app>`. |
+
+### Meta groups (implicit membership — not POSIX, no gidNumber)
+
+| Group | Scope | Meaning |
+| :--- | :--- | :--- |
+| `everyone` | global | **All authenticated users**, any site. |
+| `S_everyone` | site | **All authenticated users** at site `S`. |
+
+These are resolved by the directory (any authenticated user passes), never
+enumerated as LDAP members, and cannot be used as Unix groups.
+
+---
+
+## 3. Naming, normalization & reserved rules
+
+- The **structural delimiter is `_`**. It appears only between the fixed segments
+  of a group name.
+- **The `S` site segment is the site resource's slug verbatim.** In the SSO
+  Directory, site/host resource slugs carry a kind prefix (`site_local`,
+  `host_theta-env`); the group builders keep them verbatim rather than
+  re-slugifying (which would corrupt the delimiter: `site_local` → `site-local`)
+  or inserting a separate kind segment. So a host resource `host_theta-env` under
+  site `site_local` yields `site_local_host_theta-env_access` (the `host_` is part
+  of the resource slug), and the site's own admin group is `site_local_super_admin`.
+  Services are stored without a prefix, giving `site_local_sso-manager_access`.
+  The kind (`host`/`app`) is used only to pick the **aggregate** the resource's
+  group nests into (`{site}_hosts_*` / `{site}_apps_*`), not the resource's own
+  group name.
+- **Within a segment, normalize to lowercase** — spaces and stray `_` → `-`; strip
+  other non-`[a-z0-9-]`. A host named `Web 01` and a site `Main Office` (resource
+  slugs `host_web-01` and `site_main-office`) yield groups `site_main-office_host_web-01_*`.
+- **Aggregate groups use the plural kind** (`hosts`, `apps`); per-resource groups
+  use the singular (`host`, `app`). This makes `S_hosts_admin` unambiguous even
+  if a host were named `admin` (that host would be `S_host_admin_admin`).
+- **The last segment is the level.** If it is `admin` or `access` it is a known
+  level; any other value is an **opaque capability** owned by a downstream app.
+- **Total length budget:** keep a group cn under ~120 chars; reject group
+  creation that would exceed it.
+- Groups are **`groupOfNames`** (RFC 2307bis) with **no `gidNumber`**. GIDs are
+  generated on the host by SSSD for only the groups that host imports (see §8).
+
+---
+
+## 4. Levels and opaque capabilities
+
+- **`admin`** — manage (create/update/delete/config) the resource.
+- **`access`** — use/read the resource.
+- **`<capability>`** — an arbitrary token the SSO does **not** interpret. The SSO
+  manages membership and exposes the group to the app; **the downstream app
+  defines and enforces what the capability means** (e.g. `emby_admin`,
+  `gitea_maintain`, `reboot`, `backup`).
+
+The directory recognizes `admin`, `access`, `super_admin`, and the meta groups.
+Everything else on a resource group is treated as an opaque capability group and
+passed through to consumers.
+
+---
+
+## 5. Permission resolution (inheritance)
+
+Define a user's **effective permission** on a resource by checking, from most
+specific to most general, whether they are a member of any applicable group. The
+rule: a higher group implies everything below it.
+
+### On host `H` at site `S`
+
+| Wanted | Granted if the user is a member of **any** of |
+| :--- | :--- |
+| **admin** on `H` | `god_admin` · `S_super_admin` · `S_hosts_admin` · `S_host_H_admin` |
+| **access** on `H` | (any admin rule above) · `S_hosts_access` · `S_host_H_access` |
+| **capability `C`** on `H` | `god_admin` · `S_super_admin` · `S_hosts_C` · `S_host_H_C` |
+
+### On app `A` at site `S`
+
+Identical, with `app`/`apps` substituted for `host`/`hosts`.
+
+### Management console (SSO / Proxy / Jump-Host)
+
+Each console is registered as an **app** on its site, so console admin is:
+
+`god_admin` · `S_super_admin` · `S_app_<console>_admin`
+
+### Pseudocode
+
+```
+def effective(resource, level_or_cap, site):
+    if user in "god_admin":                  return True
+    if user in f"{site}_super_admin":        return True
+    if level_or_cap in ("admin","access"):
+        agg = f"{site}_{resource.kind}s_{level_or_cap}"
+        if user in agg:                      return True
+    specific = f"{site}_{resource.slug}_{level_or_cap}"   # slug carries its kind
+    if user in specific:                     return True
+    if level_or_cap == "access":             return effective(resource, "admin", site)
+    if level_or_cap == "admin":              return False          # access does not imply admin
+    return False
+```
+
+`everyone` / `S_everyone` are a special grantee: if a resource grants a group to
+`everyone` (or `S_everyone`), any authenticated user (at that site) passes.
+
+---
+
+## 6. Where groups live — the Directory, generated from adopted resources
+
+- There is **no standalone Groups page.** Group creation/management happens on an
+  **adopted resource** in the Directory.
+- When a host or app is **adopted** (promoted from Discovered Inventory to
+  managed), the directory auto-creates its `_admin` and `_access` groups (and
+  site aggregates if configured). Capability groups are created on demand.
+- Membership (add/remove users) and capability grants are managed on that
+  resource's modal.
+- Deleting a resource removes its per-resource groups.
+- The `S_super_admin`, `S_hosts_*`, `S_apps_*`, `S_everyone` site groups and the
+  global `god_admin`/`everyone` are managed at the site level (not on a single
+  host/app resource).
+
+---
+
+## 7. Multi-site isolation
+
+One LDAP tree can serve many sites ("Main Office", "Branch Office", "co-lo",
+"Mikes Homelab", …). Each site `S` has its own fully independent set of `S_*`
+groups behind its prefix. A `main-office_super_admin` or `main-office_hosts_admin`
+touches nothing in `branch-office_*` or `steves-homelab_*`. Only `god_admin` and
+`everyone` cross site boundaries.
+
+---
+
+## 8. Unix/POSIX groups — mapped on the host, not in LDAP
+
+Directory groups are **`groupOfNames`** (RFC 2307bis) and carry **no `gidNumber`**.
+There are hundreds of them and only a handful matter on any given host, so we do
+**not** bloat LDAP with GIDs. Instead, each Linux host uses SSSD to import only the
+groups it cares about and map them to GIDs **on the fly** (algorithmic ID mapping).
+This keeps the directory clean and the per-host surface tiny.
+
+### SSSD — generate GIDs on the fly, import only what you need
+
+```ini
+[domain/example]
+id_provider = ldap
+auth_provider = ldap
+ldap_uri = ldaps://ldap.example
+ldap_search_base = dc=example,dc=com
+
+# groupOfNames (RFC 2307bis) schema
+ldap_schema = rfc2307bis
+ldap_group_object_class = groupOfNames
+ldap_group_member = member
+
+# Map GIDs mathematically from the LDAP UUID — no gidNumber in LDAP
+ldap_id_mapping = true
+ldap_group_uuid = entryUUID
+
+# Import ONLY the groups this host needs (e.g. a naming convention or an OU)
+ldap_group_search_filter = (&(objectClass=groupOfNames)(cn=linux-*))
+```
+
+Key ideas:
+- `ldap_id_mapping = true` + `ldap_group_uuid = entryUUID` make SSSD derive a
+  stable GID for any group it imports, so **no `gidNumber` attribute is required**
+  in LDAP.
+- `ldap_group_search_filter` is the gatekeeper: SSSD imports only groups that
+  match, discarding the other hundreds. After changing the filter, clear the
+  cache (`sss_cache -E`; `rm -f /var/lib/sss/db/*`; restart sssd) and verify with
+  `getent group <cn>`.
+
+### What filter to use — the naming convention is the answer
+
+A host should import its **own** resource groups (plus any explicitly granted
+ones). Because the schema is predictable, `ldap-client` can generate the per-host
+`ldap_group_search_filter` from the enrolled host's identity, e.g. a host `web01`
+at site `main-office` imports:
+
+```
+(&(objectClass=groupOfNames)(|(cn=main-office_host_web01_access)
+                               (cn=main-office_host_web01_admin)
+                               (cn=main-office_host_web01_sudo)))
+```
+
+So the operator (or ldap-client) selects a small allowlist of the host's `_access`
+/ `_admin` / capability groups to feed sudoers, SSH `AllowGroups`, and filesystem
+ACLs. **Only those groups are imported** — no GID bloat, no mass import.
+
+### Aliasing an LDAP group into a local group (e.g. `input`)
+
+SSSD cannot merge an LDAP group into a local group whose GID varies per host.
+Two host-side mechanisms cover it:
+
+- **pam_exec** — a script in the login stack adds the user to the local group for
+  the session:
+  ```sh
+  #!/bin/bash
+  if id -Gn "$PAM_USER" | grep -q "host_input"; then usermod -a -G input "$PAM_USER"; fi
+  ```
+  `session optional pam_exec.so /usr/local/bin/add_to_input.sh` in
+  `/etc/pam.d/common-session`.
+
+- **nss-groupmerge** — merge an LDAP group into a local group at NSS time
+  (`/etc/groupmerge.conf`: `input: host_input`, then `group: files sssd groupmerge`
+  in `/etc/nsswitch.conf`), so any service querying `input` sees the LDAP group's
+  members regardless of the local GID.
+
+### Meta groups
+
+`god_admin`, `everyone`, and `S_everyone` are NOT imported by hosts — they have
+implicit membership and are resolved by the directory only.
+
+---
+
+## 9. Downstream-app consumption guide
+
+A downstream app (Emby, Gitea, a custom service, a shell script) reads group
+membership from LDAP and interprets it as follows:
+
+1. **Discover the user's groups** — bind with the user's credentials (or use a
+   service account + `memberOf`). Groups are `groupOfNames` (member DN), so query
+   by the user's DN, e.g. `(&(objectClass=groupOfNames)(member=<user_dn>))`, or use
+   the `memberOf` reverse attribute on the user's entry.
+2. **Match each group to a scope:**
+   - `god_admin` → the user is a global administrator.
+   - `{site}_super_admin` → site administrator for that site.
+   - `{site}_hosts_*` / `{site}_app_*` (aggregate) → applies to all hosts/apps at the site.
+   - `{site}_host_<host>_*` / `{site}_app_<app>_*` → applies to that one resource.
+   - `everyone` / `{site}_everyone` → the user is implicitly a member.
+3. **Interpret the last segment:**
+   - `admin` → full control of that resource.
+   - `access` → read/use.
+   - anything else → a capability **you** define; act on it or ignore it.
+4. A user with `{site}_host_web01_access` can reach `web01`; a user with
+   `{site}_host_web01_reboot` (if you define `reboot`) may reboot it; a user with
+   `{site}_app_emby_emby_admin` administers Emby.
+
+The app must **never** treat an unknown last segment as `admin` or `access`.
+
+---
+
+## 10. Migration from the legacy `app_*` groups
+
+The current global groups (`app_sso_admin`, `app_super_admin`,
+`app_sso_directory_admin`, `app_jump_admin`) are replaced by the new model:
+
+| Legacy | New |
+| :--- | :--- |
+| `app_super_admin` | `god_admin` |
+| `app_sso_admin` | `S_app_sso_admin` (+ `S_super_admin` for site admins) |
+| `app_sso_directory_admin` | `S_app_sso_admin` |
+| `app_jump_admin` | `S_app_jump_admin` |
+
+During the transition the legacy groups may be kept as short-lived aliases that
+resolve to the same effective permission; once everything is moved, remove them.
+
+---
+
+## 11. The management consoles are apps
+
+The SSO, Proxy, and Jump-Host each register themselves as an app on their site and
+receive their auto-generated groups (`S_app_sso_admin`, `S_app_proxy_admin`,
+`S_app_jump_admin`, plus `_access`). Their admin UIs gate on
+`god_admin` · `S_super_admin` · `S_app_<console>_admin`. This keeps everything
+self-consistent: the SSO is "just another app."

docs/index.md

@@ -50,6 +50,10 @@ snapshots state before every rebuild.
 - **Proxy** — add the hosts you want to protect with OIDC login.
 - **LDAPS** for direct binds — Linux hosts (PAM/SSSD, sudo, SSH keys) and
   LDAP-native apps authenticate against the same directory.
+- **Hierarchical groups & permissions** — every adopted host and app gets its own
+  `admin`/`access`/`capability` groups, generated from the Directory; they double
+  as real POSIX groups for sudo/SSH. See
+  [Group & Permission Model](GROUPS.html).
 - **ldap-client** — enroll Linux hosts into the directory (PAM/SSSD login,
   sudo, SSH keys); the host inventory shows up in the SSO UI and drives
   jump-host routing.

docs/quickstart.md

@@ -12,8 +12,7 @@ description: Step-by-step first run for theta-suite — prerequisites, setup.env
 
 ## Prerequisites
 
-- A Linux host with **Docker** + **Docker Compose** (the v2 plugin `docker
-  compose` or the v1 standalone `docker-compose` both work).
+- A Linux host with **Docker + Docker Compose** (you must use the modern `docker compose` v2 plugin; the older `docker-compose` v1 standalone will fail on BuildKit images).
 - Two hostnames that resolve to the host: one for the SSO UI (your `stack.ssoHost`),
   one for the proxy mgmt UI (your `stack.proxyHost`). On a real network add DNS
   records; for a local try, add them to `/etc/hosts`.
@@ -141,6 +140,13 @@ then converges the stack to your `./config/` values (LDAP service account + admi
 passwords are reset to the config; the OAuth client is kept if `proxy-secrets.js`
 already holds its creds).
 
+> **Troubleshooting: "A newer version is available" after running setup.sh?**
+> If the UI shows this warning immediately after you ran `./setup.sh`, the latest
+> GitHub release tag might not yet be merged into the default tracking branch for
+> the submodules, or Docker may have cached the `COPY` step if the `package.json`
+> didn't change. You can force a clean rebuild by running
+> `docker compose build --no-cache` and then re-running `./setup.sh`.
+
 ---
 
 ## Direct LDAP for LDAP-native clients and Linux hosts

docs/secrets.md

@@ -60,23 +60,49 @@ never passed to a service container.
 
 | Policy | Capabilities | Held by |
 |---|---|---|
-| `sso-broker` | read/write `secret/sso-manager/conf`, `secret/users/*`, `secret/apps/*`, `secret/plugins/*`; `update` on `auth/token/create/sso-broker`; `update` on `sys/policies/acl/user-*`, `app-*`, `sso-admin` | SSO (`SSO_VAULT_TOKEN`) |
+| `sso-broker` | read/write `secret/sso-manager/conf`, `secret/users/*`, `secret/apps/*`, `secret/plugins/*`; `update` on `auth/token/create/sso-broker` + `create/sso-app` and `auth/token/renew-accessor`/`revoke-accessor`/`lookup-accessor`; `update` on `sys/policies/acl/user-*`, `app-*`, `sso-admin` | SSO (`SSO_VAULT_TOKEN`) |
 | `sso-admin` | read/write/list all of `secret/*` | admin UI sessions (minted by the broker) |
 | `proxy` | read `secret/proxy/conf` | proxy (`PROXY_VAULT_TOKEN`) |
 | `jump-host` | read `secret/jump-host/conf` | jump host (`JUMP_VAULT_TOKEN`) |
 | `user-<uid>` | read/write `secret/users/<uid>/*` | per-user tokens (minted lazily by the broker) |
 | `app-<name>` | read/write `secret/apps/<name>/*` | per-external-app tokens (minted by an admin) |
 
-**Token role `sso-broker`** — `allowed_policies=sso-admin`,
-`allowed_policies_glob=user-*,app-*`, orphan, renewable, `token_period=24h`.
-The SSO mints per-user, per-admin, and per-app tokens *through* this role at
-runtime, so it never needs the root token to issue scoped access.
+**Token roles** — three, all orphan + renewable:
 
-The three per-app tokens (`SSO_VAULT_TOKEN`, `PROXY_VAULT_TOKEN`,
-`JUMP_VAULT_TOKEN`) are minted orphan + renewable and stored in `./.env` by
-`setup.sh`. They use OpenBao's default service-token TTL; if one expires,
-re-run `./setup.sh` and the `ensure_token` helper re-mints it (the old one
-expires on its own). Automated renewal is a planned follow-up, not yet built.
+- `sso-broker` — `allowed_policies=sso-admin`, `allowed_policies_glob=user-*,app-*`,
+  `token_period=24h`. The SSO mints per-user and per-admin tokens *through*
+  this role at runtime, so it never needs the root token to issue scoped
+  access. The 24h period is fine here because the broker re-mints these from
+  its Redis cache transparently.
+- `sso-app` — `allowed_policies_glob=app-*`, `token_period=768h`. External-app
+  tokens minted from the vault UI's Apps tab go through this role: they are
+  long-lived credentials, so they get a monthly period instead of a daily one.
+- `theta-svc` — `allowed_policies=sso-broker,proxy,jump-host`,
+  `token_period=768h`. The services' own tokens (below).
+
+### Token lifecycle — nothing expires by surprise
+
+Periodic tokens never hit a max TTL, but they die if nothing renews them
+inside a period window. Renewal is automated at every layer:
+
+- **Service tokens** (`SSO_VAULT_TOKEN`, `PROXY_VAULT_TOKEN`,
+  `JUMP_VAULT_TOKEN`, minted via `theta-svc`, stored in `./.env`): the
+  `bao-renewer` sidecar (docker-compose) renews all three every 12 hours, and
+  every `setup.sh` re-run renews them too. A valid-but-non-periodic token from
+  an older install is detected, revoked, and re-minted as periodic on the next
+  `setup.sh` run.
+- **External-app tokens** (minted in the SSO vault UI): the SSO stores each
+  token's **accessor** (which can renew/revoke but not authenticate) and
+  renews it every 6 hours and at boot — a downstream app's credential stays
+  valid as long as the SSO is running, with no renewal code in the downstream
+  app. Re-minting an app's token revokes the previous one via its accessor, so
+  exactly one credential per app is ever live.
+- **Per-user / admin tokens**: 24h TTL by design; the broker re-mints them
+  transparently, so there is nothing to renew.
+
+Worst case (the whole stack was down for >32 days): re-run `./setup.sh` — it
+re-mints anything that lapsed; external-app tokens are re-minted from the
+Apps tab (the app's policy and stored secrets are kept).
 
 ## Seeding
 

setup.env.example

@@ -73,13 +73,6 @@ CFG_DOMAIN=example.com
 # 'sso-manager' so clients don't need a public 636 port forward. See docs.
 #CFG_LDAPS_HOST=
 
-# Optional SMTP (outbound email from the SSO app). Leave blank to disable:
-#CFG_SMTP_HOST=smtp.example.com
-#CFG_SMTP_PORT=587
-#CFG_SMTP_USER=noreply@example.com
-#CFG_SMTP_PASS=your-smtp-password
-#CFG_SMTP_FROM=SSO Manager <noreply@example.com>
-
 # ── DO NOT put secrets here ──────────────────────────────────────────────────
 # The LDAP admin password, JWT secret, admin password, LDAP service-account
 # password, and the proxy's local admin password are all GENERATED (random)
@@ -90,6 +83,20 @@ CFG_DOMAIN=example.com
 # CFG_LDAP_ADMIN_PASS / CFG_JWT_SECRET / CFG_ADMIN_PASS / CFG_SVC_PASS /
 # CFG_PROXY_ADMIN_PASS here.
 
+# ── theta-agent Host Integration ─────────────────────────────────────────────
+# Configure theta-agent integration with the local host. All options default to
+# enabled (1). Set to 0 to disable.
+#
+# Enable theta-agent installation and configuration on this host.
+#CFG_THETA_AGENT_ENABLE=1
+#
+# Configure LDAP authentication for this host via ldap-client (SSSD/PAM).
+#CFG_THETA_AGENT_LDAP_AUTH=1
+#
+# Allow theta-agent full control of this host (arbitrary_bash, service_control,
+# reboot, configure_ldap capabilities).
+#CFG_THETA_AGENT_FULL_CONTROL=1
+
 # ── Geo-Location Scaling (N-Way Multi-Master LDAP) ───────────────────────────
 # If deploying this stack across multiple physical sites to provide local HA
 # for directory services, you can enable N-Way Multi-Master OpenLDAP replication.
@@ -100,4 +107,10 @@ CFG_DOMAIN=example.com
 # LDAP_REPLICATION_HOSTS is a space-separated list of the other sites' LDAP URLs.
 # Example for Site 1:
 #LDAP_SERVER_ID=1
-#LDAP_REPLICATION_HOSTS="ldaps://sso.site2.com:636 ldaps://sso.site3.com:636"
+#LDAP_REPLICATION_HOSTS="ldaps://sso.site2.com:636 ldaps://sso.site3.com:636"
+# ── Proxy HTTP/HTTPS Defaults ────────────────────────────────────────────────
+# If you are running the stack behind an external reverse proxy (like Cloudflare
+# or another ingress) that handles TLS termination, you may want the internal
+# proxy to serve everything over plain HTTP without forcing redirects to HTTPS.
+# Set this to 1 to create all default proxy host entries with forcessl=false.
+#CFG_CREATE_ALL_HTTP=1

setup.sh

@@ -61,6 +61,7 @@ set -euo pipefail
 
 cd "$(dirname "$0")"
 
+CFG_ADMIN_PASS="${CFG_ADMIN_PASS:-}"
 CONFIG_DIR=./config
 BACKUP_DIR=./backups
 BACKUP_KEEP="${BACKUP_KEEP:-5}"
@@ -71,6 +72,19 @@ warn()  { printf '\033[1;33m[setup]\033[0m %s\n' "$*" >&2; }
 error() { printf '\033[1;31m[setup]\033[0m %s\n' "$*" >&2; }
 die()   { error "$*"; exit 1; }
 
+# ── Flags ──────────────────────────────────────────────────────────────────────
+# --reset-openbao: wipe the OpenBao volume + bao-init.json and re-initialize a
+# fresh store (no prod data to preserve). Use when OpenBao state is suspect
+# (stale policies/tokens causing vault 403s). The Redis vault-token cache is
+# flushed once sso-manager is back up (see the OpenBao bootstrap section).
+RESET_OPENBAO=0
+for arg in "$@"; do
+	case "$arg" in
+		--reset-openbao) RESET_OPENBAO=1 ;;
+		*) warn "unknown argument: $arg (ignored)" ;;
+	esac
+done
+
 # Escape a value for a single-quoted JS string: \ -> \\, ' -> \', then wrap in '...'.
 js_str() {
 	local s="$1"
@@ -105,6 +119,13 @@ env_upsert() {
 	fi
 }
 
+# Read KEY= from ./.env (empty if absent)
+env_get() {
+	local key="$1" file=./.env
+	[[ -f "$file" ]] || return 0
+	grep -m1 "^${key}=" "$file" 2>/dev/null | cut -d= -f2- || true
+}
+
 # Detect docker compose (v2 plugin `docker compose` or v1 standalone `docker-compose`).
 if docker compose version >/dev/null 2>&1; then
 	COMPOSE=(docker compose)
@@ -177,6 +198,8 @@ fi
 # resolved in ensure_config; this is only the hostname override.
 [[ -f ./setup.env ]] && parse_kv_file ./setup.env
 export CFG_JUMP_HOST
+CFG_CREATE_ALL_HTTP="${CFG_CREATE_ALL_HTTP:-0}"
+export CFG_CREATE_ALL_HTTP
 
 # ── Optional outbound HTTP(S) proxy for docker build + the running containers ─
 # CFG_HTTP_PROXY / CFG_HTTPS_PROXY / CFG_NO_PROXY (from ./setup.env or the
@@ -442,6 +465,7 @@ BAOEOF
 	CFG_ADMIN_PASS="${CFG_ADMIN_PASS:-}"
 	CFG_SVC_PASS="${CFG_SVC_PASS:-}"
 	CFG_PROXY_ADMIN_PASS="${CFG_PROXY_ADMIN_PASS:-}"
+	CFG_CREATE_ALL_HTTP="${CFG_CREATE_ALL_HTTP:-0}"
 
 	# ── One-time migration from .env / proxy.env (existing deployments) ──
 	# Preserve the operator's existing secrets so the running deployment keeps
@@ -617,7 +641,7 @@ backup_before_rebuild() {
 		docker exec "$svc" redis-cli BGSAVE >/dev/null 2>&1 || true
 		ok=0
 		for i in $(seq 1 10); do
-			if [[ "$(docker exec "$svc" redis-cli LASTSAVE 2>/dev/null | tr -dc '0-9')" -gt "$before" ]]; then
+			if [[ "$(docker exec "$svc" redis-cli LASTSAVE 2>/dev/null | tr -dc '0-9' || echo 0)" -gt "$before" ]]; then
 				ok=1; break
 			fi
 			sleep 1
@@ -629,8 +653,8 @@ backup_before_rebuild() {
 		fi
 		# Redis writes dump.rdb to `dir`/`dbfilename`; ask it where that is so the
 		# copy works across the unified (/data) and standalone (/app) layouts.
-		rdir="$(docker exec "$svc" redis-cli CONFIG GET dir 2>/dev/null | sed -n '2p' | tr -d '\r\n')"
-		rfile="$(docker exec "$svc" redis-cli CONFIG GET dbfilename 2>/dev/null | sed -n '2p' | tr -d '\r\n')"
+		rdir="$(docker exec "$svc" redis-cli CONFIG GET dir 2>/dev/null | sed -n '2p' | tr -d '\r\n' || true)"
+		rfile="$(docker exec "$svc" redis-cli CONFIG GET dbfilename 2>/dev/null | sed -n '2p' | tr -d '\r\n' || true)"
 		rpath="${rdir:+$rdir/}${rfile:-dump.rdb}"
 		if [[ "$ok" == "1" ]] && docker cp "$svc:$rpath" "$dir/$svc.rdb" >/dev/null 2>&1; then
 			info "  Redis ($svc) -> $svc.rdb"
@@ -660,6 +684,20 @@ backup_before_rebuild() {
 backup_before_rebuild
 
 # ── 3b. Setup OpenBao (Vault) ────────────────────────────────────────────────
+# Full reset (--reset-openbao): stop/remove openbao, drop the data volume, and
+# delete the init/keys file (incl. any backup copy that setup.sh would otherwise
+# restore). The normal bootstrap below then initializes a brand-new store, so no
+# stale policy content or token survives.
+if [[ "$RESET_OPENBAO" == "1" ]]; then
+	info "── Full OpenBao reset requested (--reset-openbao) ──"
+	"${COMPOSE[@]}" stop openbao >/dev/null 2>&1 || true
+	"${COMPOSE[@]}" rm -f openbao >/dev/null 2>&1 || true
+	docker volume ls -q 2>/dev/null | grep '^openbao' | xargs -r docker volume rm >/dev/null 2>&1 || true
+	rm -f "$CONFIG_DIR/bao-init.json"
+	rm -f ./backups/bao-init.json ./backups/*/bao-init.json 2>/dev/null || true
+	info "  openbao volume + bao-init.json cleared; will re-initialize fresh."
+fi
+
 info "Starting openbao..."
 "${COMPOSE[@]}" run --rm --user root openbao chown -R 100:1000 /vault/data
 "${COMPOSE[@]}" up -d openbao
@@ -672,7 +710,17 @@ for i in $(seq 1 30); do
 	sleep 2
 done
 
-if ! docker exec openbao bao status -format=json 2>/dev/null | grep -q '"initialized": true' || true; then
+# If config/bao-init.json is missing, search backups for a saved copy
+if [[ ! -f "$CONFIG_DIR/bao-init.json" ]]; then
+    latest_backup_init=$(find ./backups -name "bao-init.json" 2>/dev/null | sort -r | head -n1 || true)
+    if [[ -n "$latest_backup_init" && -f "$latest_backup_init" ]]; then
+        info "Restoring $CONFIG_DIR/bao-init.json from backup ($latest_backup_init)..."
+        cp "$latest_backup_init" "$CONFIG_DIR/bao-init.json"
+        chmod 600 "$CONFIG_DIR/bao-init.json"
+    fi
+fi
+
+if ! docker exec openbao bao status -format=json 2>/dev/null | grep -q '"initialized": true'; then
     status_json=$(docker exec openbao bao status -format=json 2>/dev/null || true)
     if ! echo "$status_json" | grep -q '"initialized": true'; then
         info "Initializing openbao for the first time..."
@@ -684,13 +732,54 @@ fi
 
 status_json=$(docker exec openbao bao status -format=json 2>/dev/null || true)
 if echo "$status_json" | grep -q '"sealed": true'; then
-	info "Unsealing openbao..."
-	UNSEAL_KEY=$(grep -A1 '"unseal_keys_b64":' "$CONFIG_DIR/bao-init.json" | tail -n1 | cut -d'"' -f2)
-	docker exec openbao bao operator unseal "$UNSEAL_KEY" >/dev/null
+	UNSEAL_KEY=""
+	if [[ -f "$CONFIG_DIR/bao-init.json" ]]; then
+		UNSEAL_KEY=$(grep -A1 '"unseal_keys_b64":' "$CONFIG_DIR/bao-init.json" 2>/dev/null | tail -n1 | cut -d'"' -f2 || true)
+	fi
+	if [[ -z "$UNSEAL_KEY" ]]; then
+		UNSEAL_KEY="$(env_get VAULT_UNSEAL_KEY)"
+	fi
+
+	if [[ -n "$UNSEAL_KEY" ]]; then
+		info "Unsealing openbao..."
+		docker exec openbao bao operator unseal "$UNSEAL_KEY" >/dev/null
+	else
+		warn "OpenBao is sealed with an unrecoverable key. Resetting OpenBao volume and re-initializing..."
+		"${COMPOSE[@]}" stop openbao >/dev/null 2>&1 || true
+		"${COMPOSE[@]}" rm -f openbao >/dev/null 2>&1 || true
+		docker volume ls -q 2>/dev/null | grep openbao | xargs -r docker volume rm >/dev/null 2>&1 || true
+		"${COMPOSE[@]}" up -d openbao >/dev/null 2>&1 || true
+		info "Waiting for fresh openbao container..."
+		for i in $(seq 1 30); do
+			if docker exec openbao bao status >/dev/null 2>&1 || [[ $? -eq 2 ]]; then break; fi
+			sleep 2
+		done
+		info "Initializing fresh openbao..."
+		docker exec openbao bao operator init -key-shares=1 -key-threshold=1 -format=json > "$CONFIG_DIR/bao-init.json"
+		chmod 600 "$CONFIG_DIR/bao-init.json"
+		UNSEAL_KEY=$(grep -A1 '"unseal_keys_b64":' "$CONFIG_DIR/bao-init.json" | tail -n1 | cut -d'"' -f2)
+		info "Unsealing fresh openbao..."
+		docker exec openbao bao operator unseal "$UNSEAL_KEY" >/dev/null
+	fi
 fi
 
 export VAULT_TOKEN
-VAULT_TOKEN=$(grep '"root_token":' "$CONFIG_DIR/bao-init.json" | cut -d'"' -f4)
+if [[ -f "$CONFIG_DIR/bao-init.json" ]]; then
+	VAULT_TOKEN=$(grep '"root_token":' "$CONFIG_DIR/bao-init.json" 2>/dev/null | cut -d'"' -f4 || true)
+fi
+if [[ -z "$VAULT_TOKEN" ]]; then
+	VAULT_TOKEN="$(env_get VAULT_TOKEN)"
+fi
+
+if [[ -z "$VAULT_TOKEN" ]]; then
+	die "Could not determine OpenBao VAULT_TOKEN from $CONFIG_DIR/bao-init.json or .env."
+fi
+
+# UNSEAL_KEY is only set when OpenBao needed unsealing this run; on a re-run of
+# an already-unsealed store it is unset, so guard with ${UNSEAL_KEY:-} (set -u).
+if [[ -n "${UNSEAL_KEY:-}" ]]; then
+	env_upsert VAULT_UNSEAL_KEY "$UNSEAL_KEY"
+fi
 env_upsert VAULT_TOKEN "$VAULT_TOKEN"
 
 if ! docker exec -e BAO_TOKEN="$VAULT_TOKEN" openbao bao secrets list -format=json 2>/dev/null | grep -q '"secret/":'; then
@@ -720,33 +809,35 @@ ensure_policy() {
 	docker exec -i -e BAO_TOKEN="$VAULT_TOKEN" openbao bao policy write "$name" - >/dev/null
 }
 
-# Read KEY= from ./.env (empty if absent) — reuse a previously minted token
-# instead of minting a fresh one on every setup.sh run.
-env_get() {
-	local key="$1" file=./.env
-	[[ -f "$file" ]] || return 0
-	# `|| true` is load-bearing: under `set -euo pipefail`, a no-match `grep`
-	# exits 1 and (pipefail) makes the whole pipeline return 1. Callers do
-	# `existing="$(env_get ...)"` as a bare assignment — a non-zero return there
-	# trips `set -e` and silently kills the whole script (this is exactly what
-	# aborted a fresh install right after "Minting per-app OpenBao tokens": the
-	# root VAULT_TOKEN env_upsert had already created .env, but the app-token
-	# keys were absent, so the first env_get returned 1). "Key absent" is the
-	# normal path here, so always return 0 with empty output.
-	grep -m1 "^${key}=" "$file" 2>/dev/null | cut -d= -f2- || true
-}
 
-# Mint an orphan, renewable token for `policy` and persist it to .env as `key`,
-# OR reuse the token already in .env if it is still valid (re-mint on expiry).
+# Mint a PERIODIC service token (theta-svc role: orphan, renewable, 768h
+# period) for `policy` and persist it to .env as `key`. Periodic tokens have no
+# max-TTL death date — each renewal resets the clock — unlike the plain orphan
+# tokens minted before this (creation_ttl 768h, dead ~32 days after mint no
+# matter what). The bao-renewer sidecar renews them every 12h while the stack
+# runs, and every setup.sh re-run renews here too. A valid-but-non-periodic
+# token from an older setup.sh is revoked and re-minted as periodic.
 ensure_token() {
-	local key="$1" policy="$2" existing tok
+	local key="$1" policy="$2" existing tok lookup
 	existing="$(env_get "$key")"
-	if [[ -n "$existing" ]] && docker exec -e BAO_TOKEN="$existing" openbao bao token lookup >/dev/null 2>&1; then
-		info "  ${key} already minted + valid — keeping."
-		return 0
+	if [[ -n "$existing" ]]; then
+		lookup="$(docker exec -e BAO_TOKEN="$existing" openbao bao token lookup -format=json 2>/dev/null || true)"
+		if [[ -n "$lookup" ]]; then
+			# Periodic = minted through the theta-svc role. (OpenBao token lookup
+			# does not expose a `period` field — the role is the reliable marker;
+			# renewal behavior confirms the 768h period resets past the original
+			# creation TTL.)
+			if echo "$lookup" | grep -q '"role": *"theta-svc"'; then
+				info "  ${key} already minted + periodic (theta-svc) — renewing to reset its clock."
+				docker exec -e BAO_TOKEN="$existing" openbao bao token renew >/dev/null 2>&1 || true
+				return 0
+			fi
+			info "  ${key} is valid but NOT periodic (pre-theta-svc mint; dies at its max TTL) — revoking + re-minting."
+			bao_run token revoke "$existing" >/dev/null 2>&1 || true
+		fi
 	fi
-	info "  minting ${key} (policy=${policy})..."
-	tok="$(bao_run token create -policy="$policy" -orphan=true -field=token)" \
+	info "  minting ${key} (policy=${policy}, role=theta-svc, periodic 768h)..."
+	tok="$(bao_run token create -role=theta-svc -policy="$policy" -field=token)" \
 		|| die "failed to mint ${key} (policy=${policy})"
 	env_upsert "$key" "$tok"
 }
@@ -784,6 +875,10 @@ path "secret/metadata/apps/*" { capabilities = ["list", "read", "delete"] }
 path "secret/data/plugins/*" { capabilities = ["create", "read", "update", "delete", "list"] }
 path "secret/metadata/plugins/*" { capabilities = ["list", "read", "delete"] }
 path "auth/token/create/sso-broker" { capabilities = ["update"] }
+path "auth/token/create/sso-app" { capabilities = ["update"] }
+path "auth/token/renew-accessor" { capabilities = ["update"] }
+path "auth/token/revoke-accessor" { capabilities = ["update"] }
+path "auth/token/lookup-accessor" { capabilities = ["update"] }
 path "sys/policies/acl/user-*" { capabilities = ["create", "read", "update", "delete", "list"] }
 path "sys/policies/acl/app-*" { capabilities = ["create", "read", "update", "delete", "list"] }
 path "sys/policies/acl/sso-admin" { capabilities = ["create", "read", "update", "delete", "list"] }
@@ -795,6 +890,7 @@ HCL
 ensure_policy sso-admin <<'HCL'
 path "secret/data/*" { capabilities = ["create", "read", "update", "delete", "list"] }
 path "secret/metadata" { capabilities = ["list", "read", "delete"] }
+path "secret/metadata/" { capabilities = ["list", "read", "delete"] }
 path "secret/metadata/*" { capabilities = ["list", "read", "delete"] }
 HCL
 # proxy / jump-host — read only their own boot conf.
@@ -821,15 +917,48 @@ else
 	info "  token role sso-broker already exists — keeping."
 fi
 
+# sso-app token role: external-app tokens minted from the sso vault UI. Periodic
+# 768h (NOT the broker's 24h) — an app token is a long-lived credential; with a
+# 24h period any downstream app that didn't renew daily silently died. A 768h
+# period keeps it alive as long as the app renews (or is re-minted) at least
+# monthly: `bao token renew-self` / POST /v1/auth/token/renew-self.
+info "Configuring sso-app token role..."
+if ! bao_run read auth/token/roles/sso-app >/dev/null 2>&1; then
+	docker exec -i -e BAO_TOKEN="$VAULT_TOKEN" openbao bao write auth/token/roles/sso-app - <<'JSON' >/dev/null
+{"allowed_policies_glob":["app-*"],"orphan":true,"renewable":true,"token_period":"768h"}
+JSON
+else
+	info "  token role sso-app already exists — keeping."
+fi
+
+# theta-svc token role: the services' own tokens (SSO/PROXY/JUMP_VAULT_TOKEN).
+# Periodic 768h so they can be renewed forever (the bao-renewer sidecar renews
+# every 12h; each setup.sh re-run renews too). allowed_policies is exact-match:
+# exactly the three service policies, nothing else.
+info "Configuring theta-svc token role..."
+if ! bao_run read auth/token/roles/theta-svc >/dev/null 2>&1; then
+	docker exec -i -e BAO_TOKEN="$VAULT_TOKEN" openbao bao write auth/token/roles/theta-svc - <<'JSON' >/dev/null
+{"allowed_policies":["sso-broker","proxy","jump-host"],"orphan":true,"renewable":true,"token_period":"768h"}
+JSON
+else
+	info "  token role theta-svc already exists — keeping."
+fi
+
 info "Minting per-app OpenBao tokens (stored in .env, passed to containers as VAULT_TOKEN)..."
 ensure_token SSO_VAULT_TOKEN sso-broker
 ensure_token PROXY_VAULT_TOKEN proxy
 ensure_token JUMP_VAULT_TOKEN jump-host
 
 info "OpenBao secrets configured:"
-info "  policies:   sso-broker, sso-admin, proxy, jump-host (+ per-user/app created lazily by sso)"
-info "  token role: sso-broker (mints user-*/app-*/sso-admin tokens, 24h period)"
-info "  app tokens: SSO_VAULT_TOKEN, PROXY_VAULT_TOKEN, JUMP_VAULT_TOKEN in .env"
+info "  policies:    sso-broker, sso-admin, proxy, jump-host (+ per-user/app created lazily by sso)"
+info "  token roles: sso-broker (user-*/app-*/sso-admin, 24h period), sso-app (app-*, 768h period), theta-svc (service tokens, 768h period)"
+info "  app tokens:  SSO_VAULT_TOKEN, PROXY_VAULT_TOKEN, JUMP_VAULT_TOKEN in .env (periodic; renewed by bao-renewer)"
+
+# bao-renewer: renews the three periodic service tokens every 12h so they never
+# hit their period boundary while the stack is running. Recreated (not just
+# started) so it always picks up freshly re-minted tokens from .env.
+info "Starting bao-renewer (service-token renewal sidecar)..."
+"${COMPOSE[@]}" up -d --force-recreate bao-renewer
 
 # ── 4. Start SSO Manager, wait for health ─────────────────────────────────────
 # SSO_GIT_COMMIT: sso-manager-node is a git submodule here, so its .git is a
@@ -855,6 +984,18 @@ for i in $(seq 1 60); do
 	sleep 2
 done
 
+# After a full OpenBao reset, the Redis-cached per-user/admin vault tokens (in
+# the persisted sso-data volume) reference the old, now-wiped store — drop them
+# so the broker re-mints fresh tokens against the new instance. Belt-and-
+# suspenders: the broker also always reconciles policy content before serving a
+# token, but a token minted by the previous OpenBao instance is simply invalid
+# there, so a cache flush is required after a reset.
+if [[ "$RESET_OPENBAO" == "1" ]]; then
+	info "  clearing cached vault tokens (old OpenBao instance)..."
+	docker exec sso-manager sh -c "redis-cli EVAL \"for _,k in ipairs(redis.call('keys','vault_token:*')) do redis.call('del',k) end\" 0" \
+		>/dev/null 2>&1 || warn "  could not flush Redis vault-token cache (will re-mint on next access)"
+fi
+
 info "Seeding app configs into OpenBao (idempotent)..."
 # sso-manager/conf holds the operator-set LDAP/SMTP/jwtSecret values — sso has
 # no bootstrap-generated creds, so the file is the complete source of truth.
@@ -975,7 +1116,7 @@ async function ensureHost(host, ip, targetPort) {
 			host: host,
 			ip: ip,
 			targetPort: targetPort,
-			forcessl: true,
+			forcessl: $( [[ "${CFG_CREATE_ALL_HTTP:-0}" == "1" ]] && echo false || echo true ),
 			targetssl: false,
 			sso_enabled: false,
 			created_by: 'setup.sh',
@@ -1032,7 +1173,7 @@ const {Host} = require('/app/models').models;
 		try { await Host.get($(js_str "$JUMP_HOST")); console.log('SKIP ${JUMP_HOST} (already exists)'); }
 		catch (e) {
 			if (e.name !== 'EntryNotFound') throw e;
-			await Host.create({ host: $(js_str "$JUMP_HOST"), ip: 'jump-host', targetPort: 3002, forcessl: true, targetssl: false, sso_enabled: false, created_by: 'setup.sh' });
+			await Host.create({ host: $(js_str "$JUMP_HOST"), ip: 'jump-host', targetPort: 3002, forcessl: $( [[ "${CFG_CREATE_ALL_HTTP:-0}" == "1" ]] && echo false || echo true ), targetssl: false, sso_enabled: false, created_by: 'setup.sh' });
 			console.log('CREATED ${JUMP_HOST} -> jump-host:3002');
 		}
 		process.exit(0);
@@ -1042,9 +1183,139 @@ NODEEOF
 )
 echo "$JUMP_HOSTS_OUT" | sed 's/^/[setup] /'
 
+# ── 7c. Install theta-agent on the host ──────────────────────────────────────
+# Controlled by CFG_THETA_AGENT_ENABLE (default: 1 = enabled)
+CFG_THETA_AGENT_ENABLE="${CFG_THETA_AGENT_ENABLE:-1}"
+if [[ "$CFG_THETA_AGENT_ENABLE" == "1" ]]; then
+	info "Setting up theta-agent on the host..."
+	(
+		cd theta-agent || exit 0
+		# Install the prebuilt binary that ships in the theta-agent submodule (the
+		# repo's own install.sh uses the same release binary). We do NOT build from
+		# source here: a previous `go build -o theta-agent main.go websocket.go
+		# config.go` omitted executor.go/telemetry.go, failed to compile, and was
+		# silently skipped, so the agent was never installed.
+		if [[ ! -f "theta-agent-linux-amd64" ]]; then
+			warn "Prebuilt theta-agent-linux-amd64 missing from the theta-agent submodule. Skipping theta-agent installation."
+		else
+			info "  Installing prebuilt theta-agent binary..."
+			if [[ -x "theta-agent-linux-amd64" ]]; then
+				# The agent binary reads /etc/theta42/agent.yml (theta-agent/main.go).
+				sudo mkdir -p /etc/theta42
+				if [[ ! -f /etc/theta42/agent.yml ]]; then
+					sudo cp agent.yml.example /etc/theta42/agent.yml
+					AGENT_TOKEN="$(rand_hex 16)"
+					sudo sed -i "s/REPLACE_WITH_AGENT_TOKEN/$AGENT_TOKEN/" /etc/theta42/agent.yml
+					# We want to connect to either https or http depending on CFG_CREATE_ALL_HTTP
+					if [[ "${CFG_CREATE_ALL_HTTP:-0}" == "1" ]]; then
+						sudo sed -i "s|https://sso.example.com|http://${SSO_HOST}|" /etc/theta42/agent.yml
+					else
+						sudo sed -i "s|https://sso.example.com|https://${SSO_HOST}|" /etc/theta42/agent.yml
+					fi
+				fi
+				# Stop a running agent before overwriting its binary (cp into a
+				# running executable fails with "Text file busy" on a re-install).
+				sudo systemctl stop theta-agent.service 2>/dev/null || true
+				sudo cp theta-agent-linux-amd64 /usr/local/bin/theta-agent
+				sudo chmod +x /usr/local/bin/theta-agent
+
+				sudo bash -c "cat <<'EOF' > /etc/systemd/system/theta-agent.service
+[Unit]
+Description=Theta Agent
+After=network.target
+
+[Service]
+Type=simple
+ExecStart=/usr/local/bin/theta-agent
+Restart=on-failure
+RestartSec=5
+
+[Install]
+WantedBy=multi-user.target
+EOF"
+				sudo systemctl daemon-reload
+				sudo systemctl enable --now theta-agent.service
+				info "  theta-agent installed and started."
+			fi
+		fi
+	)
+else
+	info "theta-agent installation skipped (CFG_THETA_AGENT_ENABLE=0)."
+fi
+# ── 7d. Configure theta-agent integration with this host ─────────────────────
+# Non-interactive configuration driven by setup.env variables:
+#   CFG_THETA_AGENT_ENABLE (default: 1) - Install/configure theta-agent
+#   CFG_THETA_AGENT_LDAP_AUTH (default: 1) - Configure LDAP authentication via ldap-client
+#   CFG_THETA_AGENT_FULL_CONTROL (default: 1) - Enable all agent capabilities
+# Only runs if theta-agent was installed (section 7c) or already exists.
+if [[ "$CFG_THETA_AGENT_ENABLE" == "1" ]] && [[ -x /usr/local/bin/theta-agent ]]; then
+	info "Configuring theta-agent integration with this host..."
+
+	# Default to enabled unless explicitly disabled
+	CFG_THETA_AGENT_LDAP_AUTH="${CFG_THETA_AGENT_LDAP_AUTH:-1}"
+	CFG_THETA_AGENT_FULL_CONTROL="${CFG_THETA_AGENT_FULL_CONTROL:-1}"
+
+	if [[ "$CFG_THETA_AGENT_LDAP_AUTH" == "1" ]]; then
+		info "  Configuring LDAP authentication for this host..."
+
+		# ldap-client/index.sh refuses to run without ./ldap.vars, which is
+		# gitignored and never shipped in the checkout (it holds a real bind
+		# password). On the agent-enrollment path we generate it from the stack's
+		# own config so the host can actually enroll; an operator-provided
+		# ldap.vars (cp ldap.vars.template ldap.vars + edit) is always kept.
+		if [[ ! -f ldap-client/ldap.vars ]]; then
+			info "  Generating ldap-client/ldap.vars from the stack config..."
+			cat > ldap-client/ldap.vars <<LDAPVARS
+export ldap_host="${CFG_LDAPS_HOST:-sso.${CFG_DOMAIN}}"
+export ldap_base_dn="${CFG_BASE_DN}"
+export ldap_bind_dn="cn=ldapclient,ou=people,${CFG_BASE_DN}"
+export ldap_bind_password="${CFG_SVC_PASS}"
+export sso_url="https://${CFG_SSO_HOST}"
+export sso_token=""
+export ldap_location="${CFG_SITE_NAME:-local}"
+ldap_access_groups=( "\${ldap_location}_access" "\${ldap_location}_host_\$(hostname)_access" "app_super_admin" )
+LDAPVARS
+		else
+			info "  ldap-client/ldap.vars exists -- keeping it"
+		fi
+
+		(
+			cd ldap-client || exit 0
+			if [[ -x "index.sh" ]]; then
+				bash index.sh --non-interactive 2>/dev/null || warn "  ldap-client enrollment failed (continuing)..."
+			fi
+		)
+	else
+		info "  LDAP authentication configuration skipped (CFG_THETA_AGENT_LDAP_AUTH=0)."
+	fi
+
+	if [[ "$CFG_THETA_AGENT_FULL_CONTROL" == "1" ]]; then
+		info "  Configuring theta-agent with full host control capabilities..."
+		if [[ -f /etc/theta42/agent.yml ]]; then
+			sudo sed -i 's/arbitrary_bash: false/arbitrary_bash: true/' /etc/theta42/agent.yml
+			# service_control is a []string allowlist (NOT a bool) — setting it to
+			# `true` makes the agent fail YAML decode and crash-loop. There is no
+			# wildcard; leave the operator's list (or the [] default = deny all)
+			# alone and document how to enable specific services.
+			# sudo sed -i 's/service_control: .*/service_control: true/' ...
+			sudo sed -i 's/reboot: false/reboot: true/' /etc/theta42/agent.yml
+			sudo sed -i 's/configure_ldap: false/configure_ldap: true/' /etc/theta42/agent.yml
+			info "    (service_control left as its allowlist; set e.g. service_control: [\"nginx\"] in /etc/theta42/agent.yml to permit managing specific services)"
+			info "  theta-agent full control enabled. Restarting service..."
+			sudo systemctl restart theta-agent.service
+		else
+			warn "  /etc/theta42/agent.yml not found. Full control not configured."
+		fi
+	else
+		info "  theta-agent running with limited capabilities (CFG_THETA_AGENT_FULL_CONTROL=0)."
+	fi
+else
+	info "  theta-agent configuration skipped (agent not installed or CFG_THETA_AGENT_ENABLE=0)."
+fi
+
 # ── 8. Summary ───────────────────────────────────────────────────────────────
 echo
-info "\033[1;32mDone. Your SSO + proxy stack is up.\033[0m"
+printf '\033[1;34m[setup]\033[0m \033[1;32mDone. Your SSO + proxy stack is up.\033[0m\n'
 echo
 echo "  SSO Manager UI:    https://${SSO_HOST}   (fronted by the proxy under TLS)"
 echo "                      first-run fallback: http://127.0.0.1:${SSO_PORT:-3001}"
@@ -1056,7 +1327,7 @@ echo "  Jump host (web):    https://${JUMP_HOST:-jump.${SSO_HOST#sso.}}   (audit
 echo
 echo "  First admin login credentials are in ./config/sso-secrets.js:"
 echo "    user: ${ADMIN_UID}"
-echo "    pass: ${CFG_ADMIN_PASS}"
+echo "    pass: ${CFG_ADMIN_PASS:-<see ./config/sso-secrets.js>}"
 echo
 echo "  Proxy local admin (anti-lockout fallback if the SSO is unreachable):"
 echo "    user: proxyadmin2"