coulomb-social/history/20261006T145931Z-personal-app-deployment-receipt.md
tegwick 1272c699b0
Some checks failed
Use-case regression gate / usecase-regressions (push) Failing after 3m48s
Record deployed personal app and remaining Authelia credential rejection
Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a10e2d-a5ef-7e92-b03d-b1694e915680
2026-10-06 17:02:16 +02:00

3.7 KiB

Personal app deployment receipt — 2026-10-06

Founder explicitly approved: “Go on and deploy the interruption is not a problem.” Authority: ADMINISTER @ realm:kubernetes/railiance01, activation=APPROVED. Decision 8bbce691-a787-4140-9cd4-df06e8635a27 records that human answer.

Executed and verified

  • Correct node: railiance01 / 92.205.62.239. Preflight CPU requests 3455m/4000m, disk free 123G. Reviewed owner helper hash unchanged; dry-runs/diffs refreshed.
  • Restored only historical public coulomb-social OIDC registration through guarded SSH/CAS owner lane. Secret UID retained; resourceVersion 67716615 → 71471711. Byte-preserving validation/readback confirmed unrelated config and Secret data unchanged. No Secret values or raw errors emitted. Restarted sso/keycape; rollout succeeded. Discovery 200; public /authorize probe 302 to Authelia, without unknown client_id. This is a handoff check, not a completed user login.
  • Fresh Backup databases/csoc-preupgrade-20261006145351 for apps-pg, method barmanObjectStore: completed, start 2026-10-06T14:54:22Z, stop 2026-10-06T14:54:31Z. Completed before app upgrade began.
  • Approved owner chart merged/pushed to railiance-apps main at 3f5a909. Helm upgrade executed from railiance01 with --atomic/--wait/5m timeout. Release coulomb-social revision 10 is deployed, chart 0.2.0, source ac7bac1852, digest sha256:bf975939e22b9b0a5d9ac05584ae6265ba201169df6dc48e506ec684b30a9c58.
  • Retained local-path PVC coulomb-social-content is Bound, 2Gi/RWO; mounted at /app/var/content with CONTENT_ROOT matching. One replica/Recreate. App UID/GID 10001; volume group 10001; write check passed. A dedicated synthetic marker survived a fresh pod restart and was removed afterward. No real content touched.
  • App 1/1 available after upgrade and restart. Zero pending Django migrations; existing tegwick Member retained (count one for tenant:coulomb and live issuer).
  • Public /healthz and landing: 200. Clipboard JS: 200, 2909 bytes, ClipboardItem present. /auth/login/: 302 to correct issuer/client/callback and PKCE S256. Anonymous /app/: 302, preserving authentication boundary.

Remaining acceptance

The user has been asked to complete interactive tegwick sign-in. It is not yet confirmed. CSOC-WP-0008-T11 remains waiting for that result; T01 continues live product smoke/visual and permission acceptance. A DB backup plus persistent volume is not paired DB/content restore proof: T02 remains open. Real ReichelAg protocol reconciliation/import and manual mail-client paste remain T03/T09. No Bubble/apex cutover, real-data import, password change, broad grant or private protocol export was performed. RAPPS-WP-0015 remains active pending T04.

User sign-in result — 2026-10-06

The user reaches auth.coulomb.social but tegwick is rejected as wrong username or password. Read-only directory query through the existing provisioner confirms tegwick is present. Live Authelia username attribute is uid; its lookup supports uid or mail. Contained recent-log inspection records a tegwick LDAP invalid- credentials failure, without backend connection error or regulation-ban evidence in that entry. This does not establish why the entered credential is rejected.

The app and client restoration are deployed, but personal sign-in is not accepted. CSOC-WP-0008-T11 remains wait for human credential confirmation/recovery and a successful fresh sign-in. The user was asked whether the same password works on another service. No password was requested/read/exported or reset. Authelia's current notifier is filesystem rather than SMTP: do not promise emailed recovery or expose reset tokens from notification files. Any credential reset must use the owning attended recovery/setup lane under a separate exact approved change.