Administrationshandbuch

Rollen

Zwei Rollen. Ein Mitglied hat, was die Buchstaben auf jedem Server geben (siehe Gruppen): r-- sieht, rw- arbeitet, rwx lässt Heinzel allein ändern; daneben liest ein Mitglied das Wissen und das Audit-Protokoll. Ein Administrator hat alles, einschließlich Benutzer, Einstellungen und jeden Server, was auch immer die Buchstaben sagen; der Deckel eines Servers begrenzt trotzdem, was Heinzel dort tut. Die zweite Freigabe unumkehrbarer Befehle ist ein benanntes Recht, das ein Mitglied auf der Rechteseite bekommt. Ein Mitglied belegt einen Platz.

Die Rollen früherer Versionen (Betrachter, Operator, Freigeber, von sich aus nichts) wirken weiter wie bisher: Ein Operator ist ein Mitglied, ein Freigeber ein Mitglied mit der zweiten Freigabe, ein Betrachter ein Mitglied, dem die Arbeitsrechte genommen sind. Angeboten werden sie nicht mehr; das Speichern einer Rolle ersetzt sie.

Benutzer laden Sie unter Benutzer ein. Sie erhalten einen Anmeldelink und richten danach Passwort oder zweiten Faktor ein. Das Deaktivieren eines Benutzers beendet seine Sitzungen.

Rechte einer Person

Unter Benutzer zeigt „Rechte“ jedes Recht als Satz mit drei Antworten: wie es steht, ja, nein. „Wie es steht“ ist, was Rolle und Buchstaben geben, und die Zeile sagt, was das ist. „Nein“ gewinnt gegen „Ja“. Die zehn Rechte, die aus den Buchstaben folgen, lassen sich hier nehmen, so dass jemand, der nach seinen Buchstaben auf Servern arbeitet, trotzdem nur schaut; die benannten Rechte lassen sich geben.

Die Seite sagt das Ergebnis vor dem Speichern in einem Satz, und ob es einen Platz belegt: Rechte zum Ansehen sind frei, jedes Recht zum Handeln belegt einen. Niemand ändert die eigenen Rechte, gibt mehr, als er hat, oder ändert jemanden, der mehr hat. Ein Administrator der Installation hat in jedem Mandanten jedes Recht; das lässt sich nicht einschränken. Eine geschlossene Seite nennt das fehlende Recht, und jeder findet die eigenen Rechte auf seiner Kontoseite.

Gruppen, und wer auf welchem Server was darf

Rechte werden geschrieben wie die einer Datei, in drei Buchstaben, die aufeinander aufbauen:

Eine Regel sagt, wer was darf: Was eine Person auf einem Server darf, ist der höchste Zugriff ihrer Teams auf die Gruppen, in denen der Server ist, und nie mehr als ein Deckel. Vier Wörter tragen sie.

• Ein Team ist eine Menge von Personen (Gruppen, Teams). Seine Verwalter nehmen Personen auf und hinaus, ernennen weitere Verwalter, benennen es um oder entfernen es; wer die Benutzer verwaltet, tut das bei jedem Team, und wer ein Team anlegt, verwaltet es. Ein Mitglied verlässt ein Team selbst und tritt nie selbst ein.
• Eine Servergruppe ist eine Menge von Servern (Gruppen, Servergruppen). Ihre Verwalter legen Server hinein und nehmen sie heraus, setzen Deckel und Wartungsfenster und sagen, welche Teams sie erreichen. Das Formular eines Servers bietet die Gruppen an, die sein Bearbeiter verwaltet. Mitgliedschaft über Tags gibt es nicht: Ein Server ist in einer Gruppe, weil ihn jemand hineingelegt hat.
• Ein Zugriff ist eine Zeile: ein Team, eine Servergruppe, Buchstaben. Ihn vergibt, wer diese Servergruppe verwaltet (auf der Seite der Gruppe oder auf der des Teams); einen Zugriff auf einen einzelnen Server auf der Serverseite und einen auf alle Server, die Grundregel, auf der Seite „Wer darf was“, wer die Benutzer verwaltet. Alle und alle Server sind auch Gruppen, also ist „alle arbeiten auf allen Servern“ eine Zeile, die Grundregel, mit der ein neuer Mandant beginnt (rw-), und eine Person auf einem Server ebenso eine Zeile. Jede Person und jeder Server ist eine Gruppe für sich, die Heinzel anlegt, so dass ein Einzelner genauso genannt wird: in einer Freigabe, in einer Modellfreigabe, als Besitzer oder Ziel eines Zeitplans.
• Ein Deckel ist das Höchste, was irgendjemand darf, Administratoren eingeschlossen: auf einem Server, auf einer Servergruppe, auf einem Zugang, und der der Installation für den Mandanten. Der niedrigste gilt. --- auf einem Server sperrt ihn für alle, r-- macht ihn zum Nur-Lese-Server; wer ihn sah, sieht ihn weiter, wie ls eine Datei zeigt, die niemand öffnen darf. Auf rwx hebt einen Deckel nur ein Administrator; wer den Server betreut oder die Gruppe verwaltet, senkt ihn.

Die Seite „Wer darf was“ (Gruppen) erklärt es für eine Person, Server für Server: die Buchstaben, die sie hat, über welches Team auf welche Gruppe, und welcher Deckel sie gehalten hat; wer die Benutzer verwaltet, wählt jede Person, alle anderen lesen ihre eigene. Darunter steht jeder Zugriff, den es gibt, mit der Seite, auf der er geändert wird. Die Seite eines Teams zeigt, was es erreicht und wer es verwaltet, die einer Gruppe, wer sie erreicht; die eines Servers den Deckel, die Gruppen, in denen er ist, und die Zugriffe, die ihn erreichen; die Rechteseite einer Person, was ihr allein gehört, neben dem, was über ihre Teams kommt. Die Serverliste markiert einen Server mit +, wenn ein Zugriff ihn oder eine seiner Gruppen nennt.

Wer einen Server anlegt, arbeitet darauf, über seine eigene Gruppe, wo er ihn sonst nicht erreichen würde. Wer nicht jeden Server sieht, verliert die Rechte, die über den ganzen Mandanten reichen (Benutzer, das Audit-Protokoll, das Wissen, Rollouts, alles unter „Verwalten“), weil sie sich nicht auf einige Server zuschneiden lassen; Server und Zeitpläne lassen sich das, also bleiben diese Rechte und gelten auf den erreichten Servern. Das Recht „über alle Gruppen hinweg handeln“, das Administratoren haben, hebt jede solche Grenze auf, aber keinen Deckel.

Eine Gruppe von Servern kann ein Wartungsfenster tragen: Wochentage, von und bis, in der Zeitzone des Mandanten, wenn nötig über Mitternacht. Außerhalb des Fensters liest Heinzel auf den Servern der Gruppe nur noch allein: Jeder Befehl, der etwas ändert, wartet auf eine Person (auf zwei, wo die Matrix es auf rw- verlangt), und ein geplanter Lauf überspringt, was er geändert hätte, und listet es unter „braucht einen Operator“. Ein Server in zwei Gruppen unterliegt dem Fenster jeder. Die Richtlinien-Prüfung auf der Befehle-Seite sagt, wenn ein Fenster einen Befehl zurückhält, und wer außerhalb des Fensters freigibt, setzt sich darüber hinweg, was das Audit-Protokoll zeigt. Eine Gruppe ohne Tage hat kein Fenster.

Wie viel Heinzel allein tut

Das x sagt es, und eine Session wählt darunter:

Es zählt das Niedrigste aus mehreren, bei jedem Befehl:

• Die Obergrenze des Mandanten (Installation, Mandanten, durch einen Administrator der Installation): rw- oder rwx. Niemand im Mandanten kommt darüber.
• Die Buchstaben der Person auf dem Server, begrenzt durch die Deckel des Servers, seiner Gruppen und seines Zugangs. Wer in mehreren Teams ist, bekommt die höchsten.
• Die Session: beim Start gewählt, bis zu dem, was die Person nutzen darf. „Jeder Befehl wartet“ ist nur eine Wahl der Session; von außen wird niemand darauf festgelegt, und ein Server, der vor dem Upgrade alles fragte, steht jetzt auf rw-: Lesen läuft allein, wie in unbeaufsichtigten Läufen schon immer.

Schreibt jemand in die Session eines Kollegen, gilt für diesen Durchgang die Stufe beider. Nur-Lese-Server, gesperrte Server und die Sperrliste bleiben von jeder Wahl unberührt. Was allein läuft, gibt niemand frei. Das x nur Personen und Servern geben, bei denen das gewollt ist.

Die Matrix: was eine Klasse auf einer Stufe tut

Was rw- und rwx genau bedeuten, steht in einer Tabelle unter Einstellungen, Richtlinie: eine Zeile je Risikoklasse (schreibend, Paket, Dienst, Firewall, Identität, Neustart, unumkehrbar), eine Spalte je Stufe, in jeder Zelle „läuft sofort“, „wartet auf eine Person“, „wartet auf zwei Personen“ oder „läuft nie“. Voreingestellt wartet auf rw- alles außer Lesen auf eine Person, Unumkehrbares und Identitäten auf zwei; auf rwx läuft alles sofort, Identitäten warten auf zwei. Eine Firma, bei der Neustarts nie durch Heinzel laufen und Firewall-Änderungen zwei Personen sehen, stellt das hier ein. Drei Zellen bewegt niemand: Lesen läuft, ein gesperrter Befehl läuft nie, eine Identität (ein Konto, ein Schlüssel, eine sudo-Zeile) wartet mindestens auf eine Person. Das Formular eines Servers stellt eine Zelle für diesen Server allein strenger, nie milder. Ein geplanter Lauf überspringt, was wartet; die zweite von zwei Personen ist ein Freigeber oder Administrator, der sich in den letzten fünf Minuten angemeldet hat.

