Server und Verbindungen

Ein Server ist ein Host, auf dem Heinzel per SSH arbeitet: mit einem Schlüssel, den Heinzel Pro selbst erzeugt hat, als ein Benutzer, den Sie bestimmen, unter einem Deckel, den Sie setzen.

Einen Server anlegen

Zwei Wege: das Installations-Skript, das auf dem Server den Rest erledigt, oder alles von Hand. Server, Server hinzufügen zeigt beide als Kacheln; das Skript ist vorgewählt. Erlaubt der Tarif des Mandanten oder die Lizenz der Installation keinen weiteren Server, ist der Knopf ausgegraut, und ein Hinweis darunter sagt, welche Grenze es ist, und verlinkt dorthin, wo sie steigt.

Mit dem Installations-Skript

Für eine Maschine, auf der noch kein Heinzel ist: Debian, Ubuntu, Fedora, RHEL, SUSE, NixOS, FreeBSD, NetBSD, OpenBSD oder ein Mac mit Homebrew, mit einem Terminal. Dort führen Sie das Skript als root oder als Benutzer mit sudo-Rechten aus. Zum Installieren von WireGuard braucht es 50 MB frei auf /var und /usr; mit weniger hält es vor Ihrem Ja an und ändert nichts. Auf NixOS schreibt das Skript Module neben /etc/nixos/configuration.nix (heinzel-pro-tunnel.nix, heinzel-pro-login-<Benutzer>.nix), trägt sie dort neben ./hardware-configuration.nix in die imports ein, behält die alte Datei daneben und führt nixos-rebuild switch aus; scheitert der Rebuild, kommt die alte Datei zurück. Ein NixOS aus einem Flake richten Sie von Hand ein. Ob die Maschine direkt erreichbar ist oder einen Tunnel braucht, entscheidet die Seite; dasselbe Skript richtet beides ein. NetBSD braucht pkgin; das Skript installiert dort wireguard-go und startet den Tunnel über /etc/rc.d/heinzel, sofort und bei jedem Hochfahren, ohne Neustart. Wo npf filtert, fügt der Plan in /etc/npf.conf unter „block all“ eine Zeile ein, die SSH von Heinzels Ende des Tunnels hereinlässt, und behält die alte Datei daneben; bei einer npf.conf anderer Form zeigt das Skript die Zeile, und Sie setzen sie selbst ein. Auf FreeBSD mit aktivem pf hängt der Plan an /etc/pf.conf eine Regel an, die dasselbe tut, vorher von pfctl geprüft; die alte Datei bleibt daneben. Auf OpenBSD nimmt das Skript das WireGuard aus dem Kernel, installiert dafür nichts und schreibt den Tunnel nach /etc/hostname.wgN, das ihn sofort und bei jedem Hochfahren startet. Wo pf filtert, bekommt es dieselbe Regel wie auf FreeBSD. Für eine Anmeldung mit sudo installiert das Skript sudo und trägt @includedir /etc/sudoers.d in /etc/sudoers ein; als anderer Benutzer als root gestartet, braucht es sudo, doas reicht nicht.

1. Den Aufruf kopieren. Die Seite zeigt gleich eine Zeile curl … | sh für Linux und den Mac und eine für FreeBSD, NetBSD und OpenBSD, die ohne curl kommen: Sie lädt auf FreeBSD mit fetch, auf den beiden anderen mit ftp. Beide gelten eine Stunde und laufen zusammen genau einmal; gefragt wird noch nichts. Fehlt curl, fragt das Skript nach einem Ja und installiert es, bevor es die Maschine meldet: das Einzige, was es vor dem Plan ändert. Die Adresse ist kurz genug zum Abtippen, etwa heinzel-pro.de/setup/kx7m-p4wq, Groß- und Kleinschreibung ist egal. Ist die Stunde um, zeigt die Seite eine Warnung: Laden Sie sie neu, dann steht dort ein neuer Aufruf. Die kurze Frist sorgt dafür, dass eine kopierte und vergessene Zeile später niemandem eine Tür öffnet. Wer die Seite noch einmal öffnet, bekommt denselben Aufruf, solange ihn keine Maschine abgerufen hat.

