Compare commits

..

39 Commits

Author SHA1 Message Date
wmantly 73e1cc807a fix: setup.sh ldap.vars re-run abort + drop app_super_admin; roll up sso v1.26.1 (v1.36.1) (#162)
CI/CD / build-theta-agent (push) Successful in 45s
CI/CD / docker-push (push) Failing after 19s
- setup.sh: ldap.vars generation read CFG_* first-run vars (unset on re-run);
  now reads real values from sso-secrets.js, so LDAP enrollment works on re-runs
- generated ldap_access_groups now references god_admin (app_super_admin gone)
- gitlink: sso-manager-node 8db00f0 (v1.26.1)
2026-08-04 19:33:32 -04:00
wmantly a77aa8d2df 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)
CI/CD / build-theta-agent (push) Successful in 44s
CI/CD / docker-push (push) Failing after 16s
- 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)
2026-08-04 19:10:32 -04:00
wmantly 0e78a9e282 Merge pull request #160 from theta42/release/v1.35.18
CI/CD / build-theta-agent (push) Successful in 41s
CI/CD / docker-push (push) Failing after 19s
chore: sync proxy/jump gitlinks (v1.35.18)
2026-08-04 16:54:41 -04:00
wmantly 59c5c66007 chore: sync proxy/jump gitlinks to version-tagged commits (v1.35.18)
proxy v1.33.0 + jump v1.18.0 had package.json synced to their tags; update the
gitlinks so a deploy reports matching versions.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-04 16:53:38 -04:00
wmantly ec426680c3 Merge pull request #159 from theta42/release/v1.35.17
CI/CD / docker-push (push) Failing after 17s
CI/CD / build-theta-agent (push) Successful in 47s
docs: group & permission model + sso group model (v1.35.17)
2026-08-04 16:49:11 -04:00
wmantly 6fae96d977 chore: bump sso-manager-node gitlink to v1.25.0
sso v1.25.0 shipped the group & permission model + the v1.24.0 batch (Agents →
Directory, plugin modal rework, Vault restyle). Update the gitlink for the release.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-04 16:48:16 -04:00
wmantly 292b67c334 docs: group & permission model spec + link (v1.35.17)
Add docs/GROUPS.md — the canonical Group & Permission Model (schema, inheritance
resolver, Directory-only management, multi-site, host-side SSSD mapping, migration)
— link it from the docs index, and note sso v1.25.0 in the changelog.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-04 15:04:30 -04:00
wmantly 72606bfc13 feat: seed theta-proxy + theta-jump as managed host resources (v1.35.16)
The bootstrap now creates theta-proxy and theta-jump as managed host-kind
resources in the Directory (matching the OAuth client identities), alongside
the existing stack host and its service entries, so a fresh install shows them
as first-class hosts.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-04 13:27:28 -04:00
wmantly c28e53e505 Merge pull request #158 from theta42/fix/theta-agent-text-file-busy-v1.35.15
CI/CD / build-theta-agent (push) Successful in 43s
CI/CD / docker-push (push) Failing after 17s
fix: stop theta-agent before overwriting binary (v1.35.15)
2026-08-04 00:34:43 -04:00
wmantly 7ae2472c62 fix: stop theta-agent before overwriting binary (v1.35.15)
cp into a running executable fails with 'Text file busy' on a re-install.
Stop the service before copying the prebuilt binary.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-04 00:32:33 -04:00
wmantly 0c4abd82be Merge pull request #157 from theta42/release/v1.35.14-token-lifecycle
CI/CD / build-theta-agent (push) Successful in 43s
CI/CD / docker-push (push) Failing after 17s
feat: OpenBao token lifecycle + bump sso to v1.23.0 (v1.35.14)
2026-08-04 00:25:16 -04:00
wmantly c27e8c7867 feat: OpenBao token lifecycle + bump sso to v1.23.0 (v1.35.14)
- theta-svc token role (periodic 768h): SSO/PROXY/JUMP_VAULT_TOKEN now minted
  through it; ensure_token renews periodic tokens on every setup.sh re-run and
  detects/revokes/re-mints valid-but-non-periodic tokens from older installs.
- bao-renewer sidecar (docker-compose): renews the three service tokens every
  12h while the stack runs.
- sso-app token role (periodic 768h) + sso-broker policy grants for
  auth/token/create/sso-app and renew/revoke/lookup-accessor.
