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>
57 lines
2.7 KiB
Markdown
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` |
|