Eine Änderung, die Heinzel aussperren könnte

Bevor Heinzel eine Adresse, eine Route oder die Firewall ändert, stellt es auf dem Server einen Timer, der nach zwei Minuten den alten Zustand zurückholt, im selben Befehl wie die Änderung. Den Timer zu stoppen ist ein Dienst-Befehl: Auf rwx entscheidet Heinzel das allein, darunter gibt ihn jemand rechtzeitig frei. In beiden Fällen geht er über einen neuen Login hinaus, nie über die offene Verbindung, die eine Firewall überlebt, die neue Logins schon abweist. Scheitert dieser Login, läuft der Timer ab, und der Server nimmt die Änderung selbst zurück. Nach einem Adresswechsel meldet sich Heinzel zuerst unter der neuen Adresse an und trägt sie selbst beim Server ein, wenn der Host dort den festgehaltenen Host-Key zeigt; das Audit-Log nennt das „Zur neuen Adresse gefolgt“. Ein Server, der unter einem Namen geführt wird, folgt stattdessen seinem DNS: Solange der DNS die neue Adresse nicht nennt, wird die Änderung zurückgerollt. Die Session sagt das auf dem Befehl, der den Timer stellt, und noch einmal auf einem gescheiterten Stopp.

Zeitpläne

Ein Zeitplan läuft, ohne dass jemand dabei ist, und kann deshalb niemanden fragen. Er nennt eine von zwei Stufen. rw- liest, egal was sonst eingestellt ist. rwx geht so weit, wie eine Session seines Besitzers auf diesem Server allein gehen dürfte: Es zählt das Niedrigste aus der Obergrenze des Mandanten, der Stufe des Besitzers und der Grenze des Servers, bei jedem Befehl neu. Wählen kann das nur, wer eine Session selbst allein ändern lassen darf, und wer Stufe, Aufgabe oder Modell ändert, wird Besitzer. Was ein Lauf nicht allein darf, wird übersprungen, im Bericht genannt und eine Woche auf der Freigaben-Seite aufbewahrt. Dort übernimmt es jemand in eine eigene Session. Nur-Lese-Server, gesperrte Server und die Sperrliste gelten auch für Zeitpläne.

Was ein Mandant selbst festlegt

Neben der Stufe hat ein Mandant vier Werkzeuge. Keines hebt die Sperrliste auf oder öffnet einen nur lesbaren Server.

Not-Aus (Einstellungen, Richtlinie, und ein Banner auf jeder Seite): Keine Session startet, kein Befehl läuft, kein Zeitplan feuert, und was läuft, wird abgebrochen. Er braucht einen Grund. Ein Administrator hebt ihn auf.

Sperrliste (Einstellungen, Befehle): Befehle, die hier nie laufen, auf allen Servern oder auf einigen, in Worten oder als regulärer Ausdruck. Eine Regel kann einen Befehl statt zu sperren auch höher einstufen („zählt als“): rm unter /srv/db als unumkehrbar, der Neustart der Datenbank als Neustart. Dann entscheidet die Matrix wie für diese Klasse. Nach unten stuft keine Regel; dafür gibt es die Dauerfreigabe mit ihrer exakten Zeile.

Dauerfreigaben (Einstellungen, Befehle): Befehle, die immer in Ordnung sind. Ein Eintrag ist eine exakte Zeile; ein Vorschlag, der ihr gleicht, läuft ohne Person und wird so protokolliert. Unumkehrbare Befehle sind nie abgedeckt.

„Einen Befehl gegen die Richtlinie prüfen“ in den Einstellungen zeigt, was all das für einen Befehl auf einem Server entscheidet, ohne ihn auszuführen.

Kontrolle im Nachhinein

Gegenzeichnen (Sessions): Eine beendete Session, in der ein ändernder Befehl ohne Freigabe lief, wartet auf die Gegenzeichnung von jemandem, der an ihr nicht beteiligt war. In einem neuen Mandanten ist das aus; schalten Sie es unter Einstellungen, Richtlinie ein, wenn ein Audit vier Augen bei jeder Änderung verlangt.

Zugriffsüberprüfung (Benutzer): wer fragt und freigibt, wer volle Autonomie hat, wer seit neunzig Tagen nicht angemeldet war, wer keinen zweiten Faktor hat. Ein Administrator bestätigt sie; die Seite sagt, wenn das ein Quartal her ist.

Änderungsnachweis (Session-Seite): eine Markdown-Datei mit dem, der gefragt hat, dem, der entschieden hat, dem Ausgang jedes Befehls und der Stelle seiner Einträge in der Audit-Kette.

Vorfallsentwurf (Session-Seite): dieselben Fakten als Zeitleiste, mit den Abschnitten, die ein Mensch schreiben muss (Auswirkung, Ursache, was zu ändern ist), als TODO markiert. Kein Modell schreibt ihn.

Zurückrollen (Session-Seite): Jeder ändernde Befehl wird mit einer Notiz vorgeschlagen, wie er zurückzunehmen ist; sie steht auf seiner Karte. Zurückrollen legt diese Notizen, die neueste zuerst, in die Aufgabe einer neuen Session, die ein Mensch liest und abschickt. Niemand hat die Notizen geprüft, deshalb macht der Knopf selbst nichts rückgängig: Jeder Schritt wird wie jeder andere Befehl vorgeschlagen und freigegeben.

Zusammenfassung (oben auf der Session-Seite): was die Session nach Heinzels Darstellung ergeben hat, als Änderungen, Prüfung, offene Punkte und Weg zurück. Sie ist die eigene Darstellung des Modells und nicht gegen das geprüft, was lief; der Nachweis ist der Änderungsnachweis. Zähler oben sagen, wie viel in jedem Teil steht, und ein leerer Teil nimmt darunter keinen Platz ein. Von einem Weg zurück ist nur die Rede, wo etwas geändert wurde. Offene Punkte kommen auf das To-do des Servers.

Die zweite Freigabe eines unumkehrbaren Befehls braucht eine Anmeldung, die höchstens fünf Minuten alt ist.

Mandanten

Ein Mandant ist ein Kunde, eine Abteilung oder eine Umgebung. Er hat eigene Server, SSH-Schlüssel, Sessions, Zeitpläne, ein eigenes Audit-Protokoll, einen eigenen Modellanbieter, eigene Richtlinien und Benachrichtigungen. Nichts davon ist aus einem anderen Mandanten sichtbar, weder für Menschen noch für den Agenten. Eine Installation beginnt mit einem Mandanten und braucht keinen zweiten; mit nur einem erwähnt die Oberfläche Mandanten nirgends außer auf der Seite Mandanten.

