net-kingdom/docs/railiance01-coulombcore-cutover-inventory-2026-07-28.md

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.