Sessions und Freigaben

Eine Session ist eine Aufgabe auf einem oder mehreren Servern: Sie schreiben, was Sie brauchen, Heinzel schlägt Befehle vor, der Code stuft jeden ein, und je nach Stufe läuft er sofort oder wartet auf Sie.

Eine Session starten

Das Formular unter Neue Session fragt vier Dinge.

Drei gute Aufgaben

Eingabe: Auf web03 melden Kunden seit 14 Uhr sporadisch 502. Finde die Ursache. Nichts neu starten, bevor du mir gesagt hast, was es ist.

Eingabe: Lege auf db1 und db2 den Benutzer „monitoring“ mit Nur-Lese-Rechten auf alle Datenbanken an, Passwort aus dem Geheimnis MONITORING_DB.

Eingabe: Das Zertifikat auf mail01 läuft in 9 Tagen ab und certbot hat es dreimal nicht erneuert. Warum, und bring es in Ordnung.

Was die drei gemeinsam haben: ein Server oder zwei, ein Ziel, und die Grenze, die Heinzel kennen muss. Eine Aufgabe wie „räum mal auf“ bekommt eine Rückfrage statt eines Befehls.

Die drei Stufen

Jede Session wählt beim Start, wie weit Heinzel allein geht. Die Oberfläche schreibt die Stufen wie die Rechte einer Datei.

Es zählt bei jedem Befehl das Niedrigste aus vier Grenzen:

1. Die Obergrenze des Mandanten, von der Installation gesetzt (rw- oder rwx).
2. Die Buchstaben der Person auf diesem Server, aus ihren Teams und Gruppen.
3. Der Deckel des Servers, seiner Gruppen und des benutzten Zugangs.
4. Die Wahl der Session.

Beispiel: Anna hat über ihr Team rwx auf der Gruppe Web. Der Server web07 trägt den Deckel rw-, weil er vom Kunden selbst mitbetreut wird. Startet Anna dort eine Session auf „Ändert allein“, läuft trotzdem jede Änderung über eine Freigabe. Die Session sagt das beim Start.

Die Befehlskarte

Jeder Befehl, den Heinzel vorschlägt, erscheint als Karte mit vier Teilen.

Die Einstufung

Sie kommt aus dem Code, nicht aus dem Modell: Heinzel Pro zerlegt den Befehl in seine Teile (Pipes, &&, sudo, sh -c) und nimmt die höchste Klasse. Was der Code nicht lesen kann, gilt als schreibend. Was eine Klasse dann auf rw- und auf rwx tut, stellt der Mandant in der Matrix ein (Einstellungen, Richtlinie); die rechte Spalte zeigt die Voreinstellung.

Freigeben oder ablehnen

Freigeben lässt genau diesen Befehl einmal auf diesem Server laufen. Ablehnen nimmt einen Grund mit, den Heinzel liest: „Nicht jetzt, der Kunde fährt bis 18 Uhr einen Lasttest“ bringt den Vorschlag, nach 18 Uhr weiterzumachen, oder einen Weg ohne Neustart. Eine Ablehnung ist endgültig; Heinzel darf denselben Befehl nicht umformuliert noch einmal vorschlagen.

Wo die Matrix zwei Personen verlangt, kommt die zweite Freigabe von einer anderen Person mit dem Recht dazu, und ihre Anmeldung darf höchstens fünf Minuten alt sein. Wer freigibt, steht am Befehl und im Audit-Protokoll.

Eine Änderung, die Heinzel aussperren könnte

Vor einer Änderung an Adresse, Route oder Firewall stellt Heinzel auf dem Server einen Timer, der nach zwei Minuten den alten Zustand zurückholt, im selben Befehl wie die Änderung. Dann meldet es sich neu an und stoppt den Timer. Gelingt der neue Login nicht, nimmt der Server die Änderung selbst zurück. Die Karte sagt das dazu.

Die Seite Freigaben

Wartende Befehle aller Sessions, die Sie entscheiden dürfen, an einem Ort. Dieselbe Änderung auf vielen Servern geben Sie hier auf einmal frei. Daneben steht eine Woche lang, was nächtliche Läufe übersprungen haben, weil sie es nicht allein durften, zum Übernehmen in eine eigene Session.

