Fassung 26.09.02.20

Neu

open_basedir lässt sich je Domain erweitern. Unter Domains → Allgemein steht bei PHP das Feld Zusätzliche Pfade (open_basedir) — ein absoluter Pfad je Zeile. Anwendungen, die aus einem gemeinsamen Ordner lesen müssen — eine Bibliothek unter /usr/share/php, ein Schriftartenverzeichnis —, schrieben bisher bei jedem Zugriff eine Warnung ins Fehlerprotokoll, und es gab keinen Weg daran vorbei außer die Anwendung umzubauen. Die eingetragenen Pfade kommen hinten an das Dokumentenverzeichnis, das Verzeichnis der Domain und /tmp — ersetzt wird nichts, ein leeres Feld ist der bisherige Zustand. Ändern darf das Feld nur ein Administrator; / und der Ordner aller Subscriptions werden abgewiesen.
Das Update zeigt jetzt live, was es tut. Im Fenster des Rollouts läuft die Ausgabe des Nodes mit — welche Pakete geladen werden, welcher Dienst neu startet, ob eine Rücknahme läuft. Bisher stand dort nur der Status je Node, und was wirklich geschah, lag allein auf dem Node in /var/log/kastra-selfupdate.log. Nach dem Neustart der Control Plane verbindet sich die Anzeige wieder und holt nach, was in der Zwischenzeit gelaufen ist — genau die Zeilen des letzten Schritts, nach denen sonst am häufigsten gefragt wird.
Die Domain sagt jetzt selbst, wenn ihre DNS-Einträge draußen nicht ankommen. Am Bereich DNS stehen die Adressen, am Bereich Mail MX, SPF, DKIM und DMARC; im Kopf der Domain steht die Summe. Geprüft wird, was ein öffentlicher Resolver antwortet — nicht, was in der eigenen Zone steht: nur so fällt auf, wenn die Domain noch beim bisherigen Anbieter delegiert ist. Ein solcher Befund verdrängt die übrigen, weil sie nur seine Folge sind. Ein fremder MX neben dem eigenen ist ausdrücklich keine Warnung, und was eben erst geändert wurde, gilt eine Stunde lang als noch nicht geprüft. Geprüft wird nachts; Jetzt prüfen macht es sofort.
Datenbanken stehen jetzt auch an der Domain. Der Bereich zeigt, was ihr zugewiesen ist, und weist zu oder löst wieder. Der Menüpunkt Datenbanken bleibt daneben — eine Datenbank muss zu keiner Domain gehören.
Die Datenbankliste ist nach Domain gruppiert, dazu sortier- und filterbar. Datenbanken ohne Domain stehen am Ende in einer eigenen Gruppe; eine Datenbank an mehreren Domains erscheint unter jeder.
Die Domainliste lässt sich filtern und sortieren. Passt eine Subdomain, bleibt ihre Hauptdomain stehen — sonst verschwände der Treffer hinter einem Elternteil, das selbst nicht passt.
Mail steht jetzt an der Domain und lässt sich dort ein- und ausschalten. Beim Einschalten entstehen der DKIM-Schlüssel und die Einträge in der Zone von selbst; darunter steht in Sätzen, was geschehen ist — und was nicht, weil ein fremder Anbieter danebensteht. Ausschalten ist nicht Löschen: die Postfächer und ihre Inhalte bleiben liegen.
Ein vorhandener SPF-Eintrag wird erweitert, nie ersetzt. Wer neben Kastra weiter über Microsoft 365 oder einen anderen Anbieter verschickt, behält dessen Eintrag unverändert — dazu kommt nur der eigene Server. Gibt es in der Zone schon zwei SPF-Einträge, wird keiner geändert und gesagt warum. Im Modus nur Versand bleibt auch der fremde MX unangetastet.
Der DKIM-Schlüssel entsteht beim Einschalten, nicht erst auf Klick, und sein TXT-Eintrag landet in der eigenen Zone. Bisher stand er nur als Hinweistext da und musste von Hand übertragen werden — das Handbuch behauptete dabei das Gegenteil.
E-Mail-Weiterleitungen können mehrere Ziele haben, lassen sich bearbeiten und abschalten, statt sie zu löschen. Eine Weiterleitung braucht kein Postfach und belegt keinen Speicher.
Die Größe eines Postfachs lässt sich festlegen — beim Anlegen und jederzeit danach. Bisher schickte die Oberfläche sie gar nicht mit; jedes über das Panel angelegte Postfach hatte damit fest 1 GiB. 0 bedeutet unbegrenzt.
Der Tarif zählt jetzt auch Postfächer. max_mailboxes stand seit jeher in jedem Tarif und wurde nirgends geprüft — anders als die Zahl der Domains. Wer die Grenze erreicht hat, legt kein weiteres Postfach mehr an.
DNS steht jetzt an der Domain. Jede Domain hat einen Bereich DNS mit ihren Einträgen — dort, wo auch alles andere zu ihr steht. Die Seite DNS bleibt als Übersicht über alle Zonen: gehört eine Zone zu einer Domain, führt der Klick in deren Bereich; Zonen ohne Domain werden weiter dort bearbeitet. Der Editor ist an beiden Orten derselbe.
**Eine Subdomain sieht im Bereich DNS nur ihre eigenen Einträge.** Die Zone gehört der Hauptdomain; die ganze Zone steht weiterhin unter DNS.
Der Record-Editor zeigt, wer einen Eintrag pflegt — Kastra oder du. Zu jedem von Kastra gepflegten Eintrag sagt ein Hinweis, wofür er da ist.
Eine Subdomain bekommt ihre DNS-Einträge sofort. Bisher entstand beim Anlegen einer Subdomain kein einziger Eintrag — der Name löste erst auf, wenn jemand daran dachte, A und AAAA von Hand in die Zone der Hauptdomain zu schreiben. Jetzt stehen sie sofort dort, und beim Löschen der Subdomain verschwinden sie wieder.
Eine neue Zone bekommt alle Adressen ihres Nodes, nicht nur eine. Hat der Node zwei IPv4-Adressen oder zusätzlich IPv6, stehen sie alle in der Zone. Loopback und Link-Local bleiben draußen — sie standen bisher mit drin, sobald der Node sie meldete.
Ändert ein Node seine Adresse, ziehen die Zonen nach. A und AAAA der betroffenen Domains und Subdomains werden aktualisiert; die Zone bleibt richtig, ohne dass jemand daran denkt. Was von Hand geändert oder abgeschaltet wurde, bleibt unangetastet — der Record-Editor zeigt zu jedem Eintrag, ob Kastra ihn pflegt oder der Kunde.
Bestehende Zonen übernimmt Kastra nur auf Zuruf. Nach dem Update pflegt es zunächst nichts, was vorher schon da war. Unter DNS zeigt eine Vorschau je Zone, welche Einträge künftig nachgezogen würden — übernommen wird nur, was dem erwarteten Wert genau entspricht.
Objekt-Cache je Domain. Im Bereich Allgemein einer PHP-Domain gibt es den Schalter Objekt-Cache (Redis); darunter stehen Socket-Pfad und Datenbanknummer zum Eintragen in die Anwendung. ownCloud, Nextcloud, WordPress und Matomo laufen damit spürbar schneller — und hören auf, bei jedem Aufruf „Redis not available for local cache" ins Protokoll zu schreiben. Die Instanz gehört der Subscription und läuft in ihrem Slice, erreichbar allein über einen Unix-Socket mit ihren Rechten; zwei Domains derselben Subscription trennt die Datenbanknummer. Der Cache ist nach einem Neustart leer und schreibt nichts auf die Platte. Eingespielt wird redis-server samt PHP-Erweiterung über die neue Komponente Objekt-Cache unter Komponenten — ohne sie bricht der Rollout einer Domain mit eingeschaltetem Cache ab und sagt, was fehlt. Der Redis-Dienst der Distribution, auf dem auf einem Mailserver-Node rspamd sitzt, bleibt unangetastet.
Der Mailserver bekommt ein eigenes Zertifikat von Let's Encrypt. Bisher zeigten Postfix und Dovecot das Zertifikat des Panels vor — es lautet auf den Namen des Panels, nicht auf den, den jemand in sein Mailprogramm einträgt. Die Folge war ein Bild, das schwer zu deuten war: Programme, die den Namen prüfen, brachen mit einer Meldung über den Verbindungsaufbau ab, Programme, die ihn nicht prüfen, sendeten fehlerfrei; im Protokoll stand davon nur certificate unknown. Unter Nodes → Mailserver gibt es jetzt den Bereich Zertifikat für SMTP und IMAP: er stellt auf den Namen im SMTP-Gruß aus, nimmt weitere Namen dazu (aus den Maildomains des Nodes vorgeschlagen) und erneuert selbstständig 30 Tage vor Ablauf. Der Weg zurück auf das Panel-Zertifikat steht daneben.
**Der Bereich Mailserver nennt die Verbindungsdaten.** Server, Ports, Verschlüsselung und Anmeldung für Posteingang und Postausgang stehen jetzt im Panel — samt der Punkte, die immer wieder Zeit kosten: es gibt kein POP3, TLS 1.2 ist die Untergrenze, auf 143 und 587 ist STARTTLS Pflicht, und Port 25 gehört in kein Mailprogramm.
Ein Postfach lässt sich von einem anderen Anbieter übernehmen. Unter Mail → Postfächer → Bearbeiten steht der neue Bereich Übernahme von einem anderen Server: Server, Zugangsdaten und Verschlüsselung des alten Postfachs eintragen, Verbindung prüfen zeigt dessen Ordner, Übernahme starten holt den Bestand — mit Ordnerstruktur, Gelesen-Markierungen und Anhängen. Beim bisherigen Anbieter wird nichts verändert und nichts gelöscht. Jeder Lauf macht das Postfach zum Abbild der Quelle: er holt nichts doppelt und lässt sich wiederholen, räumt aber weg, was hier seit dem letzten Lauf zugestellt wurde. Der letzte Lauf gehört deshalb unmittelbar vor die Umstellung des MX-Eintrags. Der Lauf läuft als Aufgabe; bei einem großen Postfach dauert er.
Eine Domain kann einzelne Pfade an eine Anwendung weiterleiten, ohne die Webseite aufzugeben. Im Bereich Allgemein steht dafür der neue Schalter Einzelne Pfade an eine Anwendung weiterleiten; er erscheint bei PHP- und statischen Domains. Danach gibt es den Bereich Routen: dort führt jeder Eintrag einen Pfad wie /api auf eine Node.js-Anwendung, einen Container oder ein eigenes Ziel. Alles Übrige liefert die Domain weiter selbst aus. Bisher gehörte eine Domain ganz einer Anwendungsart — wer neben WordPress einen Node-Dienst brauchte, musste die ganze Domain umstellen und PHP verlieren.
Node.js-Anwendung und Container laufen jetzt auch dann, wenn die Domain auf PHP steht. Sobald eine Route auf sie zeigt, legt Kastra ihre systemd-Unit an und startet sie — vorher hing das allein an der Anwendungsart der Domain. Eingerichtet wird die Node.js-Anwendung im Bereich Anwendung: bei eingeschaltetem Mischbetrieb steht die Dienstverwaltung dort unterhalb des App-Installers, mit Fassung, Startdatei, Arbeitsverzeichnis und Deploy.
**Der Bereich Container steht auch einer PHP-Domain offen.** Gibt sie einzelne Pfade an einen Container ab, braucht sie eine Compose-Datei — die steht dort, und der Bereich erscheint jetzt in der Bereichsleiste, sobald der Haken für den Mischbetrieb sitzt. Vorher zeigte ihn nur die Laufzeitumgebung Container: die Route liess sich eintragen, die Compose-Datei dazu nirgends pflegen.
**Der Bereich Protokolle zeigt auch die Ausgabe einer Anwendung, die nur an einem Pfad hängt.** Gibt eine PHP-Domain /api an eine Node.js-Anwendung oder einen Container ab, stehen Ausgabe (Node.js), Fehler (Node.js) und die laufenden Container jetzt neben PHP-Fehler. Vorher entschied allein die Laufzeitumgebung der Domain, welche Protokolle dastanden — die Anwendung lief, schrieb, und ihre Ausgabe war nur über Dateimanager, SFTP oder Terminal zu finden.
Die Routen einer Container-Domain sind in einen eigenen Bereich gezogen. Sie standen bisher im Bereich Container unter der Compose-Datei. Dort steht jetzt nur noch, welcher Pfad welchen Port bekommen hat — die Angabe, die beim Schreiben der Compose-Datei gebraucht wird. Bearbeitet werden sie unter Routen.
Das Dokumentenverzeichnis lässt sich jetzt ändern, und zwar jederzeit im Bereich Allgemein einer Domain. Es darf auch tiefer liegen — httpdocs/public ist das, was Laravel, Symfony und viele Node-Anwendungen mit eigenem Ausgabeordner brauchen. Bisher stand es nur beim Anlegen zur Wahl und danach unveränderlich da. Verschoben wird beim Ändern nichts: die Einstellung sagt, wo der Webserver nachsieht.
Der Ordner einer Domain heißt jetzt auch so: Arbeitsverzeichnis. Er steht neben dem Dokumentenverzeichnis im Kopf der Domain und im Bereich Allgemein. Darin liegt alles, was zur Domain gehört und nicht ausgeliefert wird — ein geholtes Repository in repo, die Node.js-Anwendung in app, die Compose-Datei. Damit kommt niemand über den Browser an Quelltext, .env oder node_modules.
Ein Repository lässt sich filtern. Im Bereich Repository einer Domain stehen zwei neue Felder: Nur diese Ordner und Dateien und Davon ausnehmen. Einträge sind Pfade relativ zur Wurzel des Repositories, mit Platzhaltern wie *.md oder docs/**. Damit landet nur noch die Webseite auf dem Server und nicht auch Quelltext, Tests und CI-Dateien.
Ein einzelner Ordner wird zur Wurzel. Wählst du genau einen Ordner, liegt sein Inhalt direkt im Zielverzeichnis — aus webseite/index.html im Repository wird index.html im Dokumentenverzeichnis, ohne einen Ordner webseite davor. Bei mehreren Einträgen bleibt die Ordnerstruktur erhalten. Der Dialog sagt vorher an, welcher der beiden Fälle gilt.
Sobald gefiltert wird, hält Kastra das Arbeitsverzeichnis von git neben dem Ziel und spiegelt hinein. Im ausgelieferten Verzeichnis liegt dann kein .git mehr. Lokale Änderungen verwerfen bedeutet dort: das Ziel wird genau abgeglichen — was nicht aus dem Repository kommt, wird entfernt. .well-known bleibt immer stehen.
**Der Mailbereich hat einen Reiter Protokoll.** Er zeigt, was der Mailserver zu der ausgewählten Domain protokolliert hat — Annahme, Zustellversuch und die Antwort der Gegenstelle im Wortlaut. Die Warteschlange sagt, dass etwas liegen bleibt; warum, stand bisher nur auf dem Node in journalctl. Gezeigt wird, was zu den Sendungen dieser Domain gehört — auch die Zeile über den Ausgang, in der nur noch Warteschlangenkennung und Empfänger stehen. Gescheiterte Zustellungen sind rot, verschobene gelb. Filter und Zeilenzahl wie im Protokoll einer Webdomain.

Geändert

Unterhalb eines weitergeleiteten Pfades entscheidet die Anwendung, was ausgeliefert wird. Zwei Regeln des Webservers gelten dort nicht mehr: eine .htaccess greift nicht (im Modus nginx + Apache fängt nginx den Pfad ab, bevor Apache ihn sieht), und die Sperre für Dateien, die mit einem Punkt beginnen, entfällt. Das betrifft nur Pfade, die du selbst unter Routen eingetragen hast.
KASTRA_SESSION_SECRET muss mindestens 64 Zeichen haben. Bei 32 bis 63 startete die Control Plane und schlug danach bei jeder Anmeldung fehl — die Signatur der Sitzung verlangt 512 Bit. Von Kastra selbst erzeugte Werte sind 64 Zeichen lang und unverändert gültig. Ein kürzerer, von Hand eingetragener Wert lässt die Control Plane jetzt beim Start mit einer klaren Meldung abbrechen, statt später unerklärlich zu scheitern.
packaging/apt-repo.sh client verlangt den Fingerabdruck des Repo-Schlüssels (KASTRA_REPO_KEY_FINGERPRINT), sobald er über das Netz geholt wird, und lehnt eine http-Adresse ab, solange nicht KASTRA_REPO_INSECURE=1 gesetzt ist. Über diesen Schlüssel installiert apt als root; ohne Vergleich ließe sich unterwegs ein anderer unterschieben.
Drei Tabellen entfallen (ip_address, installed_runtime, dns_provider). Sie waren seit jeher leer und wurden von nichts gelesen.
Auf der Übersicht führt jede Zahl dorthin, wo sie herkommt. Die vier Kacheln sind jetzt Verweise auf Nodes, Subscriptions, Domains und Aufgaben, und ein Klick auf eine Node-Karte öffnet den Node. Bisher stand die Zahl nur da, und der Weg ging über das Menü.
Bei den letzten Aufgaben steht, worum es ging. Neben Art, Zustand und Meldung nennt die Zeile jetzt die Domain, die Subscription oder den Node — „Rollout erfolgreich" allein sagte nur, dass irgendwo etwas geschah. Bei einem Fehlschlag steht die Fehlermeldung darunter, und Protokoll öffnet die Aufgabe aufgeklappt samt vollständiger Ausgabe. Diese Adresse (/jobs?aufgabe=42) lässt sich auch als Lesezeichen ablegen oder weitergeben.
Der Probelauf der Wiederherstellung nennt die erwartete Dateizahl und den Grund eines Fehlschlags. Bisher stand dort „fehlgeschlagen" und eine Zahl ohne Vergleichswert.
**Die Kachel Nodes verbunden und der Abschnitt Nodes erscheinen nur noch für Administratoren.** Allen anderen zeigten sie dauerhaft „0 / 0" und die Anleitung, einen Node anzumelden.
Das Panel bringt kein Skript mehr direkt in der Seite unter. Nötig für die neue Content-Security-Policy: was inline steht, müsste sie erlauben — und damit erlaubte sie es jedem. Das Umschalten auf Hell und Dunkel liegt jetzt in einer eigenen Datei, und die kritischen Stile werden nicht mehr in die Seite eingebettet. Sichtbar ändert sich nichts.

Behoben

Ein über „Über GitHub anmelden" verbundenes Konto landete immer an der ersten Subscription und nie installationsweit — die Auswahl ging beim Wechsel zu GitHub verloren. Für den Benutzer sah das aus, als ginge der Zugang immer wieder verloren; er lag nur woanders, und bei jedem Versuch entstand eine weitere Zeile. Die Auswahl reist jetzt mit.
GitHub-Konten werden jede Nacht geprüft. Ein Zugang, der nicht mehr gilt, steht als Fehler am Konto, statt erst beim nächsten Holen eines Repositories aufzufallen. Dazu der Knopf Jetzt prüfen.
Beim Löschen einer Subscription verschwand ein verbundenes GitHub-Konto wortlos. Es verschwindet weiterhin — aber es steht jetzt im Prüfprotokoll.
Ein frisch eingerichtetes Nextcloud schreibt sein Protokoll nicht mehr voll. Nextcloud prüft vor jedem Dateizugriff mit realpath(), ob ein Symlink aus dem Datenverzeichnis herausführt, und steigt dabei bis zur Wurzel auf. Unter open_basedir schlägt jeder dieser Schritte fehl, die Schleife kommt nicht ans Ende — ein einziger Zugriff eines WebDAV-Clients füllte nextcloud.log um Megabytes. Der App-Installer schaltet die Prüfung jetzt ab (die Grenze selbst bleibt: open_basedir und der Unix-Benutzer der Subscription lassen keinen Symlink nach draußen) und deckelt das Protokoll bei 10 MiB. Bei bestehenden Installationen sind die beiden Werte von Hand zu setzen: occ config:system:set localstorage.allowsymlinks --value=true --type=boolean und occ config:system:set log_rotate_size --value=10485760 --type=integer.
Im Dateimanager standen kurze Dateinamen nicht bündig unter den langen. Ordner und bearbeitbare Dateien lagen in einem Knopf, der jeden Namen unter 64 Pixeln mittig setzte; die übrigen Namen standen links. Jetzt beginnen alle drei an derselben Stelle — auch „Eine Ebene höher“.
Ein Node verschickt Mail wieder über IPv4, wenn beide Wege offen sind. Bisher wählte Postfix selbst und nahm oft IPv6. Große Empfänger — Microsoft voran — weisen eine Zustellung über IPv6 mit „450 4.7.25“ zurück, solange die sendende Adresse keinen PTR-Eintrag hat; die Mail blieb dann in der Warteschlange liegen. Angenommen wird weiterhin über beide Protokolle. Wer über IPv6 versenden will, braucht dafür einen PTR, einen AAAA-Eintrag zurück auf dieselbe Adresse und einen ip6:-Eintrag im SPF.
Unter /webmail/ beantwortete der Vhost auch config/, logs/, temp/ und installer/ mit einer Seite. Zu sehen war nur die Anmeldemaske — die Verzeichnisse liegen neben dem Wurzelverzeichnis, ihr Inhalt kam nie heraus. Von außen ist eine solche Antwort aber nicht von einem erreichbaren Installer zu unterscheiden, und ein Scanner meldet sie als Fund. Diese Pfade antworten jetzt mit 404.
Die Container-Übersicht schob auf schmalen Schirmen die ganze Seite zur Seite. Die Tabelle brauchte rund 770 Pixel und nahm sie sich; auf einem Telefon ließ sich die Seite danach waagerecht schieben, und der Kopf lief aus dem Bild. Jetzt rollt die Tabelle für sich, die Seite bleibt stehen. Ebenso im Bereich Container einer Domain und in der Übersicht einer Laufzeitumgebung.
Ein Rollout nahm eine fehlerfreie Konfiguration zurück, weil die Anwendung dahinter klemmte. Der Healthcheck wertete jeden Fehlercode außer genau 500 als Zeichen dafür, dass die Konfiguration nicht taugt — auch einen, den nginx gar nicht selbst erzeugen kann. Eine Anwendung, die etwa 599 lieferte, brachte ihre Domain damit in eine Sackgasse: der Rollout rollte zurück, der nächste tat dasselbe, und keine Änderung an der Domain kam mehr an. Als Ausfall des Upstreams gelten jetzt genau 502, 503 und 504; jeder andere Fehler kommt aus der Anwendung, wird gemeldet und lässt die Konfiguration stehen.
Eine Domain liess sich nicht auf PHP 7 stellen. Die Laufzeiten-Seite spielte 7.0 bis 7.4 ein und wies sie als ohne Sicherheitsupdates aus, die Fassung stand danach auch in der Auswahl der Domain — beim Speichern kam aber „PHP 7.4 wird nicht unterstützt". Die Prüfung der Domain war bei 8.1 bis 8.4 stehengeblieben. Wer eine Anwendung betreibt, die kein PHP 8 kann — ownCloud etwa —, kann sie jetzt hier betreiben statt auf einem Server daneben. Ob die Fassung auf dem Node liegt, entscheidet weiterhin der Node beim Rollout.
Das Webmail zeigte keine einzige Nachricht. Ordner, Rahmen und die Zahl der ungelesenen Nachrichten standen da, die Liste blieb leer — in jedem Postfach und in jedem Ordner. Die Sicherheitsregel des Panels verbot Roundcube, seine eigenen Antworten auszuführen; alles, was nicht schon im Seitenaufbau steckte, verwarf der Browser stillschweigend. Auf dem Server war davon nichts zu sehen, weil dort nichts fehlschlug. Betroffen waren ausser der Nachrichtenliste auch das Öffnen einer Nachricht, die Suche und der Wechsel des Ordners. Die Regel erlaubt es jetzt; bestehende Installationen bekommen sie beim Aktualisieren nachgetragen.
Die Selbsteinrichtung bot POP3 an, das es nicht gibt. Thunderbird und Outlook bekamen von Kastra einen POP3-Zugang auf Port 995 genannt; Dovecot läuft aber nur mit IMAP, und die Verbindung lief ins Leere. Angeboten wird jetzt nur noch IMAP.
Die Selbsteinrichtung nannte den falschen Servernamen. Sie trug den Hostnamen des Nodes ein statt den Namen aus dem SMTP-Gruß. Wer beides verschieden gesetzt hatte, richtete sein Mailprogramm damit auf einen Namen ein, für den das Zertifikat nicht gilt — und bekam bei jedem Abruf eine Rückfrage.
Ein neu ausgestelltes Zertifikat wurde nicht ausgeliefert. Nach Zertifikat ausstellen zeigte der Bereich Zertifikat die neue Laufzeit und Let's Encrypt als Quelle — im Browser kam weiterhin das alte, selbstsignierte Zertifikat an. Der Pfad im Vhost bleibt derselbe, wenn ein neues Zertifikat kommt; der Rollout danach hatte deshalb nichts zu schreiben und lud nginx nicht neu, und nginx hält sein Zertifikat seit dem letzten Neuladen im Speicher. Erst ein Neustart des Dienstes brachte es zum Vorschein. Das betraf auch die automatische Erneuerung 30 Tage vor Ablauf und die Umstellung auf ein selbstsigniertes Zertifikat: dort fiel es niemandem auf, bis das alte Zertifikat im Betrieb ablief. nginx wird jetzt unmittelbar nach der Ausstellung neu geladen, und jeder Rollout prüft zusätzlich, ob seit dem letzten Durchlauf ein Zertifikat ausgetauscht wurde.
In der Warteschlange stand jede Sendung ohne Empfänger und ohne Grund. Unter Mail → Warteschlange blieben beide Angaben leer, obwohl Postfix sie meldet. Der Grund steht bei postqueue -p am Zeilenanfang statt eingerückt; Kastra las ihn als Beginn einer neuen Sendung, und die Empfänger darunter gehörten damit zu keiner mehr. Gerade bei einer stockenden Zustellung war so nicht zu sehen, an wen und woran es hängt.
Das Webmail stand ohne Stilvorlage und ohne Skripte da. Roundcube liefert seine Stilvorlagen und Skripte über static.php aus und hängt den Dateinamen als Pfad an. Der Vhost des Panels reichte nur weiter, was auf .php endete — alles andere kam als Anmeldeseite zurück, und der Browser verwarf es. Sichtbar war eine unformatierte Liste, auf der nichts funktionierte. Ein Update trägt die Regel an einem bestehenden Vhost nach; die alte Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-pathinfo liegen.
Die Nachrichtenansicht des Webmails blieb leer. Roundcube zeigt eine Nachricht in einem eingebetteten Rahmen und erlaubt das ausdrücklich für die eigene Herkunft; der Vhost des Panels verbot daneben jedes Einbetten. Zwei widersprechende Angaben, und der Browser verbietet dann alles — auch das Einbetten der eigenen Seiten. Das Webmail hat jetzt seinen eigenen Satz Kopfzeilen: Rahmen von derselben Herkunft sind erlaubt, Bilder aus einer Nachricht dürfen von fremden Servern kommen, alles Übrige bleibt zu. Ein Update trägt das nach; die alte Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-rahmen liegen.
Zwei Zonen blieben aus dem Nameserver heraus, weil einem MX-Eintrag die Vorrangzahl fehlte. Ein MX besteht aus Zahl und Ziel („10 mail.example.com."); wer den Wert aus dem Microsoft-365-Portal kopiert, bekommt dort nur den Namen zu sehen und die Zahl fällt weg. PowerDNS weist dann die ganze Zone ab. Neue Einträge dieser Art werden schon länger beim Speichern abgewiesen — bereits gespeicherte bekommen jetzt die 10 nachgetragen.
Fehlt am Dateisystem die Quota-Option, stand das bisher zweimal je Subscription im Rollout-Protokoll. Auf einem Node mit vierzig Subscriptions waren das achtzig Zeilen mit demselben Text. Jetzt steht es einmal, nennt die Zahl der betroffenen Subscriptions und den Weg zum Einschalten.
Bei vielen gleichzeitigen Vorgängen blieb das Panel stehen. Lange Aufgaben auf dem Node — ein Sicherungslauf, eine Wiederherstellung, der Rückspieltest — hielten die ganze Zeit eine Datenbankverbindung besetzt; bei wenigen gleichzeitig war keine mehr frei. Sie halten jetzt keine mehr.
Nach einem Fehlschlag verschwanden auch die geglückten Läufe. Schlug in einem nächtlichen Durchlauf eine Sicherung fehl, nahm das die Einträge aller Läufe dieses Durchlaufs mit — am Morgen sah es aus, als hätte gar nichts stattgefunden. Dasselbe galt für die Erneuerung der Zertifikate.
Ein laufender Sicherungslauf, Suchlauf oder Deploy ist jetzt schon während der Arbeit zu sehen. Die Zeile entstand bisher erst am Ende.
Ein abgelaufener Befehl läuft auf dem Node nicht mehr weiter. Die Control Plane gab nach ihrer Frist auf, der Node arbeitete weiter — ein zweiter Versuch lief dann parallel zum ersten.
Die Drift-Erkennung meldet jetzt auch Dateien, die zu viel da sind. Ein liegengebliebener Vhost einer gelöschten Domain fiel vorher niemandem auf, obwohl nginx ihn weiter lud.
Jede Fehlermeldung sagt, was jetzt gilt. Zwanzig Meldungen nannten nur den Fehlschlag und ließen offen, ob etwas halb angelegt ist.
Fehler bei der Ausstellung des Panel-Zertifikats bleiben stehen. Der Fehlertext wurde bisher beim Zurückrollen mit gelöscht.
Auf dem Node mit der Control Plane öffnet die Firewall die beiden Agent-Ports. Sie standen nirgends im Regelwerk. Auf einer Anlage mit einem einzigen Node fiel das nie auf — dessen Agent kommt über die Loopback-Regel herein. Ein entfernter Node kam bei eingeschalteter Firewall nicht durch.
Die Indexdateien einer Domain kommen aus der Datenbank. Die Spalte gab es, gelesen wurde sie nie — der Node bekam eine fest eingebaute Liste. Für bestehende Domains ändert sich nichts.
test/e2e-node.sh lässt die Firewall nicht mehr abgeschaltet zurück. Der Lauf merkt sich ihren Zustand und stellt ihn wieder her.
WildFly lässt sich wieder einspielen. Die Archive liegen seit einiger Zeit nicht mehr auf download.jboss.org — jeder Versuch endete mit „WildFly konnte nicht eingerichtet werden", und die Meldung fragte nach der Fassungsnummer, obwohl die stimmte. Geholt wird jetzt von den GitHub-Releases des Projekts. Der Node braucht dafür Zugang zu github.com.
Der Download aus dem Dateimanager funktioniert wieder in Firefox und Safari. Dort passierte beim Klick auf Herunterladen schlicht nichts.
Eine zu große Datei bleibt im Editor wirklich schreibgeschützt. Der Hinweis daneben sagte es, tippen ließ sie sich trotzdem — und was man tippte, war beim Speichern weg.
Die Brotkrumenleiste und die Abfrage des GitHub-Gerätecodes räumen sich wieder auf. Beide liefen nach dem Verlassen der Seite weiter; die GitHub-Abfrage bis zu 15 Minuten, samt Meldung zu einer längst geschlossenen Seite.
Zweimal Ausrollen ergibt auch bei Firewall-Freigaben und Cronjobs einen leeren Diff. Beide standen in der Reihenfolge der Datenbank in der Datei; bei nftables kostete das mehr als eine Zeile im Diff, denn jede Änderung lädt die Regeltabelle als Ganzes neu.
Ein SFTP-Zugang, dessen Verzeichnis sich nicht herrichten lässt, hält nicht mehr den ganzen Node auf. Er wird gemeldet, die übrigen Zugänge werden weiter bedient.
Auf dem Telefon rollte das Panel auf vielen Seiten waagerecht. Ein langer Pfad oder ein Statustext ohne Leerzeichen schob die Seite auf bis zu 642 statt 390 Pixel. Beides bricht jetzt um.
Die Suche im Audit-Log passt auch auf ein zusammengeklapptes Faltgerät (280 Pixel).
Der Bericht vor dem Update rollte waagerecht. Sein Inhalt war 620 Pixel breit angelegt, das Blatt selbst nur 560 — bei einem langen Changelog stand die Liste halb außerhalb. Lange Pfade und Kopfzeilennamen brechen jetzt ebenfalls um.
Die leere Warteschlange sah belegt aus. Unter Mail → Warteschlange stand eine Sendung mit der Kennung Mail, dem Eingang is und der Größe 0 B — in Wahrheit die Antwort von Postfix auf eine leere Warteschlange („Mail queue is empty"), Wort für Wort in die Spalten verteilt. Die Liste bleibt jetzt leer, wenn nichts liegt.
Eine neue Node.js-Domain legte den Rollout des ganzen Nodes still. Beim Anlegen bekam sie keinen Port; der Rollout brach mit „fuer app.example.com wurde kein Port vergeben" ab — und mit ihm die Konfiguration jeder anderen Domain auf demselben Node, denn der Rollout schreibt alles oder nichts. Der Port entsteht jetzt mit der Domain, so wie eine PHP-Domain ihre Fassung mitbekommt; dasselbe gilt beim Umstellen einer bestehenden Domain auf Node.js. Eine Domain, die schon ohne Port angelegt wurde, bekommt ihn beim nächsten Rollout: die Control Plane sieht vor jedem Rollout nach, ob jede Node.js-Domain ihren Port hat, und trägt ihn nach. Von Hand ist dafür nichts zu tun.
Der fehlende Port meldete sich als fehlende Node.js-Fassung. Der Rollout brach mit dem Code RUNTIME_NOT_INSTALLED und dem Hinweis ab, die Version unter /opt/node zu installieren — auf dem Node fehlte aber nichts. Der Fall hat jetzt einen eigenen Code (NODE_PORT_MISSING) und einen Hinweis, der auf die Control Plane zeigt.
Ein gefiltertes Repository ließ sich nicht holen. Sobald einer der beiden Filter etwas enthielt, endete der Lauf mit „Permission denied". Kastra hält das Arbeitsverzeichnis dann neben dem Ziel, und der Ordner darüber gehörte root — der Benutzer der Subscription, unter dem git und die Spiegelung laufen, kam nicht hindurch. Er gehört jetzt der Subscription; auf Nodes, auf denen er schon falsch angelegt wurde, zieht Kastra das beim nächsten Holen von selbst gerade. Ohne Filter war nie etwas betroffen.
Ausgehende Mail wurde mit dem falschen DKIM-Selektor signiert. Im DNS steht kastra._domainkey, die Signatur nannte aber dkim — jede Prüfung beim Empfänger suchte einen Schlüssel, den es nicht gibt, und meldete die Nachricht als nicht verifiziert. Die Zuordnung Domain → Selektor lag als Datei für root auf dem Node und war für Rspamd nicht lesbar; Rspamd fiel darauf still auf seinen eigenen Vorgabewert dkim zurück. Die Datei gehört jetzt Rspamd, und der Rückfall lautet kastra. Nach dem Update genügt ein Rollout, im DNS ist nichts zu ändern.