- docs/secrets.md rewritten around the new lifecycle.
- Bump sso-manager-node gitlink to v1.23.0 (real vault-403 fix + app-token
  lifecycle).

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-04 00:21:51 -04:00
wmantly 9750413178 Merge pull request #156 from theta42/release/v1.35.13-agents-page
CI/CD / build-theta-agent (push) Successful in 44s
CI/CD / docker-push (push) Failing after 18s
feat: bump sso to v1.22.0 (Agents page + secure /api/agent) (v1.35.13)
2026-08-03 23:16:39 -04:00
wmantly c1a9d8f059 feat: bump sso to v1.22.0 (Agents page + secure /api/agent) (v1.35.13) 2026-08-03 23:15:19 -04:00
wmantly 0edce57f80 Merge pull request #155 from theta42/fix/theta-agent-service-control-v1.35.12
CI/CD / build-theta-agent (push) Successful in 41s
CI/CD / docker-push (push) Failing after 18s
fix: stop writing invalid service_control:true for theta-agent (v1.35.12)
2026-08-03 23:06:39 -04:00
wmantly 49b868fedb fix: stop writing invalid service_control:true for theta-agent (v1.35.12)
setup.sh's 'full control' edit set service_control: true, but that field is a
[]string allowlist, so theta-agent failed YAML decode and crash-looped. Remove
the invalid edit; leave the operator's allowlist (or [] default = deny all).

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-03 23:05:04 -04:00
wmantly f9af81983b Merge pull request #154 from theta42/fix/unseal-key-unbound-v1.35.11
CI/CD / build-theta-agent (push) Successful in 45s
CI/CD / docker-push (push) Failing after 16s
fix: UNSEAL_KEY unbound variable in setup.sh (v1.35.11)
2026-08-03 22:45:27 -04:00
wmantly 5ef2493e17 chore: changelog for v1.35.11 2026-08-03 22:44:03 -04:00
wmantly 8535372123 fix: guard UNSEAL_KEY with ${UNSEAL_KEY:-} in setup.sh (v1.35.11)
On a re-run where OpenBao is already unsealed, the unseal block is skipped and
UNSEAL_KEY is never set; line 778 then referenced it under set -u and aborted
with 'UNSEAL_KEY: unbound variable'. Guard with ${UNSEAL_KEY:-} so the
VAULT_UNSEAL_KEY upsert is simply skipped when there's no key this run.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-03 22:43:51 -04:00
wmantly ade9a41aed Merge pull request #153 from theta42/release/v1.35.10-reset-openbao-theta-agent
CI/CD / build-theta-agent (push) Successful in 47s
CI/CD / docker-push (push) Failing after 16s
feat: --reset-openbao + fix theta-agent install; bump sso to v1.21.0 (v1.35.10)
2026-08-03 22:26:35 -04:00
wmantly ce664f5cb9 feat: --reset-openbao + fix theta-agent install; bump sso to v1.21.0 (v1.35.10)
- Add --reset-openbao: full clean OpenBao reset (re-init store, flush the
  Redis vault-token cache) to clear stale policies/tokens causing recurring
  vault 403s.
- Fix theta-agent install: copy the prebuilt theta-agent-linux-amd64 from the
  submodule instead of a broken go build; write config to /etc/theta42/agent.yml
  (the path the agent reads), not /etc/theta/agent.yml.
