munin/internal/hilfe/seiten/plattform-admin.md

Der Ablauf für ein neues Team

1. Workspace wählen oder anlegen. Nach der Anmeldung landest du unter Workspaces. Ein Workspace ist gedacht für eine Abteilung. Beim ersten Start gibt es bereits den Workspace „Intern“.
2. Projekt anlegen unter Projekte → Verwalten…: Name, Bezeichner (erscheint in Adressen und in der MCP-Konfiguration) und optional eine Beschreibung.
3. Ersten Key anlegen: Im neuen Projekt unter Zugänge einen Key mit der Rolle admin für die verantwortliche Person erzeugen und ihr sicher übergeben.
4. Ab da verwaltet das Team sich selbst: Die verantwortliche Person legt weitere Keys für ihr Team und ihre Agenten an. Der Verweis auf diese Hilfe ({{SERVER}}/hilfe) reicht als Einstieg.

Soll eine Abteilung ihre Projekte selbst anlegen, reicht es, ihr einen Workspace-Admin einzurichten. Die Schritte 2 und 3 übernimmt dann sie.

Workspaces

Aktion	Wo
Anlegen, wählen	Workspaces in der Seitenleiste oder Klick auf den Namen oben in der Kopfleiste
Umbenennen, löschen	Workspaces → Bearbeiten

Der Name des gerade gewählten Workspace steht immer oben in der Kopfleiste. Alles, was du unter Projekte und Protokoll (alle) siehst, bezieht sich nur auf diesen Workspace.

Unter dem Namen steht blass, wo die Daten des Workspace liegen: mit SQLite die Datei (workspaces/<id>.db im Datenverzeichnis), mit PostgreSQL das Schema (munin_ws_<id>). Damit findest du einen Workspace in der Datenbank wieder, etwa für eine Sicherung oder in psql.

Löschen entfernt die Daten des Workspace (Datei bzw. Schema) mit allen Projekten, Einträgen und Keys. Zur Bestätigung muss der Name eingetippt werden. Rückgängig machen lässt sich das nur aus einer Sicherung.

Workspace-Admins

Ein Workspace-Admin legt im eigenen Workspace Projekte an, bearbeitet und löscht sie und verwaltet deren Zugänge, nur über die Weboberfläche. Was er genau darf und was nicht, steht unter Zugänge und Sicherheit. Für ihn gibt es eine eigene Hilfeseite, Für Workspace-Admins — gut zum Weitergeben zusammen mit dem Token.

Anlegen: Workspaces → Bearbeiten → Abschnitt Workspace-Admins. Den Namen der Person eintragen. Das Token (beginnt mit wa_) wird genau einmal angezeigt und muss der Person sicher übergeben werden. Mit ihm meldet sie sich an derselben Stelle an wie mit einem Key.

Zurückziehen: am selben Ort. Das Token gilt sofort nicht mehr, auch eine laufende Sitzung endet. Beim Löschen des Workspace verschwinden seine Workspace-Admins mit.

Ungenutzte Zugänge: Wie bei den Keys trägt ein aktiver Workspace-Admin, der seit über 90 Tagen nicht benutzt wurde, die Marke ungenutzt. Die Übersicht unter Workspaces zeigt je Workspace, wie viele Workspace-Admins aktiv sind und wie viele davon ungenutzt. Ein Klick auf die Marke führt zur Bearbeitungsseite. Ein vergessenes Token öffnet den ganzen Workspace, deshalb im Zweifel zurückziehen.

Anlegen und Zurückziehen erscheinen im Protokoll (alle) des betroffenen Workspace, ebenso jede Anmeldung eines Workspace-Admins.

Projekte

Unter Projekte → Verwalten… stehen alle Projekte des Workspace mit Eintragszahl und dem Stand ihres Schreibbudgets. Über Bearbeiten lassen sich Name, Beschreibung und die eigene Obergrenze fürs Schreibbudget ändern. Dort liegt auch das Löschen.

Das Schreibbudget kann nur der Plattform-Admin ändern, auch ein Workspace-Admin nicht. Sonst könnte ein Team die Grenze selbst aufheben, die gerade vor durchdrehenden Agenten schützen soll.

Protokoll über alle Projekte

Protokoll (alle) zeigt die Vorgänge aller Projekte des gewählten Workspace, auch das Anlegen und Löschen von Projekten. Gefiltert wird wie im Protokoll eines Projekts (siehe Zugänge und Sicherheit), zusätzlich nach Projekt.

Suche in allen Projekten

