Thomas Stallinger
770c3a6c95
Ersetzt die reinen Marker-Datei-Platzhalter durch echte Anforderungen des Schulcomputer-Workspace: - guest-session: flüchtige Gastsitzung über lokalen gast-User + pam_namespace-tmpfs-Polyinstantiation, nopasswdlogin-Login. PAM-Layout wird über ansible_facts os_family erkannt (RedHat vs. Debian), da der Rollenname für beide Backends geteilt wird. - brave-fedora: Installation via Flatpak/Flathub, neue optionale standardbrowser-Option (tuxflotte_optionen) setzt/entfernt den System-Default in /etc/xdg/mimeapps.list, mit Firefox-Fallback. - onlyoffice-fedora: Installation via Flatpak/Flathub. site.yml reicht zusätzlich zu tuxflotte_auftrag_states auch tuxflotte_auftrag_optionen pro Rolle durch. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
58 lines
4.8 KiB
Markdown
58 lines
4.8 KiB
Markdown
# ansible-content
|
|
|
|
Ansible-Rollen, die der Tuxflotte Provisioning Agent per `ansible-pull` gegen installierte Geräte anwendet.
|
|
|
|
Rollennamen entsprechen 1:1 der Spalte `ansible_role` in der `blueprints`-Tabelle des Provisioning-Servers (siehe `provisioning-server/migrations/0005_seed_workspace_backend_blueprint_data.sql`).
|
|
|
|
`site.yml` bindet jede Rolle unter einem zu ihrem Namen passenden Tag ein. Der Agent ruft sie über:
|
|
|
|
```
|
|
ansible-pull -U <repo-url> --tags <rolle1>,<rolle2>,... -i localhost, site.yml
|
|
```
|
|
|
|
## Aktueller Stand
|
|
|
|
Alle drei Rollen haben echten Inhalt (Stand 2026-08-04) — die Marker-Dateien unter `/run/tuxflotte/agent/applied/<rolle>.marker` bleiben zusätzlich als schneller E2E-Nachweis bestehen, sind aber nicht mehr der eigentliche Effekt der Rollen:
|
|
|
|
- **`guest-session`**: echte flüchtige Gastsitzung. Lokaler User `gast`, Login ohne Passwort über die `nopasswdlogin`-Gruppenkonvention, `$HOME` per `pam_namespace`-Polyinstantiation (`/etc/security/namespace.conf`) als tmpfs — wird bei Sitzungsende automatisch verworfen, kein Cleanup-Skript nötig. PAM-Dateilayout unterscheidet sich zwischen RedHat- (`gdm-password`/`postlogin`) und Debian-Familie (`lightdm`/`common-session`) und wird über `ansible_facts['os_family']` erkannt, da derselbe Rollenname für beide Backends (`fedora`, `mint`) verwendet wird.
|
|
- **`brave-fedora`**: Installation von Brave via Flatpak/Flathub (`community.general.flatpak`). Unterstützt zusätzlich die Auftragskatalog-Option `standardbrowser` (siehe unten).
|
|
- **`onlyoffice-fedora`**: Installation von OnlyOffice Desktop Editors via Flatpak/Flathub.
|
|
|
|
**Neue Abhängigkeit:** die `community.general`-Collection (Module `flatpak`, `flatpak_remote`, `ini_file`). Auf der Zielplattform muss sie installiert sein — auf der bisherigen Test-VM (Linux Mint) bereits vorhanden (`ansible-collection-community-general`), auf frisch installierten Fedora-Geräten ggf. per `ansible-galaxy collection install community.general` oder passendes RPM-Paket sicherstellen.
|
|
|
|
## present/absent (Auftragskatalog, ADR-0010)
|
|
|
|
Merkmale, die für die geräteweise Ad-hoc-Zuweisung über den Auftragskatalog freigegeben sind (`merkmale.im_auftragskatalog = true`), können nicht nur zugewiesen, sondern auch wieder abgewählt werden — und das muss real etwas zurückbauen, nicht nur zukünftige Anwendung verhindern.
|
|
|
|
Dafür reicht der Agent bei jedem `ansible-pull`-Lauf eine Variable `tuxflotte_auftrag_states` durch (Rollenname → `"present"`/`"absent"`, aus der Check-in-Antwort `auftraege`), die `site.yml` pro Rolle als `tuxflotte_state` an die jeweilige Rolle weiterreicht. Rollen, die dort nicht auftauchen (zum Beispiel weil sie nur workspace-komponiert sind, nicht katalogfähig), laufen unverändert additiv über `--tags`, ohne `absent`-Zustand — siehe `tuxflotte_auftrag_states.get(<rolle>, 'present')` in `site.yml`.
|
|
|
|
Jede Rolle, die katalogfähig werden soll, muss deshalb ihre Tasks auf `tuxflotte_state` verzweigen:
|
|
|
|
```yaml
|
|
- name: <Merkmal anwenden>
|
|
...
|
|
when: tuxflotte_state == "present"
|
|
|
|
- name: <Merkmal zurückbauen>
|
|
...
|
|
when: tuxflotte_state == "absent"
|
|
```
|
|
|
|
`tuxflotte_state` hat in `roles/<name>/defaults/main.yml` den Default `present`, damit die Rolle auch bei direkter Verwendung ohne die `site.yml`-Verdrahtung nicht auf eine undefinierte Variable trifft.
|
|
|
|
Rollen, die nie katalogfähig werden (rein workspace-komponierte Merkmale), brauchen keinen `absent`-Zweig — das ist bewusst kein Zwang für alle Rollen, nur für die, die tatsächlich im Auftragskatalog landen.
|
|
|
|
## optionen (Auswahl-Parameter je Zuweisung)
|
|
|
|
Über die reine present/absent-Zuweisung hinaus kann eine Auftragskatalog-Zuweisung zusätzliche, rollenspezifische Optionen tragen (`device_merkmale.optionen`, JSONB) — z.B. `{"standardbrowser": true}` bei `browser-brave`. Der Server kennt die Bedeutung dieser Optionen nicht, reicht sie nur unverändert durch (Check-in-Antwort `auftraege[].optionen`).
|
|
|
|
Der Agent baut daraus `tuxflotte_auftrag_optionen` (Rollenname → optionen-Dict) als zweites `--extra-vars`-Feld neben `tuxflotte_auftrag_states`. `site.yml` reicht es pro Rolle als `tuxflotte_optionen` durch (Default `{}`, falls die Rolle nicht in der Map auftaucht). Nur Rollen, die tatsächlich Optionen brauchen, lesen die Variable (aktuell nur `brave-fedora`) — für alle anderen ist sie ungenutzt.
|
|
|
|
## Neue Rolle hinzufügen
|
|
|
|
1. `roles/<name>/tasks/main.yml` anlegen
|
|
2. `roles/<name>/defaults/main.yml` mit `tuxflotte_state: present` anlegen
|
|
3. Eintrag in `site.yml` mit `tags: <name>` und `vars: tuxflotte_state: "{{ tuxflotte_auftrag_states.get('<name>', 'present') }}"` ergänzen
|
|
4. Entsprechenden `ansible_role`-Wert in der `blueprints`-Tabelle referenzieren
|
|
5. Nur falls die Rolle katalogfähig werden soll (`im_auftragskatalog = true`): Tasks wie oben auf `tuxflotte_state` verzweigen, sonst reicht der additive Pfad ohne `when`
|