2. Das Skript auf der Maschine ausführen. Der erste Abruf verbraucht den Aufruf, und die Seite zeigt sofort, dass er benutzt wird. Jeder weitere Abruf bekommt nur Heinzels Mütze und einen Hinweis; war es nicht Ihre Maschine, erzeugt „Nicht meine Maschine: neuer Befehl“ einen neuen. Das Skript ändert noch nichts: Es meldet die Maschine (Name, System, wer es gestartet hat, Host-Key, Hardware, Last, ein schon vorhandener Heinzel-Tunnel), zeigt einen sechsstelligen Prüfcode und sagt, dass Sie jetzt im Browser dran sind: Prüfcode vergleichen, Freigabeformular ausfüllen, „Einrichten“. Die Seite geht von selbst weiter. Wer das Skript nicht als root startet, wird vorher gefragt, ob es sudo benutzen darf; sudo fragt dann einmal nach dem Passwort.

3. Prüfcode vergleichen und freigeben. Die Seite zeigt denselben Prüfcode. Er kommt aus einem Geheimnis, das nur die Maschine kennt, die sich gemeldet hat: Hat eine fremde Maschine den Aufruf benutzt, stimmen die Codes nicht überein, und „Nicht meine Maschine“ verwirft den Befehl, ohne dass etwas Heinzel verlassen hat. Stimmen sie, fragt die Seite:

   • Name: vorbelegt mit dem Hostnamen, den die Maschine meldet. Heißt schon ein anderer Server so, folgt die Adresse der Maschine in Klammern, etwa web1 (203.0.113.5). Unter diesem Namen erscheint der Server überall; Heinzel wählt die Adresse.
   • Obergrenze: vorbelegt mit rwx, so weit Sie die Obergrenze setzen dürfen.
   • Weg: durch einen Tunnel, den das Skript einrichtet, direkt, wenn Heinzel Pro den SSH-Port aus dem Internet erreicht. Vorgeschlagen ist, was die Seite gemessen hat; hat die Maschine den Tunnel einer VPN-Verbindung schon, geht es durch diese. Ein Tunnel braucht das Recht, VPN-Verbindungen zu verwalten.
   • Anmeldung: heinzel, ein neuer Benutzer, den das Skript anlegt; der Benutzer, der das Skript gestartet hat, wenn es nicht root war; oder root. Bei den ersten beiden ein Haken für sudo ohne Passwort, bei root keiner. Gibt es auf der Maschine schon einen Benutzer heinzel ohne Heinzels Schlüssel, ist er ausgegraut, und die Seite schlägt den nächsten vor.
   • Sicherung: ab rw-.

   „Einrichten“ gibt den Plan frei.

4. Auf der Maschine Ja sagen. Das Skript zeigt genau diesen Plan und fragt einmal nach Ihrem Ja; solange es wartet, steht das auf der Seite in einem gelben Kasten. Dann installiert es WireGuard und startet den Tunnel, wo einer nötig ist (die VPN-Verbindung heißt wie der Server), legt Heinzels Schlüssel in authorized_keys und, wo gewählt, eine sudoers-Datei an und meldet sich zurück. Einen neuen Benutzer heinzel legt es ohne Passwort an: An der Konsole oder per SSH mit Passwort kommt niemand als dieser Benutzer hinein. Bei einem vorhandenen Benutzer kommt Heinzels Schlüssel zu den Schlüsseln dazu, die schon dort stehen. Währenddessen zeigt die Seite ein Band mit dem laufenden Schritt, seit wann er läuft und was danach kommt, darunter die Last der Maschine und jede Zeile des Skripts. Heinzel meldet sich zum ersten Mal an; die Seite zeigt oben, ob das klappte, und „Zum Server“ führt weiter.

Was ein früherer Lauf hinterlassen hat, übernimmt das Skript: den Tunnel und den Benutzer mit Heinzels Schlüssel. Einen älteren Heinzel-Tunnel ersetzt es und hebt seine Datei daneben auf; beides sagt es vor Ihrem Ja. Gehört ein Benutzer heinzel, die sudoers-Datei oder ein Tunnel dieses Namens jemand anderem, hält das Skript an und ändert nichts. Terminal und Seite zeigen dieselbe Meldung: den Befehl, der das Vorhandene entfernt, wenn es niemand mehr braucht (danach einen neuen Befehl erzeugen), und die Adresse, unter der Sie den Server stattdessen von Hand einrichten. Was das Skript tut, steht Wort für Wort unter „Das Skript ansehen“. Lesen Sie es dort und nicht über die Adresse im Browser: Auch dieser Abruf verbraucht den Befehl. Das Skript braucht curl; fehlt es auf der Maschine, zeigt „Kein curl auf der Maschine?“ direkt unter dem Aufruf, aufgeklappt, den Befehl, der es auf dem jeweiligen System installiert. Der Befehl bleibt solange gültig, er hat Heinzel Pro ja nie erreicht.

