provisioning-agent/README.md
Thomas Stallinger 9799a3daa0 feat: apply and report Auftragskatalog state via ansible-pull
Extends the checkin/apply cycle to cover the "auftraege" list from the
check-in response (see ADR-0010) alongside the existing workspace
blueprints: both are merged into one ansible-pull invocation, with
--tags the union of all involved roles (a catalog role needs to run
even when its target state is absent, so its removal branch executes)
and a new --extra-vars payload (tuxflotte_auftrag_states, role ->
present/absent) that ansible-content's site.yml threads down into each
role.

After the pull, reports the outcome of each Auftragskatalog entry back
via the new POST /api/v1/agent/report endpoint (applied/apply_failed/
removed/remove_failed). This is intentionally coarse: ansible-pull has
one exit code for the whole run, not per-role results, so all entries
in a given run share that outcome. Workspace blueprints are not
reported on, matching ADR-0010's scope.

Verified end to end against anode and the QEMU test VM: selecting
browser-brave as a catalog entry produced an "applied" event and the
marker file; deselecting it removed the marker and produced a
"removed" event - both written by the agent's own report call, not
simulated.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-04 09:45:07 +02:00

57 lines
2.7 KiB
Markdown

# provisioning-agent
Der Tuxflotte Provisioning Agent läuft auf installierten Geräten, meldet sich in regelmäßigen Abständen bei `anode` und wendet die ihm zugewiesenen Ansible-Rollen per `ansible-pull` an (siehe `ansible-content/`).
**Stand:** Kernschleife (Check-in → ansible-pull) sowie Auftragskatalog (present/absent, Ergebnis-Report) laufen. Die Einrichtung vor dem ersten Reboot ist über `backend_postinstall()` im Fedora-Backend angebunden (`tuxflotte-installer/backends/fedora/kickstart.tpl`), ruft dabei denselben `POST /api/v1/agent/bootstrap`-Endpoint auf, der hier für die manuelle Testgerät-Einrichtung beschrieben ist.
## Auftragskatalog (ADR-0010)
Neben den additiv über den Workspace zugewiesenen Blueprints liefert der Check-in zusätzlich `auftraege`: den vollständigen present/absent-Zustand aller katalogfähigen Merkmale für das Gerät. Der Agent führt beide Listen in einem gemeinsamen `ansible-pull`-Lauf aus (`--tags` = Vereinigung aller Rollennamen, `--extra-vars` reicht `tuxflotte_auftrag_states` als Rolle→Zustand-Dict durch, siehe `ansible-content/README.md`) und meldet danach das Ergebnis je Auftragskatalog-Eintrag per `POST /api/v1/agent/report` zurück (`applied`/`apply_failed`/`removed`/`remove_failed`). Das Ergebnis ist grob granular — ein `ansible-pull`-Lauf hat einen einzigen Exit-Code für alle enthaltenen Rollen, es gibt noch keine Rolle-für-Rolle-Auswertung.
## Manuelle Installation (Testgerät)
Voraussetzung: `ansible-core` ist installiert (`ansible-pull` im PATH).
1. Gerät aktivieren und Bereitstellungsvorlage zuweisen (bestehender Provisioning-Flow, siehe `provisioning-server`)
2. Agent-Secret erzeugen:
```
curl -X POST https://anode.tuxflotte.de/api/v1/agent/bootstrap \
-H "Content-Type: application/json" \
-d '{"device_id": "<device-uuid>"}'
```
3. Credentials ablegen:
```
install -d -m 0700 /etc/tuxflotte
cat > /etc/tuxflotte/agent.credentials <<EOF
{"device_id": "<device-uuid>", "agent_secret": "<agent-secret aus Schritt 2>"}
EOF
chmod 0600 /etc/tuxflotte/agent.credentials
```
4. Agent-Code ablegen und Dienst einrichten:
```
install -d /opt/tuxflotte/agent
cp agent.py /opt/tuxflotte/agent/
cp tuxflotte-agent.service /etc/systemd/system/
systemctl daemon-reload
systemctl enable --now tuxflotte-agent
```
5. Prüfen:
```
journalctl -u tuxflotte-agent -f
ls /run/tuxflotte/agent/applied/
```
## Konfiguration
| Umgebungsvariable | Zweck | Default |
|---|---|---|
| `TUXFLOTTE_ANODE_URL` | Basis-URL des Provisioning-Servers | `https://anode.tuxflotte.de` |
| `TUXFLOTTE_AGENT_CREDENTIALS` | Pfad zur Credentials-Datei | `/etc/tuxflotte/agent.credentials` |