tegwick
1272c699b0
Some checks failed
Use-case regression gate / usecase-regressions (push) Failing after 3m48s
Assistant: codex Assistant-Model: gpt-6.1-sol Assistant-Session: 01a10e2d-a5ef-7e92-b03d-b1694e915680
59 lines
3.7 KiB
Markdown
59 lines
3.7 KiB
Markdown
# 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 ac7bac1852c9,
|
|
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.
|