Record CoulombCore cutover inventory
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

This commit is contained in:
tegwick 2026-07-28 02:52:14 +02:00
parent fea55461e9
commit ae986c723a
2 changed files with 86 additions and 2 deletions

View file

@ -0,0 +1,75 @@
# Railiance01 / CoulombCore cutover inventory
Captured read-only on 2026-07-28. This inventory intentionally contains no
Secret values, private keys, password hashes, tokens, or database contents.
## Public routing
| Name | Current target | Cutover owner/state |
| --- | --- | --- |
| `kc.coulomb.social` | railiance01 (`92.205.62.239`) | KeyCape active |
| `auth.coulomb.social` | railiance01 (`92.205.62.239`) | Authelia active |
| `login.coulomb.social` | railiance01 (`92.205.62.239`) | Authelia alias active |
| `lldap.coulomb.social` | CoulombCore (`92.205.130.254`) | identity cutover pending |
| `pink.coulomb.social` | CoulombCore (`92.205.130.254`) | identity cutover pending |
| `pink-account.coulomb.social` | CoulombCore (`92.205.130.254`) | identity cutover pending |
| `bao.coulomb.social` | CoulombCore (`92.205.130.254`) | OpenBao-owned cutover |
| `gitea.coulomb.social` | CoulombCore (`92.205.130.254`) | Forgejo/Gitea-owned cutover |
| `hub.coulomb.social` | CoulombCore (`92.205.130.254`) | State Hub-owned cutover |
Public recursive resolvers return railiance01 for both Authelia names. The
certificate at railiance01 is trusted and covers both names. The portal →
KeyCape → Authelia redirect chain terminates on railiance01.
During cutover, cert-manager's HTTP-01 self-check inherited stale node DNS.
The live controller now uses `1.1.1.1:53,8.8.8.8:53` for ACME self-checks and
the expanded certificate was renewed through `cmctl`. The cluster add-on
configuration must codify that resolver flag so a future Helm reconciliation
does not remove it.
## Identity workload comparison
| Component | CoulombCore | railiance01 | Finding |
| --- | --- | --- | --- |
| KeyCape | `main-nonce-0601` | `key-cape:909bb32` | New runtime is ahead; both healthy |
| Authelia | `authelia:4.38` | `authelia:4.38` | Same declared image |
| LLDAP | `lldap/lldap:stable` | `lldap/lldap:stable` | Independent PVCs; content differs |
| privacyIDEA | `3.12.2` | `3.12.2` | Independent data/log PVCs |
| NetKingdom PostgreSQL | 10 Gi PVC | 10 Gi PVC | Independent clusters require semantic comparison |
| Identity provisioner | absent | `identity-provisioner:dbf7cfd` | railiance01-only lifecycle adapter |
| User engine | absent | `user-engine:portal-e23674d` | railiance01-only control surface |
Both KeyCape endpoints serve the same public JWKS fingerprint:
`8e3237da6030c6af91c5005d0112a149204bc549f67d2234939c5581fdb95a32`.
This proves current public signing-key continuity, not full configuration
equivalence.
## Persistent state and backup observations
- Both LLDAP databases are 139264 bytes, but their SHA-256 fingerprints differ:
CoulombCore `b3be5eed...b91278`; railiance01 `fc538cc8...03dab`.
Equal size is not equivalence. Railiance01 also has newer writes from the
provisioning conformance path.
- railiance01 runs daily LLDAP, Authelia, and privacyIDEA backup CronJobs and
exposes an LLDAP backup directory on its PVC.
- The queried CoulombCore workload inventory exposed daily logical PostgreSQL
backup CronJobs, but no matching LLDAP, Authelia, or privacyIDEA backup
CronJobs. A fresh source-side protected backup is therefore a hard gate.
- Both servers retain independent LLDAP, Authelia, privacyIDEA, and
NetKingdom PostgreSQL PVCs. No DNS move for LLDAP/privacyIDEA is evidence of
data migration.
- CoulombCore still runs KeyCape and Authelia ingress even though their public
DNS moved. Keep these intact only for the bounded rollback window; prevent
new authoritative writes once state migration begins.
## Required next evidence
1. Create and verify fresh encrypted CoulombCore identity backups.
2. Compare semantic user/group counts and stable identifiers without exporting
credential material into logs.
3. Compare privacyIDEA realms, resolver mappings, token counts, and encryption
custody using redacted/count-only probes.
4. Compare NetKingdom PostgreSQL schemas and row counts.
5. Freeze writes, merge the authoritative source into railiance01, rerun the
comparisons, and then exercise platform-root and Binky login/MFA.
6. Move LLDAP and privacyIDEA DNS only after those gates pass.