Von Hand

Einen Server entfernen

„Entfernen“ auf der Seite des Servers fragt den Namen noch einmal ab und nennt, was mitgeht: seine Zeitpläne, Server, die über ihn als Sprungserver erreicht werden, und die VPN-Verbindung, wenn nur dieser Server durch sie geht; der Haken dafür ist gesetzt. Eine Verbindung, durch die andere Server gehen, bleibt. Auf dem Host bleibt alles, bis Sie es dort entfernen; die Falte „So entfernen Sie Heinzel von diesem Host“ zeigt die Befehle.

Den Host vorbereiten

Nach dem Speichern zeigt die Serverseite unter „Schlüssel und Host-Key“ den öffentlichen Schlüssel. Er gehört in die authorized_keys jedes Benutzers, als der Heinzel sich anmelden soll. Drei Wege, je nach System.

Debian, Ubuntu, RHEL, Rocky, Alma, SUSE

# Als root auf dem Host. Die Schlüsselzeile von der Serverseite kopieren.
$ useradd --create-home --shell /bin/bash --comment "Heinzel Pro" heinzel
$ install -d -m 700 -o heinzel -g heinzel /home/heinzel/.ssh
$ echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI… heinzel-pro" \
  > /home/heinzel/.ssh/authorized_keys
$ chown heinzel:heinzel /home/heinzel/.ssh/authorized_keys
$ chmod 600 /home/heinzel/.ssh/authorized_keys
$ echo "heinzel ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/heinzel
$ chmod 440 /etc/sudoers.d/heinzel
$ visudo -c   # prüft die Syntax; ein Tippfehler sperrt sudo für alle

FreeBSD

$ pw useradd heinzel -m -c "Heinzel Pro" -s /bin/sh -G wheel
$ install -d -m 700 -o heinzel -g heinzel /home/heinzel/.ssh
$ echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI… heinzel-pro" \
  > /home/heinzel/.ssh/authorized_keys
$ chown heinzel:heinzel /home/heinzel/.ssh/authorized_keys
$ chmod 600 /home/heinzel/.ssh/authorized_keys
$ pkg install -y sudo
$ echo "heinzel ALL=(ALL) NOPASSWD: ALL" > /usr/local/etc/sudoers.d/heinzel

NetBSD

$ useradd -m -c "Heinzel Pro" -s /bin/sh heinzel
$ install -d -m 700 -o heinzel -g users /home/heinzel/.ssh
$ echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI… heinzel-pro" \
  > /home/heinzel/.ssh/authorized_keys
$ chown heinzel /home/heinzel/.ssh/authorized_keys
$ chmod 600 /home/heinzel/.ssh/authorized_keys
$ pkgin -y install sudo
$ echo "heinzel ALL=(ALL) NOPASSWD: ALL" > /usr/pkg/etc/sudoers.d/heinzel

macOS

Fernanmeldung einschalten (Systemeinstellungen, Allgemein, Teilen, Entfernte Anmeldung), den Schlüssel in die ~/.ssh/authorized_keys eines Administrator-Kontos eintragen und diesem Konto in /etc/sudoers.d/heinzel NOPASSWD geben. Das Regelwerk hat eine eigene Regel für macOS.

Was der Host sonst braucht:

• OpenSSH mit Public-Key-Anmeldung; Passwörter benutzt Heinzel Pro nie. Ein Host, der nur Zertifikate annimmt (AuthorizedKeysFile none), lässt sich nicht verwalten.
• Für RSA-Schlüssel OpenSSH ab 7.2, weil Heinzel Pro nur mit SHA-2 signiert.
• sh, nohup und ein Home-Verzeichnis, in das der Benutzer schreiben darf: Ein Befehl, der etwas ändert, läuft als Job in ~/.heinzel/jobs/ und überlebt so einen Neustart von Heinzel Pro. Fehlt das, läuft er im SSH-Kanal wie ein Lesebefehl.

Testen

