fix(sbomify): REDIS_URL in compose + coreutils in keycloak image#75
Merged
Merged
Conversation
Fixes three issues that together make the published quickstart unable to complete the OIDC login flow: 1. Server 500 on OIDC callback — sbomify settings.py reads REDIS_URL and falls back to redis://localhost:6379 when unset; our compose file was setting REDIS_HOST (which nothing reads) to the docker hostname. django-redis cache then failed every operation with "Error 111 connecting to localhost:6379. Connection refused." allauth's verify_jti calls cache.add() during the OIDC callback, so the whole login chain blew up. Renamed REDIS_HOST → REDIS_URL in x-common-env and pointed it at redis://sbomify-redis:6379. 2. keycloak-bootstrap exit 127 on re-run — the idempotent branch for an existing client in keycloak-bootstrap.sh pipes through `tr -d '"'` to extract a UUID from CSV output, but tr isn't in the sbomify- keycloak image (minimalBusybox curates applets by CVE surface and tr wasn't included). Recreating the container after first provision would exit 127 and break the `depends_on: service_completed_successfully` gate on sbomify-backend. 3. kcadm.sh noise — Keycloak's upstream kcadm.sh wrapper calls $(uname) and `readlink -f "$0"` on every invocation. Without those binaries in PATH, every kcadm.sh call printed "uname: command not found" and "readlink: command not found" (or "invalid option -- 'f'" once uname returned Linux and the busybox readlink got selected). Cosmetic but obscures the real bootstrap output and makes debugging harder. Resolved #2 and #3 together by adding pkgs.coreutils to the sbomify-keycloak image packages. Kept minimalBusybox untouched so other images (postgres, redis, minio, sbomify-app, caddy) stay lean; only keycloak carries the extra coreutils weight (~1.7MB), which it needs because it embeds an upstream wrapper that assumes GNU coreutils semantics. Verified against the published sbomify-v26.1.0-20260419.2 compose release: - REDIS_URL fix: `docker compose up -d` (patched compose, unchanged images) → cache.set/get/add all succeed, Django talks to sbomify-redis:6379. - coreutils fix: rebuilt sbomify-keycloak-image locally, reran the stack → first-run bootstrap log is silent (no "not found" / "invalid option" lines), exit 0; force-recreated the bootstrap container to hit the re-run path → exit 0 (previously 127), client still exists and is correctly updated. Co-Authored-By: Yakoff (Claude) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Three chained issues that prevent the published quickstart from completing an OIDC login. Users who deploy the stack hit a server 500 as soon as they click "sign in" and try to authenticate — before this PR the quickstart wasn't actually usable end-to-end, even after #73 got the stack to boot.
1. Server 500 on OIDC callback — wrong Redis env var
sbomify/settings.py:359readsREDIS_URL(falling back toredis://localhost:6379). The compose file setREDIS_HOST=sbomify-redis:6379, which nothing reads. Every cache call inside sbomify failed withError 111 connecting to localhost:6379. Connection refused.allauth'sverify_jtihitscache.add()during the OIDC callback, so login blew up:Fix: rename
REDIS_HOST: ${REDIS_HOST:-sbomify-redis:6379}→REDIS_URL: ${REDIS_URL:-redis://sbomify-redis:6379}inx-common-env.2.
keycloak-bootstrapexits 127 on re-runThe idempotent "client already exists" branch of
keycloak-bootstrap.shpipes throughtr -d '"'to parse a UUID out of CSV.trisn't in the sbomify-keycloak image —minimalBusyboxcurates applets by CVE surface andtrwasn't on the allow-list. First boot (create path) worked fine, but recreating the container after the first provision (say, during a config reload or after adocker compose up -d --force-recreate) exits 127 and blocks theservice_completed_successfullydependency gate onsbomify-backend.3.
kcadm.shnoise on every callKeycloak's upstream
kcadm.sh-wrappedstarts withcase "$(uname) in … *) readlink -f "$0". Neither binary was in PATH inside the image, so every invocation printed:Once uname started returning Linux, the case fell through to the default branch and called busybox
readlink -f, which doesn't support-f→readlink: invalid option -- 'f'on every call. Cosmetic, but it drowns out the real bootstrap output.Fix
Added
pkgs.coreutilstoapps/sbomify/images/sbomify-keycloak.nix. This gives the keycloak image GNUtr,uname, andreadlink -fwithout touching the globalminimalBusyboxallow-list — other images (postgres, redis, minio, sbomify-app, caddy) stay on the lean minimal shell, only the keycloak image carries the ~1.7 MB coreutils weight it needs because it ships an upstream wrapper that assumes GNU semantics.Test plan
sbomify-v26.1.0-20260419.2compose release by clicking through the OIDC login flow in a browser (asjdoe/foobar123). Got HTTP 500 on/accounts/oidc/keycloak/login/callback/; backend log shows thedjango_redis.exceptions.ConnectionInterruptedtrace quoted above.REDIS_URLreachessbomify-backend, Django cache talks tosbomify-redis:6379,cache.set/get/addall succeed.sbomify-keycloak-imagelocally with the coreutils change (nix build .#sbomify-keycloak-image), loaded into docker, ran full stack:keycloak-bootstraplog is now silent — nouname: command not found, noreadlink: command not found, noinvalid option. Exit 0.curl /UuPha8mu/→ 200, Django cache reachable, full OIDC login flow completes (with the matching combined fix this is unblocked).down -v, no residual state.Notes
APP_BASE_URLport-coupling alone — separate issue, deserves its own PR with a proper override story.🤖 Generated with Claude Code