fix(ops-agent): setup.sh wist de hub-sudoers-regels bij elke run #145

Merged

janpeter merged 1 commit from fix/setup-wire-hub-module into main

2026-08-20 09:31:52 +02:00

janpeter commented

2026-08-20 09:15:26 +02:00

Owner

setup.sh installeert /etc/sudoers.d/ops-agent met een harde install uit de repo (regel 193), geen append. Elke per-waarde geënumereerde regel die een module-installer eerder toevoegde, verdwijnt daarmee. Voor network en docker-inspection is dat onschadelijk: setup.sh roept die installers er direct achteraan aan en ze zetten hun regels terug. install-hub-module.sh (nieuw in #143) is nooit ingehaakt, dus alleen de hub verliest zijn beleid — bij elke setup.sh-run opnieuw.

Waargenomen op srv

Na een setup.sh-run:

de zeven hub-regels weg (grep -c 'hub wrappers' /etc/sudoers.d/ops-agent → 0)
sudo -n … hub-hook-status.sh als ops-agent → "I'm sorry ops-agent. I'm afraid I can't do that"
hub_hook_status via /agent/v1/exec → exit 1
Instance.hub_snapshot_at voor srv bevroor 15 minuten

Waarom dit zo laat opvalt

Alles eromheen blijft er gezond uitzien:

signaal	staat
`last_seen_at`	vers — de hartslag zelf werkt gewoon door
`commands.yml`	compleet — de drie hub-keys staan er, alleen de sudo-policy is weg
`check-ops-agent-drift.sh`	groen — die vergelijkt `commands.yml` + flows, niet sudoers

Alleen hub_snapshot_at loopt niet meer, en dat ziet niemand tot iemand /settings/hub opent en de knoppen uit ziet staan.

De fix

Eén aanroep erbij, in exact de vorm van de andere twee en op dezelfde plek (ná de sudoers-install). Handmatig herstel met dezelfde installer werkt óók, maar regresseert bij de volgende run — dit haalt de terugkerende oorzaak weg.

De harness (test/control-room-foundation-harness.ts) bouwt een nep-repo met stubs voor precies de installers die setup.sh aanroept; zonder de derde stub valt setup.sh daar op een ontbrekend script. Die lijst gaat dus mee.

`setup.sh` installeert `/etc/sudoers.d/ops-agent` met een **harde `install`** uit de repo (regel 193), geen append. Elke per-waarde geënumereerde regel die een module-installer eerder toevoegde, verdwijnt daarmee. Voor network en docker-inspection is dat onschadelijk: setup.sh roept die installers er direct achteraan aan en ze zetten hun regels terug. `install-hub-module.sh` (nieuw in #143) is nooit ingehaakt, dus **alleen de hub verliest zijn beleid — bij elke setup.sh-run opnieuw.** ## Waargenomen op srv Na een `setup.sh`-run: - de zeven hub-regels weg (`grep -c 'hub wrappers' /etc/sudoers.d/ops-agent` → 0) - `sudo -n … hub-hook-status.sh` als ops-agent → *"I'm sorry ops-agent. I'm afraid I can't do that"* - `hub_hook_status` via `/agent/v1/exec` → **exit 1** - `Instance.hub_snapshot_at` voor srv bevroor 15 minuten ## Waarom dit zo laat opvalt Alles eromheen blijft er gezond uitzien: | signaal | staat | |---|---| | `last_seen_at` | vers — de hartslag zelf werkt gewoon door | | `commands.yml` | compleet — de drie hub-keys staan er, alleen de sudo-policy is weg | | `check-ops-agent-drift.sh` | **groen** — die vergelijkt `commands.yml` + flows, niet sudoers | Alleen `hub_snapshot_at` loopt niet meer, en dat ziet niemand tot iemand `/settings/hub` opent en de knoppen uit ziet staan. ## De fix Eén aanroep erbij, in exact de vorm van de andere twee en op dezelfde plek (ná de sudoers-install). Handmatig herstel met dezelfde installer werkt óók, maar regresseert bij de volgende run — dit haalt de terugkerende oorzaak weg. De harness (`test/control-room-foundation-harness.ts`) bouwt een nep-repo met stubs voor precies de installers die setup.sh aanroept; zonder de derde stub valt setup.sh daar op een ontbrekend script. Die lijst gaat dus mee.

janpeter added 1 commit

2026-08-20 09:15:27 +02:00

fix(ops-agent): setup.sh haalde de hub-sudoers-regels weg zonder ze terug te zetten

CI / Root app checks (pull_request) Successful in 5m44s

Details

CI / Ops-agent checks (pull_request) Successful in 15s

Details

CI / Deploy artifact checks (pull_request) Successful in 12s

Details

CI / Docker image build (pull_request) Successful in 1m17s

Details

6e5eb76398

setup.sh installeert /etc/sudoers.d/ops-agent met een harde `install` uit de
repo (regel 193) — geen append. Alle per-waarde geenumereerde regels die de
module-installers eerder toevoegden, verdwijnen daarmee. Voor network en
docker-inspection is dat onschadelijk: setup.sh roept die installers er direct
achteraan aan en ze zetten hun regels terug. install-hub-module.sh (nieuw in
#143) werd nooit ingehaakt, dus alleen de hub verloor zijn beleid.

Waargenomen op srv na een setup.sh-run: de zeven hub-regels weg, `sudo -n`
weigert de agent ("I'm sorry ops-agent"), `hub_hook_status` exit 1 en
hub_snapshot_at bevriest. Het verraderlijke is hoe gezond de rest oogt --
last_seen_at blijft vers, de drie hub-keys staan gewoon in commands.yml (alleen
de sudo-policy is weg) en check-ops-agent-drift.sh blijft groen, want die
vergelijkt commands.yml en flows, niet sudoers. Handmatig herstel met dezelfde
installer werkt, maar regresseert bij de volgende setup.sh-run.

De harness bouwt een nep-repo met stubs voor precies de installers die setup.sh
aanroept; zonder de derde stub zou setup.sh daar op een ontbrekend script vallen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>