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>
sso-manager-node d5e951f — ships sudo.schema + openssh-lpk.schema (included
in the all-in-one slapd.conf) so user creation works (addPosixAccount tags
every user with sudoRole + ldapPublicKey). Also fixes the .dockerignore build
error from the previous theta42 schema bump. See theta42/sso-manager-node#33.
Co-Authored-By: Claude <noreply@anthropic.com>
sso-manager-node: d1620dd -> 84e5358
Load the theta42 (dateOfBirth) schema in the all-in-one image
(theta42/sso-manager-node#32)
Fixes PUT /api/user/<uid> failing with "objectClass: value #0 invalid per
syntax (0x15)" when a dateOfBirth is set, and user creation for the
theta42Person objectClass. Requires a rebuild of the sso-manager image.
Co-Authored-By: Claude <noreply@anthropic.com>
Point sso-manager-node and proxy at the commits that add the Logs (Docker)
section to their README/DEPLOYMENT docs:
proxy: cca5e48 -> 3f178b0
sso-manager-node: fe9b7c1 -> d1620dd
Co-Authored-By: Claude <noreply@anthropic.com>
Both services (sso-manager, proxy) run under Compose; document how to get
logs via docker compose logs, the proxy's nginx access/error logs (which go
to /var/log/nginx on the proxy-logs volume, not docker logs), and a direct
ldapsearch health check for the SSO.
Co-Authored-By: Claude <noreply@anthropic.com>
Add a first step to setup.sh that runs `git submodule update --init --remote
--recursive`, so each ./setup.sh builds from the newest sso-manager-node + proxy
upstream rather than whatever was pinned at clone time. --init also populates
the submodules if the repo was cloned without --recursive.
Behavior:
- If the fetch is unreachable (offline), warn and continue building the
currently checked-out code instead of hard-failing.
- SKIP_SUBMODULE_UPDATE=1 locks to the pinned commits (offline rebuild /
deliberate pin).
- Verifies the build contexts (Dockerfile.openldap, Dockerfile) exist and
dies with a clear message if a submodule was never initialized.
- Requires git (added to the Requires line); git absent is fatal unless
SKIP_SUBMODULE_UPDATE=1.
Renumbered the subsequent step headers (env -> 2, sso-manager -> 3, ...).
README repo-layout note updated to say setup.sh auto-updates submodules.
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