- Bump sso-manager-node gitlink to v1.21.0 (shared secrets + durable vault 403 fix).

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-03 22:24:48 -04:00
wmantly 647f5b846c Merge pull request #152 from theta42/fix/submodule-version-sync-v1.35.9
CI/CD / build-theta-agent (push) Successful in 42s
CI/CD / docker-push (push) Failing after 17s
fix: bump sso & proxy submodules to corrected version tags (v1.35.9)
2026-08-03 21:37:39 -04:00
wmantly fe08c2f8c7 fix: bump sso & proxy submodules to corrected version tags (v1.35.9)
The v1.20.2 / v1.32.0 release tags were created but their package.json
versions lagged (1.20.1 / 1.14.3), so the deployed apps' update-check
banner falsely reported a newer version. Repoint the sso-manager-node and
proxy gitlinks to the corrected commits and release v1.35.9.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-03 21:36:24 -04:00
wmantly 43c58e7ed5 Merge pull request #151 from theta42/fix/auto-reset-unseal-key-loss-v1.35.8
CI/CD / build-theta-agent (push) Successful in 44s
CI/CD / docker-push (push) Failing after 17s
fix(setup): auto-reset OpenBao volume and re-initialize if unseal key is lost v1.35.8
2026-08-03 15:44:22 -04:00
wmantly 13d8a979c7 fix(setup): auto-reset OpenBao volume and re-initialize if unseal key is lost v1.35.8
Lint / Shellcheck setup.sh (push) Failing after 9s
Lint / Syntax check bootstrap.js (push) Successful in 13s
2026-08-03 15:43:35 -04:00
wmantly 16cbe46793 Merge pull request #150 from theta42/fix/restore-bao-init-from-backup-v1.35.7
CI/CD / build-theta-agent (push) Successful in 41s
CI/CD / docker-push (push) Failing after 17s
fix(setup): auto-restore bao-init.json from backups if missing from config/ v1.35.7
2026-08-03 15:42:35 -04:00
wmantly 40a1e7f64e fix(setup): auto-restore bao-init.json from backups if missing from config/ v1.35.7
Lint / Shellcheck setup.sh (push) Failing after 10s
Lint / Syntax check bootstrap.js (push) Successful in 14s
2026-08-03 15:42:01 -04:00
wmantly 45715b61ea Merge pull request #149 from theta42/fix/env-get-function-order-v1.35.6
CI/CD / build-theta-agent (push) Successful in 44s
CI/CD / docker-push (push) Failing after 17s
fix(setup): move env_get helper function definition to top of setup.sh v1.35.6
2026-08-03 15:39:39 -04:00
wmantly 54ebb83bb1 fix(setup): move env_get helper function definition to top of setup.sh v1.35.6
Lint / Shellcheck setup.sh (push) Failing after 10s
Lint / Syntax check bootstrap.js (push) Successful in 14s
2026-08-03 15:39:05 -04:00
wmantly a67d972217 Merge pull request #148 from theta42/fix/setup-openbao-unseal-fallback-v1.35.5
CI/CD / build-theta-agent (push) Successful in 42s
CI/CD / docker-push (push) Failing after 18s
fix(setup): fallback to .env VAULT_UNSEAL_KEY and VAULT_TOKEN if bao-init.json is missing v1.35.5
2026-08-03 15:36:46 -04:00
wmantly 875ea874b4 fix(setup): fallback to .env VAULT_UNSEAL_KEY and VAULT_TOKEN if bao-init.json is missing v1.35.5
Lint / Shellcheck setup.sh (push) Failing after 8s
Lint / Syntax check bootstrap.js (push) Successful in 12s
2026-08-03 15:36:22 -04:00
wmantly 119f21b821 Merge pull request #147 from theta42/bump/sso-v1.20.2-proxy-v1.32.0
CI/CD / build-theta-agent (push) Successful in 42s
CI/CD / docker-push (push) Failing after 18s
bump(deps): update sso-manager-node to v1.20.2 and proxy to v1.32.0
2026-08-03 15:31:29 -04:00
wmantly 80275c42e4 bump(deps): update sso-manager-node to v1.20.2 and proxy to v1.32.0
Lint / Shellcheck setup.sh (push) Failing after 9s
Lint / Syntax check bootstrap.js (push) Successful in 13s
2026-08-03 15:30:56 -04:00
wmantly a30deae866 Merge pull request #146 from theta42/bump/theta-agent-v1.2.1
CI/CD / build-theta-agent (push) Successful in 44s
CI/CD / docker-push (push) Failing after 17s
bump(theta-agent): update to v1.2.1 for automatic SSSD installation
2026-08-03 15:02:56 -04:00
wmantly dc9a7ff9c4 bump(theta-agent): update to v1.2.1 for automatic SSSD installation
Lint / Shellcheck setup.sh (push) Failing after 8s
Lint / Syntax check bootstrap.js (push) Successful in 13s
2026-08-03 15:02:14 -04:00
wmantly 7937d6cf92 Merge pull request #145 from theta42/fix/setup-unbound-var-v1.35.2
CI/CD / build-theta-agent (push) Successful in 45s
CI/CD / docker-push (push) Failing after 18s
fix(setup): export CFG_CREATE_ALL_HTTP default and add fail-safe parameter expansion v1.35.2
2026-08-03 14:59:07 -04:00
wmantly 21333de814 fix(setup): export CFG_CREATE_ALL_HTTP default and add fail-safe parameter expansion v1.35.2
Lint / Shellcheck setup.sh (push) Failing after 9s
Lint / Syntax check bootstrap.js (push) Successful in 12s
2026-08-03 14:58:39 -04:00
wmantly b3bdebe1c9 Merge pull request #144 from theta42/release/v1.35.1
CI/CD / build-theta-agent (push) Successful in 44s
CI/CD / docker-push (push) Failing after 16s
release(theta-suite): v1.35.1
2026-08-03 14:02:55 -04:00
wmantly e6b318e28e release(theta-suite): v1.35.1 - Submodule updates, Directory, Conf layout & Jump host target filter
Lint / Shellcheck setup.sh (push) Failing after 9s
Lint / Syntax check bootstrap.js (push) Successful in 14s
2026-08-03 14:02:13 -04:00
11 changed files with 841 additions and 66 deletions
+93
View File
@@ -8,6 +8,99 @@ 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.1] - 2026-08-04
### Fixed
- **`setup.sh` no longer aborts with `CFG_BASE_DN: unbound variable`** — the ldap-client `ldap.vars` generation read the CFG_* first-run vars, which `ensure_config` only derives once (it returns early on a re-run once `sso-secrets.js` exists). It now reads the real values from the operator-owned `./config/sso-secrets.js` when the CFG_* vars are unset, so LDAP enrollment works on re-runs too. The generated `ldap_access_groups` now references `god_admin` (the legacy `app_super_admin` is gone).
- **Roll up sso v1.26.1** — drops the legacy `app_super_admin`: `SUPER_ADMIN_GROUP` is now `god_admin` (nested into every resource's `_admin` group), and `docker-entrypoint.sh` no longer seeds/nests `app_super_admin`. See the [sso changelog](https://github.com/theta42/sso-manager-node/blob/master/CHANGELOG.md).
## [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
+96 -1
View File
@@ -89,7 +89,13 @@ 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
// per-console admin groups still used by the SSO UI. god_admin is nested into
// the app_sso_* groups (and every resource's _admin group) by
// docker-entrypoint.sh + api_directory_admin, 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,11 +429,38 @@ 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,
@@ -510,6 +543,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.
@@ -759,6 +845,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) {
+36
View File
@@ -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
+323
View File
@@ -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."
+4
View File
@@ -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.
+36 -10
View File
@@ -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
+1 -1
Submodule proxy updated: 62cdaa2cdd...bbaa006925
+249 -51
View File
@@ -72,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"
@@ -106,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)
@@ -178,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
@@ -270,6 +292,21 @@ dn_from_domain() {
echo "dc=$1" | sed 's/\./,dc=/g'
}
# Read a value from the (operator-owned) ./config/sso-secrets.js -- the source of
# truth on re-runs, where the CFG_* first-run shell vars are not (re)derived
# (ensure_config returns early once sso-secrets.js exists). Reads `stack.<key>`.
# Prints empty on any failure. Usage: sso_secrets_get ldapBaseDn
sso_secrets_get() {
node -e 'const c=require(process.argv[1]);const k=process.argv[2];console.log(c&&c.stack&&c.stack[k]!=null?c.stack[k]:"")' \
"$PWD/$CONFIG_DIR/sso-secrets.js" "$1" 2>/dev/null || true
}
# Read a top-level (non-stack) secret from sso-secrets.js, e.g. serviceAccountPass.
sso_secrets_get_top() {
node -e 'const c=require(process.argv[1]);const k=process.argv[2];console.log(c&&c[k]!=null?c[k]:"")' \
"$PWD/$CONFIG_DIR/sso-secrets.js" "$1" 2>/dev/null || true
}
# Write ./config/sso-secrets.js from the CFG_* shell vars.
write_sso_secrets() {
local dn="$CFG_BASE_DN" domain="$CFG_DOMAIN"
@@ -662,6 +699,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
@@ -674,6 +725,16 @@ for i in $(seq 1 30); do
sleep 2
done
# 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
@@ -686,13 +747,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
@@ -722,33 +824,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"
}
@@ -786,6 +890,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"] }
@@ -824,15 +932,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
@@ -858,6 +999,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.
@@ -978,7 +1131,7 @@ async function ensureHost(host, ip, targetPort) {
host: host,
ip: ip,
targetPort: targetPort,
forcessl: $( [[ "$CFG_CREATE_ALL_HTTP" == "1" ]] && echo false || echo true ),
forcessl: $( [[ "${CFG_CREATE_ALL_HTTP:-0}" == "1" ]] && echo false || echo true ),
targetssl: false,
sso_enabled: false,
created_by: 'setup.sh',
@@ -1035,7 +1188,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: $( [[ "$CFG_CREATE_ALL_HTTP" == "1" ]] && echo false || echo 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);
@@ -1052,25 +1205,33 @@ if [[ "$CFG_THETA_AGENT_ENABLE" == "1" ]]; then
info "Setting up theta-agent on the host..."
(
cd theta-agent || exit 0
if ! command -v go >/dev/null 2>&1; then
warn "Go is not installed. Skipping theta-agent installation."
# 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 " Building theta-agent..."
go build -o theta-agent main.go websocket.go config.go || warn " Failed to build theta-agent."
if [[ -x "theta-agent" ]]; then
sudo mkdir -p /etc/theta
if [[ ! -f /etc/theta/agent.yml ]]; then
sudo cp agent.yml.example /etc/theta/agent.yml
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/theta/agent.yml
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" == "1" ]]; then
sudo sed -i "s|https://sso.example.com|http://${SSO_HOST}|" /etc/theta/agent.yml
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/theta/agent.yml
sudo sed -i "s|https://sso.example.com|https://${SSO_HOST}|" /etc/theta42/agent.yml
fi
fi
sudo cp theta-agent /usr/local/bin/theta-agent
# 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
@@ -1111,6 +1272,38 @@ if [[ "$CFG_THETA_AGENT_ENABLE" == "1" ]] && [[ -x /usr/local/bin/theta-agent ]]
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..."
# CFG_* first-run vars may be unset on a re-run (ensure_config returns
# early once sso-secrets.js exists), so fall back to reading the real
# values from the operator-owned sso-secrets.js. All `:-` guarded so a
# missing value degrades to an empty ldap.vars field, not a set -u abort.
ldap_base_dn="${CFG_BASE_DN:-$(sso_secrets_get ldapBaseDn)}"
ldap_site="${CFG_SITE_NAME:-$(sso_secrets_get siteName)}"
ldap_bind_pass="${CFG_SVC_PASS:-$(sso_secrets_get_top serviceAccountPass)}"
sso_host="${CFG_SSO_HOST:-$(sso_secrets_get ssoHost)}"
ldaps_host="${CFG_LDAPS_HOST:-}"
[[ -n "$ldaps_host" ]] || ldaps_host="${sso_host:-}"
cat > ldap-client/ldap.vars <<LDAPVARS
export ldap_host="${ldaps_host}"
export ldap_base_dn="${ldap_base_dn}"
export ldap_bind_dn="cn=ldapclient,ou=people,${ldap_base_dn}"
export ldap_bind_password="${ldap_bind_pass}"
export sso_url="https://${sso_host}"
export sso_token=""
export ldap_location="${ldap_site:-local}"
ldap_access_groups=( "\${ldap_location}_access" "\${ldap_location}_host_\$(hostname)_access" "god_admin" )
LDAPVARS
else
info " ldap-client/ldap.vars exists -- keeping it"
fi
(
cd ldap-client || exit 0
if [[ -x "index.sh" ]]; then
@@ -1123,15 +1316,20 @@ if [[ "$CFG_THETA_AGENT_ENABLE" == "1" ]] && [[ -x /usr/local/bin/theta-agent ]]
if [[ "$CFG_THETA_AGENT_FULL_CONTROL" == "1" ]]; then
info " Configuring theta-agent with full host control capabilities..."
if [[ -f /etc/theta/agent.yml ]]; then
sudo sed -i 's/arbitrary_bash: false/arbitrary_bash: true/' /etc/theta/agent.yml
sudo sed -i 's/service_control: .*/service_control: true/' /etc/theta/agent.yml
sudo sed -i 's/reboot: false/reboot: true/' /etc/theta/agent.yml
sudo sed -i 's/configure_ldap: false/configure_ldap: true/' /etc/theta/agent.yml
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/theta/agent.yml not found. Full control not configured."
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)."