From 345de165521f820f7c4e8bb0adf00ae55653858a Mon Sep 17 00:00:00 2001 From: Ruben Hensen Date: Sun, 25 Oct 2026 02:52:52 +0100 Subject: [PATCH] docs: record the Vault 2.2.1 upgrade --- docs/longhorn-second-ssd.md | 6 ++++-- docs/roadmap.md | 28 +++++++++++++++++++++------- 2 files changed, 25 insertions(+), 9 deletions(-) diff --git a/docs/longhorn-second-ssd.md b/docs/longhorn-second-ssd.md index 1d185a4..a479cb0 100644 --- a/docs/longhorn-second-ssd.md +++ b/docs/longhorn-second-ssd.md @@ -61,8 +61,10 @@ between them live. - [ ] Boot into the BIOS (F2): the NVMe drive shows up under storage, SATA operation stays AHCI, and the boot sequence still starts "ubuntu" from the SATA SSD. -- [ ] Boot. `lsblk` shows `nvme0n1`; wait until everything is green again - (gatus on s1 and s2). +- [ ] Boot. `lsblk` shows `nvme0n1`. +- [ ] Unseal Vault, which comes up sealed (until then ESO can't refresh + secrets): `for p in vault-0 vault-1 vault-2; do kubectl -n vault exec -ti $p -- vault operator unseal; done` +- [ ] Wait until everything is green again (gatus on s1 and s2). ## Prepare the disk (sudo on opti1) diff --git a/docs/roadmap.md b/docs/roadmap.md index d42b7e7..cb6e52d 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -87,15 +87,29 @@ April and May. auth.scoutingmbg.nl (immich's issuer), so find out first what the setting does with two hostnames -### 4. Vault 1.17.2 +### 4. Vault 1.17.2 → 2.2.1 -The server is pinned and out of support. It unseals with Shamir keys, so -after every reboot (the SSD install, for one) Vault stays sealed and ESO -stops refreshing secrets until someone unseals it. +Vault unseals with Shamir keys, so after every reboot (the SSD install, +for one) it stays sealed and ESO stops refreshing secrets until someone +unseals it. -- [ ] Make sure the unseal keys are kept outside this cluster -- [ ] Add unsealing to the SSD install steps -- [ ] Upgrade the server (needs the unseal keys) +- [x] Upgraded 2026-10-25, straight from 1.17.2 to 2.2.1. HashiCorp + doesn't require going through every release, and the change tracker + lists no breaking change that applies here: `disable_mlock` is set + (required for raft since 1.20), the chart sets `SKIP_SETCAP` and runs + Vault as uid 100 (2.0.1's IPC_LOCK requirement, dropped again in 2.0.2), + and ESO uses a token and KV v2. `tools/vault-roll.sh 2.2.1` restarted + the standbys first and the active node last, unsealing each; vault-1 + took over as active within seconds. Safety net: Longhorn snapshots + `vault-{0,1,2}-pre-2-2-1`. Afterwards all three ran 2.2.1 at the same + raft index, and all 24 ExternalSecrets refreshed after a force-sync + - The OIDC job called `vault auth tune -listing_visibility`, a flag that + doesn't exist, so the OIDC mount's listing visibility was never set. + Fixed; the job now uses the 2.2.1 CLI instead of 1.15 +- [ ] There is one unseal key (1 share, threshold 1). Keep it in two + places outside this cluster; without it the data in Vault is lost +- [x] Unsealing is in the SSD install steps +- [ ] After a week without problems: delete the three snapshots ### 5. Backups: which tool keeps what