Suche (alle Projekte) in der Seitenleiste durchsucht alle Projekte des gewählten Workspace auf einmal, für die Frage „In welchem Projekt stand das nochmal?“. Die Treffer stehen nach Projekt gruppiert, je Projekt die besten fünf, das passendste Projekt oben. Über Weitere Treffer geht es zur Suche im jeweiligen Projekt.

Das können der Plattform-Admin und Workspace-Admins, denn beide sehen ohnehin alle Projekte. Am Zugriff der Keys ändert sich nichts: Ein Key und ein Agent sehen weiter genau ein Projekt.

System

System (nur Plattform-Admin) zeigt, ob etwas zu tun ist, wie Munin genutzt wird und worauf es läuft. Von oben nach unten:

• Zustand: alles, was Aufmerksamkeit braucht. Warnungen sollten behoben werden: die Verbindungen werden knapp (ab 80 % der höchstens möglichen Workspaces), PostgreSQL sortiert nicht nach C, die WAL-Datei eines Workspace wächst über 64 MB, der letzte Export ist fehlgeschlagen oder überfällig. Hinweise sind zur Kenntnis: Keys, die bald ablaufen oder seit 90 Tagen niemand benutzt hat (je Workspace genannt), oder Anfragen, die seit dem letzten Blick auf eine Datenbankverbindung warten mussten. Steht hier „Alles in Ordnung“, ist nichts zu tun.
• Aktivität der letzten 30 Tage: Schreibvorgänge und Suchen je Tag über alle Workspaces. Fährt man mit der Maus über einen Tag, erscheinen die genauen Zahlen; Als Tabelle zeigt alle. Darunter die aktivsten Projekte und die Projekte ganz ohne Aktivität. Wird so ein Projekt noch gebraucht, oder fehlt dem Team die Anbindung?
• Bestand je Workspace: Projekte, Einträge, ältere Fassungen, Papierkorb, gültige Keys und der belegte Platz in der Datenbank.
• Speicher und Verbindungen: SQLite oder PostgreSQL samt Ort (nie das Passwort), und ob die Datenbank antwortet, wie bei /ready. Dazu, wie viele Verbindungen gerade offen sind, für die Kontroll-Datenbank und jeden geöffneten Workspace. Mit PostgreSQL steht daneben das Budget: max_connections und die Zahl der Workspaces, die es höchstens erlaubt. Darüber startet Munin nicht und lehnt neue Workspaces ab. Gewartet zählt, wie oft eine Anfrage auf eine freie Verbindung warten musste. Ab und zu ist normal; wächst die Zahl stetig, sind die Pools zu klein.
• Programm: Fassung (aus Git, falls beim Bauen vorhanden), Go-Fassung, Startzeit, Schema-Stand und der letzte Markdown-Export.

Aktivität und Bestand zählt Munin höchstens alle 5 Minuten neu; daneben steht der Stand. Verbindungen und Zustand der Datenbank sind bei jedem Neuladen aktuell.

Was die Seite nicht zeigt: ob die Sicherung gelaufen ist. Die läuft außerhalb von Munin, siehe unten.

Für den gewählten Workspace gibt es außerdem Überblick (Workspace): genau die Seite, die ein Workspace-Admin sieht — was je Projekt zu tun ist, Projekte und Aktivität, ohne Technik. Einzelheiten unter Für Workspace-Admins.

Sicherung und Export

Die eigentliche Sicherung läuft außerhalb der Oberfläche über scripts/backup.sh. Das Skript sichert jeden Workspace einzeln (die Datei bzw. mit PostgreSQL das Schema), sodass sich auch eine einzelne Abteilung wiederherstellen lässt.

Ist auf dem Server ein Exportverzeichnis eingerichtet, schreibt Munin einmal täglich alle Einträge aller Workspaces als Markdown-Dateien dorthin, als zusätzliche, lesbare Sicherung, etwa für ein Git-Repository. Unter Projekte exportiert der Knopf Jetzt exportieren sofort den gerade gewählten Workspace, zum Beispiel vor einer größeren Änderung.

Ohne Exportverzeichnis und ohne Zugriff auf den Server geht es über den Download: Alle als ZIP herunterladen unter Projekte liefert alle Projekte des gewählten Workspace in einem Archiv, Als ZIP herunterladen über der Eintragsliste ein einzelnes Projekt. Beides dürfen auch Workspace-Admins. Jeder Download steht im Protokoll.

Zurück kommt ein Export über den Import im jeweiligen Projekt: das ZIP eines Projekts direkt hochladen, oder den Projektordner aus dem Exportverzeichnis als ZIP-Archiv packen und hochladen. So lässt sich auch ein einzelnes Projekt wiederherstellen, ohne die ganze Workspace-Datei zurückzuspielen.