• Konten gehören zur Installation, Rollen zu einem Mandanten. Ein Mensch hat ein Konto (ein Passwort, einen Passkey, einen zweiten Faktor) und in jedem Mandanten, dem er angehört, eine Rolle. Wer mehrere Mandanten hat, landet nach der Anmeldung im zuletzt benutzten und wechselt oben in der Navigation.
• Ein Mandant je Tab. Ein Tab arbeitet in dem Mandanten, den seine Adresse nennt (/acme/servers). Mehrere Tabs arbeiten also nebeneinander in mehreren Mandanten. Ein Tab, der neu geladen wird oder nach einem Verbindungsabbruch zurückkommt, kommt in seinem Mandanten zurück, was immer die anderen Tabs getan haben: Ein halb ausgefülltes Formular wird nie in einen anderen mitgenommen. Bei mehreren Mandanten nennt der Titel des Tabs den Mandanten. Die erste Anfrage einer Anmeldung in einen anderen Mandanten steht in dessen Protokoll. Wird der Mandant einer Adresse für jemanden geschlossen, wählt er neu; nichts, was er gerade tun wollte, geschieht woanders. Eine geänderte Rolle in einem Mandanten lässt die Seiten eines anderen in Ruhe.
• Ein Konto je Browser. Die Tabs eines Browsers teilen sich die Anmeldung. Wer sich mit einem anderen Konto anmeldet, während eines angemeldet ist, wird mit „Melde dich erst ab“ abgewiesen. Für zwei Konten zugleich nehmen Sie ein zweites Browser-Profil oder ein privates Fenster.
• Administratoren der Installation legen Mandanten an, benennen sie um, schließen und löschen sie, pflegen die Tarife und ändern als Einzige, was mandantenübergreifend gilt: Anmelderegeln, Single Sign-on, die Lizenz, das Regelwerk, den Mailversand und das Konto eines anderen (Sperre, zweiter Faktor, Passkeys). All das liegt unter Installation (siehe unten), außerhalb jedes Mandanten. Sie sehen jeden Mandanten von außen (Tarif, Grenzen, Nutzung, Administratoren) und betreten nur die, in denen sie Mitglied sind, mit der Rolle, die sie dort haben, und eingeschränkt wie jeder andere. Das erste Konto einer Installation ist einer; weitere ernennen sie unter Installation, Konten. Das Betreten eines Mandanten steht in dessen Audit-Protokoll.
• Ein neuer Mandant nennt die Adresse seiner ersten Admin-Person. Sie wird per Mail eingeladen wie bei jeder Einladung und hat jedes Recht im Mandanten, sobald sie zusagt; danach legt sie ihre Leute, Server und ihren Modellanbieter selbst an. Wer den Mandanten angelegt hat, bleibt draußen. Eine weitere Admin-Person lädt man genauso unter Installation, Mandanten, Bearbeiten ein.
• Tarife (Installation, Tarife) sind Vorlagen für die Grenzen eines Mandanten: Plätze, Server und wie weit Heinzel allein gehen darf. Wer einem Mandanten einen Tarif gibt, füllt damit seine Grenzen aus; danach lassen sie sich für diesen Mandanten allein ändern, und die Liste zeigt ihn als „angepasst“. Ein geänderter oder entfernter Tarif lässt die Grenzen seiner Mandanten, wie sie sind. Bezahlung gehört nicht dazu.
• Der Administrator eines Mandanten verwaltet dessen Mitglieder und ihre Rollen, Server, Schlüssel und Einstellungen, außer den Adressen, die der Server aufruft (Basis-URL des Modells, Webhook); die legt ein Administrator der Installation fest. Entfernen nimmt ein Mitglied aus dem Mandanten und lässt das Konto unberührt.
• Einladungen brauchen ein Ja. Wer eine Adresse einlädt, schickt dem Menschen eine Mail: einen Anmeldelink für ein neues Konto, einen Hinweis für jemanden, der schon eines hat. Nach der Anmeldung nimmt er an oder lehnt ab, auf der Seite, auf der er landet, oder unter Mandant wechseln. Bis dahin zeigt die Mitgliederliste die Adresse als eingeladen und nichts vom Konto.
• Ein geschlossener Mandant behält seine Daten, lässt niemanden hinein und seine Zeitpläne ruhen; Schließen lässt sich rückgängig machen. Löschen geht nur bei einem geschlossenen Mandanten und verlangt, dass man seine Adresse eintippt: Alles darin ist dann weg, auch sein Audit-Protokoll, Konten und andere Mandanten bleiben. Jeder Mandant hat eine eigene Audit-Kette, die übrigen lassen sich also weiter prüfen; das Löschen selbst steht im Protokoll der Installation. Die Arbeit läuft im Hintergrund und setzt nach einem Neustart von selbst wieder ein.
• Plätze zählen pro Konto für die ganze Installation: Wer in drei Mandanten arbeitet, belegt einen Platz. Eine Einladung belegt ihren Platz erst mit der Annahme; ist dann keiner frei, wird die Person an einen Administrator verwiesen. Alle Mandanten schöpfen aus dem einen Kontingent der Lizenz.
• Plätze pro Mandant: Ein Administrator der Installation kann einem Mandanten eine Zahl von Plätzen geben, die er nutzen darf (Mandanten, Bearbeiten). Die Administratoren des Mandanten sehen die Belegung auf der Seite Benutzer und werden mit Nennung der Grenze abgewiesen, wenn eine Rolle, ein Recht zum Handeln oder eine angenommene Einladung sie überschritte. Diese Grenze zählt, wer in diesem Mandanten handelt: Wer in zwei Mandanten handelt, belegt in jedem einen Platz und in der Lizenz einen. Ohne Zahl gilt für einen Mandanten allein die Gesamtzahl der Lizenz, die ohnehin über allen Mandanten steht. Eine Grenze unter der aktuellen Belegung nimmt niemandem etwas: Die Seite Mandanten zeigt die Zeile rot, und bis es wieder passt, kommt niemand weiteres hinein.
• Server pro Mandant: Daneben steht die Zahl der Server, die ein Mandant anlegen darf. Das Formular Server weist mit Nennung der Grenze ab, wenn sie voll ist; ein entfernter Server macht seinen Platz frei. Ohne Zahl zählt allein die Gesamtzahl der Lizenz. Eine Grenze unter der aktuellen Zahl entfernt keinen Server. Das Formular zeigt darunter, was die Lizenz der ganzen Installation an Plätzen und Servern erlaubt.
• Single Sign-on: Mit einem Mandanten tritt ein neues Konto ihm mit der Standardrolle bei. Mit mehreren tritt es keinem bei und wartet auf einen Administrator.

Ausgesperrt

Wenn niemand Mail empfangen kann, erzeugt ein Operator mit Shell-Zugang auf dem Host einen Anmeldelink für jedes Konto:

$ docker compose exec app bin/login-link admin@example.com

Der Link gilt einmal und 15 Minuten. Öffnen, dann unter Konto Passwort oder zweiten Faktor einrichten.

Passkeys legt jeder Benutzer selbst unter Konto an. Geht ein Gerät mit Passkey verloren, löscht „Passkeys entfernen“ auf der Benutzerseite die Passkeys dieses Benutzers; er meldet sich mit Passwort oder Anmeldelink an und legt einen neuen an.

Installation

Die Seiten der Installation stehen außerhalb jedes Mandanten unter /installation, hinter dem Eintrag Installation unten in der Navigation. Nur Administratoren der Installation sehen den Eintrag und öffnen die Seiten, mit oder ohne eigenen Mandanten; der Weg zurück in den Mandanten, aus dem sie kamen, steht oben. Die Seiten: Mandanten (anlegen, bearbeiten, schließen, löschen, mit dem Not-Aus der Installation), Tarife, Konten (alle, die sich anmelden können, mit ihren Mandanten; ein Konto sperren, zweiten Faktor oder Passkeys zurücksetzen, einen Anmeldelink schicken, zum Administrator der Installation machen, und eine Person in einen Mandanten setzen oder herausnehmen, wenn dessen eigene Administratoren es nicht können, etwa weil der einzige ausgesperrt ist), Mailversand, Einstellungen (Anmeldung, Lizenz, Regelwerk) und Protokoll (die eigene Audit-Kette der Installation: Anmeldungen, Konten, Mandanten; und ob die Installation läuft: Version, Lizenz, Mail, Migrationen, Hintergrundjobs). Eine Installation mit einem Mandanten hat dieselben Seiten und braucht sie selten.

Einstellungen

Die Einstellungen sind Seiten mit einer Navigation daneben, sieben für den Mandanten. Anmeldung, Lizenz und Regelwerk gehören der Installation und liegen unter Installation, Einstellungen.

Allgemein: Name der Organisation, Sprache für System-Mails, Zeitzone (die Uhr, nach der Zeitpläne laufen und Zeiten gezeigt werden), Aufbewahrung.

Richtlinie: Freigabemodus, die Matrix (was eine Klasse auf einer Stufe tut), nach wie vielen Minuten eine wartende Freigabe eskaliert wird, was neue Sessions für alle sind, Links für Personen ohne Konto, Bereinigung der Ausgaben, Zeitlimit für Befehle und das längste Zeitlimit, das Heinzel für einen einzelnen Befehl anfragen darf (ein Paket-Upgrade). Der Not-Aus steht auf dieser Seite, und die Fähigkeiten unten auch.

Fähigkeiten

Das offene Regelwerk Heinzel (ab Version 3.0) liest Partitionstabellen, Bootloader, Benutzerkonten und Secrets und ändert nichts davon: das ist die Arbeit von Heinzel Pro, und sie wird je Mandant auf der Richtlinien-Seite eingeschaltet.

• Identität: Benutzerkonten, SSH-Schlüssel und sudo-Rechte anlegen und ändern. Von Anfang an an. Ein solcher Befehl hat die Klasse „Identität“: er wartet auf jeder Stufe auf eine Person, auf zwei, wo unumkehrbare Befehle es tun, und läuft nie unbeaufsichtigt. Ein Konto löschen oder ein Passwort ändern bleibt unumkehrbar.
• Secrets und Zertifikate: ein Secret rotieren, nachdem jeder Verbraucher gefunden ist, Zertifikate über die Flotte beobachten und erneuern. Von Anfang an an; aus für einen Mandanten, der Secrets einem Vault überlässt.
• Partitionieren: Partitionstabellen schreiben. Von Anfang an aus.
• OS-Austausch: Dateisysteme anlegen, Platten roh beschreiben, Bootloader und EFI-Einträge ändern. Von Anfang an aus.

Rollouts, Zeitpläne, der Fleet-Audit, OS-Upgrades in Wellen, die Versionsmatrix und Wartungsfenster brauchen keinen Schalter: Sie gehören der Laufzeit, und ihre Regeln stehen immer in der Liste des Agenten.

Ein Schalter tut drei Dinge zugleich: Die Regeldateien für die Arbeit (priv/rules_pro, auf der Regeln-Seite mit ihrer Fähigkeit gezeigt) kommen in die Anweisungen des Agenten, der Classifier lässt die Befehle als unumkehrbar durch, und die Richtlinie verlangt die Freigaben. Ist die Fähigkeit aus, werden dieselben Befehle mit einem Grund abgelehnt, der den Schalter nennt, und der Agent soll lesen und berichten. Das Formular eines Servers schaltet eine Fähigkeit für diesen Server wieder aus, sodass ein Datenbank-Host nie partitioniert wird, wie der Mandant auch eingestellt ist. Rollouts, Zeitpläne und der Fleet-Audit brauchen keinen Schalter. Jede Änderung steht im Audit-Protokoll und in der Richtlinien-Datei.

Die Kopie des offenen Regelwerks, die ein Image mitbringt, ist eine getaggte Version (priv/rules/VERSION und SOURCE sagen welche); ein neuerer Tag derselben Hauptversion wird stündlich von selbst übernommen, eine neue Hauptversion unter Installation, Einstellungen, Regelwerk, beides ohne neues Image (upgrade.md, „Regelwerk“).

Eigene Regeln

Unter Regeln, „Ihre eigenen Regeln“ steht, was die Organisation dem Regelwerk hinzufügt, in der Form, in der Heinzel es in einem Checkout hält: ein Text je Regel oder all für jede Regel, für alle Server des Mandanten oder für einen Server. Überschriften sagen, was ein Abschnitt tut: ## Add: ergänzt, ## Replace: ersetzt den genannten Abschnitt der Regel, ## Remove: streicht ihn; eine Überschrift ohne Präfix ergänzt. Das Spätere gewinnt, wie in Heinzel: das Regelwerk, dann der Text für alle Server, dann der eigene des Servers. Die all-Texte kommen in die Anweisungen jeder Session, unter die Regeln und über die Wissensnotizen; die eigenen Abschnitte einer Regel folgen der Regel, wenn der Agent sie liest.

