lament/pantheon

`just pki-enroll` automates Secure Boot key enrollment; SPNEGO's LDAP lookup gets fixed #110

Merged

lament merged 1 commit from fixes into main

2026-07-24 20:34:34 -05:00

lament commented

2026-07-24 20:19:09 -05:00

Owner

just pki-enroll <host> [user]: new recipe pushes the fleet's Secure Boot PK/KEK/db (sops/pki/{lament,db}.yaml) straight into a lanzaboote host's firmware over ssh
- decrypts locally, tars to a tmpfs staging dir on the target (plaintext keys never touch its disk), sbctl import-keys + sbctl enroll-keys, verifies after
- guards: aborts if the target isn't in firmware setup mode, requires typing the hostname back to confirm - it drops the Microsoft UEFI CA, which a discrete GPU/Thunderbolt dock could need for pre-boot init
- replaces ceremony/01-gen-keys.sh + 02-update-sops.sh (deleted) - that pair minted builder/deployer ssh keys by hand, an unrelated one-off ceremony just newhost has since made obsolete
fixed: kerberos SPNEGO login silently broke after any Keycloak logout
- krbPrincipalAttribute defaults to Keycloak's own (wrong) krb5PrincipalName, and the KDC's kldap backend keeps principals in a separate krbContainer subtree regardless - so the LDAP lookup Keycloak does on a fresh (uncached) kerberos login could never succeed
- openldap.nix now mirrors krbPrincipalName onto the person entry itself (aux objectClass, additive ldapmodify, same idiom as the existing seed block); realm-lament.json pins the correct attribute name
- it only ever "worked" before because Keycloak's user cache masked the broken lookup until a logout evicted it
lanzaboote.nix/kdc.nix comments repointed at just pki-enroll and the wiki runbook instead of the now-deleted ceremony
README/CLAUDE.md doc sweep: the identity role + verdandi, site-mesh (fate), hestia parked, mkSopsBin/keytabs, docs/ is wiki-staging-only
buildMachines.nix's remote-dispatch entry gets maxJobs set for the first time - it silently defaulted to 1, so every host offloading a build to brigid serialized to one job at a time regardless of its actual size
- maxJobs = 12, ahead of brigid's next restart doubling its vCPUs 6 -> 12 (per-job core count isn't a buildMachines field - that's the builder's own nix.conf, already auto on brigid)

- `just pki-enroll <host> [user]`: new recipe pushes the fleet's Secure Boot PK/KEK/db (`sops/pki/{lament,db}.yaml`) straight into a lanzaboote host's firmware over ssh - decrypts locally, tars to a tmpfs staging dir on the target (plaintext keys never touch its disk), `sbctl import-keys` + `sbctl enroll-keys`, verifies after - guards: aborts if the target isn't in firmware setup mode, requires typing the hostname back to confirm - it drops the Microsoft UEFI CA, which a discrete GPU/Thunderbolt dock could need for pre-boot init - replaces `ceremony/01-gen-keys.sh` + `02-update-sops.sh` (deleted) - that pair minted builder/deployer ssh keys by hand, an unrelated one-off ceremony `just newhost` has since made obsolete - fixed: kerberos SPNEGO login silently broke after any Keycloak logout - `krbPrincipalAttribute` defaults to Keycloak's own (wrong) `krb5PrincipalName`, and the KDC's `kldap` backend keeps principals in a separate `krbContainer` subtree regardless - so the LDAP lookup Keycloak does on a fresh (uncached) kerberos login could never succeed - `openldap.nix` now mirrors `krbPrincipalName` onto the person entry itself (aux objectClass, additive `ldapmodify`, same idiom as the existing seed block); `realm-lament.json` pins the correct attribute name - it only ever "worked" before because Keycloak's user cache masked the broken lookup until a logout evicted it - `lanzaboote.nix`/`kdc.nix` comments repointed at `just pki-enroll` and the wiki runbook instead of the now-deleted ceremony - README/CLAUDE.md doc sweep: the `identity` role + `verdandi`, site-mesh (`fate`), `hestia` parked, `mkSopsBin`/keytabs, docs/ is wiki-staging-only - `buildMachines.nix`'s remote-dispatch entry gets `maxJobs` set for the first time - it silently defaulted to `1`, so every host offloading a build to `brigid` serialized to one job at a time regardless of its actual size - `maxJobs = 12`, ahead of brigid's next restart doubling its vCPUs 6 -> 12 (per-job core count isn't a `buildMachines` field - that's the builder's own `nix.conf`, already auto on brigid)

lament added 1 commit

2026-07-24 20:19:09 -05:00

minor fixes

CI / check (pull_request) Successful in 1m13s

Details

CI / deploy (pull_request) Has been skipped

Details

CI / build (pull_request) Successful in 2m15s

Details

CI / dry-activate (pull_request) Successful in 1m13s

Details

020d9a4d5b