Damit Sie nichts verpassen, ohne die Seite offen zu halten:

• Die Navigation zählt, was Ihre Sessions brauchen; der Browser-Tab trägt die Zahl im Titel.
• Der Tab einer Session beginnt mit „● Freigabe nötig“, „● Fehlgeschlagen“, „● Angehalten“ oder „● Antwort da“, und mit „…“, solange Heinzel arbeitet.
• „In diesem Browser benachrichtigen“ auf der Seite Sessions: eine Benachrichtigung, auch aus einem anderen Fenster.
• Mail oder Webhook, wenn der Mandant das Ereignis „Freigabe nötig“ unter Einstellungen, Alarme eingeschaltet hat. Eine Freigabe, die zu lange wartet, lässt sich eskalieren (Einstellungen, Richtlinie).

Pläne

Braucht eine Aufgabe drei oder mehr ändernde Befehle, 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. Sie geben ihn als Ganzes frei oder lehnen ihn ab.

Ein freigegebener Schritt lässt genau diesen Befehl einmal laufen, in der Reihenfolge des Plans, der nächste erst, wenn der davor gelungen ist. Weicht ein Befehl um ein Zeichen ab, fragt er für sich. Ebenso einer, der zwei Personen braucht, ein Geheimnis nennt oder eine Datei ändert. Ein Stopp oder Ihre nächste Nachricht beendet den Plan.

Dateiänderungen

Ändert Heinzel eine Konfigurationsdatei, zeigt die Karte den Unterschied als Diff. Eine Dateiänderung fragt immer für sich; kein Plan und keine Dauerfreigabe ersetzt das. Vor dem Schreiben prüft Heinzel Pro, ob die Datei noch die ist, gegen die der Diff gezeigt wurde, und verweigert sonst. Die alte Datei bleibt als <Datei>.heinzel-<Zeit>.bak daneben liegen.