Einige Regeln nehmen nur Ergänzungen an: die Verbindungspipeline, die Anomalie-Erkennung, die Secrets-Hygiene und jede Regel von Heinzel Pro selbst, die das Manifest nicht als überschreibbar markiert. Die Ethik-Regel nimmt nichts an. Ein abgelehnter Abschnitt bleibt mit seinem Grund im Formular stehen und wird ins Audit-Protokoll geschrieben; nichts fällt stillschweigend weg. Die Texte schreibt, wer die Richtlinie gestalten darf; lesen darf sie jedes Mitglied.

Ein Team, das von Heinzel kommt, importiert seinen Checkout: die Dateien aus memory/custom-rules (all.md, eine je Regel) und die rules.md, memory.md und todo.md eines Servers (Gedächtnis und To-do-Liste landen im Server), so hochgeladen, wie sie sind, mit einer Vorschau, was übernommen und was übersprungen wird (eine Datei, die nach keiner Regel des benutzten Regelwerks heißt, oder eine mit einem abgelehnten Abschnitt). HEINZEL_RULES_DIR bleibt die Stufe der Installation: ein eingehängtes Verzeichnis ersetzt das öffentliche Regelwerk für alle Mandanten, und die Texte hier liegen darüber wie über einer Version.

Befehle: die Sperrliste, die Dauerfreigaben und ein Formular, das sagt, was die Richtlinie mit einem Befehl täte.

Anmeldung (Installation, Einstellungen): Passwortanmeldung, 2FA-Pflicht, Abmelden nach Untätigkeit, Single Sign-on.

Modellanbieter: Ein Anbieter ist ein Konto bei einem Hersteller oder ein Server im eigenen Netz: ein Name, Anthropic oder OpenAI-kompatibel, der Schlüssel und, für einen Administrator der Installation, die Basis-URL. Er bietet so viele seiner Modelle an, wie Sie ankreuzen. Typisch ist ein Anthropic-Konto mit drei Modellen: ein ausgewogenes für alle, das stärkste fürs erfahrene Team, das schnellste für Kleinigkeiten. Den Anbieter einmal anlegen, die Modelle ankreuzen, die Heinzel Pro kennt, oder andere IDs eintippen, und testen. Der Schlüssel steht an einer Stelle, und eine Änderung erreicht jedes Modell des Anbieters; ein leeres Schlüsselfeld behält den gespeicherten Schlüssel. Die erweiterten Optionen decken Anthropic Thinking und Effort, OpenAI Reasoning-Effort und Kompatibilitätsschalter für Azure und ältere Server ab.

Jedes Modell hat dann eine eigene Seite für das, was man sieht und darf: seinen Namen, die Aufwand-Stufen, die es anbietet, seine Preise und wer es nutzen darf. Wer eine Session startet, wählt unter den Modellen, die ihm offenstehen. Ein Anbieter behält seine Art; ein zweiter Hersteller, oder der EU-Endpunkt desselben Herstellers, ist ein zweiter Anbieter.

• Wer es nutzen darf. Ein Modell steht jedem Mitglied des Mandanten offen oder ist auf die angekreuzten Gruppen und Personen eingeschränkt. Ein kleines Team lässt alles offen und sieht davon nichts. Administratoren werden gefragt wie alle anderen.
• Ein stärkeres Modell (im Formular des Modells): Starten Sie Sessions auf einem günstigen Modell und nennen Sie das, an das eine Session übergeben werden kann. Der Agent übergibt, wenn sich die Aufgabe als schwer erweist, und ebenso jeder, der in der Session schreiben darf. Es geht in eine Richtung, das Audit-Protokoll hält fest, wer es wollte und warum, und die Session-Seite zeigt, wie viele Tokens jedes Modell verbraucht hat.
• Ein Ersatzmodell (im Formular des Modells): das Modell, das einen Schritt beantwortet, wenn der Anbieter dieses Modells überlastet ist oder nicht antwortet, nach den üblichen Wiederholungen. Es wird nur für Personen benutzt, die es ebenfalls benutzen dürfen; Session und Audit-Protokoll halten es fest, und der nächste Schritt fragt wieder das erste Modell.
• Gruppen (Administration, Gruppen) sind benannte Mengen von Mitgliedern, etwa ein Team. Wer nach Gruppe freigibt, gibt einem Neuen die richtigen Modelle, indem er ihn in die Gruppe aufnimmt; eine namentlich angekreuzte Person bekommt die Freigabe über ihre eigene Gruppe.
• Aufwand. Die Stufen ankreuzen, die das Modell annimmt; keine ankreuzen für einen Server, der die Einstellung ablehnt. Dann festlegen, wer wie weit gehen darf: jedes Mitglied bis zu einer Stufe, Gruppen oder Personen weiter. Wer eine Session startet, wählt aus dem, was er nutzen darf, oder belässt es bei Standard (wie der Anbieter unter Erweiterte Optionen eingestellt ist). Der Wert geht als effort an Anthropic und als reasoning_effort an OpenAI-kompatible Server. Zeitpläne laufen mit Standard.
• Modellkatalog. Das Modellfeld bietet die Modelle an, die Heinzel Pro kennt; die Auswahl füllt Name und Aufwand-Stufen aus. Jede andere ID lässt sich eintippen. Ein neuerer, vom Hersteller signierter Katalog wird von einem Administrator der Installation am Fuß von Einstellungen, Modellanbieter eingefügt; mit jedem Release kommt ohnehin einer mit. Heinzel Pro holt ihn nie selbst.
• Ein Modell, das der Anbieter abschaltet. Anbieter schalten Modelle mit Wochen Vorlauf ab, per Mail und auf ihren Webseiten, nie über die API; Anfragen an ein abgeschaltetes Modell schlagen fehl. Der Katalog trägt diese Termine. Ein Modell auf dem Weg hinaus ist unter Modellanbieter und auf dem Dashboard markiert, mit Tag und Nachfolger, und ein Klick stellt es um: ID, Aufwand-Stufen und der Katalogname wechseln, wer es nutzen darf, wo es vorgeschrieben ist, sein Ersatz und sein Platz als Standard bleiben. Seine Preise werden gelöscht, der Nachfolger kostet etwas anderes. Die Meldung „Ein Modell wird vom Anbieter abgeschaltet“ geht bei der Ankündigung hinaus, zwei Wochen vor dem Tag und wenn er da ist. Eine Session, die auf ein abgeschaltetes Modell trifft, schlägt fehl und sagt es; nach der Umstellung geht es in einer neuen Session weiter. Nichts stellt sich von selbst um: ein für einen Server vorgeschriebenes Modell ist ein Versprechen, wohin seine Ausgaben gehen.
• Standard. Ein Anbieter ist der Standard. Wer mehrere nutzen darf, wählt beim Start einer Session; bei nur einem erscheint keine Auswahl. Ein Zeitplan nennt einen Anbieter oder nimmt den Standard zum Zeitpunkt des Laufs.
• Eine Session behält ihren Anbieter. Der Zugriff wird bei jeder Nachricht und vor jedem Modellaufruf geprüft. Wird der Anbieter ausgeschaltet oder entfernt oder der Zugriff entzogen, endet die Session dort; kein anderes Modell springt stillschweigend ein.
• Ein Zeitplan läuft im Namen der Person, die zuletzt Aufgabe, Modell oder Stufe geändert hat, auf einem Anbieter, den diese Person nutzen darf. Welche Gruppe ihn ändern darf, ist eine andere Frage, siehe Zeitpläne.
• Ein entferntes Mitglied verlässt jede Gruppe und Freigabe des Mandanten, die eigene Gruppe eingeschlossen. Ein Administrator der Installation, der kein Mitglied des Mandanten ist, kann keinen eingeschränkten Anbieter freigegeben bekommen; dazu erst als Mitglied aufnehmen.
• Preise (optional). Eintragen, was pro Million Tokens gezahlt wird: Eingabe, Ausgabe, gecachte Eingabe lesen, Cache schreiben, dazu die Währung. Jeder Modellaufruf wird dann im Moment des Aufrufs zu den damaligen Preisen bepreist, und Sessions zeigen ihr Modell und ihre Kosten. Anbieter liefern Token-Zahlen, keine Preise; ohne eigene Preise wird deshalb keiner angezeigt und nichts geschätzt. Eine Session zeigt nur dann Kosten, wenn sich jeder seiner Aufrufe bepreisen ließ; Aufrufe vor 2.1 lassen sich nicht bepreisen, weil gecachte und frische Eingabe damals nicht getrennt erfasst wurden. Steuern, Rabatte und die Rundung der Anbieterrechnung stecken nicht in der Zahl.
• Prompt-Caching ist standardmäßig an (Einstellungen, Sessions). Der Anbieter behält dann Anweisungen und Verlauf einer Session zwischen den Schritten in seinem Cache; ein Schritt zahlt den vollen Preis nur für das Neue und für den Rest den Cache-Preis. Anthropic macht das; andere Anbieter cachen nach eigenem Ermessen. Was sich von Schritt zu Schritt ändert, etwa das Gedächtnis eines Hosts, wird getrennt vom Gleichbleibenden geschickt, damit der gecachte Teil erhalten bleibt.

