fix(token-audit): make token-audit.prom world-readable + group metric families (#75) #108

Sammanfogat

supernaut sammanfogade 1 incheckning från fix/token-audit-prom-readable in i main

2026-07-18 16:21:17 +00:00

supernaut kommenterad

2026-07-18 16:18:15 +00:00

Ägare

Hotfix for #96 (already applied to prod; landing on main so it isn't re-broken on the next apply).

Symptom

The token-audit ran clean (last_run_status=0) but its metrics never reached VictoriaMetrics — node_textfile_scrape_error{host=gitborg-prod}=1, so ForgejoTokenRotationDue was silently blind.

Root cause

The script wrote the file with mktemp (mode 0600) then mv'd it into place, so token-audit.prom was 0600 while every other textfile metric is 0644. node_exporter reads the textfile dir as a non-root user inside the rootless container and couldn't open the 0600 file (that's exactly what node_textfile_scrape_error reports — 'error opening or reading a file'). The backup/reconciler scripts avoid this by using plain > redirection (umask 0644).

Fix

chmod 0644 the temp file before mv (the actual fix).
Also group each metric family's samples contiguously (count block, then created-timestamp block) — correct per the Prometheus text exposition format and cleaner, though not the cause here.

Verified on prod (after apply)

File now 0644; node_textfile_scrape_error=0.
gitborg_forgejo_token_count / _created_timestamp_seconds present in VM for all 6 accounts; last_run_status=0.
ForgejoTokenRotationDue correctly quiet (newest token per account ~10–12 days, under the 80-day threshold).

Note

Both this and the caddy #102 bug are exactly the failure class a Tier-0/Tier-1 smoke test (bitborg-docs#37 → bitborg-infra#104) would catch — a check asserting node_textfile_scrape_error==0 and containers actually up. Reinforces the staging epic.

**Hotfix for #96** (already applied to prod; landing on `main` so it isn't re-broken on the next apply). ## Symptom The token-audit ran clean (`last_run_status=0`) but its metrics never reached VictoriaMetrics — `node_textfile_scrape_error{host=gitborg-prod}=1`, so `ForgejoTokenRotationDue` was silently blind. ## Root cause The script wrote the file with `mktemp` (mode **0600**) then `mv`'d it into place, so `token-audit.prom` was 0600 while every other textfile metric is 0644. node_exporter reads the textfile dir as a non-root user inside the rootless container and **couldn't open** the 0600 file (that's exactly what `node_textfile_scrape_error` reports — 'error opening or reading a file'). The backup/reconciler scripts avoid this by using plain `>` redirection (umask 0644). ## Fix - `chmod 0644` the temp file before `mv` (the actual fix). - Also group each metric family's samples contiguously (count block, then created-timestamp block) — correct per the Prometheus text exposition format and cleaner, though not the cause here. ## Verified on prod (after apply) - File now 0644; `node_textfile_scrape_error=0`. - `gitborg_forgejo_token_count` / `_created_timestamp_seconds` present in VM for all 6 accounts; `last_run_status=0`. - `ForgejoTokenRotationDue` correctly quiet (newest token per account ~10–12 days, under the 80-day threshold). ## Note Both this and the caddy #102 bug are exactly the failure class a Tier-0/Tier-1 smoke test (bitborg-docs#37 → bitborg-infra#104) would catch — a check asserting `node_textfile_scrape_error==0` and containers actually up. Reinforces the staging epic.

supernaut lade till 1 incheckning

2026-07-18 16:18:16 +00:00

fix(token-audit): make token-audit.prom world-readable + group metric families (#75 )

ci / ci (pull_request) Successful in 2m4s

Detaljer

c1dba5e117

The #96 audit ran clean but its metrics never reached VictoriaMetrics:
node_textfile_scrape_error=1 on gitborg-prod, so ForgejoTokenRotationDue
was silently blind.

Root cause: the script built the file with mktemp (mode 0600) then mv'd
it into place, so token-audit.prom was 0600 while every other textfile
metric is 0644. node_exporter reads the textfile dir as a non-root user
inside the rootless container and couldn't open the 0600 file. Fix:
chmod 0644 before mv, matching the umask-0644 the other textfile scripts
get from plain > redirection.

Also group each metric family's samples contiguously (count block, then
created-timestamp block) — required by the Prometheus text exposition
format and cleaner, though not the cause here.

Verified on prod after apply: file 0644, node_textfile_scrape_error=0,
gitborg_forgejo_token_count/created present in VM for all 6 accounts,
last_run_status=0, ForgejoTokenRotationDue quiet (newest token per
account ~10-12d, under the 80d threshold).

Both this and the caddy #102 bug are exactly the class a Tier-0/Tier-1
smoke test (gitborg-docs#37 / gitborg-infra#104) would catch.

supernaut refererade till denna ändringsförfrågan

2026-07-18 16:19:11 +00:00

chore(vault): add vault_forgejo_token_audit_token (#75) #109

supernaut sammanfogade incheckning 7ed97adece till main

2026-07-18 16:21:17 +00:00

supernaut tog bort grenen fix/token-audit-prom-readable

2026-07-18 16:21:17 +00:00

supernaut refererade denna ändringsförfrågan från en incheckning

2026-07-18 16:21:18 +00:00

fix(token-audit): make token-audit.prom world-readable + group metric families (#75) (#108)

supernaut refererade denna ändringsförfrågan från en incheckning

2026-07-18 16:23:15 +00:00