Dateien, die Ansible, Terraform oder ein anderes Werkzeug schreibt, tragen Sie unter Verwaltete Dateien ein, etwa /etc/nginx/**; eine Änderung dort wird mit dem Hinweis verweigert, wohin sie stattdessen gehört. Eine Datei, deren erste Zeilen „Ansible managed“ sagen, wird auch ohne Eintrag verweigert.

Geheimnisse

Ein Passwort oder Token, das ein Befehl braucht, legen Administratoren unter Geheimnisse ab. Heinzel benutzt es als $HEINZEL_SECRET_NAME; der Wert geht nie ans Modell, erreicht den Befehl über die Standardeingabe und wird in der Ausgabe geschwärzt. Ein Befehl, der ein Geheimnis nennt, wartet auf jeder Stufe auf einen Menschen. Lesen Sie ihn, bevor Sie freigeben: Ein Befehl kann einen Wert in anderer Gestalt weitergeben.

# So sieht Heinzels Vorschlag aus, wenn MONITORING_DB hinterlegt ist
psql -c "CREATE ROLE monitoring LOGIN PASSWORD '$HEINZEL_SECRET_MONITORING_DB'"

Mehrere Sessions nebeneinander

Starten Sie die nächste, während die erste liest. Die Liste unter Sessions und die Leiste neben einer offenen Session sagen, was jede gerade tut.

Lange Sessions laufen weiter: Die Seite zeigt, wie viel vom Raum des Modells eine Session verbraucht hat, und über das Budget hinaus fasst der Anbieter die früheren Nachrichten für das Modell zusammen, während die Session jede Nachricht in voller Länge behält.

Wenn die Aufgabe erledigt ist

Heinzel schreibt die Zusammenfassung oben in die Session: Änderungen, Prüfung, offene Punkte, Weg zurück. Sie ist die Darstellung des Modells und nicht gegen das geprüft, was lief; der Nachweis ist das Protokoll der Befehle. Offene Punkte landen auf dem To-do des Servers, und eine Notiz geht ins Journal des Servers und, wo der Server es erlaubt, als Übergabenotiz in dessen Systemjournal (journalctl -t heinzel).

Eine Session, deren Aufgabe erledigt ist, schließt sich nach drei ruhigen Stunden von selbst, sonst nach den Arbeitsstunden des Mandanten ohne Aktivität. Weiterarbeiten geht in einer neuen Session, die die Zusammenfassung der alten liest. Unter Mehr auf der Session-Seite:

• Änderungsnachweis: eine Markdown-Datei mit dem, der gefragt hat, dem, der entschieden hat, dem Ausgang jedes Befehls und seiner Stelle in der Audit-Kette. Für das Ticket oder den Prüfer.
• Vorfallsentwurf: dieselben Fakten als Zeitleiste, die Abschnitte für Menschen (Auswirkung, Ursache, was zu ändern ist) als TODO markiert. Kein Modell schreibt ihn.
• Zurückrollen: legt die Rücknahme-Notizen aller Befehle, die neueste zuerst, in die Aufgabe einer neuen Session. Der Knopf selbst macht nichts rückgängig; jeder Schritt wird wie jeder andere Befehl vorgeschlagen und freigegeben.
• Bericht und Nachrichten: wohin der Bericht dieser Session geht, siehe unten.
• Regeln neu laden, sobald ein neueres Regelwerk gilt; eine Session behält sonst das, mit dem sie begonnen hat.

Teilen

Eine Session gehört dem, der sie gestartet hat. Unter Personen in der Session öffnet der Besitzer sie für alle im Mandanten, für Gruppen und Personen, jeweils zum Lesen oder zum Schreiben, oder für Menschen ohne Konto über einen Link, der nach 1, 7 oder 30 Tagen endet. Links erlaubt ein Administrator unter Einstellungen, Richtlinie; anfangs sind sie aus. Schreiben heißt, Nachrichten senden: Ein Kollege macht weiter, wo Sie aufgehört haben, jede Nachricht trägt ihren Absender, und ein Durchgang läuft mit den geringeren Rechten beider. Mit Übernehmen wird ein Administrator oder ein namentlich Beteiligter zum Besitzer.

Was neue Sessions für alle sind (privat, lesbar, schreibbar), legt die Richtlinie fest; jedes Mitglied setzt unter Sessions, Freigaben eine eigene Vorgabe, etwa „privat, und die Gruppe Bereitschaft darf schreiben“.

Berichte und Nachrichten

Eine Session schickt ihren Bericht an die Ziele auf ihrer Seite: Mailadressen und den Kanal des Teams (der Webhook des Mandanten, Slack, Teams, Mattermost). Er geht von selbst hinaus, wenn Heinzel eine Aufgabe erledigt und die Zusammenfassung geschrieben hat, und wenn die Session fehlschlägt. Unter Konto legt „Berichte meiner Sessions“ die Ziele fest, die jede Ihrer Sessions mitnimmt.

Oder Sie bitten in der Aufgabe darum:

Eingabe: Prüfe auf allen Webservern, ob das Zertifikat noch mindestens 20 Tage gilt, und dann schicke mir eine Mail an ops@example.com.

Heinzel schreibt nur an Ziele, die ein Mensch genannt hat: eine Adresse aus einer Nachricht der Session, die Berichtsziele, die Personen der Session, den Kanal des Teams. Eine Adresse, die es auf einem Host oder in einer Datei gelesen hat, wird abgelehnt. Höchstens zehn Nachrichten je Session und Stunde, jede von Geheimnissen befreit, jede im Audit-Protokoll.

Anhänge

Das Nachrichtenfeld nimmt Dateien über die Büroklammer, durch Ablegen oder Einfügen: Textdateien bis 300 kB, mit einem Anthropic-Modell auch Bilder und PDFs bis 3,5 MB, fünf je Nachricht. Ein Fehlerbild aus dem Monitoring, eine Konfigurationsdatei vom Laptop, der Screenshot einer Fehlermeldung. Ein Text, der sich wie Anweisungen an Heinzel liest, wird dem Modell vorenthalten, bis jemand mit Schreibrecht ihn durchlässt.