docs(runbook): record §5 mail as complete, with the verification #391

Sammanfogat

supernaut sammanfogade 1 incheckning från docs/mail-domain-step5-closeout in i main

2026-08-05 21:09:11 +00:00

supernaut kommenterad

2026-08-05 21:07:59 +00:00

Ägare

Documentation only — no variable or template changes, so no apply.

The mail-domain move (#381) is applied and verified, but two places in the runbook still described it
as unblocked-but-unfinished:

the switchover register entry, which said "step 0 now PASSES; the move is unblocked but steps
1–3 are not done"
the §4 mail_sending_domain section, still headed 🛑 BLOCKED with "Sweego does not
authorise email.bitborg.se"

Both now record the outcome.

What is kept, and why

The §4 account of the failed first attempt is not deleted. The reusable part of that section is
the failure mode, not this migration's result — the next sending-domain move needs step 0 and the
"published DNS is not provider authorisation" lesson regardless of how this one ended. The mistaken
reading is marked as mistaken and points at the correction that already sits below it, rather than
being quietly removed.

Same reasoning for the four-step sequence: annotated as applied, but framed as the procedure for
any future move.

Added to the register

Step 3's apply made seven changed tasks against six predicted, the extra being the portal
restart --check cannot see — and that the delta was reconciled by task name.
The verification, with the controls rather than the bare passes: the portal's own sendEmail()
returning ok while a foreign allowlist is refused; SMTP rc=0 against rc=67 Login denied on a
wrong password; Alertmanager's loaded config read from /api/v2/status rather than the
template; six probes 1; only Watchdog; changed=0 on both hosts.
That delivery was confirmed received, not merely accepted with a 2xx.

Follow-ups filed rather than folded in

#388 — the cross-probe's From display name still reads gitborg monitoring; the address moved,
the name did not. It reaches a real mailbox during an incident.
#389 — nothing in automation detects a provider-side sending-domain or credential failure.
Step 0 remains a runbook step a human must remember, and it was skipped once already.
#390 — the seven service-account email addresses. Includes the ordering hazard that makes it
more than a declaration edit: create-user.yml is create-only, so editing the declaration alone
drifts it from the server while still reporting changed=0.

Documentation only — no variable or template changes, so no apply. The mail-domain move (#381) is applied and verified, but two places in the runbook still described it as unblocked-but-unfinished: - the **switchover register** entry, which said "step 0 now PASSES; the move is unblocked but steps 1–3 are not done" - the **§4 `mail_sending_domain`** section, still headed 🛑 **BLOCKED** with "Sweego does not authorise `email.bitborg.se`" Both now record the outcome. ## What is kept, and why The §4 account of the failed first attempt is **not** deleted. The reusable part of that section is the failure mode, not this migration's result — the next sending-domain move needs step 0 and the "published DNS is not provider authorisation" lesson regardless of how this one ended. The mistaken reading is marked as mistaken and points at the correction that already sits below it, rather than being quietly removed. Same reasoning for the four-step sequence: annotated as applied, but framed as **the procedure** for any future move. ## Added to the register - Step 3's apply made **seven** changed tasks against six predicted, the extra being the portal restart `--check` cannot see — and that the delta was reconciled **by task name**. - The verification, with the controls rather than the bare passes: the portal's own `sendEmail()` returning `ok` while a foreign allowlist is refused; SMTP `rc=0` against `rc=67 Login denied` on a wrong password; Alertmanager's **loaded** config read from `/api/v2/status` rather than the template; six probes `1`; only `Watchdog`; `changed=0` on both hosts. - That delivery was confirmed **received**, not merely accepted with a `2xx`. ## Follow-ups filed rather than folded in - **#388** — the cross-probe's From *display* name still reads `gitborg monitoring`; the address moved, the name did not. It reaches a real mailbox during an incident. - **#389** — nothing in automation detects a provider-side sending-domain or credential failure. Step 0 remains a runbook step a human must remember, and it was skipped once already. - **#390** — the seven service-account email addresses. Includes the ordering hazard that makes it more than a declaration edit: `create-user.yml` is create-only, so editing the declaration alone drifts it from the server while still reporting `changed=0`.

supernaut lade till 1 incheckning

2026-08-05 21:08:00 +00:00

docs(runbook): record §5 mail as complete, with the verification

ci / ci (pull_request) Successful in 17s

Detaljer

effa22289b

The register entry and the §4 mail section both still described the move
as unblocked-but-unfinished. Both now record it as done, and the §4
"Sweego does not authorise email.bitborg.se" reading is marked as the
mistaken one it turned out to be, pointing at the correction already
below it rather than deleting the account.

Keeps the four-step sequence and the step-0 traps as procedure for the
next move, not as a record of this one — the reusable part is the failure
mode, not the outcome.

Notes the seven-vs-six changed-task delta and that it was reconciled by
task name, and records the follow-ups filed instead of folded in
(#388 display name, #389 no provider-side detection, #390 service-account
addresses).

supernaut sammanfogade incheckning 3b3543e095 till main

2026-08-05 21:09:11 +00:00

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

2026-08-05 21:09:12 +00:00

docs(runbook): record §5 mail as complete, with the verification (#391)

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

2026-10-02 17:56:57 +00:00

docs(runbook): record §5 mail as complete, with the verification (#391)

Logga in för att delta i denna konversation.

Inga granskare