Testen auf der Serverseite meldet sich an, speichert den Host-Key, erkennt System, Prozessor, Arbeitsspeicher, Platten und Laufzeit und holt von da an Last, Speicher, Temperatur und Platten in dem Takt, den Sie der Liste geben, von node_exporter, wo einer läuft, sonst aus /proc und /sys. Unter „System“ stehen Prozessor, Zahl der CPUs und RAM, unter jeder Platte, wie viel von wie viel frei ist. Klappt der Test, wird der Knopf grün („Angemeldet“), und darunter steht, als wer Heinzel sich angemeldet hat; schlägt er fehl, steht dort der Grund. „Schlüssel und Host-Key“ bleibt zugeklappt, solange die Verbindung steht. Ein geänderter Host-Key verweigert künftig die Verbindung, markiert den Server und alarmiert die Administratoren; wurde ein Host neu installiert, drücken Sie „Neuem Host-Key vertrauen“.

Die Serverliste ist gebaut wie die der Sessions: oben die Reiter Alle, Wartet auf Sie (was einen Fehler hat, voll ist oder noch nicht eingerichtet), Bei der Arbeit, Neustart und Gesperrt, darunter Suche und Tags, dann eine Zeile je Server. Das Zeichen vorn sagt den Zustand, dahinter stehen Host, Rechte, System, ein Hinweis, CPU, RAM, Ping und die Platten. Jeder Kopf sortiert, ein zweiter Klick dreht die Richtung. Der Host steht mit dem ersten Teil seines Namens da, der ganze Name erscheint beim Darüberfahren; ein Server hinter einem Tunnel heißt nach seiner Tunneladresse, und der Name, den er bei der Einrichtung bekam, steht daneben; das Häkchen voll im Kopf zeigt alle Namen ganz und merkt sich das für Sie, in jeder Tabelle mit Hostnamen: Sessions, Freigaben, Befunde, Zeitpläne, Rollouts, Zugänge und Berichte. Wo die Liste zu schmal für Köpfe ist, steht es im Menü der Reihenfolge. Ping sagt, wie weit der Server im Netz von Heinzel Pro entfernt ist: die Zeit, die eine Nachricht hin und zurück braucht, ohne die Arbeit des Servers für die Abfrage. Ein Klick auf die Zeile öffnet den Server, und unter der Liste stellen Sie den Takt der Aktualisierung für alle Server der Liste ein.

Zugänge

Ein Zugang ist ein Benutzer, als der Heinzel sich anmeldet. Ein Server hat einen oder mehrere, etwa root für die Administratoren und deploy ohne sudo für alle anderen. 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.

• Ein Zugang hat einen eigenen Deckel, der nur senkt: root@web1 mit r-- lässt alle als root nur lesen, während sie als deploy arbeiten.
• Das Formular eines Servers stellt unter „Strenger auf diesem Server“ eine Zelle der Matrix des Mandanten strenger, nie milder: Auf db02 wartet ein Neustart auf zwei Personen, überall sonst auf eine. Die Matrix steht unter Rechte.
• Ein Zugang kann nennen, wer ihn nutzt: niemand angehakt heißt alle, die den Server erreichen; ein Team angehakt heißt nur dieses.
• Ohne sudo: Ist der Haken aus, lehnt Heinzel jeden Befehl ab, in dem sudo, doas, su, pkexec oder run0 vorkommt. Ein Netz, keine Wand: Was der Benutzer wirklich darf, sagt die sudoers-Datei des Hosts.
• Ein Zugang, den niemand mehr braucht, wird stillgelegt, nicht gelöscht: Alte Sessions zeigen weiter, als wer sie gearbeitet haben.

Schlüssel

Heinzel Pro erzeugt jeden privaten Schlüssel selbst, speichert ihn verschlüsselt und gibt ihn nie heraus. Einen Schlüssel hochladen geht absichtlich nicht: Ein Schlüssel, der auch auf einem Laptop liegt, ließe sich von Heinzel Pro aus nicht zurückziehen, und seine Nutzung wäre nicht von der einer Person zu unterscheiden.