Internes Modell im eigenen Netz: OpenAI-kompatibel wählen, die Basis-URL des eigenen Servers eintragen (Ollama http://ollama.intranet:11434/v1, vLLM oder LM Studio http://host:8000/v1, LocalAI) sowie den Modellnamen, den er ausliefert, und den Schlüssel leer lassen, wenn der Server keine Authentifizierung hat. Dann verlässt nichts das Netz; der Container muss nur diesen Host erreichen. Modelle mit Tool-Calling funktionieren am besten (bei Ollama ein Modell, dessen Karte „tools“ nennt).

Erreicht der Container diesen Host nicht direkt, wählen Sie unter „Erreichbar über“ eine Ihrer VPN-Verbindungen oder einen Ihrer Server. Die Adresse wird dann in Ihrem Netz gewählt: über eine VPN-Verbindung ein Name in Ihrem Tailnet oder LAN (LM Studio auf einem Laptop, http://macbook:1234/v1), über einen Server eine Adresse aus dessen Sicht, http://localhost:11434/v1 ist also ein Ollama, das nur auf dem Server selbst lauscht. Der Server leitet den Port per SSH weiter, als sein erster Zugang ohne sudo; sshd muss das erlauben (AllowTcpForwarding, von Haus aus an). Auf einer gehosteten Installation darf ein Administrator des Mandanten die Adresse nur so setzen.

Die Richtlinie als Datei (Einstellungen, Richtlinie als Datei): wie viel Heinzel von sich aus tut, das Vier-Augen-Prinzip, das Teilen, Zeitlimits, die Sperrliste und die Dauerfreigaben als eine JSON-Datei mit einem SHA-256 über ihren Inhalt. Fügen Sie eine Datei ein, um sie mit dem Eingestellten zu vergleichen; das Anwenden macht die Richtlinie des Mandanten gleich der Datei und wird mit dem Hash festgehalten. Regeln für einen Server nennen ihn beim Hostnamen. Einstellungen je Server, Adressen und Geheimnisse stehen nicht in der Datei.

Alarme: eine Liste von E-Mail-Adressen und ein optionaler Webhook (Slack, Teams, Mattermost oder generisches JSON). Wählen Sie, welche Ereignisse alarmieren: Freigabe nötig, Befehl fehlgeschlagen oder abgelehnt, Host-Key geändert, geplanter Lauf beendet, wiederholt fehlgeschlagene Anmeldungen, Benutzer angelegt, eine zu lange wartende Freigabe und eine Wochenmail mit dem, was liegen geblieben ist. Ereignisse, die ein Upgrade mitbringt, sind aus, bis Sie sie einschalten. Für Teams den Webhook mit Workflows anlegen („Bei Eingang einer Webhookanforderung in einem Kanal posten“); die älteren Office-365-Connectors sind abgekündigt und nehmen diese Karten nicht an.

Alarme aus dem Monitoring (Einstellungen, Anbindungen): Erzeugen Sie ein Token und lassen Sie das Monitoring damit als Bearer-Token an /api/alerts/<mandant> senden. Der Webhook von Alertmanager wird angenommen, wie er ist; jedes andere System sendet JSON mit host, title und text. Ein Alarm, dessen Host einer der Server des Mandanten ist, startet dort eine Session, die nur liest und Ursache und Lösungsvorschlag berichtet; die Antwort auf den Aufruf enthält die Adresse der Session. Derselbe Alarm findet innerhalb einer Stunde seine Session, und höchstens zwanzig Sessions starten pro Stunde. Die Sessions laufen im Namen dessen, der das Token erzeugt hat.

Dieselbe Seite markiert Änderungen im Monitoring: Mit einem Endpunkt, der Annotationen annimmt wie die API von Grafana (https://…/api/annotations, ein Service-Account-Token), erscheint jeder ausgeführte Befehl oberhalb von Lesen in den Graphen, mit Host, Befehl, Freigebendem und Ausgang.

Dieselbe Seite verschickt das Audit-Protokoll: Ein Administrator der Installation gibt einem Mandanten einen HTTPS-Endpunkt und optional ein Bearer-Token, und jedes Audit-Ereignis dieses Mandanten geht innerhalb einer Minute als eine Zeile JSON dorthin, mit Position und Hash in der Kette. Was der Endpunkt nicht annimmt, bleibt geschuldet. Ein Ereignis enthält, was das Audit-Protokoll zeigt, den Text von Befehlen eingeschlossen.

Single Sign-on (Installation, Einstellungen, Anmeldung): jeder OpenID-Connect-Issuer. Redirect-URI ist <Basis-URL>/auth/oidc/callback. Neue SSO-Benutzer erhalten die Standardrolle; eine Domain-Liste begrenzt, wer sich anmelden darf.

Lizenz (Installation, Einstellungen): Schlüssel einfügen. Testphase, Kulanzfrist und Platzbelegung werden angezeigt.

Server

Server mit Hostname, Port und erstem Zugang (SSH-Benutzer) anlegen und seinen Deckel setzen, das Höchste, was irgendjemand dort darf, in den Buchstaben einer Datei (siehe Gruppen): --- sperrt ihn, r-- macht ihn zum Nur-Lese-Server, rw- lässt arbeiten, wobei Heinzel vor jeder Änderung fragt, rwx lässt Heinzel allein ändern, was nur ein Administrator einschaltet. Wer den Server unter dem Deckel erreicht, sagen die Zugriffe der Teams auf die Gruppen, in denen er ist; wer einen Server anlegt, arbeitet darauf.

Ein Server trägt außerdem Tags, Wörter oder schlüssel:wert wie env:prod role:db. Die Serverliste filtert danach, und mehrere Tags grenzen auf die Hosts ein, die alle tragen. Sperrregeln und Dauerfreigaben gelten für jeden Server oder für einen, nicht nach Tags.

Befunde (Navigation): was ein geplanter Lauf als Problem gefunden hat, ein Eintrag je Server und Problem. In der nächsten Nacht wieder gesehen, bleibt es ein Eintrag mit Zähler; sieht ein späterer Lauf desselben Zeitplans es nicht mehr, schließt er sich von selbst. Operatoren übernehmen einen Befund, schließen ihn von Hand oder starten daraus eine Session, nachdem sie die vorgeschlagene Aufgabe gelesen haben.

Auf vielen Servern (Neue Session, „Auf allen parallel dasselbe“): Haken Sie die Server an, von Hand oder nach Tag, und schreiben Sie die Aufgabe einmal. Die Liste der Sessions zeigt den Rollout als eine Zeile, die zu seiner Seite führt. Sie läuft auf dem ersten Server als gewöhnliche Sitzung mit jeder Freigabe, die sie braucht. Ist diese Sitzung durch, öffnet jemand, der Befehle freigeben darf, den Rollout, sieht sich die Sitzung des ersten Servers an und sagt Go; die Aufgabe läuft dann auf den anderen, vier gleichzeitig. Die Seite des Rollouts nennt vor dem Go die Befehle, die es abdeckt: die, die ein Mensch auf dem ersten Server freigegeben hat und die dort gelungen sind, keiner davon unumkehrbar. Auf jedem anderen Server laufen diese ohne Rückfrage, in dieser Reihenfolge, jeder nur als derselbe Text auf dem eigenen Server der Sitzung und erst, wenn der davor dort gelungen ist, und nur im ersten Durchlauf der Sitzung. Als Freigebender wird vermerkt, wer Go gesagt hat; diese Person muss die Sitzung des ersten Servers lesen können. Alles andere fragt wie immer, ebenso ein Befehl für zwei Personen, einer, der ein Geheimnis nennt, und eine Dateiänderung. Die Seite des Rollouts zeigt je Server eine Zeile mit Zustand und Befehlen; jeder Server behält seine eigene Sitzung, sein Protokoll und seinen Stopp-Knopf.

Verwaltete Dateien (Navigation, Administratoren): Nennen Sie die Dateien, die Ansible, Terraform oder ein anderes Werkzeug schreibt, als Pfad oder Muster (/etc/nginx/**), mit dem Ort, an den eine Änderung stattdessen gehört. Die Liste gilt auf jedem Server. Heinzel erfährt die Liste für den Server der Sitzung, ein Befehl, der eine solche Datei ändern würde, wird mit diesem Hinweis verweigert, eine Dateiänderung ebenso. Eine Datei, deren erste zehn Zeilen sagen, dass sie verwaltet ist (Ansible managed, This file is managed by …), wird auch ohne Eintrag verweigert: vor der Freigabe, wo die Datei dann gelesen werden darf, und in jedem Fall beim Schreiben selbst, das sich auf dem Host die ersten Zeilen der Datei ansieht. Ein Muster, das auf /** endet, deckt auch das Verzeichnis ab. Ein Befehl wird verweigert, wenn eine verwaltete Datei das ist, wohin er schreibt: Eine Kopie davon, ein Archiv davon oder ein Test davon bleibt unberührt. Die Liste wird von Hand gepflegt; ein Repository wird nicht gelesen. Die Prüfung von Befehlen findet einen Pfad, der im Befehl steht, nicht einen aus Variablen gebauten oder über einen Symlink erreichten.

Ein Eintrag hat einen Modus, so wie Heinzels memory/protected-paths.md sie kennt. Von einem Werkzeug verwaltet ist das Obige. Nur lesen lehnt jede Änderung ab, mit dem Grund, den Sie angeben. Verborgen lehnt auch das Lesen des Inhalts ab, nicht einmal eine Zeilenzahl: eine Secrets-Datei, ein Verzeichnis mit den Daten anderer Leute. Änderungen warten auf eine Person lässt jede Änderung dort von einer Person lesen, bevor sie läuft, was die Session sonst auch allein dürfte. Der Agent erfährt die Liste mit jedem Modus, und dass ein Muster ein Hinweis ist, keine Sandbox: Eine rekursive Kopie eines übergeordneten Verzeichnisses berührt den Pfad auch.

Anhänge (Sitzungsseite): Das Nachrichtenfeld nimmt Dateien über die Büroklammer, durch Ablegen und durch Einfügen aus der Zwischenablage: Textdateien bis 300 kB, und in einer Sitzung mit einem Anthropic-Modell auch Bilder (PNG, JPEG, GIF, WebP) und PDFs bis 3,5 MB, fünf je Nachricht und 12 MB je Sitzung, weil alles Angehängte mit jedem Schritt an das Modell geht. Was eine Datei ist, entscheidet, wie ihre Bytes beginnen und enden. Dateien liegen mit der Sitzung in der Datenbank und werden mit ihr gelöscht; wer in der Sitzung schreiben darf, kann eine wieder herausnehmen, und eine Datei, die für eine nie gesendete Nachricht angenommen wurde, wird einen Tag später gelöscht. Ein Text wird von den hinterlegten Geheimnissen und wie die Ausgabe eines Befehls bereinigt, und einer, der sich wie Anweisungen an Heinzel liest, wird ihm vorenthalten, bis jemand, der in der Sitzung schreiben darf, ihn durchlässt. Ein Bild lässt sich so nicht prüfen.

Dateiänderungen (Befehlskarte): Ändert Heinzel eine Konfigurationsdatei, nennt er die Datei und ihren ganzen neuen Inhalt, und die Karte zeigt den Unterschied als Diff. Die Datei wird dafür nur dort vorab gelesen, wo Lesen ohne Freigabe läuft; sonst zeigt die Karte den neuen Inhalt, und der Diff kommt vom Host zurück, sobald der Befehl gelaufen ist. Wo ein Diff gezeigt wurde, prüft das Schreiben zuerst, ob die Datei noch die ist, gegen die er gezeigt wurde, und verweigert sonst. Eine Dateiänderung fragt immer für sich; kein Plan und keine Dauerfreigabe ersetzt das. Eine Kopie der alten Datei bleibt als <Datei>.heinzel-<Zeit>.bak daneben liegen; diese Kopien werden nicht aufgeräumt. Geschrieben wird durch einen Symlink hindurch auf dessen Ziel, und nicht atomar.

Pläne (Sitzungsseite): Für eine Aufgabe mit drei oder mehr ändernden Befehlen legt Heinzel zuerst einen Plan vor: das Ziel, jeden Schritt mit seinem genauen Befehl, was schiefgehen kann und wie es rückgängig zu machen ist. Wer Befehle freigeben darf, gibt ihn als Ganzes frei oder lehnt ihn ab. Ein freigegebener Schritt lässt genau diesen Befehl einmal auf dem genannten Server laufen; ein Befehl, der um ein Zeichen abweicht, fragt für sich, ebenso einer, der zwei Personen braucht oder ein Geheimnis nennt. Die Schritte laufen in ihrer Reihenfolge, der nächste erst, wenn der davor gelungen ist, und der Plan gilt für seinen Durchlauf: Ein Stopp oder die nächste Nachricht beendet ihn. Ein wartender Plan steht auf der Seite Freigaben und in ihrer Zählung; Mail oder Push gibt es dafür noch nicht. Unbeaufsichtigte Läufe haben keine Pläne.

sudo muss für den Benutzer, mit dem Heinzel sich anmeldet, ohne Passwort gehen, oder Heinzel meldet sich als root an. Heinzel hinterlegt kein Passwort für einen Host. Wo sudo eines verlangt, scheitert ein Befehl mit sudo sofort, und der Agent arbeitet ohne erhöhte Rechte und sagt das.

Zugänge (Seite des Servers, „Zugänge und Schlüssel“): Ein Zugang ist ein Benutzer, als der Heinzel sich anmeldet. Ein Server hat einen oder mehrere, etwa root und stefan. Der Schlüssel des Servers öffnet jeden; tragen Sie ihn in die authorized_keys jedes Benutzers ein. Wer eine Session öffnet, wählt den Zugang, wo es mehr als einen gibt. Eine Session, die von einer anderen ausgeht, sie zurückrollt oder einen ihrer Befehle aufgreift, meldet sich als derselbe Benutzer an. Ein Zeitplan und ein Rollout nennen einen Benutzer, der auf jedem ihrer Server gilt (ohne Angabe der erste Zugang, den ihr Besitzer benutzen darf); ein Server ohne diesen Zugang wird ausgelassen, nicht als jemand anderes bearbeitet.

Ein Zugang hat einen eigenen Deckel, der nur senkt, was der Server erlaubt, so wie eine Datei ihren Ordner: root@web1 mit r-- lässt alle als root nur lesen, während sie als stefan arbeiten. Ein Zugang kann auch nennen, wer ihn nutzt: niemand angehakt, alle, die den Server erreichen; ein Team angehakt, nur dieses Team, ein root-Zugang für die Administratoren. Freigeben kann nur, wer als der Zugang des Befehls arbeiten darf.

Ohne sudo: Bei einem anderen Benutzer als root fragt das Formular des Zugangs, ob er sudo benutzen darf. Ist der Haken aus, arbeitet Heinzel nur mit den Rechten des Benutzers und lehnt jeden Befehl ab, in dem sudo, sudoedit, doas, su, pkexec oder run0 vorkommt, auch als Argument. Das ist ein Netz, keine Wand: Was der Benutzer wirklich darf, legt die sudoers-Datei des Hosts fest.

Ein Zugang, den niemand mehr braucht, wird stillgelegt statt gelöscht: Er wird niemandem mehr angeboten, eine Session mit ihm führt nichts mehr aus, und die alten Sessions zeigen weiter, als wer sie gearbeitet haben. Der letzte Zugang eines Servers bleibt.

Geheimnisse (Navigation, Administratoren): Hinterlegen Sie ein Passwort oder ein Token unter einem Namen, und Heinzel benutzt es als $HEINZEL_SECRET_NAME in einem Befehl. Der Wert geht nie an das Modell; er erreicht den Befehl über dessen Standardeingabe, nicht über die Befehlszeile, und wird in der Ausgabe geschwärzt, bevor sie gespeichert wird. Nehmen Sie zufällige Werte mit zwölf oder mehr Zeichen: Ein Wert, der sich raten lässt, lässt sich herausfinden, indem ein Befehl Rateversuche ausgibt und sieht, welcher geschwärzt wurde. Ein Befehl, der ein Geheimnis nennt, wartet auf jeder Autonomiestufe auf einen Menschen und läuft nicht unbeaufsichtigt, weil ein Befehl einen Wert in anderer Gestalt weitergeben kann (kodiert, in eine Datei geschrieben). Lesen Sie einen solchen Befehl, bevor Sie ihn freigeben.

Ein Zeitplan kann statt eines Servers Tags nennen. Er läuft dann auf jedem Server, der alle trägt, vier gleichzeitig, lässt gesperrte Server aus und verschickt einen Bericht: zuerst die Hosts, die jemanden brauchen, dann eine Zeile für jeden, bei dem alles in Ordnung ist. Ein später getaggter Server ist beim nächsten Lauf dabei.

Den öffentlichen Schlüssel in die authorized_keys jedes Zugangs kopieren, dann Verbindung testen. Der Host-Key wird beim ersten Kontakt gespeichert. Wurde ein Host neu installiert, nutzen Sie „Neuem Host-Key vertrauen“. „Schlüssel erneuern“ erzeugt ein neues Paar.

Ein Host, der SSH nur von einem Sprung-Host annimmt, nennt diesen Server unter „Erreicht über (Bastion-Host)“. Heinzel verbindet sich mit dem Schlüssel und dem gespeicherten Host-Key des Bastion-Hosts dorthin, tunnelt von dort und meldet sich am Host mit dessen eigenem Schlüssel an. Der Bastion-Host muss TCP-Weiterleitung erlauben (AllowTcpForwarding); unterstützt wird ein Sprung.

Übergabe (Serverseite) ist eine Markdown-Datei mit dem, was über den Server gespeichert ist: System, Zugang, die Notizen des Agenten, offene To-dos und Befunde, das Journal, seine Sessions und seine Zeitpläne. Sie nennt nur die Sessions, die ihr Leser lesen darf, und kein Modell wird gefragt, sie zu schreiben.

Das Gedächtnis ist, was Heinzel über einen Host weiß: Betriebssystem, Dienste, Pfade, Eigenheiten. Der Agent aktualisiert es nach der Arbeit; Sie können es bearbeiten. Das Journal listet Änderungen.

Ein Host, den auch andere betreuen

Zwei Mandanten können denselben Host anlegen, jeder mit eigener Zeile, eigenem Schlüsselpaar, eigenem Host-Key, Gedächtnis, Journal und To-dos; keiner sieht, dass der andere ihn hat, und der Kommentar des öffentlichen Schlüssels in authorized_keys ist für alle gleich (heinzel-pro). Was Heinzel Pro über einen Host weiß, bleibt im Mandanten.

Der Host selbst ist gemeinsamer Boden: Wer dort eine Shell hat, sieht Dateien, Pakete, Logs und Shell-Historie, mit oder ohne Heinzel. Eines kommt hinzu: Heinzels Übergabenotizen im Systemjournal. Ein neuer Server hinterlässt und liest sie. Teilt ein Mandant einen Host mit Fremden, die nicht mitlesen sollen, schaltet er beides im Serverformular aus; der nächste Abschnitt sagt, was die Notizen sind und was sich einstellen lässt.

Übergabenotizen im Systemjournal

Eine Übergabenotiz ist eine Zeile im Systemjournal des Hosts unter dem Tag heinzel. Wer dort journalctl -t heinzel aufruft, sieht, was Heinzel geändert hat: Kollegen mit Shell-Zugang ebenso wie eine zweite Heinzel-Instanz, die denselben Host betreut.

Das Serverformular hat dafür zwei Häkchen. „Heinzel hinterlässt Übergabenotizen“ gibt etwas preis, „Heinzel liest die Notizen, die es dort findet“ holt fremden Text ins Modell. Bei einem neuen Server ist beides an. Wer Server betreut, darf beides ausschalten; wieder einschalten kann es nur ein Administrator. Gelesene Notizen gelten als Angaben über den Host, nie als Anweisung.

Was in einer Notiz steht, legt der Mandant unter Einstellungen, Richtlinie fest, und ein Server darf davon abweichen. Beide Seiten zeigen dieselben Schalter und darüber die Zeile, die mit der aktuellen Auswahl entsteht:

Das Serverformular stellt dazu eine Frage: „Wie bei allen Servern“ oder „Für diesen Server anders“. Erst die zweite Antwort zeigt die fünf Einstellungen, und ein Punkt markiert, was für alle Server gilt. Wer diesen Wert wählt, folgt den Einstellungen weiter. Vom Mandanten spricht das Formular nicht: Wer Server betreut, kennt die Einstellungen, nicht den Mandanten dahinter.

Das Formular zeigt die Zeile, die mit der aktuellen Auswahl entsteht, etwa [Ada Lovelace/root] nginx auf 1.28.0 aktualisiert, weil die alte Version eine Sicherheitslücke hatte. Hinter dem Schrägstrich steht das Konto, mit dem Heinzel auf dem Host arbeitet. Ein Zeitplan-Lauf nennt keine Person, denn es war niemand dabei; die Kontaktadresse nennt er.

Das Modell liefert nur den Satz. Absender, Konto und Link setzt Heinzel Pro darum und schreibt die Zeile selbst; ein logger -t heinzel des Modells wird abgelehnt, ebenso jedes Lesen, wo der Server keine Notizen liest, auf jeder Autonomie-Stufe und auch dann, wenn der Befehl freigegeben wurde, bevor das Häkchen entfernt wurde. Die Notiz läuft als Befehl der Session und wird behandelt wie ein Lesebefehl: Sie wartet auf eine Freigabe, wo auch Lesen wartet. Sprache und Wortlaut bleiben Sache des Modells; sie stehen im Prompt und lassen sich nicht im Code prüfen. Die Sperre kennt die Schreibweisen der Regeln und die naheliegenden weiteren; sie ist ein Filter, kein Beweis.

Ein Journal wird oft an einen zentralen Logserver weitergeleitet. Mit der gemeinsamen Kontaktadresse bleibt die Adresse einer einzelnen Person draußen.

SSH-Schlüssel

Heinzel Pro besitzt jeden privaten Schlüssel, den es benutzt. Schlüssel werden in der Anwendung erzeugt, verschlüsselt gespeichert und nie exportiert; einen privaten Schlüssel hochladen geht absichtlich nicht: Ein Schlüssel, der auch auf einem Laptop liegt, lässt sich von Heinzel Pro allein nicht zurückziehen, und seine Nutzung wäre nicht von der einer Person zu unterscheiden.

Zwei Formen:

• Eigener Schlüssel pro Server (Standard). Geringste Rechte: Ein kompromittierter Host verrät nichts über die anderen. Rotation beim Server.
• Gemeinsamer Schlüssel (Administration, SSH-Schlüssel). Ein Schlüsselpaar für eine Gruppe von Hosts, damit das Konfigurationsmanagement eine öffentliche Zeile überall einträgt. Operatoren wählen ihn im Serverformular. Die Rotation behält den vorherigen Schlüssel als "zurückgezogen": Hosts, die nur die alte Zeile tragen, funktionieren weiter und werden markiert; der Administrator verwirft den zurückgezogenen Schlüssel, sobald jeder Host die neue Zeile hat.

Zugang für Menschen ist keine Schlüsselfrage. Alle mit der Rolle Operator arbeiten über dieselben Schlüssel; das Audit-Protokoll hält fest, wer was verlangt hat. Geben Sie jedem Host einen eigenen Benutzer heinzel mit den nötigen sudo-Rechten statt persönlicher Konten, dann erzählen Host-Logs und Audit-Protokoll dieselbe Geschichte.

VPN-Verbindungen

Für Server, die Heinzel aus dem Internet nicht erreicht: hinter dem Router zu Hause, im Büronetz, ohne öffentliche Adresse. Eine VPN-Verbindung ist ein verschlüsselter Tunnel (WireGuard) zwischen Heinzel und Ihrem Netz. Durch ihn meldet sich Heinzel per SSH an, mit demselben Schlüssel und demselben gespeicherten Host-Key wie überall. Administratoren legen Verbindungen unter „VPN“ an.

Es gibt drei Wege. Wer unsicher ist und kein Tailscale nutzt, nimmt den ersten; wer Tailscale oder Headscale schon nutzt, den dritten.

Weg 1: Ihr Server verbindet sich mit Heinzel

1. „VPN“, „Neue VPN-Verbindung“, einen Namen eingeben, speichern.
2. Auf dem Server WireGuard installieren: sudo apt install wireguard (Debian, Ubuntu) oder sudo dnf install wireguard-tools (Fedora, RHEL, AlmaLinux, Rocky Linux).
3. Den Block von der Seite der Verbindung kopieren und im Terminal des Servers einfügen. Er speichert /etc/wireguard/heinzel.conf und startet den Tunnel, jetzt und nach jedem Neustart.
4. Warten, bis der Status „verbunden“ zeigt, meist binnen zehn Sekunden. Die Seite aktualisiert sich selbst.
5. „Diese Maschine als Server hinzufügen“. Adresse und Verbindung sind schon eingetragen. Weiter wie bei jedem Server: öffentlichen SSH-Schlüssel eintragen, Verbindung testen.

Am Netzwerk des Servers ändert sich sonst nichts: Durch den Tunnel geht nur, was für Heinzels Tunneladresse bestimmt ist. Der Block enthält den Schlüssel der Verbindung, behandeln Sie ihn wie ein Passwort.

Abschalten können Sie den Tunnel jederzeit auf Ihrer Seite: sudo systemctl disable --now wg-quick@heinzel

Ein ganzes Netz über eine Maschine. Geräte, auf denen kein WireGuard läuft (ein NAS, ein Switch), erreicht Heinzel über eine Linux-Maschine im selben Netz, die immer an ist. Tragen Sie beim Anlegen unter „Ein ganzes Netz über eine Maschine erreichen“ das Netz ein, etwa 192.168.1.0/24. Der Block richtet dann auch die Weiterleitung ein (dafür zusätzlich iptables installieren) und lässt Heinzel nur in die genannten Netze. Die übrigen Geräte legen Sie mit ihrer Adresse im eigenen Netz an und wählen die VPN-Verbindung aus.

Weg 2: Heinzel verbindet sich mit Ihrem Router

Legen Sie Heinzel am Router an wie einen Laptop: als neues WireGuard-Gerät. Der Router bietet dann eine Konfigurationsdatei an. Öffnen Sie sie mit einem Texteditor und fügen Sie den ganzen Inhalt unter „Neue VPN-Verbindung“, „Heinzel verbindet sich mit meinem VPN-Router“ ein. Heinzel speichert den Schlüssel darin verschlüsselt und zeigt ihn nie wieder an.

FRITZ!Box: „Internet“, „Freigaben“, Reiter „VPN (WireGuard)“, Verbindung hinzufügen, „Einzelgerät verbinden“, einen Namen vergeben, an der Box bestätigen, „Einstellungen herunterladen“. Die Bezeichnungen weichen je nach FRITZ!OS-Version leicht ab. Die Box braucht eine MyFRITZ!-Adresse und einen Anschluss mit öffentlicher Adresse; an einem DS-Lite-Anschluss nehmen Sie Weg 1.

Andere Router: einen WireGuard-Peer (Client) für Heinzel anlegen und seine Konfiguration exportieren. Erlauben Sie ihm nur die betreuten Server und deren SSH-Port.

Server legen Sie mit der Adresse an, die sie in Ihrem Netz haben, etwa 192.168.178.20, und wählen die VPN-Verbindung aus.

Weg 3: Heinzel als Gerät in Ihrem Tailscale-Netz

Für alle, die Tailscale oder Headscale schon nutzen. Heinzel tritt Ihrem Netz als ein weiteres Gerät namens heinzel bei. Auf den Servern wird nichts installiert, an keinem Router etwas geändert.

1. In der Tailscale-Admin-Konsole „Settings“, „Keys“, „Generate auth key“. „Ephemeral“ bleibt aus. Nutzen Sie Tags, geben Sie dem Schlüssel einen, etwa tag:heinzel: Ein Gerät mit Tag läuft nicht ab. Ohne Tag schalten Sie später für das Gerät heinzel auf der Seite „Machines“ den Schlüsselablauf aus, sonst muss es nach einigen Monaten neu beitreten.
2. In Heinzel „VPN“, „Neue VPN-Verbindung“, „Meine Server sind in einem Tailscale-Netz“, Namen und Schlüssel eintragen, speichern. Für Headscale tragen Sie zusätzlich die Adresse Ihres Control-Servers ein.
3. Warten, bis der Status „verbunden“ zeigt. Ist bei Ihnen die Gerätefreigabe eingeschaltet, geben Sie das Gerät vorher frei; die Seite sagt, wenn es darauf wartet.
4. In den Zugriffsregeln Ihres Netzes dem Gerät die betreuten Server auf deren SSH-Port erlauben, sonst nichts.
5. Server mit ihrer Tailscale-Adresse (beginnt mit 100.) oder ihrem Namen im Tailscale-Netz anlegen und die VPN-Verbindung auswählen.

Heinzel benutzt den Schlüssel einmal und vergisst ihn nach dem Beitritt. Tailscale SSH wird nicht benutzt: Heinzel meldet sich am gewöhnlichen SSH-Dienst an, mit eigenem Schlüssel und gespeichertem Host-Key. Server hinter einem Subnet-Router legen Sie mit ihrer Adresse in jenem Netz an.

Abschalten auf Ihrer Seite: das Gerät heinzel unter „Machines“ entfernen oder ihm die Zugriffsregel nehmen.

Meldet die Seite, Heinzel sei nicht angemeldet, wurde der Schlüssel abgelehnt, ist er abgelaufen, oder das Gerät wurde entfernt: einen neuen Schlüssel erzeugen und unter „Ändern“ einfügen. Wird ein Server nicht erreicht, prüfen Sie zuerst die Zugriffsregeln.

Wenn es bei „wartet auf die Gegenseite“ bleibt

• Weg 1: sudo wg show heinzel zeigt auf der Maschine „latest handshake“, sobald beide Seiten miteinander gesprochen haben. Die Maschine muss UDP an den Port senden dürfen, den die Seite der Verbindung nennt; eine Firmen-Firewall braucht dafür eine Regel.
• Weg 1, verbunden, aber der Server antwortet nicht: Eine Firewall auf dem Server muss SSH von Heinzels Tunneladresse erlauben, mit ufw sudo ufw allow in on heinzel to any port 22 proto tcp
• Weg 2: Der Router muss unter seinem Namen aus dem Internet erreichbar sein. Wurde die Verbindung am Router gelöscht oder neu angelegt, fügen Sie unter „Ändern“ die neue Datei ein.
• Kam noch nie eine Verbindung nach Weg 1 zustande, sind vermutlich die UDP-Ports der Installation nicht offen, siehe installation.md.

Grenzen

• Zwei Server mit derselben Adresse und demselben Port kann ein Mandant nicht anlegen, auch nicht in zwei verschiedenen Netzen. Weg 1 gibt jeder Verbindung eigene Adressen und kennt das Problem nicht.
• Hinter einem Bastion-Host gehört die VPN-Verbindung an den Bastion-Host.
• Nach einem Neustart von Heinzel Pro ruft es die Gegenseite dort an, wo sie zuletzt zu hören war. Hat sich deren Adresse inzwischen geändert, steht der Tunnel erst wieder, wenn sie sich selbst meldet; das kann einige Minuten dauern.
• Eine Verbindung nach Weg 3 ist ein Gerät in genau einem Tailscale-Netz. Für ein zweites Netz legen Sie eine zweite Verbindung an.

Sessions

Server wählen, Aufgabe beschreiben. Jeder vorgeschlagene Befehl erscheint als Karte mit Risikoklasse und Begründung. Freigeben oder ablehnen; eine Ablehnung kann einen Grund tragen, den das Modell liest. Ausgaben sehen Sie unbereinigt. Die Seite Freigaben listet offene Befehle über alle Sessions hinweg.

Mehrere gleichzeitig

Sessions laufen nebeneinander: eine starten, die nächste starten und dorthin gehen, wo eine Sie braucht. Die Liste und die Leiste neben einer offenen Session zeigen, was jede gerade tut:

Was Sie braucht, steht oben. Für eigene Sessions (von Ihnen gestartet, oder an Ihrer Nachricht arbeitend) zeigt die Navigation eine Zahl, der Browser-Tab trägt sie im Titel, und mit „In diesem Browser benachrichtigen“ zeigt der Browser eine Benachrichtigung, während Sie in einem anderen Tab oder Fenster sind. Der Tab einer Session spricht nur für diese Session: Sein Titel beginnt mit „● Freigabe nötig“, „● Fehlgeschlagen“, „● Angehalten“ oder „● Antwort da“, wenn sie Sie braucht, und mit „…“, solange Heinzel arbeitet. Unter mehreren Session-Tabs sehen Sie so, welcher wartet. Zwei Tabs derselben Session zeigen dasselbe. Eine Antwort gilt als gelesen, sobald ihre Seite vor Ihnen liegt, nicht solange der Tab im Hintergrund ist. Mit Ihnen geteilte Sessions stehen mit ihrem Zustand in der Liste und melden sich nicht; ihre Antworten zählen erst als ungelesen, nachdem Sie sie einmal geöffnet haben.

Teilen

Eine Session gehört dem, der sie gestartet hat. Die Freigabe wird für jede Session einzeln eingestellt, in der Session selbst: Personen zeigt, wer dabei ist, und dort holt der Besitzer einen Kollegen oder eine Gruppe hinzu, ändert, was sie dürfen, oder sperrt sie wieder aus, einzeln und sofort. Wer ausgesperrt wird und die Session offen hat, verliert sie in dem Moment. Der Besitzer öffnet es:

• für alle im Mandanten, zum Lesen oder zum Schreiben,
• für Gruppen und Personen, zum Lesen oder zum Schreiben,
• für Menschen ohne Konto, zum Lesen, über einen Link, der nach 1, 7 oder 30 Tagen endet oder zurückgenommen wird. Links erlaubt ein Administrator unter Einstellungen, Richtlinie; anfangs sind sie aus. Die Seite hinter einem Link lässt Namen weg und schwärzt Geheimnisse in der Ausgabe von Befehlen; Hostnamen und Befehle stehen da, wie sie sind.

Schreiben heißt Nachrichten senden, damit ein Kollege dort weitermacht, wo der Besitzer aufgehört hat. Jede Nachricht zeigt ihren Absender, und das Audit-Protokoll hält jede Nachricht, jede Änderung der Freigabe und jeden Link mit dem Handelnden fest. Ein Durchgang, den jemand anderes angestoßen hat, läuft mit den geringeren Rechten beider. Mit Übernehmen wird ein Administrator zum Besitzer, oder jemand, mit dem die Session namentlich oder über eine Gruppe zum Schreiben geteilt ist; der bisherige Besitzer schreibt weiter mit, und ein Link endet. Zu „allen“ zu gehören reicht zum Übernehmen nicht.

Vorgaben: Einstellungen, Richtlinie legt fest, was neue Sessions für alle im Mandanten sind (privat, lesbar, schreibbar). Jedes Mitglied kann unter Sessions, Freigaben eine eigene Vorgabe setzen, etwa „privat, und die Gruppe Bereitschaft darf schreiben“.

Administratoren des Mandanten können jede Session öffnen. Die Seite Freigaben zeigt jeden wartenden Befehl denen, die darüber entscheiden, mit einem Link zur Session nur dort, wo sie mit ihnen geteilt ist. Das Audit-Protokoll lässt aus, was in Sessions geschah, die der Leser nicht öffnen darf. Läufe von Zeitplänen sind für den ganzen Mandanten lesbar. Zwei Dinge bleiben über eine private Session hinaus sichtbar: Das Journal eines Servers führt jede Änderung auf ihm mit dem Befehl, und Benachrichtigungen über einen wartenden Befehl gehen an die, die der Mandant dafür eingetragen hat. Nachrichten aus der Zeit vor 2.4 tragen keinen Absender.

Zeitpläne

Ein Zeitplan läuft auf einer Servergruppe, ein einzelner Server ist seine eigene: eine unbeaufsichtigte Session je Server, einige zugleich, und am Ende ein Bericht. Er gehört einer Personengruppe, einer Person oder allen; die Personen dieser Gruppe ändern, entfernen und starten ihn, und einen Zeitplan, der allen gehört, ändert, wer Zeitpläne verwaltet. Wer festlegt, wo er läuft, muss auf diesen Servern arbeiten; wer nicht jeden Server sieht, sieht die Zeitpläne, die auf einem Server laufen, den er sieht.

Cron-Ausdrücke in UTC. Die Aufgabe läuft unbeaufsichtigt: Lesebefehle werden ausgeführt, Änderungen auch, wo der Zeitplan auf „Änderungen allein“ steht (siehe Zeitpläne oben). Alles andere wird übersprungen und im Bericht unter „Braucht einen Operator“ gelistet. Der Bericht geht an die Ziele des Zeitplans: Mailadressen, und der Kanal des Teams, wo der Mandant einen Webhook hat. Eine Mail enthält den Bericht als Text und als HTML.

Berichte und Nachrichten

Eine Session schickt ihren Bericht an die Ziele, die auf ihrer Seite stehen (Mehr, Bericht und Nachrichten). Er geht von selbst hinaus, wenn Heinzel eine Aufgabe erledigt und die Zusammenfassung geschrieben hat, und wenn die Session fehlschlägt; ein Zug, der mit einer Frage endet, schickt nichts. „Bericht jetzt senden“ schickt ihn jederzeit. Dasselbe Feld listet, was aus der Session gesendet wurde und ob es hinausging.

Unter Konto legt „Berichte meiner Sessions“ die Ziele fest, die jede Session einer Person mitnimmt.

Man kann auch in einer Nachricht darum bitten: „und dann schicke mir eine Mail an ops@example.com“. Heinzel schreibt diese Nachricht mit dem Werkzeug send_message. Sie erreicht nur ein Ziel, das ein Mensch genannt hat: eine Adresse aus einer Nachricht der Session, die Berichtsziele der Session, die Personen der Session oder den Kanal des Teams. Eine Adresse, die Heinzel auf einem Host oder in einer Datei gelesen hat, wird abgelehnt, ebenso jede Adresse in einer Session, die ein Alarm gestartet hat. Eine Session sendet höchstens zehn solche Nachrichten pro Stunde, jede wird von allem befreit, was nach einem Geheimnis aussieht, und jede steht im Audit-Protokoll.

Ein Ziel ist eine Mailadresse oder ein Kanal. Es gibt zwei Kanäle: Mail und den Webhook des Mandanten (Einstellungen, Benachrichtigungen), der ein Ort für das ganze Team ist. Eine Zustellung, die scheitert, wird fünfmal versucht.

Audit-Protokoll

Nach Aktion, Akteur oder Text filtern; CSV exportieren; Kette prüfen. Die Ziel-Links springen zur Session oder zum Server.