CFG_HTTP_PROXY / CFG_HTTPS_PROXY / CFG_NO_PROXY in setup.env (all
optional, unset by default) get wired into every service's docker build
(npm/apt) and running container (SMTP, ACME/Let's Encrypt, DNS provider
calls, the jump-host directory API client) as HTTP_PROXY/HTTPS_PROXY/
NO_PROXY. Useful for isolated/offline/corporate-network test hosts that
only reach the internet through an upstream proxy — distinct from the
theta42 "proxy" app itself. CFG_NO_PROXY defaults to the stack's own
internal service names so container-to-container traffic never routes
through the proxy.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds jump-host as a third, opt-in submodule, wired behind
CFG_JUMP_HOST_ENABLED (default off — existing installs unaffected):
- .gitmodules + jump-host submodule pinned to v1.0.0
- setup.sh: resolves the enable flag early, adds jump-host to the
submodule tag-update loop and activates the `jump-host` compose
profile when enabled; builds/starts the service after the proxy,
waits for its /health, and registers its web UI as a proxy Host;
passes CFG_JUMP_HOST_ENABLED/CFG_JUMP_HOST to the bootstrap
- docker-compose.yml: jump-host service with profiles:["jump-host"],
depends_on sso-manager healthy, ports 2222 (SSH) + 3002 (web),
./config:ro + jump-data volume
- bootstrap.js: when enabled, mints a directory API token and writes
./config/jump-secrets.js (binds as cn=admin so it can write the
sshPublicKey attribute for key injection), and seeds a directory
service entry for the jump host. Warn-only, idempotent.
- setup.env.example: CFG_JUMP_HOST_ENABLED / CFG_JUMP_HOST / JUMP_SSH_PORT
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Pass optional CFG_LDAPS_HOST from setup.env through setup.sh into the
generated ./config/sso-secrets.js as ldap.ldapsHost. This lets operators
advertise an internal-only LDAPS hostname (e.g. ldap.internal.example.com
or sso-manager) on the SSO /integrations page instead of the public
OAuth issuer, avoiding a public 636 port forward.
- setup.env.example: add CFG_LDAPS_HOST
- setup.sh: read/forward CFG_LDAPS_HOST into sso-secrets.js
- config.example/sso-secrets.js.example: document ldapsHost/ldapsPort
- .env.example: add LDAPS_HOST for legacy .env migrations
- docker-compose.yml: comment warning against public 636 forwarding
- README.md: explain CFG_LDAPS_HOST recommendation
- CHANGELOG.md + bump version to 1.1.19
Co-authored-by: Claude <noreply@anthropic.com>
- proxy -> v1.1.14
- sso-manager-node -> v1.1.14
Both bump @simpleworkjs/conf to 1.2.0 and jq-repeat to 2.2.0, and use
the new CONF_SECRETS env var instead of symlinking the mounted secrets
file into /app/conf/secrets.js. Updated theta-env's own docs/setup.sh/
docker-compose.yml comments to match -- no change to the config file
format or bind mounts.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two related fixes found while testing the Docker build:
1. Print the proxy's local anti-lockout admin (proxyadmin2) password
in the summary. Previously this account was always created with
username == password == "proxyadmin2" (a hardcoded proxy default —
see theta42/proxy#133), and setup.sh had no way to know or surface
whatever password ended up in use. Now generates a random
CFG_PROXY_ADMIN_PASS the same way it already does for the SSO
admin, writes it into proxy-secrets.js's auth.localAdminPass (read
by the proxy once, on first creation of that account), and prints
it in the final summary. read_config_kv() reads it back from
proxy-secrets.js so this works correctly on re-runs too (config
already exists -> ensure_config's early-return path never sets
CFG_PROXY_ADMIN_PASS in that run's shell, same reasoning as the
existing SSO_HOST/PROXY_HOST/ADMIN_PASS readback).
2. Pass GIT_COMMIT build-args so the proxy/sso-manager images bake in
their real commit hash instead of "unknown". Both submodules' .git
is a pointer file, not a real repo, so the images can never resolve
their own commit from inside the Docker build context no matter
what (see theta42/proxy#133 and theta42/sso-manager-node#43) --
only the host, where the submodule resolves correctly, can compute
it. setup.sh does that with `git -C <submodule> rev-parse --short
HEAD` right before each build and exports it for docker-compose.yml
to pick up.
Verified end to end against a real ./setup.sh run (not just docker
build in isolation):
- Local admin password printed on first run, logs in successfully;
the DEFAULT ("proxyadmin2"/"proxyadmin2") correctly does NOT.
- Re-running prints the SAME password (confirms the readback path
works on re-runs, not just first-run).
- `docker exec proxy cat /app/.build_commit` and the equivalent for
sso-manager both match `git -C <submodule> rev-parse --short HEAD`
on the host — footer now shows the real hash instead of "unknown".
Cleanup pass ahead of the public release announcement:
- docs/index.md: fix the Quick Start block, which described a stale
"edit config then re-run setup.sh a second time" flow. setup.sh now
requires setup.env (with CFG_BASE_DN) before it will do anything, and
builds + bootstraps + starts in a single run. Updated to match
README.md's correct 4-line sequence.
- Add a standard MIT LICENSE at the repo root (theta42, 2026) so
docs/index.md's "MIT License — see the repository for details" claim
is actually true.
- docs/standalone.md: document the hardcoded auth.adminUsers:
['proxyadmin2'] local anti-lockout admin bypass written into every
generated proxy-secrets.js — what it's for, that it requires a
matching SSO user to actually use, and how to rename/extend/disable
it.
- README.md + docker-compose.yml: fix the LDAPS strict-trust security
note, which implied mounting the SSO's cert into the proxy was a
config-only change. It also requires a docker-compose.yml edit
(ldap-certs isn't mounted into the proxy service); added commented-out
boilerplate for that mount and clarified the doc text.
- Also includes the pre-existing "Why use this instead of running the
two separately?" README paragraph that was already staged as
in-progress work.
- Verified: no Vagrant references, no emoji, and no hardcoded
custom-domain URLs anywhere in this repo outside the proxy/ and
sso-manager-node/ submodules; no docs/CNAME (github.io URL scheme
confirmed).
- Added --- section dividers to docs/*.md to match README.md's
formatting convention.
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Part A — lossless upgrades:
- Persist both bundled Redis stores via AOF+RDB on named volumes (sso-data,
proxy-data) so OAuth clients, Host records, perms, DNS creds, and auto-ssl
Let's Encrypt certs survive rebuilds.
- setup.sh: backup_before_rebuild() snapshots ./config/ + LDAP (slapcat) +
both Redis (BGSAVE + compose cp) to ./backups/<ts>/ before each rebuild,
keeps last BACKUP_KEEP (default 5). First run is a no-op.
- Restore runbook (README + docs): full / Redis-only / LDAP-only, with the
AOF-vs-RDB note (delete the AOF before restoring an RDB).
Part B — eliminate .env / proxy.env:
- All config + secrets live in bind-mounted ./config/ (gitignored), read by each
app's @simpleworkjs/conf from a symlinked secrets.js. Compose passes only
NODE_ENV + NODE_PORT (no app_* env, which would override secrets.js).
- ./config/sso-secrets.js: app secrets + orchestrator-only stack/bootstrap/
serviceAccountPass keys (app ignores the ones it doesn't use).
- ./config/proxy-secrets.js: oidc (clientId/clientSecret filled in by the
bootstrap), ldap (bind creds), auth (admin groups/users).
- setup.sh ensure_config(): generates ./config/ with random secrets on first
run (then exits for editing); one-time migration from .env/proxy.env
preserving existing secrets (LDAP admin pass, JWT, OAuth client, service
pass) so a running deployment keeps its directory + tokens + OAuth client.
- bootstrap/bootstrap.js: reads /config/*.js (not process.env), registers the
proxy as an OIDC client, and writes the SSO-generated client id+secret back
into ./config/proxy-secrets.js (sso mounts ./config RW, proxy RO).
- config.example/ holds committed annotated templates for manual reference.
- .gitignore: add config/, backups/, *.rdb, *.ldif.
Bump both gitlinks to the merged submodule tips:
- sso-manager-node -> 6920a9f (PR #34)
- proxy -> 8e78604 (PR #118)
Co-authored-by: Claude <noreply@anthropic.com>
The SSO web UI and the proxy management UI were bound to 127.0.0.1, so they
were only reachable from the host running the stack — inconvenient during
first-run setup from another machine. Make the bind address configurable
(SSO_BIND / MGMT_BIND, default 0.0.0.0) so both are LAN-reachable by default,
with a one-line flip back to 127.0.0.1 once the proxy fronts them under TLS.
Also: friendlier README with an upfront prerequisites section (domain, >=2 DNS
records to the public IP, port-forward 80/443) and a note that .env values with
spaces should be quoted.
Co-Authored-By: Claude <noreply@anthropic.com>
wmantly