• Eigener Schlüssel pro Server (Standard): Ein kompromittierter Host verrät nichts über die anderen.
• Gemeinsamer Schlüssel (Verwaltung, SSH-Schlüssel): ein Paar für viele Hosts, damit das Konfigurationsmanagement eine Zeile überall einträgt. Die Rotation behält den alten Schlüssel als „zurückgezogen“, bis jeder Host die neue Zeile hat.
• Schlüssel erneuern auf der Serverseite erzeugt ein neues Paar; der alte Schlüssel gilt weiter, bis Sie den neuen eingetragen haben.

Geben Sie jedem Host einen eigenen Benutzer heinzel statt persönlicher Konten: Dann erzählen Host-Logs und Audit-Protokoll dieselbe Geschichte, und das Audit-Protokoll sagt, welcher Mensch was verlangt hat.

Viele Server auf einmal

Auf dieser Seite einer nach dem anderen; für ein Skript oder eine Pipeline gibt es POST /api/v1/<mandant>/servers, siehe API.

Hinter einem Sprungserver

Nimmt ein Host SSH nur von einem Bastion-Host an, legen Sie den Bastion-Host als Server an und nennen ihn beim Ziel unter „Über einen Sprungserver“. Heinzel verbindet sich mit dem Schlüssel und dem gespeicherten Host-Key des Bastion-Hosts dorthin, tunnelt weiter und meldet sich am Ziel mit dessen eigenem Schlüssel an. Der Bastion-Host muss TCP-Weiterleitung erlauben (AllowTcpForwarding yes in seiner sshd_config, die Vorgabe); unterstützt wird ein Sprung.

Server ohne öffentliche Adresse: VPN

Hinter dem Router zu Hause, im Büronetz, in einer Cloud ohne öffentliche IP: Eine VPN-Verbindung ist ein WireGuard-Tunnel zwischen Heinzel Pro und Ihrem Netz. Durch ihn meldet sich Heinzel per SSH an, mit demselben Schlüssel und Host-Key wie überall. Der Befehl unter „Server hinzufügen“ legt die Verbindung für einen Server von selbst an; Administratoren sehen und ändern alle unter Server, VPN-Verbindungen und legen dort die anderen Wege an. Drei Wege:

Weg 1, Schritt für Schritt

Der kürzeste Weg ist das Skript unter Mit dem Installations-Skript: Es legt die Verbindung und den Tunnel an und danach den Zugang. Soll die Maschine Heinzel nur in ihr Netz weiterreichen, beginnen Sie unter Neue VPN-Verbindung ohne den Haken (unten) und legen die Server dahinter auf der Seite der Verbindung an, jeden mit seiner Adresse im Netz.

Erst die Verbindung: VPN, Neue VPN-Verbindung, „Mein Server verbindet sich mit Heinzel“, ein Name. Das Formular fragt gleich, ob die Maschine auch Server wird (vorausgewählt): der Benutzer für Heinzel, sudo, die Obergrenze, ab rw- die Sicherung. Die Seite der Verbindung öffnet unter „Mit einem Befehl“ mit einer Zeile curl … | sh für genau diese Verbindung: dasselbe Skript wie unter „Server hinzufügen“. Die Maschine meldet sich auf der Seite, „Schlüssel freigeben“ schickt ihr den ganzen Plan, das Skript zeigt ihn, fragt einmal nach Ihrem Ja, startet den Tunnel und legt den Benutzer mit Heinzels Schlüssel an; Heinzel meldet sich an, der Server ist fertig. Was das Skript gerade tut, steht währenddessen Zeile für Zeile auf der Seite. Ohne den Haken richtet der Befehl nur den Tunnel ein, für eine Maschine, die Heinzel bloß weiterreicht. „Als Datei“ gibt die Konfiguration für ein NAS, einen Router oder die WireGuard-App auf dem Mac heraus; „Von Hand“ zeigt die Schritte für apt, dnf und BSD einzeln. Die Datei und der Block enthalten den Schlüssel der Verbindung; behandeln Sie beides wie ein Passwort. Steht „verbunden“ und gibt es noch keinen Server, legt „Diese Maschine als Server anlegen“ ihn mit Adresse und Verbindung an; weiter wie bei jedem Server: Schlüssel eintragen, testen.

Ein ganzes Netz über eine Maschine: Geräte ohne WireGuard (ein NAS, ein Switch) erreicht Heinzel über eine Linux-Maschine im selben Netz, die immer an ist. Tragen Sie unter „Ändern“ das Netz ein, etwa 192.168.1.0/24, und übernehmen Sie die Datei dort neu; sie richtet die Weiterleitung mit ein. Abschalten geht jederzeit auf Ihrer Seite: sudo systemctl disable --now wg-quick@heinzel

Weg 2

Legen Sie Heinzel am Router an wie einen Laptop, als neues WireGuard-Gerät, und fügen Sie die Konfigurationsdatei, die der Router dann anbietet, unter „Heinzel verbindet sich mit meinem VPN-Router“ ein. FRITZ!Box: Internet, Freigaben, VPN (WireGuard), Verbindung hinzufügen, Einzelgerät verbinden, Einstellungen herunterladen; die Box braucht eine MyFRITZ!-Adresse und eine öffentliche IP, an einem DS-Lite-Anschluss nehmen Sie Weg 1. Server legen Sie mit ihrer Adresse im Heimnetz an, etwa 192.168.178.20, und wählen die Verbindung.

Weg 3

In der Tailscale-Konsole einen Auth-Key erzeugen (nicht „Ephemeral“, mit einem Tag wie tag:heinzel, damit das Gerät nicht abläuft), in Heinzel unter „Meine Server sind in einem Tailscale-Netz“ eintragen, für Headscale dazu die Adresse des Control-Servers. Heinzel tritt als Gerät heinzel bei, benutzt den Schlüssel einmal und vergisst ihn. Erlauben Sie dem Gerät in den Zugriffsregeln nur die betreuten Server auf deren SSH-Port, und legen Sie die Server mit ihrer Tailscale-Adresse (100.…) oder ihrem Namen an. Tailscale SSH wird nicht benutzt; Heinzel meldet sich am gewöhnlichen sshd an.

Was Heinzel über einen Server weiß

• Gedächtnis (Serverseite, „Was Heinzel weiß“): Betriebssystem, Dienste, Pfade, Eigenheiten. Heinzel aktualisiert es nach der Arbeit; Sie können es bearbeiten. Jede Session liest es zuerst. Es beschreibt den Host, wie er heute ist; was wann geschah, steht im Journal. Heinzel schreibt höchstens 12.000 Zeichen, die To-dos und das Gedächtnis eines Zugangs je 4.000. Würde ein Text länger, verdichtet Heinzel ihn: Geschichte, Erledigtes und Doppeltes fallen weg. Ist ein Text zu lang, den Sie von Hand gespeichert haben, verdichtet ihn die nächste Session. Neben der Überschrift steht, wie viel davon belegt ist.
• Gedächtnis eines Zugangs (gleiche Seite, ein Kasten je Zugang): was nur für diesen Benutzer gilt, etwa Home-Verzeichnis, sudo, Laufzeitumgebungen, Crontab. Eine Session liest das Gedächtnis des Zugangs, mit dem sie sich anmeldet, neben dem des Servers.
• Journal: jede Änderung auf dem Server mit ihrem Befehl, dazu Ihre Notizen von Hand („Kunde will keine Neustarts dienstags“).
• Übergabe: eine Markdown-Datei mit allem, was über den Server gespeichert ist, für die Kollegin, die ihn übernimmt. Kein Modell schreibt sie.
• Übergabenotizen auf dem Host: eine Zeile im Systemjournal des Hosts nach jeder Änderung, für alle mit Shell-Zugang und für eine zweite Heinzel-Instanz. Zwei Häkchen im Serverformular (hinterlassen, lesen), beide anfangs an. Wortlaut unter Einstellungen, Richtlinie.

$ journalctl -t heinzel
heinzel: [Anna Berg/root] nginx auf 1.28.0 aktualisiert, weil die alte Version eine Sicherheitslücke hatte
         https://heinzel-pro.de/beispiel/sessions/0199e2c4-…

Einen Host sperren, ohne Heinzel Pro zu öffnen

Wer root auf einem Host ist, hält Heinzel mit einer Datei zurück, die auch das offene Heinzel beachtet:

# /etc/heinzel.conf
allow_changes = false
reason = Datenbank-Migration bis 20.10.

Vor jedem ändernden Befehl liest Heinzel Pro die Datei. Nur eine fehlende Datei oder allow_changes = true lässt die Änderung durch; alles andere verweigert sie mit dem Grund des Besitzers am Befehl. Lesen läuft weiter. Der Classifier sperrt jeden Befehl, der die Datei schreibt oder löscht, also hebt nur der Besitzer die Sperre auf.