Zum Inhalt
Getestet, wie es benutzt wird. Kastra ist nicht unter Produktionsbedingungen geprüft — auch der Kanal stabil nicht. Was das heißt.
test 26.10.28.2 stabil 26.10.12.1

Changelog · Kanal Test

Kanal Test

Jeder Bau, der die Gates besteht, landet hier — schnell und oft. Aktuell: 26.10.28.2, veröffentlicht am 28. Oktober 2026.

26.10.28.2

Eingriff am Node Test 108 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.
  • Unter Einstellungen › PHP gibt es eine allgemeine PHP-Konfiguration für alle Nodes und alle PHP-Fassungen: Grenzen, Fehler und Regionales, Sitzungen, OPcache, FPM-Prozesse und freie php.ini-Zeilen. Jede Domain erbt, was sie nicht selbst setzt; bei jedem Feld steht, wie viele Domains abweichen. Nur für Administratoren.
  • Der Bereich PHP einer Domain zeigt bei jedem Feld, ob der Wert eigen ist oder wie allgemein; ein leeres Feld oder Alles wie allgemein setzt ihn zurück. Neu dort: Sitzungs-Cookies (nur über HTTPS, HttpOnly, SameSite, nur bekannte Kennungen), das OPcache-Prüfintervall, freie php.ini-Zeilen und — für Administratoren — die FPM-Prozesse samt harter Zeitgrenze und Protokoll langsamer Anfragen.
  • Dauert eine PHP-Anfrage länger als eingestellt, steht ihr Aufrufstapel im neuen Protokoll Langsame PHP-Anfragen der Domain.
  • Die PHP-Fassung des Webmails lässt sich im Bereich Mailserver eines Nodes einstellen, unabhängig von den Maildomains. Automatisch bleibt die Voreinstellung und wählt wie bisher die neueste Fassung bis 8.3. Fehlen der gewählten Fassung Erweiterungen, die Roundcube braucht, bleibt das Webmail auf der automatischen Wahl, und der Rollout nennt die fehlenden Pakete. Eine Fassung, auf der das Webmail eingestellt ist, lässt sich unter Laufzeiten nicht entfernen.
  • Kastra prüft die Software auf jedem Node gegen bekannte Sicherheitslücken: jedes installierte Paket — auch PostgreSQL, OpenSSL, OpenSSH und den Kernel —, dazu Node.js, WildFly, phpMyAdmin, Roundcube, Composer und WP-CLI. Die Daten kommen nachts von Debian, Ubuntu, php.net, der Node.js Security-WG, OSV und endoflife.date; der Paketbestand verlässt dafür den Server nicht. Der neue Bereich Sicherheitslücken eines Nodes nennt je Technologie Paket, installierte Fassung, Fix-Fassung, CVE, betroffene Domains und den nächsten Schritt; eine Lücke, die nicht greift, lässt sich mit Begründung quittieren.
  • Die Seite Sicherheitslücken zeigt dasselbe über alle Nodes und beantwortet, ob eine bestimmte Technologie irgendwo betroffen ist. Eingestellt wird unter Einstellungen › Sicherheitslücken: Schwelle des Alarms, Karenz und die Adressen der Quellen (leer schaltet eine Quelle ab, etwa ohne Internet oder mit eigenem Spiegel). Nur für Administratoren.
  • Neue Alarmarten: SCHWACHSTELLE meldet behebbare Lücken ab Dringlichkeit hoch und — kritisch — jede Lücke, die laut CISA aktiv ausgenutzt wird; Fixe, die die automatischen Sicherheitsupdates selbst holen, erst nach 48 Stunden. LEBENSENDE meldet Software ohne Sicherheitsupdates (etwa PHP 8.1 oder Node.js 20), SCHWACHSTELLEN_DATEN eine Quelle, die länger als 72 Stunden nicht abgerufen werden konnte.
  • Im Bereich Sicherheitslücken eines Nodes spielt Aktualisieren den Fix eines Befunds ein, Alle behebbaren aktualisieren alle auf einmal — als Aufgabe mit Protokoll, danach verschwindet der Befund. Das ist auch der Weg für PHP aus sury: die automatischen Sicherheitsupdates holen es weiterhin nicht, weil sury neben PHP neuere Bibliotheken mitbringt. Was sich so nicht beheben lässt (phpMyAdmin, Roundcube, Composer, WP-CLI, ein Kernel, der nur neu starten muss), nennt den Grund.
  • Läuft auf dem Host der Control Plane kein Agent, zeigt die Seite Sicherheitslücken ihn als „nicht erfasst“: PostgreSQL und Java dort werden dann nicht geprüft.
  • Die Control Plane lädt dafür einmal am Tag Daten von security-tracker.debian.org, security-metadata.canonical.com, cisa.gov, php.net, raw.githubusercontent.com, osv-vulnerabilities.storage.googleapis.com und endoflife.date. Sie liegen unter /var/lib/kastra-control-plane/schwachstellen.
  • Erkannter Spam landet im Ordner Junk des Postfachs. Bisher bekam er nur den Kopf X-Spam: Yes und blieb im Posteingang, weil kaum ein Mailprogramm diesen Kopf auswertet. Unter Mail › Spamfilter lässt eine Maildomain ihn auf Wunsch im Posteingang.
  • Der Bereich Mailserver eines Nodes hat einen Abschnitt Spamfilter mit drei Schwellen in Punkten: Greylisting ab (Vorgabe 4), Spam ab (6) und Ablehnen ab (15). Nur für Administratoren.
  • Jede Maildomain führt unter Mail › Spamfilter zwei Absenderlisten: Nie Spam (weder vertagt noch abgelehnt noch im Junk-Ordner) und Immer Spam (immer im Junk-Ordner), je Zeile eine Adresse oder @domain.
  • Verschiebt jemand eine Mail in den Junk-Ordner, lernt der Spamfilter sie als Spam; holt er sie heraus, als erwünscht — in jedem Mailprogramm über IMAP und im Webmail.
  • Eingehende Mail trägt im Kopf X-Spamd-Result mit den Punkten und den Regeln, die angeschlagen haben, und X-Spam-Status. Daran lässt sich ablesen, warum eine Mail im Junk-Ordner liegt.
  • Die Mailstatistik einer Maildomain und eines Nodes hat einen Abschnitt Spamfilter: wie viele eingehende Mails sauber, vertagt, als Spam markiert und abgelehnt wurden, wie oft jemand Spam selbst in den Junk-Ordner gelegt oder erwünschte Post herausgeholt hat, die Quoten Spam erkannt und Fehlalarme mit einer Empfehlung zur Schwelle und die Verteilung der Punkte mit den Schwellen des Nodes. Als Spam bewertete oder abgelehnte versendete Mail steht als Warnung darunter. Gezählt wird ab dem Update.
  • Die Liste Sendungen zeigt bei jeder Mail, die Rspamd bewertet hat, ihre Punkte.
  • Der Bereich Sicherheitslücken prüft auch die Bibliotheken, die eine Software mitbringt: jedes Jar von WildFly, vendor/ von phpMyAdmin und Roundcube, den Inhalt von Composer und WP-CLI und die Go-Module von Programmen aus einer fremden Paketquelle wie CrowdSec. Ein Befund heißt dann etwa io.undertow:undertow-core (wildfly-36.0.1.Final) und sagt, woher der Fix kommt. Ein WildFly 36.0.1 bringt zum Stand dieses Updates rund 90 behebbare Lücken mit, ein wp-cli 2.12.0 ein Composer 2.2.25 mit mehreren hohen.
  • Für Node.js zählt zusätzlich jede Sicherheitsfassung, die nodejs.org für den installierten Major führt — auch eine, die nur OpenSSL, undici oder npm erneuert und dafür keine CVE der Security-WG hat.
  • Unter Einstellungen › Sicherheitslücken stehen drei neue Quellen: Node.js Releases (nodejs.org), OSV Maven und OSV Go. Die Control Plane lädt dafür zusätzlich von nodejs.org; eine leere Adresse schaltet eine Quelle ab.
  • WildFly wird überwacht: fällt er aus oder antwortet er drei Minuten lang nicht, startet Kastra ihn neu — bei einem Hänger nach einem Thread-Dump ins Journal. Zu jedem Ausfall steht unter Laufzeiten › WildFly, wann er war und woran es lag, etwa Speichermangel, ein Absturz der JVM oder ein von außen gesendetes Signal. Nach fünf Neustarts in 30 Minuten gibt Kastra beim nächsten Ausfall auf, hält WildFly an und meldet die neue Alarmart WILDFLY_DOWN mit allen Ursachen. Starten im Panel setzt die Zählung zurück.
  • Eine Domain lässt sich im neuen Bereich Umzug in eine andere Subscription verschieben — zu einem anderen Kunden oder auf einen anderen Node. Sie zieht mit allen Subdomains, Datenbanken, Cronjobs, FTP-Zugängen, Mail und DNS um; eine Domain, die dieselbe Datenbank nutzt, zieht mit. Die Vorprüfung zeigt die ganze Gruppe mit dem Grund je Domain und prüft beim Wechsel des Nodes, ob dort läuft, was die Gruppe braucht (PHP-Fassung und Erweiterungen, Apache, Node.js, Podman, WAF, Objekt-Cache, Composer, MariaDB, Mail, FTP) und ob er den Sicherungsspeicher der Quelle erreicht, über den die Daten gehen. Gespeicherte Pfade in Cronjobs, Compose-Dateien, Zusatzkonfiguration und PHP-Einstellungen werden umgeschrieben; Dateien der Anwendung, die das alte Verzeichnis nennen, meldet die Vorprüfung. Nur für Administratoren.
  • Zieht eine Domain, die auf WildFly zeigt, auf einen anderen Node, zieht WildFly mit — samt Anwendungen, Konfiguration und jeder anderen Domain, die ebenfalls darauf zeigt, auch aus fremden Subscriptions. Die Vorprüfung nennt das in einem eigenen Block und verlangt eine Bestätigung; auf dem Ziel darf noch kein WildFly laufen.
  • Ein gescheiterter Domain-Umzug auf einen anderen Node lässt sich zurücknehmen; Quelle freigeben entfernt danach die alten Daten. Beides steht auch im Bereich Umzug der Subscriptions.
  • Eine Subdomain kann allein umziehen: im Bereich Umzug einer Subdomain gibt es die Wahl Nur … herauslösen. Sie zieht samt ihren eigenen Subdomains in die Ziel-Subscription — auch auf einen anderen Node — und ist dort eine eigene Domain. Ihr Ordner behält seinen Pfad unter dem Ordner der Subscription (…/example.com/shop.example.com); zieht die Hauptdomain später nach, kommt sie in denselben Ordner dazu. Die Hauptdomain und ihre übrigen Subdomains bleiben, wo sie sind, und liefern während des Umzugs weiter aus. Die DNS-Einträge bleiben in der Zone der Hauptdomain, beim Wechsel des Nodes werden dort nur ihre Adressen umgestellt. Teilt die Hauptdomain eine Datenbank mit der Subdomain, weist die Vorprüfung das Herauslösen ab, statt die ganze Domain umzuziehen.
  • Der Branch eines Repositories lässt sich über Bearbeiten wechseln: der Dialog bietet die Branches bei GitHub zur Auswahl an, und beim Speichern holt Kastra den neuen Branch sofort und stellt das Verzeichnis darauf um. Ohne Lokale Änderungen verwerfen bricht der Wechsel ab, wenn geänderte Dateien im Weg sind, und das Verzeichnis bleibt auf dem bisherigen Branch. Bisher nahm Bearbeiten einen anderen Branch zwar an, im Verzeichnis blieb aber der alte stehen — oder das nächste Holen scheiterte.

Geändert

  • Welche DNS-Zone zu einer Domain gehört, sucht Kastra über den Namen: die eigene, sonst die Zone mit dem längsten Namen darüber. Dadurch finden auch Subdomains zweiter Stufe (a.shop.example.com) die Zone ihrer Hauptdomain — ihre Adressen werden nachgeführt und im Befund geprüft. Zone entfernen nennt in der Bestätigung Domains anderer Subscriptions, deren Adressen in der Zone stehen.
  • Ein im Panel angehaltener WildFly bleibt für Kastra angehalten; wer ihn auf dem Node mit systemctl stop anhält, findet ihn dagegen eine Minute später wieder laufend. Ein WildFly, der vor dem Update als angehalten gemeldet war, gilt danach als im Panel angehalten.
  • Archiv erstellen im Dateimanager packt im Hintergrund: über der Liste und in der Leiste unten rechts steht, wie viel schon gepackt ist, und der Dateimanager bleibt währenddessen bedienbar — auch ein Seitenwechsel hält das Packen nicht an. Ein großes Archiv bricht nicht mehr nach fünf Minuten ab; die Grenze liegt jetzt bei einer Stunde.
  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.
  • Das Webmail richtet Kastra mit Roundcube 1.7.5 statt 1.7.3 ein. Die Fassung schließt die Sicherheitslücken in league/commonmark, die Sicherheitslücken am Node meldet, und die Lücken, die Roundcube 1.7.4 und 1.7.5 selbst beheben. Ein vorhandener Node bekommt sie, wenn unter Komponenten beim Webmail erneut Einrichten gewählt wird; Datenbank und Einstellungen bleiben dabei erhalten.
  • Der Upload-Fortschritt in PHP-Sitzungen (session.upload_progress.enabled) ist auf jeder Domain aus und lässt sich je Domain nicht wieder einschalten, auch nicht über eine .user.ini. Braucht eine Anwendung ihn, schaltet ihn ein Administrator unter Einstellungen › PHP ein. Anlass ist die für den 21. Oktober 2026 angekündigte PHP-Sicherheitslücke in diesem Handler.
  • opcache_get_status() und opcache_reset() sind für jede Domain gesperrt, und PHP prüft bei jedem Treffer im OPcache, ob der Benutzer die Datei lesen darf. Bisher sah jede Domain die Dateipfade aller anderen Domains derselben PHP-Fassung, und Cache leeren in einer Anwendung leerte ihn allen.
  • PHP-Werte einer Domain, die genau auf der bisherigen Vorgabe standen (etwa memory_limit = 256M), gelten nach dem Update als wie allgemein und folgen künftig der allgemeinen Konfiguration. Auf dem Node ändert sich dadurch nichts; eine Domain, die einen solchen Wert bewusst eingetragen hatte, trägt ihn bei Bedarf neu ein.
  • Freie php.ini-Zeilen je Domain nehmen nur Direktiven an, die eine Anwendung auch selbst über .user.ini oder ini_set() setzen dürfte. Eine Zeile wie sendmail_path hätte im FPM-Pool sonst einen beliebigen Befehl erlaubt.
  • Eingehende Mail mit 15 Punkten oder mehr wird abgelehnt — auch auf bestehenden Nodes. Bisher wurde nichts abgelehnt, auch eindeutiger Spam nicht. Verloren geht dabei nichts unbemerkt: der absendende Server bekommt den Fehler und benachrichtigt seinen Absender. Wer weiterhin nichts ablehnen will, leert im Bereich Mailserver das Feld Ablehnen ab.
  • Der lernende Teil des Spamfilters (Bayes) lernt von selbst nur noch eindeutigen Spam ab der Ablehnschwelle. Bisher lernte er alles ab 6 Punkten als Spam, auch Grenzfälle.
  • Die WildFly-Verwaltungskonsole öffnet sich auf Port 8447 desselben Namens wie das Panel, etwa https://panel.example:8447/console/index.html. Bisher lief sie unter der Adresse des Panels, und ein Skript der Konsole hätte das Panel mit der Sitzung des angemeldeten Administrators bedienen können. Die Firewall von Kastra gibt Port 8447 auf dem Node des Panels frei, unter denselben Regeln wie SSH und das Panel; eine Firewall oder ein eigener Proxy davor muss ihn ebenfalls durchlassen, sonst bleibt der Rahmen leer. Ein bestehender Panel-Vhost bekommt den neuen Server-Block beim Update, die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsolenport liegen.
  • Wer unter Einstellungen › Aktualisierung Repository, Versionsauskunft oder Signaturschlüssel ändert, gibt dazu den Code aus der App oder das aktuelle Passwort an; ein Konto nur mit Passkey braucht eine Anmeldung, die keine zehn Minuten zurückliegt. Beide Adressen müssen http:// oder https:// ohne Leerzeichen, Anmeldedaten, Abfrage oder Anker sein, der Schlüssel ein öffentlicher PGP-Schlüssel. Bisher genügte die Sitzung, und die Adresse ging ungeprüft in die apt-Quelle jedes Nodes.
  • Eine Anmeldung mit falschem Einmalcode, an einem gesperrten oder an einem deaktivierten Konto bekommt dieselbe Meldung wie eine mit falschem Passwort: Benutzername, Passwort oder Einmalcode ist falsch. Der Hinweis darunter nennt die Sperre nach fünf Fehlversuchen als möglichen Grund. Bisher verrieten eigene Meldungen, dass es das Konto gibt, in welchem Zustand es ist oder dass das Passwort stimmte.
  • Von einer Adresse lassen sich höchstens 60 Passkey-Anmeldungen je Minute beginnen; darüber kommt eine Meldung, die Anmeldung mit Passwort bleibt möglich. Die Mengengrenze der ACME-Delegation zählt IPv6-Adressen je /64 statt je Adresse.
  • Je Subscription sind höchstens vier Web-Terminals gleichzeitig offen, je Node 32, und je Node höchstens 64 Live-Protokolle. Darüber nennt das Panel die Grenze, statt ein weiteres zu öffnen.
  • Die privaten Schlüssel der Zertifikate liegen verschlüsselt in der Datenbank, sobald KASTRA_SECRET_KEY gesetzt ist; vorhandene werden beim ersten Start nach dem Update umgestellt.
  • /actuator ist außer /actuator/health nur noch für angemeldete Administratoren erreichbar. Steht die Verbundadresse KASTRA_CLUSTER_BASE_URL nicht auf https://, meldet die Control Plane das beim Start als Fehler.
  • Ein stillgelegter Node wird sofort getrennt. Bisher redete sein Agent weiter, bis er sich von selbst neu verband.
  • Bei einem unerwarteten Fehler sehen nur Administratoren die Ursache im Feld Detail; alle anderen bekommen die Correlation-ID, unter der sie im Protokoll steht.

Behoben

  • Der Bereich FTP einer Subscription oder Domain zeigt auf einem Node, auf dem FTP ausgeschaltet ist, keine Fehlerkarte „kein FTP-Dienst eingerichtet“ mehr; das Protokoll bleibt dort einfach leer.
  • Wird die JVM von WildFly hart beendet (kill -9), startet WildFly wieder. Bisher blieb er in diesem Fall aus, und im Serverprotokoll stand nichts dazu.
  • Ein frisch eingeschalteter Mailserver nimmt Mail von außen an. Bisher horchte Postfix nach dem Einschalten weiter nur auf 127.0.0.1:25, weil der Rollout es nur neu geladen statt neu gestartet hat, und unter Komponenten blieb „horchen auf Port 25 aber nur auf 127.0.0.1“ stehen. Ein Node, der so hängen geblieben ist, kommt mit dem nächsten Rollout nach dem Update von selbst in Ordnung; Postfix startet dabei einmal neu.
  • Das Lebensende von PHP, Node.js und der Distribution wird wieder geladen. Lag auf einem Node WildFly, scheiterte der ganze Abruf von endoflife.date, weil es dort kein Produkt WildFly gibt.
  • Unter Einstellungen › Sicherheitslücken steht eine Quelle, die kein Node braucht, als nicht benötigt statt noch nie abgerufen — etwa php.net, solange kein Node PHP aus sury hat. Die Seite Sicherheitslücken zeigte eine nie abgerufene Quelle bisher als aktuell.
  • Die Schwachstellendaten werden jede Nacht abgerufen. Nach einem Abruf von Hand am Nachmittag fiel bisher die folgende Nacht aus.
  • Alarme per Mail oder Webhook kommen wieder an. Bisher blieben sie oft unzugestellt und standen unter Einstellungen › Alarmierung dauerhaft als wartend — betroffen war jede Alarmart außer der Probemeldung, etwa Node nicht erreichbar oder Verwaltete Dateien verändert.
  • Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
  • Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.
  • Ein gekürzter Hinweis unter einem Eingabefeld zeigt beim Überfahren überall seinen vollen Text, etwa im Formular Tarif bearbeiten. Bisher tat er das nur auf wenigen Seiten.
  • Ein Repository, an dem kein GitHub-Konto hängt — etwa nach einem Domain-Umzug —, lässt sich über Bearbeiten wieder mit einem Konto verbinden. Bisher bot der Dialog die Auswahl nur beim Hinzufügen an, und der Hinweis „wähle es am Repository aus“ führte ins Leere; es blieb nur, den Eintrag zu entfernen und neu anzulegen.
  • Die Protokolle einer Domain füllen ihren Kasten sofort ganz. Bisher erschien bei einem langen Protokoll nur der obere Teil, der Rest erst beim Rollen.
  • Die Control Plane läuft auf Spring Boot 4.1 (Spring Framework 7, Tomcat 11, Hibernate 7). Damit sind 24 bekannte Lücken in ihren Bibliotheken geschlossen, darunter drei kritische in Tomcat und zwei in BouncyCastle; für die bisherige Spring-Linie gibt es keine freien Sicherheitsupdates mehr. Am Betrieb ändert sich nichts: Einstellungen, Umgebungsvariablen und die Antworten der Schnittstelle bleiben gleich.
  • Auf Ubuntu-Nodes werden die Pakete der Distribution gegen die Sicherheitsdaten von Canonical abgeglichen, und phpMyAdmin, Roundcube, Composer und WP-CLI gegen OSV. Bisher standen sie trotz geladener Daten als nicht erfasst da — es lagen „noch keine Schwachstellendaten vor“.
  • Die nginx-Zusatzkonfiguration einer Domain prüft jetzt jede Anweisung einer Zeile, nicht nur das erste Wort. Eine zweite Anweisung hinter einem Semikolon — etwa expires 1h; proxy_pass … oder ein über Klammern eingeschleuster location-Block mit alias /etc/ — wird mit der ganzen Zeile verworfen und steht unter den Hinweisen des Rollouts. access_log ist nur noch zum Abschalten (off) erlaubt. Bisher kam alles hinter dem ersten Wort ungeprüft durch.
  • Eine Weiterleitung, ein Catch-All-Ziel und der Name eines Versandzugangs nehmen nur noch eine Adresse der eigenen Maildomain an; ein erlaubter Absender ebenso. Bisher ließ sich darüber die Post einer fremden Maildomain auf demselben Node umleiten oder unter ihrem Namen versenden. Ein Versandzugang bekommt nur noch dann eine DKIM-Signatur, wenn die Domain seiner Anmeldung zur Domain im Absender passt.
  • Der Datenbankabzug einer Sicherung folgt im Heimatverzeichnis keinem symbolischen Verweis mehr. Bisher hätte ein Verweis ~/.kastra-sicherung auf ein Systemverzeichnis dieses beim nächsten Sicherungslauf übereignen oder überschreiben können.
  • Das Aufgabenprotokoll zeigt einem Kunden nicht mehr den Rollout-Diff des ganzen Nodes. Bisher stand im Feld der abgeschlossenen Aufgabe die geänderte Konfiguration aller Kunden des Nodes samt Mail-Passwortdatei und privaten Schlüsseln; Administratoren sehen ihn weiterhin.
  • Einen neuen Passkey hinzufügen, TOTP (neu) einrichten und ein API-Token anlegen verlangen jetzt denselben zweiten Nachweis wie das Widerrufen eines Passkeys — einen Code aus der Authenticator-App, das aktuelle Passwort oder eine frische Anmeldung. Bisher genügte dafür die Sitzung, und ein fremder Zugriff auf eine angemeldete Sitzung konnte sich damit dauerhaft einnisten.
  • Die Sperre nach fünf Fehlversuchen trifft nur noch die Passwortanmeldung. Ein Konto ohne Passwortanmeldung zählt keine Fehlversuche mehr, und eine bestehende Sperre hält Passkey und Wiederherstellungscode nicht länger auf. Bisher ließ sich ein Konto, das nur per Passkey erreichbar ist, mit fünf Anfragen aussperren.
  • Meldet sich ein Node mit einem anderen Zertifikat als dem, das bei seiner Anmeldung ausgestellt wurde, wird er abgewiesen. Damit verliert ein ausgetauschter oder abgegebener Rechner seinen Zugang, sobald sich an seiner Stelle ein neuer anmeldet.
  • Eine Subdomain einer fremden Domain lässt sich nicht mehr als eigene Hauptdomain anlegen. Bisher hätte ein Kunde so eine Domain samt eigener DNS-Zone und Zertifikat unter einem fremden Namen beanspruchen können.
  • Ein Virenscan und ein Rückspieltest halten keine Datenbankverbindung mehr über ihre ganze Laufzeit. Bisher konnten mehrere gleichzeitig gestartete Läufe die Control Plane ausbremsen.
  • Grundbausteine der Control Plane sind auf aktuelle, abgesicherte Fassungen gehoben: Spring Boot 3.5.16, gRPC 1.76 (darin Netty mit den Fixes gegen CVE-2025-24970 und CVE-2025-55163 — ein Absturz des gesamten Dienstes über ein präpariertes TLS- bzw. HTTP/2-Paket) und die JWT-Bibliothek 10.0.2 (CVE-2025-53864, ein Lahmlegen über ein verschachteltes Sitzungscookie).
  • READONLY-Konten können kein Web-Terminal mehr öffnen; das war Schreibzugriff und widersprach der Rolle.
  • Ein Kunde kann die Übernahme eines Postfachs nur noch von einem öffentlichen IMAP-Server auf Port 143 oder 993 anstoßen. Bisher ließ sich damit das interne Netz des Nodes abtasten.
  • Die Statusseite zeigt einem Kunden das Gesamtbild, aber nicht mehr die einzelnen Vorfälle anderer Kunden samt Node-Namen.
  • Ein Sicherungsziel lässt sich nur noch auswählen, wenn es auf dem Node der Subscription liegt. Bisher hätte ein Kunde das Ziel eines fremden Nodes anhängen können.
  • Ein SFTP-Unterverzeichnis, das über einen symbolischen Verweis aus dem Heimatverzeichnis führt, wird abgewiesen statt eingehängt.
  • Fällige Sicherungen und Suchläufe nach Schadsoftware laufen jetzt nebenläufig an und halten einander nicht mehr auf. Bisher konnte ein langer Lauf dazu führen, dass eine Regel, die kurz danach fällig war, in dieser Nacht gar nicht lief — ohne Meldung.
  • Die Aufbewahrungsfrist des Audit-Logs wirkt. Bisher verhinderte ein Schutz gegen Änderungen auch das Löschen alter Einträge, und das Audit-Log wuchs trotz eingestellter Frist unbegrenzt.
  • Mail lässt sich nicht mehr für eine gleichnamige Maildomain eines anderen Kunden ein- oder ausschalten.
  • Den Node einer Maildomain und einer DNS-Zone sowie Art und Herkunft einer Zone wählt nur noch ein Administrator; ein Kunde bekommt den vorgesehenen Node.
  • Ein Rückspieltest schreibt nicht mehr durch einen symbolischen Verweis im Heimatverzeichnis an eine fremde Stelle.
  • Drift-Berichte eines Nodes werden gedeckelt gespeichert (höchstens 1000 Zeilen je Bericht, Diff gekürzt), statt die Datenbank bei dauerhafter Abweichung zu füllen.
  • Ein Node schreibt nur noch in sein eigenes Update-Protokoll, nicht mehr in das eines anderen.
  • Gleichzeitige Anmeldeversuche können die Control Plane nicht mehr über den Speicher der Passwortprüfung lahmlegen (höchstens vier gleichzeitige Prüfungen, der Rest wartet kurz).
  • Eine Container-Angabe mit einem Bind-Mount in der langen Form außerhalb des Subscription-Verzeichnisses oder mit einem auf 0.0.0.0 veröffentlichten Port wird jetzt ebenfalls abgewiesen.
  • Der Panel-Vhost nennt die nginx-Fassung nicht mehr (server_tokens off), beschränkt die TLS-1.2-Verschlüsselung auf Verfahren mit Vorwärtsgeheimnis (ssl_ciphers), erlaubt per connect-src nur noch Verbindungen zum Panel selbst, sperrt vendor/ unter phpMyAdmin und nimmt unter /api/ höchstens 64 MB an, ohne sie vor der Anmeldung auf die Platte zu puffern. Ein bestehender Vhost bekommt das beim Update nachgetragen; die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-pruefbericht liegen.
  • Ein Einmalcode aus der Authenticator-App lässt sich auch bei zwei gleichzeitigen Anmeldungen nur einmal verwenden.
  • Verbindet sich ein Node neu, während seine alte Verbindung noch abgebaut wird, bleibt er verbunden. Bisher scheiterten seine laufenden Aufgaben dann mit Node nicht erreichbar, und er stand bis zum nächsten Herzschlag als getrennt da.
  • Alarme per Mail oder Webhook werden auf eigenen Fäden zugestellt. Ein langsamer Mailserver oder Webhook hält keinen Rollout und keine Datenbankverbindung mehr auf.
  • Ein Hostname, der kein gültiger Rechnername ist, wird beim Anmelden eines Nodes abgewiesen. Bisher ging er ungeprüft ins Zertifikat und in die Betreffzeile von Alarmmails.
  • Ein Anmelde-Token mit Hostnamen gilt nur noch für genau diesen Namen: ein Rechner, der sich unter einem anderen meldet, wird abgewiesen, und das Token bleibt gültig. Bisher meldete sich damit jeder Rechner unter jedem freien Namen an. Der Befehl unter Nodes › Node aufnehmen nennt dafür den Hostnamen aus dem Token mit.
  • kastractl node token gibt den Befehl für den Node samt Fingerabdruck der CA aus, und als Adresse den Panel-Namen. Bisher fehlte der Fingerabdruck, und der Agent wies den Befehl ab; die Adresse war der Rechnername des Panel-Hosts, auf den das Zertifikat der Control Plane nicht lauten muss.
  • Ein neues FTP-Passwort wird in einem Feld unter dem Zugang eingegeben. Bisher fragte ein Browser-Dialog danach, der es im Klartext zeigte.
  • Passwortfelder für Postfächer, Sicherungsziele, Alarmkanäle und Datenbanken füllt der Browser nicht mehr mit dem gespeicherten Panel-Passwort.
  • Wechselt man die Domain, verschwinden die einmaligen Zugangsdaten einer gerade angelegten ACME-Delegation. Bisher standen sie unter der nächsten Domain weiter da.
  • Auf einem Panel, das vor dem 31. August 2026 eingerichtet wurde, öffnet sich die WildFly-Verwaltungskonsole. Seinem Vhost fehlte die Regel für die Konsole, und kein Update trug sie nach; seit die Konsole auf Port 8447 liegt, meldete der Rahmen nur noch, der Server habe die Verbindung abgelehnt. Das Update trägt Regel und Port jetzt nach, die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsole liegen.
  • Auf einem Panel, das vor dem 1. September 2026 eingerichtet wurde, tragen die Oberfläche und ihre Dateien dieselben Sicherheitskopfzeilen wie auf einer neuen Anlage: Content-Security-Policy, X-Frame-Options, HSTS, nosniff und Referrer-Policy. Bisher kam das Panel dort ohne sie beim Browser an und ließ sich von jeder fremden Seite einrahmen. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-kopfzeilen liegen.
  • Auf einem Panel, das seit dem 1. September 2026 eingerichtet wurde, verbot die Sicherheitsregel des Panels phpMyAdmin das Skript, mit dem es seine Seiten in Gang setzt. phpMyAdmin bekommt jetzt eine eigene Regel, die das zulässt und es weiterhin vor fremden Rahmen schützt. Kartenkacheln für GIS-Daten lädt phpMyAdmin nicht von außen nach. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-phpmyadmin liegen.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

Rendert anders

  • nft — auf dem Node, der das Panel trägt, lässt die Verwaltungsregel neben 22 und 8443 auch Port 8447 zu (WildFly-Konsole), mit derselben Drosselung bzw. denselben Admin-Netzen.
  • wildfly-unit — /etc/systemd/system/kastra-wildfly.service trägt Restart=always statt Restart=on-failure, StartLimitIntervalSec=1800, StartLimitBurst=6 und WorkingDirectory=-/opt/wildfly/standalone. Der Agent zieht eine bestehende Unit nach seinem Start einmal nach; ein laufender WildFly wird dabei nicht neu gestartet, die Werte gelten ab dem nächsten Start.
  • fpm-confd — neu je PHP-Fassung: /etc/php/<fassung>/fpm/conf.d/99-kastra.ini mit opcache.validate_permission = 1, opcache.restrict_api und session.upload_progress.enabled = 0, dazu, was unter Einstellungen › PHP allgemein steht. Alle FPM-Fassungen werden dafür einmal neu geladen. Die Datei gehört ab jetzt Kastra; eine von Hand dort abgelegte Datei mit anderem Namen bleibt unberührt. Eine Notfalldatei wie 99-notfall.ini kann nach dem Update weg.
  • fpm-pool — jeder Pool trägt php_admin_flag[session.upload_progress.enabled] = off. Weitere neue Zeilen (Sitzungs-Cookies, OPcache, Zeitgrenze, Slowlog, allgemeine freie Zeilen) erscheinen nur, wenn jemand einen Wert einstellt.
  • apparmor-php — das Profil von PHP-FPM erlaubt das Schreiben unter /var/log/kastra/subscriptions/ und das Mitlesen eines langsamen Workers für das Protokoll langsamer Anfragen.
  • logrotate — php-slow.log wird mit php-error.log gedreht.
  • mail — auf jedem Node mit Mailserver: unter /etc/rspamd/local.d/ neu milter_headers.conf und settings.conf, geändert actions.conf und classifier-bayes.conf; neu das Verzeichnis /etc/dovecot/kastra-spam/ mit den Sieve-Skripten für Junk-Ordner und Lernen samt zwei Programmen, die rspamc aufrufen und jede Korrektur ins Mailprotokoll schreiben; die Dovecot-Konfiguration bindet sie über sieve_before und IMAPSieve ein. Rspamd und Dovecot werden dafür einmal neu geladen.

26.10.27.9

Eingriff am Node Test 107 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.
  • Unter Einstellungen › PHP gibt es eine allgemeine PHP-Konfiguration für alle Nodes und alle PHP-Fassungen: Grenzen, Fehler und Regionales, Sitzungen, OPcache, FPM-Prozesse und freie php.ini-Zeilen. Jede Domain erbt, was sie nicht selbst setzt; bei jedem Feld steht, wie viele Domains abweichen. Nur für Administratoren.
  • Der Bereich PHP einer Domain zeigt bei jedem Feld, ob der Wert eigen ist oder wie allgemein; ein leeres Feld oder Alles wie allgemein setzt ihn zurück. Neu dort: Sitzungs-Cookies (nur über HTTPS, HttpOnly, SameSite, nur bekannte Kennungen), das OPcache-Prüfintervall, freie php.ini-Zeilen und — für Administratoren — die FPM-Prozesse samt harter Zeitgrenze und Protokoll langsamer Anfragen.
  • Dauert eine PHP-Anfrage länger als eingestellt, steht ihr Aufrufstapel im neuen Protokoll Langsame PHP-Anfragen der Domain.
  • Die PHP-Fassung des Webmails lässt sich im Bereich Mailserver eines Nodes einstellen, unabhängig von den Maildomains. Automatisch bleibt die Voreinstellung und wählt wie bisher die neueste Fassung bis 8.3. Fehlen der gewählten Fassung Erweiterungen, die Roundcube braucht, bleibt das Webmail auf der automatischen Wahl, und der Rollout nennt die fehlenden Pakete. Eine Fassung, auf der das Webmail eingestellt ist, lässt sich unter Laufzeiten nicht entfernen.
  • Kastra prüft die Software auf jedem Node gegen bekannte Sicherheitslücken: jedes installierte Paket — auch PostgreSQL, OpenSSL, OpenSSH und den Kernel —, dazu Node.js, WildFly, phpMyAdmin, Roundcube, Composer und WP-CLI. Die Daten kommen nachts von Debian, Ubuntu, php.net, der Node.js Security-WG, OSV und endoflife.date; der Paketbestand verlässt dafür den Server nicht. Der neue Bereich Sicherheitslücken eines Nodes nennt je Technologie Paket, installierte Fassung, Fix-Fassung, CVE, betroffene Domains und den nächsten Schritt; eine Lücke, die nicht greift, lässt sich mit Begründung quittieren.
  • Die Seite Sicherheitslücken zeigt dasselbe über alle Nodes und beantwortet, ob eine bestimmte Technologie irgendwo betroffen ist. Eingestellt wird unter Einstellungen › Sicherheitslücken: Schwelle des Alarms, Karenz und die Adressen der Quellen (leer schaltet eine Quelle ab, etwa ohne Internet oder mit eigenem Spiegel). Nur für Administratoren.
  • Neue Alarmarten: SCHWACHSTELLE meldet behebbare Lücken ab Dringlichkeit hoch und — kritisch — jede Lücke, die laut CISA aktiv ausgenutzt wird; Fixe, die die automatischen Sicherheitsupdates selbst holen, erst nach 48 Stunden. LEBENSENDE meldet Software ohne Sicherheitsupdates (etwa PHP 8.1 oder Node.js 20), SCHWACHSTELLEN_DATEN eine Quelle, die länger als 72 Stunden nicht abgerufen werden konnte.
  • Im Bereich Sicherheitslücken eines Nodes spielt Aktualisieren den Fix eines Befunds ein, Alle behebbaren aktualisieren alle auf einmal — als Aufgabe mit Protokoll, danach verschwindet der Befund. Das ist auch der Weg für PHP aus sury: die automatischen Sicherheitsupdates holen es weiterhin nicht, weil sury neben PHP neuere Bibliotheken mitbringt. Was sich so nicht beheben lässt (phpMyAdmin, Roundcube, Composer, WP-CLI, ein Kernel, der nur neu starten muss), nennt den Grund.
  • Läuft auf dem Host der Control Plane kein Agent, zeigt die Seite Sicherheitslücken ihn als „nicht erfasst“: PostgreSQL und Java dort werden dann nicht geprüft.
  • Die Control Plane lädt dafür einmal am Tag Daten von security-tracker.debian.org, security-metadata.canonical.com, cisa.gov, php.net, raw.githubusercontent.com, osv-vulnerabilities.storage.googleapis.com und endoflife.date. Sie liegen unter /var/lib/kastra-control-plane/schwachstellen.
  • Erkannter Spam landet im Ordner Junk des Postfachs. Bisher bekam er nur den Kopf X-Spam: Yes und blieb im Posteingang, weil kaum ein Mailprogramm diesen Kopf auswertet. Unter Mail › Spamfilter lässt eine Maildomain ihn auf Wunsch im Posteingang.
  • Der Bereich Mailserver eines Nodes hat einen Abschnitt Spamfilter mit drei Schwellen in Punkten: Greylisting ab (Vorgabe 4), Spam ab (6) und Ablehnen ab (15). Nur für Administratoren.
  • Jede Maildomain führt unter Mail › Spamfilter zwei Absenderlisten: Nie Spam (weder vertagt noch abgelehnt noch im Junk-Ordner) und Immer Spam (immer im Junk-Ordner), je Zeile eine Adresse oder @domain.
  • Verschiebt jemand eine Mail in den Junk-Ordner, lernt der Spamfilter sie als Spam; holt er sie heraus, als erwünscht — in jedem Mailprogramm über IMAP und im Webmail.
  • Eingehende Mail trägt im Kopf X-Spamd-Result mit den Punkten und den Regeln, die angeschlagen haben, und X-Spam-Status. Daran lässt sich ablesen, warum eine Mail im Junk-Ordner liegt.
  • Die Mailstatistik einer Maildomain und eines Nodes hat einen Abschnitt Spamfilter: wie viele eingehende Mails sauber, vertagt, als Spam markiert und abgelehnt wurden, wie oft jemand Spam selbst in den Junk-Ordner gelegt oder erwünschte Post herausgeholt hat, die Quoten Spam erkannt und Fehlalarme mit einer Empfehlung zur Schwelle und die Verteilung der Punkte mit den Schwellen des Nodes. Als Spam bewertete oder abgelehnte versendete Mail steht als Warnung darunter. Gezählt wird ab dem Update.
  • Die Liste Sendungen zeigt bei jeder Mail, die Rspamd bewertet hat, ihre Punkte.
  • Der Bereich Sicherheitslücken prüft auch die Bibliotheken, die eine Software mitbringt: jedes Jar von WildFly, vendor/ von phpMyAdmin und Roundcube, den Inhalt von Composer und WP-CLI und die Go-Module von Programmen aus einer fremden Paketquelle wie CrowdSec. Ein Befund heißt dann etwa io.undertow:undertow-core (wildfly-36.0.1.Final) und sagt, woher der Fix kommt. Ein WildFly 36.0.1 bringt zum Stand dieses Updates rund 90 behebbare Lücken mit, ein wp-cli 2.12.0 ein Composer 2.2.25 mit mehreren hohen.
  • Für Node.js zählt zusätzlich jede Sicherheitsfassung, die nodejs.org für den installierten Major führt — auch eine, die nur OpenSSL, undici oder npm erneuert und dafür keine CVE der Security-WG hat.
  • Unter Einstellungen › Sicherheitslücken stehen drei neue Quellen: Node.js Releases (nodejs.org), OSV Maven und OSV Go. Die Control Plane lädt dafür zusätzlich von nodejs.org; eine leere Adresse schaltet eine Quelle ab.
  • WildFly wird überwacht: fällt er aus oder antwortet er drei Minuten lang nicht, startet Kastra ihn neu — bei einem Hänger nach einem Thread-Dump ins Journal. Zu jedem Ausfall steht unter Laufzeiten › WildFly, wann er war und woran es lag, etwa Speichermangel, ein Absturz der JVM oder ein von außen gesendetes Signal. Nach fünf Neustarts in 30 Minuten gibt Kastra beim nächsten Ausfall auf, hält WildFly an und meldet die neue Alarmart WILDFLY_DOWN mit allen Ursachen. Starten im Panel setzt die Zählung zurück.
  • Eine Domain lässt sich im neuen Bereich Umzug in eine andere Subscription verschieben — zu einem anderen Kunden oder auf einen anderen Node. Sie zieht mit allen Subdomains, Datenbanken, Cronjobs, FTP-Zugängen, Mail und DNS um; eine Domain, die dieselbe Datenbank nutzt, zieht mit. Die Vorprüfung zeigt die ganze Gruppe mit dem Grund je Domain und prüft beim Wechsel des Nodes, ob dort läuft, was die Gruppe braucht (PHP-Fassung und Erweiterungen, Apache, Node.js, Podman, WAF, Objekt-Cache, Composer, MariaDB, Mail, FTP) und ob er den Sicherungsspeicher der Quelle erreicht, über den die Daten gehen. Gespeicherte Pfade in Cronjobs, Compose-Dateien, Zusatzkonfiguration und PHP-Einstellungen werden umgeschrieben; Dateien der Anwendung, die das alte Verzeichnis nennen, meldet die Vorprüfung. Nur für Administratoren.
  • Zieht eine Domain, die auf WildFly zeigt, auf einen anderen Node, zieht WildFly mit — samt Anwendungen, Konfiguration und jeder anderen Domain, die ebenfalls darauf zeigt, auch aus fremden Subscriptions. Die Vorprüfung nennt das in einem eigenen Block und verlangt eine Bestätigung; auf dem Ziel darf noch kein WildFly laufen.
  • Ein gescheiterter Domain-Umzug auf einen anderen Node lässt sich zurücknehmen; Quelle freigeben entfernt danach die alten Daten. Beides steht auch im Bereich Umzug der Subscriptions.
  • Eine Subdomain kann allein umziehen: im Bereich Umzug einer Subdomain gibt es die Wahl Nur … herauslösen. Sie zieht samt ihren eigenen Subdomains in die Ziel-Subscription — auch auf einen anderen Node — und ist dort eine eigene Domain. Ihr Ordner behält seinen Pfad unter dem Ordner der Subscription (…/example.com/shop.example.com); zieht die Hauptdomain später nach, kommt sie in denselben Ordner dazu. Die Hauptdomain und ihre übrigen Subdomains bleiben, wo sie sind, und liefern während des Umzugs weiter aus. Die DNS-Einträge bleiben in der Zone der Hauptdomain, beim Wechsel des Nodes werden dort nur ihre Adressen umgestellt. Teilt die Hauptdomain eine Datenbank mit der Subdomain, weist die Vorprüfung das Herauslösen ab, statt die ganze Domain umzuziehen.

Geändert

  • Welche DNS-Zone zu einer Domain gehört, sucht Kastra über den Namen: die eigene, sonst die Zone mit dem längsten Namen darüber. Dadurch finden auch Subdomains zweiter Stufe (a.shop.example.com) die Zone ihrer Hauptdomain — ihre Adressen werden nachgeführt und im Befund geprüft. Zone entfernen nennt in der Bestätigung Domains anderer Subscriptions, deren Adressen in der Zone stehen.
  • Ein im Panel angehaltener WildFly bleibt für Kastra angehalten; wer ihn auf dem Node mit systemctl stop anhält, findet ihn dagegen eine Minute später wieder laufend. Ein WildFly, der vor dem Update als angehalten gemeldet war, gilt danach als im Panel angehalten.
  • Archiv erstellen im Dateimanager packt im Hintergrund: über der Liste und in der Leiste unten rechts steht, wie viel schon gepackt ist, und der Dateimanager bleibt währenddessen bedienbar — auch ein Seitenwechsel hält das Packen nicht an. Ein großes Archiv bricht nicht mehr nach fünf Minuten ab; die Grenze liegt jetzt bei einer Stunde.
  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.
  • Das Webmail richtet Kastra mit Roundcube 1.7.5 statt 1.7.3 ein. Die Fassung schließt die Sicherheitslücken in league/commonmark, die Sicherheitslücken am Node meldet, und die Lücken, die Roundcube 1.7.4 und 1.7.5 selbst beheben. Ein vorhandener Node bekommt sie, wenn unter Komponenten beim Webmail erneut Einrichten gewählt wird; Datenbank und Einstellungen bleiben dabei erhalten.
  • Der Upload-Fortschritt in PHP-Sitzungen (session.upload_progress.enabled) ist auf jeder Domain aus und lässt sich je Domain nicht wieder einschalten, auch nicht über eine .user.ini. Braucht eine Anwendung ihn, schaltet ihn ein Administrator unter Einstellungen › PHP ein. Anlass ist die für den 21. Oktober 2026 angekündigte PHP-Sicherheitslücke in diesem Handler.
  • opcache_get_status() und opcache_reset() sind für jede Domain gesperrt, und PHP prüft bei jedem Treffer im OPcache, ob der Benutzer die Datei lesen darf. Bisher sah jede Domain die Dateipfade aller anderen Domains derselben PHP-Fassung, und Cache leeren in einer Anwendung leerte ihn allen.
  • PHP-Werte einer Domain, die genau auf der bisherigen Vorgabe standen (etwa memory_limit = 256M), gelten nach dem Update als wie allgemein und folgen künftig der allgemeinen Konfiguration. Auf dem Node ändert sich dadurch nichts; eine Domain, die einen solchen Wert bewusst eingetragen hatte, trägt ihn bei Bedarf neu ein.
  • Freie php.ini-Zeilen je Domain nehmen nur Direktiven an, die eine Anwendung auch selbst über .user.ini oder ini_set() setzen dürfte. Eine Zeile wie sendmail_path hätte im FPM-Pool sonst einen beliebigen Befehl erlaubt.
  • Eingehende Mail mit 15 Punkten oder mehr wird abgelehnt — auch auf bestehenden Nodes. Bisher wurde nichts abgelehnt, auch eindeutiger Spam nicht. Verloren geht dabei nichts unbemerkt: der absendende Server bekommt den Fehler und benachrichtigt seinen Absender. Wer weiterhin nichts ablehnen will, leert im Bereich Mailserver das Feld Ablehnen ab.
  • Der lernende Teil des Spamfilters (Bayes) lernt von selbst nur noch eindeutigen Spam ab der Ablehnschwelle. Bisher lernte er alles ab 6 Punkten als Spam, auch Grenzfälle.
  • Die WildFly-Verwaltungskonsole öffnet sich auf Port 8447 desselben Namens wie das Panel, etwa https://panel.example:8447/console/index.html. Bisher lief sie unter der Adresse des Panels, und ein Skript der Konsole hätte das Panel mit der Sitzung des angemeldeten Administrators bedienen können. Die Firewall von Kastra gibt Port 8447 auf dem Node des Panels frei, unter denselben Regeln wie SSH und das Panel; eine Firewall oder ein eigener Proxy davor muss ihn ebenfalls durchlassen, sonst bleibt der Rahmen leer. Ein bestehender Panel-Vhost bekommt den neuen Server-Block beim Update, die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsolenport liegen.
  • Wer unter Einstellungen › Aktualisierung Repository, Versionsauskunft oder Signaturschlüssel ändert, gibt dazu den Code aus der App oder das aktuelle Passwort an; ein Konto nur mit Passkey braucht eine Anmeldung, die keine zehn Minuten zurückliegt. Beide Adressen müssen http:// oder https:// ohne Leerzeichen, Anmeldedaten, Abfrage oder Anker sein, der Schlüssel ein öffentlicher PGP-Schlüssel. Bisher genügte die Sitzung, und die Adresse ging ungeprüft in die apt-Quelle jedes Nodes.
  • Eine Anmeldung mit falschem Einmalcode, an einem gesperrten oder an einem deaktivierten Konto bekommt dieselbe Meldung wie eine mit falschem Passwort: Benutzername, Passwort oder Einmalcode ist falsch. Der Hinweis darunter nennt die Sperre nach fünf Fehlversuchen als möglichen Grund. Bisher verrieten eigene Meldungen, dass es das Konto gibt, in welchem Zustand es ist oder dass das Passwort stimmte.
  • Von einer Adresse lassen sich höchstens 60 Passkey-Anmeldungen je Minute beginnen; darüber kommt eine Meldung, die Anmeldung mit Passwort bleibt möglich. Die Mengengrenze der ACME-Delegation zählt IPv6-Adressen je /64 statt je Adresse.
  • Je Subscription sind höchstens vier Web-Terminals gleichzeitig offen, je Node 32, und je Node höchstens 64 Live-Protokolle. Darüber nennt das Panel die Grenze, statt ein weiteres zu öffnen.
  • Die privaten Schlüssel der Zertifikate liegen verschlüsselt in der Datenbank, sobald KASTRA_SECRET_KEY gesetzt ist; vorhandene werden beim ersten Start nach dem Update umgestellt.
  • /actuator ist außer /actuator/health nur noch für angemeldete Administratoren erreichbar. Steht die Verbundadresse KASTRA_CLUSTER_BASE_URL nicht auf https://, meldet die Control Plane das beim Start als Fehler.
  • Ein stillgelegter Node wird sofort getrennt. Bisher redete sein Agent weiter, bis er sich von selbst neu verband.
  • Bei einem unerwarteten Fehler sehen nur Administratoren die Ursache im Feld Detail; alle anderen bekommen die Correlation-ID, unter der sie im Protokoll steht.

Behoben

  • Der Bereich FTP einer Subscription oder Domain zeigt auf einem Node, auf dem FTP ausgeschaltet ist, keine Fehlerkarte „kein FTP-Dienst eingerichtet“ mehr; das Protokoll bleibt dort einfach leer.
  • Wird die JVM von WildFly hart beendet (kill -9), startet WildFly wieder. Bisher blieb er in diesem Fall aus, und im Serverprotokoll stand nichts dazu.
  • Ein frisch eingeschalteter Mailserver nimmt Mail von außen an. Bisher horchte Postfix nach dem Einschalten weiter nur auf 127.0.0.1:25, weil der Rollout es nur neu geladen statt neu gestartet hat, und unter Komponenten blieb „horchen auf Port 25 aber nur auf 127.0.0.1“ stehen. Ein Node, der so hängen geblieben ist, kommt mit dem nächsten Rollout nach dem Update von selbst in Ordnung; Postfix startet dabei einmal neu.
  • Das Lebensende von PHP, Node.js und der Distribution wird wieder geladen. Lag auf einem Node WildFly, scheiterte der ganze Abruf von endoflife.date, weil es dort kein Produkt WildFly gibt.
  • Unter Einstellungen › Sicherheitslücken steht eine Quelle, die kein Node braucht, als nicht benötigt statt noch nie abgerufen — etwa php.net, solange kein Node PHP aus sury hat. Die Seite Sicherheitslücken zeigte eine nie abgerufene Quelle bisher als aktuell.
  • Die Schwachstellendaten werden jede Nacht abgerufen. Nach einem Abruf von Hand am Nachmittag fiel bisher die folgende Nacht aus.
  • Alarme per Mail oder Webhook kommen wieder an. Bisher blieben sie oft unzugestellt und standen unter Einstellungen › Alarmierung dauerhaft als wartend — betroffen war jede Alarmart außer der Probemeldung, etwa Node nicht erreichbar oder Verwaltete Dateien verändert.
  • Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
  • Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.
  • Ein gekürzter Hinweis unter einem Eingabefeld zeigt beim Überfahren überall seinen vollen Text, etwa im Formular Tarif bearbeiten. Bisher tat er das nur auf wenigen Seiten.
  • Ein Repository, an dem kein GitHub-Konto hängt — etwa nach einem Domain-Umzug —, lässt sich über Bearbeiten wieder mit einem Konto verbinden. Bisher bot der Dialog die Auswahl nur beim Hinzufügen an, und der Hinweis „wähle es am Repository aus“ führte ins Leere; es blieb nur, den Eintrag zu entfernen und neu anzulegen.
  • Die Protokolle einer Domain füllen ihren Kasten sofort ganz. Bisher erschien bei einem langen Protokoll nur der obere Teil, der Rest erst beim Rollen.
  • Die Control Plane läuft auf Spring Boot 4.1 (Spring Framework 7, Tomcat 11, Hibernate 7). Damit sind 24 bekannte Lücken in ihren Bibliotheken geschlossen, darunter drei kritische in Tomcat und zwei in BouncyCastle; für die bisherige Spring-Linie gibt es keine freien Sicherheitsupdates mehr. Am Betrieb ändert sich nichts: Einstellungen, Umgebungsvariablen und die Antworten der Schnittstelle bleiben gleich.
  • Auf Ubuntu-Nodes werden die Pakete der Distribution gegen die Sicherheitsdaten von Canonical abgeglichen, und phpMyAdmin, Roundcube, Composer und WP-CLI gegen OSV. Bisher standen sie trotz geladener Daten als nicht erfasst da — es lagen „noch keine Schwachstellendaten vor“.
  • Die nginx-Zusatzkonfiguration einer Domain prüft jetzt jede Anweisung einer Zeile, nicht nur das erste Wort. Eine zweite Anweisung hinter einem Semikolon — etwa expires 1h; proxy_pass … oder ein über Klammern eingeschleuster location-Block mit alias /etc/ — wird mit der ganzen Zeile verworfen und steht unter den Hinweisen des Rollouts. access_log ist nur noch zum Abschalten (off) erlaubt. Bisher kam alles hinter dem ersten Wort ungeprüft durch.
  • Eine Weiterleitung, ein Catch-All-Ziel und der Name eines Versandzugangs nehmen nur noch eine Adresse der eigenen Maildomain an; ein erlaubter Absender ebenso. Bisher ließ sich darüber die Post einer fremden Maildomain auf demselben Node umleiten oder unter ihrem Namen versenden. Ein Versandzugang bekommt nur noch dann eine DKIM-Signatur, wenn die Domain seiner Anmeldung zur Domain im Absender passt.
  • Der Datenbankabzug einer Sicherung folgt im Heimatverzeichnis keinem symbolischen Verweis mehr. Bisher hätte ein Verweis ~/.kastra-sicherung auf ein Systemverzeichnis dieses beim nächsten Sicherungslauf übereignen oder überschreiben können.
  • Das Aufgabenprotokoll zeigt einem Kunden nicht mehr den Rollout-Diff des ganzen Nodes. Bisher stand im Feld der abgeschlossenen Aufgabe die geänderte Konfiguration aller Kunden des Nodes samt Mail-Passwortdatei und privaten Schlüsseln; Administratoren sehen ihn weiterhin.
  • Einen neuen Passkey hinzufügen, TOTP (neu) einrichten und ein API-Token anlegen verlangen jetzt denselben zweiten Nachweis wie das Widerrufen eines Passkeys — einen Code aus der Authenticator-App, das aktuelle Passwort oder eine frische Anmeldung. Bisher genügte dafür die Sitzung, und ein fremder Zugriff auf eine angemeldete Sitzung konnte sich damit dauerhaft einnisten.
  • Die Sperre nach fünf Fehlversuchen trifft nur noch die Passwortanmeldung. Ein Konto ohne Passwortanmeldung zählt keine Fehlversuche mehr, und eine bestehende Sperre hält Passkey und Wiederherstellungscode nicht länger auf. Bisher ließ sich ein Konto, das nur per Passkey erreichbar ist, mit fünf Anfragen aussperren.
  • Meldet sich ein Node mit einem anderen Zertifikat als dem, das bei seiner Anmeldung ausgestellt wurde, wird er abgewiesen. Damit verliert ein ausgetauschter oder abgegebener Rechner seinen Zugang, sobald sich an seiner Stelle ein neuer anmeldet.
  • Eine Subdomain einer fremden Domain lässt sich nicht mehr als eigene Hauptdomain anlegen. Bisher hätte ein Kunde so eine Domain samt eigener DNS-Zone und Zertifikat unter einem fremden Namen beanspruchen können.
  • Ein Virenscan und ein Rückspieltest halten keine Datenbankverbindung mehr über ihre ganze Laufzeit. Bisher konnten mehrere gleichzeitig gestartete Läufe die Control Plane ausbremsen.
  • Grundbausteine der Control Plane sind auf aktuelle, abgesicherte Fassungen gehoben: Spring Boot 3.5.16, gRPC 1.76 (darin Netty mit den Fixes gegen CVE-2025-24970 und CVE-2025-55163 — ein Absturz des gesamten Dienstes über ein präpariertes TLS- bzw. HTTP/2-Paket) und die JWT-Bibliothek 10.0.2 (CVE-2025-53864, ein Lahmlegen über ein verschachteltes Sitzungscookie).
  • READONLY-Konten können kein Web-Terminal mehr öffnen; das war Schreibzugriff und widersprach der Rolle.
  • Ein Kunde kann die Übernahme eines Postfachs nur noch von einem öffentlichen IMAP-Server auf Port 143 oder 993 anstoßen. Bisher ließ sich damit das interne Netz des Nodes abtasten.
  • Die Statusseite zeigt einem Kunden das Gesamtbild, aber nicht mehr die einzelnen Vorfälle anderer Kunden samt Node-Namen.
  • Ein Sicherungsziel lässt sich nur noch auswählen, wenn es auf dem Node der Subscription liegt. Bisher hätte ein Kunde das Ziel eines fremden Nodes anhängen können.
  • Ein SFTP-Unterverzeichnis, das über einen symbolischen Verweis aus dem Heimatverzeichnis führt, wird abgewiesen statt eingehängt.
  • Fällige Sicherungen und Suchläufe nach Schadsoftware laufen jetzt nebenläufig an und halten einander nicht mehr auf. Bisher konnte ein langer Lauf dazu führen, dass eine Regel, die kurz danach fällig war, in dieser Nacht gar nicht lief — ohne Meldung.
  • Die Aufbewahrungsfrist des Audit-Logs wirkt. Bisher verhinderte ein Schutz gegen Änderungen auch das Löschen alter Einträge, und das Audit-Log wuchs trotz eingestellter Frist unbegrenzt.
  • Mail lässt sich nicht mehr für eine gleichnamige Maildomain eines anderen Kunden ein- oder ausschalten.
  • Den Node einer Maildomain und einer DNS-Zone sowie Art und Herkunft einer Zone wählt nur noch ein Administrator; ein Kunde bekommt den vorgesehenen Node.
  • Ein Rückspieltest schreibt nicht mehr durch einen symbolischen Verweis im Heimatverzeichnis an eine fremde Stelle.
  • Drift-Berichte eines Nodes werden gedeckelt gespeichert (höchstens 1000 Zeilen je Bericht, Diff gekürzt), statt die Datenbank bei dauerhafter Abweichung zu füllen.
  • Ein Node schreibt nur noch in sein eigenes Update-Protokoll, nicht mehr in das eines anderen.
  • Gleichzeitige Anmeldeversuche können die Control Plane nicht mehr über den Speicher der Passwortprüfung lahmlegen (höchstens vier gleichzeitige Prüfungen, der Rest wartet kurz).
  • Eine Container-Angabe mit einem Bind-Mount in der langen Form außerhalb des Subscription-Verzeichnisses oder mit einem auf 0.0.0.0 veröffentlichten Port wird jetzt ebenfalls abgewiesen.
  • Der Panel-Vhost nennt die nginx-Fassung nicht mehr (server_tokens off), beschränkt die TLS-1.2-Verschlüsselung auf Verfahren mit Vorwärtsgeheimnis (ssl_ciphers), erlaubt per connect-src nur noch Verbindungen zum Panel selbst, sperrt vendor/ unter phpMyAdmin und nimmt unter /api/ höchstens 64 MB an, ohne sie vor der Anmeldung auf die Platte zu puffern. Ein bestehender Vhost bekommt das beim Update nachgetragen; die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-pruefbericht liegen.
  • Ein Einmalcode aus der Authenticator-App lässt sich auch bei zwei gleichzeitigen Anmeldungen nur einmal verwenden.
  • Verbindet sich ein Node neu, während seine alte Verbindung noch abgebaut wird, bleibt er verbunden. Bisher scheiterten seine laufenden Aufgaben dann mit Node nicht erreichbar, und er stand bis zum nächsten Herzschlag als getrennt da.
  • Alarme per Mail oder Webhook werden auf eigenen Fäden zugestellt. Ein langsamer Mailserver oder Webhook hält keinen Rollout und keine Datenbankverbindung mehr auf.
  • Ein Hostname, der kein gültiger Rechnername ist, wird beim Anmelden eines Nodes abgewiesen. Bisher ging er ungeprüft ins Zertifikat und in die Betreffzeile von Alarmmails.
  • Ein Anmelde-Token mit Hostnamen gilt nur noch für genau diesen Namen: ein Rechner, der sich unter einem anderen meldet, wird abgewiesen, und das Token bleibt gültig. Bisher meldete sich damit jeder Rechner unter jedem freien Namen an. Der Befehl unter Nodes › Node aufnehmen nennt dafür den Hostnamen aus dem Token mit.
  • kastractl node token gibt den Befehl für den Node samt Fingerabdruck der CA aus, und als Adresse den Panel-Namen. Bisher fehlte der Fingerabdruck, und der Agent wies den Befehl ab; die Adresse war der Rechnername des Panel-Hosts, auf den das Zertifikat der Control Plane nicht lauten muss.
  • Ein neues FTP-Passwort wird in einem Feld unter dem Zugang eingegeben. Bisher fragte ein Browser-Dialog danach, der es im Klartext zeigte.
  • Passwortfelder für Postfächer, Sicherungsziele, Alarmkanäle und Datenbanken füllt der Browser nicht mehr mit dem gespeicherten Panel-Passwort.
  • Wechselt man die Domain, verschwinden die einmaligen Zugangsdaten einer gerade angelegten ACME-Delegation. Bisher standen sie unter der nächsten Domain weiter da.
  • Auf einem Panel, das vor dem 31. August 2026 eingerichtet wurde, öffnet sich die WildFly-Verwaltungskonsole. Seinem Vhost fehlte die Regel für die Konsole, und kein Update trug sie nach; seit die Konsole auf Port 8447 liegt, meldete der Rahmen nur noch, der Server habe die Verbindung abgelehnt. Das Update trägt Regel und Port jetzt nach, die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsole liegen.
  • Auf einem Panel, das vor dem 1. September 2026 eingerichtet wurde, tragen die Oberfläche und ihre Dateien dieselben Sicherheitskopfzeilen wie auf einer neuen Anlage: Content-Security-Policy, X-Frame-Options, HSTS, nosniff und Referrer-Policy. Bisher kam das Panel dort ohne sie beim Browser an und ließ sich von jeder fremden Seite einrahmen. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-kopfzeilen liegen.
  • Auf einem Panel, das seit dem 1. September 2026 eingerichtet wurde, verbot die Sicherheitsregel des Panels phpMyAdmin das Skript, mit dem es seine Seiten in Gang setzt. phpMyAdmin bekommt jetzt eine eigene Regel, die das zulässt und es weiterhin vor fremden Rahmen schützt. Kartenkacheln für GIS-Daten lädt phpMyAdmin nicht von außen nach. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-phpmyadmin liegen.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

Rendert anders

  • nft — auf dem Node, der das Panel trägt, lässt die Verwaltungsregel neben 22 und 8443 auch Port 8447 zu (WildFly-Konsole), mit derselben Drosselung bzw. denselben Admin-Netzen.
  • wildfly-unit — /etc/systemd/system/kastra-wildfly.service trägt Restart=always statt Restart=on-failure, StartLimitIntervalSec=1800, StartLimitBurst=6 und WorkingDirectory=-/opt/wildfly/standalone. Der Agent zieht eine bestehende Unit nach seinem Start einmal nach; ein laufender WildFly wird dabei nicht neu gestartet, die Werte gelten ab dem nächsten Start.
  • fpm-confd — neu je PHP-Fassung: /etc/php/<fassung>/fpm/conf.d/99-kastra.ini mit opcache.validate_permission = 1, opcache.restrict_api und session.upload_progress.enabled = 0, dazu, was unter Einstellungen › PHP allgemein steht. Alle FPM-Fassungen werden dafür einmal neu geladen. Die Datei gehört ab jetzt Kastra; eine von Hand dort abgelegte Datei mit anderem Namen bleibt unberührt. Eine Notfalldatei wie 99-notfall.ini kann nach dem Update weg.
  • fpm-pool — jeder Pool trägt php_admin_flag[session.upload_progress.enabled] = off. Weitere neue Zeilen (Sitzungs-Cookies, OPcache, Zeitgrenze, Slowlog, allgemeine freie Zeilen) erscheinen nur, wenn jemand einen Wert einstellt.
  • apparmor-php — das Profil von PHP-FPM erlaubt das Schreiben unter /var/log/kastra/subscriptions/ und das Mitlesen eines langsamen Workers für das Protokoll langsamer Anfragen.
  • logrotate — php-slow.log wird mit php-error.log gedreht.
  • mail — auf jedem Node mit Mailserver: unter /etc/rspamd/local.d/ neu milter_headers.conf und settings.conf, geändert actions.conf und classifier-bayes.conf; neu das Verzeichnis /etc/dovecot/kastra-spam/ mit den Sieve-Skripten für Junk-Ordner und Lernen samt zwei Programmen, die rspamc aufrufen und jede Korrektur ins Mailprotokoll schreiben; die Dovecot-Konfiguration bindet sie über sieve_before und IMAPSieve ein. Rspamd und Dovecot werden dafür einmal neu geladen.

26.10.27.4

Eingriff am Node Test 105 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.
  • Unter Einstellungen › PHP gibt es eine allgemeine PHP-Konfiguration für alle Nodes und alle PHP-Fassungen: Grenzen, Fehler und Regionales, Sitzungen, OPcache, FPM-Prozesse und freie php.ini-Zeilen. Jede Domain erbt, was sie nicht selbst setzt; bei jedem Feld steht, wie viele Domains abweichen. Nur für Administratoren.
  • Der Bereich PHP einer Domain zeigt bei jedem Feld, ob der Wert eigen ist oder wie allgemein; ein leeres Feld oder Alles wie allgemein setzt ihn zurück. Neu dort: Sitzungs-Cookies (nur über HTTPS, HttpOnly, SameSite, nur bekannte Kennungen), das OPcache-Prüfintervall, freie php.ini-Zeilen und — für Administratoren — die FPM-Prozesse samt harter Zeitgrenze und Protokoll langsamer Anfragen.
  • Dauert eine PHP-Anfrage länger als eingestellt, steht ihr Aufrufstapel im neuen Protokoll Langsame PHP-Anfragen der Domain.
  • Die PHP-Fassung des Webmails lässt sich im Bereich Mailserver eines Nodes einstellen, unabhängig von den Maildomains. Automatisch bleibt die Voreinstellung und wählt wie bisher die neueste Fassung bis 8.3. Fehlen der gewählten Fassung Erweiterungen, die Roundcube braucht, bleibt das Webmail auf der automatischen Wahl, und der Rollout nennt die fehlenden Pakete. Eine Fassung, auf der das Webmail eingestellt ist, lässt sich unter Laufzeiten nicht entfernen.
  • Kastra prüft die Software auf jedem Node gegen bekannte Sicherheitslücken: jedes installierte Paket — auch PostgreSQL, OpenSSL, OpenSSH und den Kernel —, dazu Node.js, WildFly, phpMyAdmin, Roundcube, Composer und WP-CLI. Die Daten kommen nachts von Debian, Ubuntu, php.net, der Node.js Security-WG, OSV und endoflife.date; der Paketbestand verlässt dafür den Server nicht. Der neue Bereich Sicherheitslücken eines Nodes nennt je Technologie Paket, installierte Fassung, Fix-Fassung, CVE, betroffene Domains und den nächsten Schritt; eine Lücke, die nicht greift, lässt sich mit Begründung quittieren.
  • Die Seite Sicherheitslücken zeigt dasselbe über alle Nodes und beantwortet, ob eine bestimmte Technologie irgendwo betroffen ist. Eingestellt wird unter Einstellungen › Sicherheitslücken: Schwelle des Alarms, Karenz und die Adressen der Quellen (leer schaltet eine Quelle ab, etwa ohne Internet oder mit eigenem Spiegel). Nur für Administratoren.
  • Neue Alarmarten: SCHWACHSTELLE meldet behebbare Lücken ab Dringlichkeit hoch und — kritisch — jede Lücke, die laut CISA aktiv ausgenutzt wird; Fixe, die die automatischen Sicherheitsupdates selbst holen, erst nach 48 Stunden. LEBENSENDE meldet Software ohne Sicherheitsupdates (etwa PHP 8.1 oder Node.js 20), SCHWACHSTELLEN_DATEN eine Quelle, die länger als 72 Stunden nicht abgerufen werden konnte.
  • Im Bereich Sicherheitslücken eines Nodes spielt Aktualisieren den Fix eines Befunds ein, Alle behebbaren aktualisieren alle auf einmal — als Aufgabe mit Protokoll, danach verschwindet der Befund. Das ist auch der Weg für PHP aus sury: die automatischen Sicherheitsupdates holen es weiterhin nicht, weil sury neben PHP neuere Bibliotheken mitbringt. Was sich so nicht beheben lässt (phpMyAdmin, Roundcube, Composer, WP-CLI, ein Kernel, der nur neu starten muss), nennt den Grund.
  • Läuft auf dem Host der Control Plane kein Agent, zeigt die Seite Sicherheitslücken ihn als „nicht erfasst“: PostgreSQL und Java dort werden dann nicht geprüft.
  • Die Control Plane lädt dafür einmal am Tag Daten von security-tracker.debian.org, security-metadata.canonical.com, cisa.gov, php.net, raw.githubusercontent.com, osv-vulnerabilities.storage.googleapis.com und endoflife.date. Sie liegen unter /var/lib/kastra-control-plane/schwachstellen.
  • Erkannter Spam landet im Ordner Junk des Postfachs. Bisher bekam er nur den Kopf X-Spam: Yes und blieb im Posteingang, weil kaum ein Mailprogramm diesen Kopf auswertet. Unter Mail › Spamfilter lässt eine Maildomain ihn auf Wunsch im Posteingang.
  • Der Bereich Mailserver eines Nodes hat einen Abschnitt Spamfilter mit drei Schwellen in Punkten: Greylisting ab (Vorgabe 4), Spam ab (6) und Ablehnen ab (15). Nur für Administratoren.
  • Jede Maildomain führt unter Mail › Spamfilter zwei Absenderlisten: Nie Spam (weder vertagt noch abgelehnt noch im Junk-Ordner) und Immer Spam (immer im Junk-Ordner), je Zeile eine Adresse oder @domain.
  • Verschiebt jemand eine Mail in den Junk-Ordner, lernt der Spamfilter sie als Spam; holt er sie heraus, als erwünscht — in jedem Mailprogramm über IMAP und im Webmail.
  • Eingehende Mail trägt im Kopf X-Spamd-Result mit den Punkten und den Regeln, die angeschlagen haben, und X-Spam-Status. Daran lässt sich ablesen, warum eine Mail im Junk-Ordner liegt.
  • Die Mailstatistik einer Maildomain und eines Nodes hat einen Abschnitt Spamfilter: wie viele eingehende Mails sauber, vertagt, als Spam markiert und abgelehnt wurden, wie oft jemand Spam selbst in den Junk-Ordner gelegt oder erwünschte Post herausgeholt hat, die Quoten Spam erkannt und Fehlalarme mit einer Empfehlung zur Schwelle und die Verteilung der Punkte mit den Schwellen des Nodes. Als Spam bewertete oder abgelehnte versendete Mail steht als Warnung darunter. Gezählt wird ab dem Update.
  • Die Liste Sendungen zeigt bei jeder Mail, die Rspamd bewertet hat, ihre Punkte.
  • Der Bereich Sicherheitslücken prüft auch die Bibliotheken, die eine Software mitbringt: jedes Jar von WildFly, vendor/ von phpMyAdmin und Roundcube, den Inhalt von Composer und WP-CLI und die Go-Module von Programmen aus einer fremden Paketquelle wie CrowdSec. Ein Befund heißt dann etwa io.undertow:undertow-core (wildfly-36.0.1.Final) und sagt, woher der Fix kommt. Ein WildFly 36.0.1 bringt zum Stand dieses Updates rund 90 behebbare Lücken mit, ein wp-cli 2.12.0 ein Composer 2.2.25 mit mehreren hohen.
  • Für Node.js zählt zusätzlich jede Sicherheitsfassung, die nodejs.org für den installierten Major führt — auch eine, die nur OpenSSL, undici oder npm erneuert und dafür keine CVE der Security-WG hat.
  • Unter Einstellungen › Sicherheitslücken stehen drei neue Quellen: Node.js Releases (nodejs.org), OSV Maven und OSV Go. Die Control Plane lädt dafür zusätzlich von nodejs.org; eine leere Adresse schaltet eine Quelle ab.
  • WildFly wird überwacht: fällt er aus oder antwortet er drei Minuten lang nicht, startet Kastra ihn neu — bei einem Hänger nach einem Thread-Dump ins Journal. Zu jedem Ausfall steht unter Laufzeiten › WildFly, wann er war und woran es lag, etwa Speichermangel, ein Absturz der JVM oder ein von außen gesendetes Signal. Nach fünf Neustarts in 30 Minuten gibt Kastra beim nächsten Ausfall auf, hält WildFly an und meldet die neue Alarmart WILDFLY_DOWN mit allen Ursachen. Starten im Panel setzt die Zählung zurück.
  • Eine Domain lässt sich im neuen Bereich Umzug in eine andere Subscription verschieben — zu einem anderen Kunden oder auf einen anderen Node. Sie zieht mit allen Subdomains, Datenbanken, Cronjobs, FTP-Zugängen, Mail und DNS um; eine Domain, die dieselbe Datenbank nutzt, zieht mit. Die Vorprüfung zeigt die ganze Gruppe mit dem Grund je Domain und prüft beim Wechsel des Nodes, ob dort läuft, was die Gruppe braucht (PHP-Fassung und Erweiterungen, Apache, Node.js, Podman, WAF, Objekt-Cache, Composer, MariaDB, Mail, FTP) und ob er den Sicherungsspeicher der Quelle erreicht, über den die Daten gehen. Gespeicherte Pfade in Cronjobs, Compose-Dateien, Zusatzkonfiguration und PHP-Einstellungen werden umgeschrieben; Dateien der Anwendung, die das alte Verzeichnis nennen, meldet die Vorprüfung. Nur für Administratoren.
  • Zieht eine Domain, die auf WildFly zeigt, auf einen anderen Node, zieht WildFly mit — samt Anwendungen, Konfiguration und jeder anderen Domain, die ebenfalls darauf zeigt, auch aus fremden Subscriptions. Die Vorprüfung nennt das in einem eigenen Block und verlangt eine Bestätigung; auf dem Ziel darf noch kein WildFly laufen.
  • Ein gescheiterter Domain-Umzug auf einen anderen Node lässt sich zurücknehmen; Quelle freigeben entfernt danach die alten Daten. Beides steht auch im Bereich Umzug der Subscriptions.
  • Eine Subdomain kann allein umziehen: im Bereich Umzug einer Subdomain gibt es die Wahl Nur … herauslösen. Sie zieht samt ihren eigenen Subdomains in die Ziel-Subscription — auch auf einen anderen Node — und ist dort eine eigene Domain mit eigenem Ordner; die Hauptdomain und ihre übrigen Subdomains bleiben, wo sie sind, und liefern während des Umzugs weiter aus. Die DNS-Einträge bleiben in der Zone der Hauptdomain, beim Wechsel des Nodes werden dort nur ihre Adressen umgestellt. Teilt die Hauptdomain eine Datenbank mit der Subdomain, weist die Vorprüfung das Herauslösen ab, statt die ganze Domain umzuziehen.

Geändert

  • Welche DNS-Zone zu einer Domain gehört, sucht Kastra über den Namen: die eigene, sonst die Zone mit dem längsten Namen darüber. Dadurch finden auch Subdomains zweiter Stufe (a.shop.example.com) die Zone ihrer Hauptdomain — ihre Adressen werden nachgeführt und im Befund geprüft. Zone entfernen nennt in der Bestätigung Domains anderer Subscriptions, deren Adressen in der Zone stehen.
  • Ein im Panel angehaltener WildFly bleibt für Kastra angehalten; wer ihn auf dem Node mit systemctl stop anhält, findet ihn dagegen eine Minute später wieder laufend. Ein WildFly, der vor dem Update als angehalten gemeldet war, gilt danach als im Panel angehalten.
  • Archiv erstellen im Dateimanager packt im Hintergrund: über der Liste und in der Leiste unten rechts steht, wie viel schon gepackt ist, und der Dateimanager bleibt währenddessen bedienbar — auch ein Seitenwechsel hält das Packen nicht an. Ein großes Archiv bricht nicht mehr nach fünf Minuten ab; die Grenze liegt jetzt bei einer Stunde.
  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.
  • Der Upload-Fortschritt in PHP-Sitzungen (session.upload_progress.enabled) ist auf jeder Domain aus und lässt sich je Domain nicht wieder einschalten, auch nicht über eine .user.ini. Braucht eine Anwendung ihn, schaltet ihn ein Administrator unter Einstellungen › PHP ein. Anlass ist die für den 21. Oktober 2026 angekündigte PHP-Sicherheitslücke in diesem Handler.
  • opcache_get_status() und opcache_reset() sind für jede Domain gesperrt, und PHP prüft bei jedem Treffer im OPcache, ob der Benutzer die Datei lesen darf. Bisher sah jede Domain die Dateipfade aller anderen Domains derselben PHP-Fassung, und Cache leeren in einer Anwendung leerte ihn allen.
  • PHP-Werte einer Domain, die genau auf der bisherigen Vorgabe standen (etwa memory_limit = 256M), gelten nach dem Update als wie allgemein und folgen künftig der allgemeinen Konfiguration. Auf dem Node ändert sich dadurch nichts; eine Domain, die einen solchen Wert bewusst eingetragen hatte, trägt ihn bei Bedarf neu ein.
  • Freie php.ini-Zeilen je Domain nehmen nur Direktiven an, die eine Anwendung auch selbst über .user.ini oder ini_set() setzen dürfte. Eine Zeile wie sendmail_path hätte im FPM-Pool sonst einen beliebigen Befehl erlaubt.
  • Eingehende Mail mit 15 Punkten oder mehr wird abgelehnt — auch auf bestehenden Nodes. Bisher wurde nichts abgelehnt, auch eindeutiger Spam nicht. Verloren geht dabei nichts unbemerkt: der absendende Server bekommt den Fehler und benachrichtigt seinen Absender. Wer weiterhin nichts ablehnen will, leert im Bereich Mailserver das Feld Ablehnen ab.
  • Der lernende Teil des Spamfilters (Bayes) lernt von selbst nur noch eindeutigen Spam ab der Ablehnschwelle. Bisher lernte er alles ab 6 Punkten als Spam, auch Grenzfälle.
  • Die WildFly-Verwaltungskonsole öffnet sich auf Port 8447 desselben Namens wie das Panel, etwa https://panel.example:8447/console/index.html. Bisher lief sie unter der Adresse des Panels, und ein Skript der Konsole hätte das Panel mit der Sitzung des angemeldeten Administrators bedienen können. Die Firewall von Kastra gibt Port 8447 auf dem Node des Panels frei, unter denselben Regeln wie SSH und das Panel; eine Firewall oder ein eigener Proxy davor muss ihn ebenfalls durchlassen, sonst bleibt der Rahmen leer. Ein bestehender Panel-Vhost bekommt den neuen Server-Block beim Update, die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsolenport liegen.
  • Wer unter Einstellungen › Aktualisierung Repository, Versionsauskunft oder Signaturschlüssel ändert, gibt dazu den Code aus der App oder das aktuelle Passwort an; ein Konto nur mit Passkey braucht eine Anmeldung, die keine zehn Minuten zurückliegt. Beide Adressen müssen http:// oder https:// ohne Leerzeichen, Anmeldedaten, Abfrage oder Anker sein, der Schlüssel ein öffentlicher PGP-Schlüssel. Bisher genügte die Sitzung, und die Adresse ging ungeprüft in die apt-Quelle jedes Nodes.
  • Eine Anmeldung mit falschem Einmalcode, an einem gesperrten oder an einem deaktivierten Konto bekommt dieselbe Meldung wie eine mit falschem Passwort: Benutzername, Passwort oder Einmalcode ist falsch. Der Hinweis darunter nennt die Sperre nach fünf Fehlversuchen als möglichen Grund. Bisher verrieten eigene Meldungen, dass es das Konto gibt, in welchem Zustand es ist oder dass das Passwort stimmte.
  • Von einer Adresse lassen sich höchstens 60 Passkey-Anmeldungen je Minute beginnen; darüber kommt eine Meldung, die Anmeldung mit Passwort bleibt möglich. Die Mengengrenze der ACME-Delegation zählt IPv6-Adressen je /64 statt je Adresse.
  • Je Subscription sind höchstens vier Web-Terminals gleichzeitig offen, je Node 32, und je Node höchstens 64 Live-Protokolle. Darüber nennt das Panel die Grenze, statt ein weiteres zu öffnen.
  • Die privaten Schlüssel der Zertifikate liegen verschlüsselt in der Datenbank, sobald KASTRA_SECRET_KEY gesetzt ist; vorhandene werden beim ersten Start nach dem Update umgestellt.
  • /actuator ist außer /actuator/health nur noch für angemeldete Administratoren erreichbar. Steht die Verbundadresse KASTRA_CLUSTER_BASE_URL nicht auf https://, meldet die Control Plane das beim Start als Fehler.
  • Ein stillgelegter Node wird sofort getrennt. Bisher redete sein Agent weiter, bis er sich von selbst neu verband.
  • Bei einem unerwarteten Fehler sehen nur Administratoren die Ursache im Feld Detail; alle anderen bekommen die Correlation-ID, unter der sie im Protokoll steht.

Behoben

  • Der Bereich FTP einer Subscription oder Domain zeigt auf einem Node, auf dem FTP ausgeschaltet ist, keine Fehlerkarte „kein FTP-Dienst eingerichtet“ mehr; das Protokoll bleibt dort einfach leer.
  • Wird die JVM von WildFly hart beendet (kill -9), startet WildFly wieder. Bisher blieb er in diesem Fall aus, und im Serverprotokoll stand nichts dazu.
  • Ein frisch eingeschalteter Mailserver nimmt Mail von außen an. Bisher horchte Postfix nach dem Einschalten weiter nur auf 127.0.0.1:25, weil der Rollout es nur neu geladen statt neu gestartet hat, und unter Komponenten blieb „horchen auf Port 25 aber nur auf 127.0.0.1“ stehen. Ein Node, der so hängen geblieben ist, kommt mit dem nächsten Rollout nach dem Update von selbst in Ordnung; Postfix startet dabei einmal neu.
  • Das Lebensende von PHP, Node.js und der Distribution wird wieder geladen. Lag auf einem Node WildFly, scheiterte der ganze Abruf von endoflife.date, weil es dort kein Produkt WildFly gibt.
  • Unter Einstellungen › Sicherheitslücken steht eine Quelle, die kein Node braucht, als nicht benötigt statt noch nie abgerufen — etwa php.net, solange kein Node PHP aus sury hat. Die Seite Sicherheitslücken zeigte eine nie abgerufene Quelle bisher als aktuell.
  • Die Schwachstellendaten werden jede Nacht abgerufen. Nach einem Abruf von Hand am Nachmittag fiel bisher die folgende Nacht aus.
  • Alarme per Mail oder Webhook kommen wieder an. Bisher blieben sie oft unzugestellt und standen unter Einstellungen › Alarmierung dauerhaft als wartend — betroffen war jede Alarmart außer der Probemeldung, etwa Node nicht erreichbar oder Verwaltete Dateien verändert.
  • Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
  • Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.
  • Ein gekürzter Hinweis unter einem Eingabefeld zeigt beim Überfahren überall seinen vollen Text, etwa im Formular Tarif bearbeiten. Bisher tat er das nur auf wenigen Seiten.
  • Die Protokolle einer Domain füllen ihren Kasten sofort ganz. Bisher erschien bei einem langen Protokoll nur der obere Teil, der Rest erst beim Rollen.
  • Die Control Plane läuft auf Spring Boot 4.1 (Spring Framework 7, Tomcat 11, Hibernate 7). Damit sind 24 bekannte Lücken in ihren Bibliotheken geschlossen, darunter drei kritische in Tomcat und zwei in BouncyCastle; für die bisherige Spring-Linie gibt es keine freien Sicherheitsupdates mehr. Am Betrieb ändert sich nichts: Einstellungen, Umgebungsvariablen und die Antworten der Schnittstelle bleiben gleich.
  • Auf Ubuntu-Nodes werden die Pakete der Distribution gegen die Sicherheitsdaten von Canonical abgeglichen, und phpMyAdmin, Roundcube, Composer und WP-CLI gegen OSV. Bisher standen sie trotz geladener Daten als nicht erfasst da — es lagen „noch keine Schwachstellendaten vor“.
  • Die nginx-Zusatzkonfiguration einer Domain prüft jetzt jede Anweisung einer Zeile, nicht nur das erste Wort. Eine zweite Anweisung hinter einem Semikolon — etwa expires 1h; proxy_pass … oder ein über Klammern eingeschleuster location-Block mit alias /etc/ — wird mit der ganzen Zeile verworfen und steht unter den Hinweisen des Rollouts. access_log ist nur noch zum Abschalten (off) erlaubt. Bisher kam alles hinter dem ersten Wort ungeprüft durch.
  • Eine Weiterleitung, ein Catch-All-Ziel und der Name eines Versandzugangs nehmen nur noch eine Adresse der eigenen Maildomain an; ein erlaubter Absender ebenso. Bisher ließ sich darüber die Post einer fremden Maildomain auf demselben Node umleiten oder unter ihrem Namen versenden. Ein Versandzugang bekommt nur noch dann eine DKIM-Signatur, wenn die Domain seiner Anmeldung zur Domain im Absender passt.
  • Der Datenbankabzug einer Sicherung folgt im Heimatverzeichnis keinem symbolischen Verweis mehr. Bisher hätte ein Verweis ~/.kastra-sicherung auf ein Systemverzeichnis dieses beim nächsten Sicherungslauf übereignen oder überschreiben können.
  • Das Aufgabenprotokoll zeigt einem Kunden nicht mehr den Rollout-Diff des ganzen Nodes. Bisher stand im Feld der abgeschlossenen Aufgabe die geänderte Konfiguration aller Kunden des Nodes samt Mail-Passwortdatei und privaten Schlüsseln; Administratoren sehen ihn weiterhin.
  • Einen neuen Passkey hinzufügen, TOTP (neu) einrichten und ein API-Token anlegen verlangen jetzt denselben zweiten Nachweis wie das Widerrufen eines Passkeys — einen Code aus der Authenticator-App, das aktuelle Passwort oder eine frische Anmeldung. Bisher genügte dafür die Sitzung, und ein fremder Zugriff auf eine angemeldete Sitzung konnte sich damit dauerhaft einnisten.
  • Die Sperre nach fünf Fehlversuchen trifft nur noch die Passwortanmeldung. Ein Konto ohne Passwortanmeldung zählt keine Fehlversuche mehr, und eine bestehende Sperre hält Passkey und Wiederherstellungscode nicht länger auf. Bisher ließ sich ein Konto, das nur per Passkey erreichbar ist, mit fünf Anfragen aussperren.
  • Meldet sich ein Node mit einem anderen Zertifikat als dem, das bei seiner Anmeldung ausgestellt wurde, wird er abgewiesen. Damit verliert ein ausgetauschter oder abgegebener Rechner seinen Zugang, sobald sich an seiner Stelle ein neuer anmeldet.
  • Eine Subdomain einer fremden Domain lässt sich nicht mehr als eigene Hauptdomain anlegen. Bisher hätte ein Kunde so eine Domain samt eigener DNS-Zone und Zertifikat unter einem fremden Namen beanspruchen können.
  • Ein Virenscan und ein Rückspieltest halten keine Datenbankverbindung mehr über ihre ganze Laufzeit. Bisher konnten mehrere gleichzeitig gestartete Läufe die Control Plane ausbremsen.
  • Grundbausteine der Control Plane sind auf aktuelle, abgesicherte Fassungen gehoben: Spring Boot 3.5.16, gRPC 1.76 (darin Netty mit den Fixes gegen CVE-2025-24970 und CVE-2025-55163 — ein Absturz des gesamten Dienstes über ein präpariertes TLS- bzw. HTTP/2-Paket) und die JWT-Bibliothek 10.0.2 (CVE-2025-53864, ein Lahmlegen über ein verschachteltes Sitzungscookie).
  • READONLY-Konten können kein Web-Terminal mehr öffnen; das war Schreibzugriff und widersprach der Rolle.
  • Ein Kunde kann die Übernahme eines Postfachs nur noch von einem öffentlichen IMAP-Server auf Port 143 oder 993 anstoßen. Bisher ließ sich damit das interne Netz des Nodes abtasten.
  • Die Statusseite zeigt einem Kunden das Gesamtbild, aber nicht mehr die einzelnen Vorfälle anderer Kunden samt Node-Namen.
  • Ein Sicherungsziel lässt sich nur noch auswählen, wenn es auf dem Node der Subscription liegt. Bisher hätte ein Kunde das Ziel eines fremden Nodes anhängen können.
  • Ein SFTP-Unterverzeichnis, das über einen symbolischen Verweis aus dem Heimatverzeichnis führt, wird abgewiesen statt eingehängt.
  • Fällige Sicherungen und Suchläufe nach Schadsoftware laufen jetzt nebenläufig an und halten einander nicht mehr auf. Bisher konnte ein langer Lauf dazu führen, dass eine Regel, die kurz danach fällig war, in dieser Nacht gar nicht lief — ohne Meldung.
  • Die Aufbewahrungsfrist des Audit-Logs wirkt. Bisher verhinderte ein Schutz gegen Änderungen auch das Löschen alter Einträge, und das Audit-Log wuchs trotz eingestellter Frist unbegrenzt.
  • Mail lässt sich nicht mehr für eine gleichnamige Maildomain eines anderen Kunden ein- oder ausschalten.
  • Den Node einer Maildomain und einer DNS-Zone sowie Art und Herkunft einer Zone wählt nur noch ein Administrator; ein Kunde bekommt den vorgesehenen Node.
  • Ein Rückspieltest schreibt nicht mehr durch einen symbolischen Verweis im Heimatverzeichnis an eine fremde Stelle.
  • Drift-Berichte eines Nodes werden gedeckelt gespeichert (höchstens 1000 Zeilen je Bericht, Diff gekürzt), statt die Datenbank bei dauerhafter Abweichung zu füllen.
  • Ein Node schreibt nur noch in sein eigenes Update-Protokoll, nicht mehr in das eines anderen.
  • Gleichzeitige Anmeldeversuche können die Control Plane nicht mehr über den Speicher der Passwortprüfung lahmlegen (höchstens vier gleichzeitige Prüfungen, der Rest wartet kurz).
  • Eine Container-Angabe mit einem Bind-Mount in der langen Form außerhalb des Subscription-Verzeichnisses oder mit einem auf 0.0.0.0 veröffentlichten Port wird jetzt ebenfalls abgewiesen.
  • Der Panel-Vhost nennt die nginx-Fassung nicht mehr (server_tokens off), beschränkt die TLS-1.2-Verschlüsselung auf Verfahren mit Vorwärtsgeheimnis (ssl_ciphers), erlaubt per connect-src nur noch Verbindungen zum Panel selbst, sperrt vendor/ unter phpMyAdmin und nimmt unter /api/ höchstens 64 MB an, ohne sie vor der Anmeldung auf die Platte zu puffern. Ein bestehender Vhost bekommt das beim Update nachgetragen; die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-pruefbericht liegen.
  • Ein Einmalcode aus der Authenticator-App lässt sich auch bei zwei gleichzeitigen Anmeldungen nur einmal verwenden.
  • Verbindet sich ein Node neu, während seine alte Verbindung noch abgebaut wird, bleibt er verbunden. Bisher scheiterten seine laufenden Aufgaben dann mit Node nicht erreichbar, und er stand bis zum nächsten Herzschlag als getrennt da.
  • Alarme per Mail oder Webhook werden auf eigenen Fäden zugestellt. Ein langsamer Mailserver oder Webhook hält keinen Rollout und keine Datenbankverbindung mehr auf.
  • Ein Hostname, der kein gültiger Rechnername ist, wird beim Anmelden eines Nodes abgewiesen. Bisher ging er ungeprüft ins Zertifikat und in die Betreffzeile von Alarmmails.
  • Ein Anmelde-Token mit Hostnamen gilt nur noch für genau diesen Namen: ein Rechner, der sich unter einem anderen meldet, wird abgewiesen, und das Token bleibt gültig. Bisher meldete sich damit jeder Rechner unter jedem freien Namen an. Der Befehl unter Nodes › Node aufnehmen nennt dafür den Hostnamen aus dem Token mit.
  • kastractl node token gibt den Befehl für den Node samt Fingerabdruck der CA aus, und als Adresse den Panel-Namen. Bisher fehlte der Fingerabdruck, und der Agent wies den Befehl ab; die Adresse war der Rechnername des Panel-Hosts, auf den das Zertifikat der Control Plane nicht lauten muss.
  • Ein neues FTP-Passwort wird in einem Feld unter dem Zugang eingegeben. Bisher fragte ein Browser-Dialog danach, der es im Klartext zeigte.
  • Passwortfelder für Postfächer, Sicherungsziele, Alarmkanäle und Datenbanken füllt der Browser nicht mehr mit dem gespeicherten Panel-Passwort.
  • Wechselt man die Domain, verschwinden die einmaligen Zugangsdaten einer gerade angelegten ACME-Delegation. Bisher standen sie unter der nächsten Domain weiter da.
  • Auf einem Panel, das vor dem 31. August 2026 eingerichtet wurde, öffnet sich die WildFly-Verwaltungskonsole. Seinem Vhost fehlte die Regel für die Konsole, und kein Update trug sie nach; seit die Konsole auf Port 8447 liegt, meldete der Rahmen nur noch, der Server habe die Verbindung abgelehnt. Das Update trägt Regel und Port jetzt nach, die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsole liegen.
  • Auf einem Panel, das vor dem 1. September 2026 eingerichtet wurde, tragen die Oberfläche und ihre Dateien dieselben Sicherheitskopfzeilen wie auf einer neuen Anlage: Content-Security-Policy, X-Frame-Options, HSTS, nosniff und Referrer-Policy. Bisher kam das Panel dort ohne sie beim Browser an und ließ sich von jeder fremden Seite einrahmen. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-kopfzeilen liegen.
  • Auf einem Panel, das seit dem 1. September 2026 eingerichtet wurde, verbot die Sicherheitsregel des Panels phpMyAdmin das Skript, mit dem es seine Seiten in Gang setzt. phpMyAdmin bekommt jetzt eine eigene Regel, die das zulässt und es weiterhin vor fremden Rahmen schützt. Kartenkacheln für GIS-Daten lädt phpMyAdmin nicht von außen nach. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-phpmyadmin liegen.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

Rendert anders

  • nft — auf dem Node, der das Panel trägt, lässt die Verwaltungsregel neben 22 und 8443 auch Port 8447 zu (WildFly-Konsole), mit derselben Drosselung bzw. denselben Admin-Netzen.
  • wildfly-unit — /etc/systemd/system/kastra-wildfly.service trägt Restart=always statt Restart=on-failure, StartLimitIntervalSec=1800, StartLimitBurst=6 und WorkingDirectory=-/opt/wildfly/standalone. Der Agent zieht eine bestehende Unit nach seinem Start einmal nach; ein laufender WildFly wird dabei nicht neu gestartet, die Werte gelten ab dem nächsten Start.
  • fpm-confd — neu je PHP-Fassung: /etc/php/<fassung>/fpm/conf.d/99-kastra.ini mit opcache.validate_permission = 1, opcache.restrict_api und session.upload_progress.enabled = 0, dazu, was unter Einstellungen › PHP allgemein steht. Alle FPM-Fassungen werden dafür einmal neu geladen. Die Datei gehört ab jetzt Kastra; eine von Hand dort abgelegte Datei mit anderem Namen bleibt unberührt. Eine Notfalldatei wie 99-notfall.ini kann nach dem Update weg.
  • fpm-pool — jeder Pool trägt php_admin_flag[session.upload_progress.enabled] = off. Weitere neue Zeilen (Sitzungs-Cookies, OPcache, Zeitgrenze, Slowlog, allgemeine freie Zeilen) erscheinen nur, wenn jemand einen Wert einstellt.
  • apparmor-php — das Profil von PHP-FPM erlaubt das Schreiben unter /var/log/kastra/subscriptions/ und das Mitlesen eines langsamen Workers für das Protokoll langsamer Anfragen.
  • logrotate — php-slow.log wird mit php-error.log gedreht.
  • mail — auf jedem Node mit Mailserver: unter /etc/rspamd/local.d/ neu milter_headers.conf und settings.conf, geändert actions.conf und classifier-bayes.conf; neu das Verzeichnis /etc/dovecot/kastra-spam/ mit den Sieve-Skripten für Junk-Ordner und Lernen samt zwei Programmen, die rspamc aufrufen und jede Korrektur ins Mailprotokoll schreiben; die Dovecot-Konfiguration bindet sie über sieve_before und IMAPSieve ein. Rspamd und Dovecot werden dafür einmal neu geladen.

26.10.27.2

Eingriff am Node Test 103 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.
  • Unter Einstellungen › PHP gibt es eine allgemeine PHP-Konfiguration für alle Nodes und alle PHP-Fassungen: Grenzen, Fehler und Regionales, Sitzungen, OPcache, FPM-Prozesse und freie php.ini-Zeilen. Jede Domain erbt, was sie nicht selbst setzt; bei jedem Feld steht, wie viele Domains abweichen. Nur für Administratoren.
  • Der Bereich PHP einer Domain zeigt bei jedem Feld, ob der Wert eigen ist oder wie allgemein; ein leeres Feld oder Alles wie allgemein setzt ihn zurück. Neu dort: Sitzungs-Cookies (nur über HTTPS, HttpOnly, SameSite, nur bekannte Kennungen), das OPcache-Prüfintervall, freie php.ini-Zeilen und — für Administratoren — die FPM-Prozesse samt harter Zeitgrenze und Protokoll langsamer Anfragen.
  • Dauert eine PHP-Anfrage länger als eingestellt, steht ihr Aufrufstapel im neuen Protokoll Langsame PHP-Anfragen der Domain.
  • Die PHP-Fassung des Webmails lässt sich im Bereich Mailserver eines Nodes einstellen, unabhängig von den Maildomains. Automatisch bleibt die Voreinstellung und wählt wie bisher die neueste Fassung bis 8.3. Fehlen der gewählten Fassung Erweiterungen, die Roundcube braucht, bleibt das Webmail auf der automatischen Wahl, und der Rollout nennt die fehlenden Pakete. Eine Fassung, auf der das Webmail eingestellt ist, lässt sich unter Laufzeiten nicht entfernen.
  • Kastra prüft die Software auf jedem Node gegen bekannte Sicherheitslücken: jedes installierte Paket — auch PostgreSQL, OpenSSL, OpenSSH und den Kernel —, dazu Node.js, WildFly, phpMyAdmin, Roundcube, Composer und WP-CLI. Die Daten kommen nachts von Debian, Ubuntu, php.net, der Node.js Security-WG, OSV und endoflife.date; der Paketbestand verlässt dafür den Server nicht. Der neue Bereich Sicherheitslücken eines Nodes nennt je Technologie Paket, installierte Fassung, Fix-Fassung, CVE, betroffene Domains und den nächsten Schritt; eine Lücke, die nicht greift, lässt sich mit Begründung quittieren.
  • Die Seite Sicherheitslücken zeigt dasselbe über alle Nodes und beantwortet, ob eine bestimmte Technologie irgendwo betroffen ist. Eingestellt wird unter Einstellungen › Sicherheitslücken: Schwelle des Alarms, Karenz und die Adressen der Quellen (leer schaltet eine Quelle ab, etwa ohne Internet oder mit eigenem Spiegel). Nur für Administratoren.
  • Neue Alarmarten: SCHWACHSTELLE meldet behebbare Lücken ab Dringlichkeit hoch und — kritisch — jede Lücke, die laut CISA aktiv ausgenutzt wird; Fixe, die die automatischen Sicherheitsupdates selbst holen, erst nach 48 Stunden. LEBENSENDE meldet Software ohne Sicherheitsupdates (etwa PHP 8.1 oder Node.js 20), SCHWACHSTELLEN_DATEN eine Quelle, die länger als 72 Stunden nicht abgerufen werden konnte.
  • Im Bereich Sicherheitslücken eines Nodes spielt Aktualisieren den Fix eines Befunds ein, Alle behebbaren aktualisieren alle auf einmal — als Aufgabe mit Protokoll, danach verschwindet der Befund. Das ist auch der Weg für PHP aus sury: die automatischen Sicherheitsupdates holen es weiterhin nicht, weil sury neben PHP neuere Bibliotheken mitbringt. Was sich so nicht beheben lässt (phpMyAdmin, Roundcube, Composer, WP-CLI, ein Kernel, der nur neu starten muss), nennt den Grund.
  • Läuft auf dem Host der Control Plane kein Agent, zeigt die Seite Sicherheitslücken ihn als „nicht erfasst“: PostgreSQL und Java dort werden dann nicht geprüft.
  • Die Control Plane lädt dafür einmal am Tag Daten von security-tracker.debian.org, security-metadata.canonical.com, cisa.gov, php.net, raw.githubusercontent.com, osv-vulnerabilities.storage.googleapis.com und endoflife.date. Sie liegen unter /var/lib/kastra-control-plane/schwachstellen.
  • Erkannter Spam landet im Ordner Junk des Postfachs. Bisher bekam er nur den Kopf X-Spam: Yes und blieb im Posteingang, weil kaum ein Mailprogramm diesen Kopf auswertet. Unter Mail › Spamfilter lässt eine Maildomain ihn auf Wunsch im Posteingang.
  • Der Bereich Mailserver eines Nodes hat einen Abschnitt Spamfilter mit drei Schwellen in Punkten: Greylisting ab (Vorgabe 4), Spam ab (6) und Ablehnen ab (15). Nur für Administratoren.
  • Jede Maildomain führt unter Mail › Spamfilter zwei Absenderlisten: Nie Spam (weder vertagt noch abgelehnt noch im Junk-Ordner) und Immer Spam (immer im Junk-Ordner), je Zeile eine Adresse oder @domain.
  • Verschiebt jemand eine Mail in den Junk-Ordner, lernt der Spamfilter sie als Spam; holt er sie heraus, als erwünscht — in jedem Mailprogramm über IMAP und im Webmail.
  • Eingehende Mail trägt im Kopf X-Spamd-Result mit den Punkten und den Regeln, die angeschlagen haben, und X-Spam-Status. Daran lässt sich ablesen, warum eine Mail im Junk-Ordner liegt.
  • Die Mailstatistik einer Maildomain und eines Nodes hat einen Abschnitt Spamfilter: wie viele eingehende Mails sauber, vertagt, als Spam markiert und abgelehnt wurden, wie oft jemand Spam selbst in den Junk-Ordner gelegt oder erwünschte Post herausgeholt hat, die Quoten Spam erkannt und Fehlalarme mit einer Empfehlung zur Schwelle und die Verteilung der Punkte mit den Schwellen des Nodes. Als Spam bewertete oder abgelehnte versendete Mail steht als Warnung darunter. Gezählt wird ab dem Update.
  • Die Liste Sendungen zeigt bei jeder Mail, die Rspamd bewertet hat, ihre Punkte.
  • Der Bereich Sicherheitslücken prüft auch die Bibliotheken, die eine Software mitbringt: jedes Jar von WildFly, vendor/ von phpMyAdmin und Roundcube, den Inhalt von Composer und WP-CLI und die Go-Module von Programmen aus einer fremden Paketquelle wie CrowdSec. Ein Befund heißt dann etwa io.undertow:undertow-core (wildfly-36.0.1.Final) und sagt, woher der Fix kommt. Ein WildFly 36.0.1 bringt zum Stand dieses Updates rund 90 behebbare Lücken mit, ein wp-cli 2.12.0 ein Composer 2.2.25 mit mehreren hohen.
  • Für Node.js zählt zusätzlich jede Sicherheitsfassung, die nodejs.org für den installierten Major führt — auch eine, die nur OpenSSL, undici oder npm erneuert und dafür keine CVE der Security-WG hat.
  • Unter Einstellungen › Sicherheitslücken stehen drei neue Quellen: Node.js Releases (nodejs.org), OSV Maven und OSV Go. Die Control Plane lädt dafür zusätzlich von nodejs.org; eine leere Adresse schaltet eine Quelle ab.
  • WildFly wird überwacht: fällt er aus oder antwortet er drei Minuten lang nicht, startet Kastra ihn neu — bei einem Hänger nach einem Thread-Dump ins Journal. Zu jedem Ausfall steht unter Laufzeiten › WildFly, wann er war und woran es lag, etwa Speichermangel, ein Absturz der JVM oder ein von außen gesendetes Signal. Nach fünf Neustarts in 30 Minuten gibt Kastra beim nächsten Ausfall auf, hält WildFly an und meldet die neue Alarmart WILDFLY_DOWN mit allen Ursachen. Starten im Panel setzt die Zählung zurück.
  • Eine Domain lässt sich im neuen Bereich Umzug in eine andere Subscription verschieben — zu einem anderen Kunden oder auf einen anderen Node. Sie zieht mit allen Subdomains, Datenbanken, Cronjobs, FTP-Zugängen, Mail und DNS um; eine Domain, die dieselbe Datenbank nutzt, zieht mit. Die Vorprüfung zeigt die ganze Gruppe mit dem Grund je Domain und prüft beim Wechsel des Nodes, ob dort läuft, was die Gruppe braucht (PHP-Fassung und Erweiterungen, Apache, Node.js, Podman, WAF, Objekt-Cache, Composer, MariaDB, Mail, FTP) und ob er den Sicherungsspeicher der Quelle erreicht, über den die Daten gehen. Gespeicherte Pfade in Cronjobs, Compose-Dateien, Zusatzkonfiguration und PHP-Einstellungen werden umgeschrieben; Dateien der Anwendung, die das alte Verzeichnis nennen, meldet die Vorprüfung. Nur für Administratoren.
  • Zieht eine Domain, die auf WildFly zeigt, auf einen anderen Node, zieht WildFly mit — samt Anwendungen, Konfiguration und jeder anderen Domain, die ebenfalls darauf zeigt, auch aus fremden Subscriptions. Die Vorprüfung nennt das in einem eigenen Block und verlangt eine Bestätigung; auf dem Ziel darf noch kein WildFly laufen.
  • Ein gescheiterter Domain-Umzug auf einen anderen Node lässt sich zurücknehmen; Quelle freigeben entfernt danach die alten Daten. Beides steht auch im Bereich Umzug der Subscriptions.

Geändert

  • Ein im Panel angehaltener WildFly bleibt für Kastra angehalten; wer ihn auf dem Node mit systemctl stop anhält, findet ihn dagegen eine Minute später wieder laufend. Ein WildFly, der vor dem Update als angehalten gemeldet war, gilt danach als im Panel angehalten.
  • Archiv erstellen im Dateimanager packt im Hintergrund: über der Liste und in der Leiste unten rechts steht, wie viel schon gepackt ist, und der Dateimanager bleibt währenddessen bedienbar — auch ein Seitenwechsel hält das Packen nicht an. Ein großes Archiv bricht nicht mehr nach fünf Minuten ab; die Grenze liegt jetzt bei einer Stunde.
  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.
  • Der Upload-Fortschritt in PHP-Sitzungen (session.upload_progress.enabled) ist auf jeder Domain aus und lässt sich je Domain nicht wieder einschalten, auch nicht über eine .user.ini. Braucht eine Anwendung ihn, schaltet ihn ein Administrator unter Einstellungen › PHP ein. Anlass ist die für den 21. Oktober 2026 angekündigte PHP-Sicherheitslücke in diesem Handler.
  • opcache_get_status() und opcache_reset() sind für jede Domain gesperrt, und PHP prüft bei jedem Treffer im OPcache, ob der Benutzer die Datei lesen darf. Bisher sah jede Domain die Dateipfade aller anderen Domains derselben PHP-Fassung, und Cache leeren in einer Anwendung leerte ihn allen.
  • PHP-Werte einer Domain, die genau auf der bisherigen Vorgabe standen (etwa memory_limit = 256M), gelten nach dem Update als wie allgemein und folgen künftig der allgemeinen Konfiguration. Auf dem Node ändert sich dadurch nichts; eine Domain, die einen solchen Wert bewusst eingetragen hatte, trägt ihn bei Bedarf neu ein.
  • Freie php.ini-Zeilen je Domain nehmen nur Direktiven an, die eine Anwendung auch selbst über .user.ini oder ini_set() setzen dürfte. Eine Zeile wie sendmail_path hätte im FPM-Pool sonst einen beliebigen Befehl erlaubt.
  • Eingehende Mail mit 15 Punkten oder mehr wird abgelehnt — auch auf bestehenden Nodes. Bisher wurde nichts abgelehnt, auch eindeutiger Spam nicht. Verloren geht dabei nichts unbemerkt: der absendende Server bekommt den Fehler und benachrichtigt seinen Absender. Wer weiterhin nichts ablehnen will, leert im Bereich Mailserver das Feld Ablehnen ab.
  • Der lernende Teil des Spamfilters (Bayes) lernt von selbst nur noch eindeutigen Spam ab der Ablehnschwelle. Bisher lernte er alles ab 6 Punkten als Spam, auch Grenzfälle.
  • Die WildFly-Verwaltungskonsole öffnet sich auf Port 8447 desselben Namens wie das Panel, etwa https://panel.example:8447/console/index.html. Bisher lief sie unter der Adresse des Panels, und ein Skript der Konsole hätte das Panel mit der Sitzung des angemeldeten Administrators bedienen können. Die Firewall von Kastra gibt Port 8447 auf dem Node des Panels frei, unter denselben Regeln wie SSH und das Panel; eine Firewall oder ein eigener Proxy davor muss ihn ebenfalls durchlassen, sonst bleibt der Rahmen leer. Ein bestehender Panel-Vhost bekommt den neuen Server-Block beim Update, die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsolenport liegen.
  • Wer unter Einstellungen › Aktualisierung Repository, Versionsauskunft oder Signaturschlüssel ändert, gibt dazu den Code aus der App oder das aktuelle Passwort an; ein Konto nur mit Passkey braucht eine Anmeldung, die keine zehn Minuten zurückliegt. Beide Adressen müssen http:// oder https:// ohne Leerzeichen, Anmeldedaten, Abfrage oder Anker sein, der Schlüssel ein öffentlicher PGP-Schlüssel. Bisher genügte die Sitzung, und die Adresse ging ungeprüft in die apt-Quelle jedes Nodes.
  • Eine Anmeldung mit falschem Einmalcode, an einem gesperrten oder an einem deaktivierten Konto bekommt dieselbe Meldung wie eine mit falschem Passwort: Benutzername, Passwort oder Einmalcode ist falsch. Der Hinweis darunter nennt die Sperre nach fünf Fehlversuchen als möglichen Grund. Bisher verrieten eigene Meldungen, dass es das Konto gibt, in welchem Zustand es ist oder dass das Passwort stimmte.
  • Von einer Adresse lassen sich höchstens 60 Passkey-Anmeldungen je Minute beginnen; darüber kommt eine Meldung, die Anmeldung mit Passwort bleibt möglich. Die Mengengrenze der ACME-Delegation zählt IPv6-Adressen je /64 statt je Adresse.
  • Je Subscription sind höchstens vier Web-Terminals gleichzeitig offen, je Node 32, und je Node höchstens 64 Live-Protokolle. Darüber nennt das Panel die Grenze, statt ein weiteres zu öffnen.
  • Die privaten Schlüssel der Zertifikate liegen verschlüsselt in der Datenbank, sobald KASTRA_SECRET_KEY gesetzt ist; vorhandene werden beim ersten Start nach dem Update umgestellt.
  • /actuator ist außer /actuator/health nur noch für angemeldete Administratoren erreichbar. Steht die Verbundadresse KASTRA_CLUSTER_BASE_URL nicht auf https://, meldet die Control Plane das beim Start als Fehler.
  • Ein stillgelegter Node wird sofort getrennt. Bisher redete sein Agent weiter, bis er sich von selbst neu verband.
  • Bei einem unerwarteten Fehler sehen nur Administratoren die Ursache im Feld Detail; alle anderen bekommen die Correlation-ID, unter der sie im Protokoll steht.

Behoben

  • Der Bereich FTP einer Subscription oder Domain zeigt auf einem Node, auf dem FTP ausgeschaltet ist, keine Fehlerkarte „kein FTP-Dienst eingerichtet“ mehr; das Protokoll bleibt dort einfach leer.
  • Wird die JVM von WildFly hart beendet (kill -9), startet WildFly wieder. Bisher blieb er in diesem Fall aus, und im Serverprotokoll stand nichts dazu.
  • Ein frisch eingeschalteter Mailserver nimmt Mail von außen an. Bisher horchte Postfix nach dem Einschalten weiter nur auf 127.0.0.1:25, weil der Rollout es nur neu geladen statt neu gestartet hat, und unter Komponenten blieb „horchen auf Port 25 aber nur auf 127.0.0.1“ stehen. Ein Node, der so hängen geblieben ist, kommt mit dem nächsten Rollout nach dem Update von selbst in Ordnung; Postfix startet dabei einmal neu.
  • Das Lebensende von PHP, Node.js und der Distribution wird wieder geladen. Lag auf einem Node WildFly, scheiterte der ganze Abruf von endoflife.date, weil es dort kein Produkt WildFly gibt.
  • Unter Einstellungen › Sicherheitslücken steht eine Quelle, die kein Node braucht, als nicht benötigt statt noch nie abgerufen — etwa php.net, solange kein Node PHP aus sury hat. Die Seite Sicherheitslücken zeigte eine nie abgerufene Quelle bisher als aktuell.
  • Die Schwachstellendaten werden jede Nacht abgerufen. Nach einem Abruf von Hand am Nachmittag fiel bisher die folgende Nacht aus.
  • Alarme per Mail oder Webhook kommen wieder an. Bisher blieben sie oft unzugestellt und standen unter Einstellungen › Alarmierung dauerhaft als wartend — betroffen war jede Alarmart außer der Probemeldung, etwa Node nicht erreichbar oder Verwaltete Dateien verändert.
  • Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
  • Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.
  • Ein gekürzter Hinweis unter einem Eingabefeld zeigt beim Überfahren überall seinen vollen Text, etwa im Formular Tarif bearbeiten. Bisher tat er das nur auf wenigen Seiten.
  • Die Protokolle einer Domain füllen ihren Kasten sofort ganz. Bisher erschien bei einem langen Protokoll nur der obere Teil, der Rest erst beim Rollen.
  • Die Control Plane läuft auf Spring Boot 4.1 (Spring Framework 7, Tomcat 11, Hibernate 7). Damit sind 24 bekannte Lücken in ihren Bibliotheken geschlossen, darunter drei kritische in Tomcat und zwei in BouncyCastle; für die bisherige Spring-Linie gibt es keine freien Sicherheitsupdates mehr. Am Betrieb ändert sich nichts: Einstellungen, Umgebungsvariablen und die Antworten der Schnittstelle bleiben gleich.
  • Auf Ubuntu-Nodes werden die Pakete der Distribution gegen die Sicherheitsdaten von Canonical abgeglichen, und phpMyAdmin, Roundcube, Composer und WP-CLI gegen OSV. Bisher standen sie trotz geladener Daten als nicht erfasst da — es lagen „noch keine Schwachstellendaten vor“.
  • Die nginx-Zusatzkonfiguration einer Domain prüft jetzt jede Anweisung einer Zeile, nicht nur das erste Wort. Eine zweite Anweisung hinter einem Semikolon — etwa expires 1h; proxy_pass … oder ein über Klammern eingeschleuster location-Block mit alias /etc/ — wird mit der ganzen Zeile verworfen und steht unter den Hinweisen des Rollouts. access_log ist nur noch zum Abschalten (off) erlaubt. Bisher kam alles hinter dem ersten Wort ungeprüft durch.
  • Eine Weiterleitung, ein Catch-All-Ziel und der Name eines Versandzugangs nehmen nur noch eine Adresse der eigenen Maildomain an; ein erlaubter Absender ebenso. Bisher ließ sich darüber die Post einer fremden Maildomain auf demselben Node umleiten oder unter ihrem Namen versenden. Ein Versandzugang bekommt nur noch dann eine DKIM-Signatur, wenn die Domain seiner Anmeldung zur Domain im Absender passt.
  • Der Datenbankabzug einer Sicherung folgt im Heimatverzeichnis keinem symbolischen Verweis mehr. Bisher hätte ein Verweis ~/.kastra-sicherung auf ein Systemverzeichnis dieses beim nächsten Sicherungslauf übereignen oder überschreiben können.
  • Das Aufgabenprotokoll zeigt einem Kunden nicht mehr den Rollout-Diff des ganzen Nodes. Bisher stand im Feld der abgeschlossenen Aufgabe die geänderte Konfiguration aller Kunden des Nodes samt Mail-Passwortdatei und privaten Schlüsseln; Administratoren sehen ihn weiterhin.
  • Einen neuen Passkey hinzufügen, TOTP (neu) einrichten und ein API-Token anlegen verlangen jetzt denselben zweiten Nachweis wie das Widerrufen eines Passkeys — einen Code aus der Authenticator-App, das aktuelle Passwort oder eine frische Anmeldung. Bisher genügte dafür die Sitzung, und ein fremder Zugriff auf eine angemeldete Sitzung konnte sich damit dauerhaft einnisten.
  • Die Sperre nach fünf Fehlversuchen trifft nur noch die Passwortanmeldung. Ein Konto ohne Passwortanmeldung zählt keine Fehlversuche mehr, und eine bestehende Sperre hält Passkey und Wiederherstellungscode nicht länger auf. Bisher ließ sich ein Konto, das nur per Passkey erreichbar ist, mit fünf Anfragen aussperren.
  • Meldet sich ein Node mit einem anderen Zertifikat als dem, das bei seiner Anmeldung ausgestellt wurde, wird er abgewiesen. Damit verliert ein ausgetauschter oder abgegebener Rechner seinen Zugang, sobald sich an seiner Stelle ein neuer anmeldet.
  • Eine Subdomain einer fremden Domain lässt sich nicht mehr als eigene Hauptdomain anlegen. Bisher hätte ein Kunde so eine Domain samt eigener DNS-Zone und Zertifikat unter einem fremden Namen beanspruchen können.
  • Ein Virenscan und ein Rückspieltest halten keine Datenbankverbindung mehr über ihre ganze Laufzeit. Bisher konnten mehrere gleichzeitig gestartete Läufe die Control Plane ausbremsen.
  • Grundbausteine der Control Plane sind auf aktuelle, abgesicherte Fassungen gehoben: Spring Boot 3.5.16, gRPC 1.76 (darin Netty mit den Fixes gegen CVE-2025-24970 und CVE-2025-55163 — ein Absturz des gesamten Dienstes über ein präpariertes TLS- bzw. HTTP/2-Paket) und die JWT-Bibliothek 10.0.2 (CVE-2025-53864, ein Lahmlegen über ein verschachteltes Sitzungscookie).
  • READONLY-Konten können kein Web-Terminal mehr öffnen; das war Schreibzugriff und widersprach der Rolle.
  • Ein Kunde kann die Übernahme eines Postfachs nur noch von einem öffentlichen IMAP-Server auf Port 143 oder 993 anstoßen. Bisher ließ sich damit das interne Netz des Nodes abtasten.
  • Die Statusseite zeigt einem Kunden das Gesamtbild, aber nicht mehr die einzelnen Vorfälle anderer Kunden samt Node-Namen.
  • Ein Sicherungsziel lässt sich nur noch auswählen, wenn es auf dem Node der Subscription liegt. Bisher hätte ein Kunde das Ziel eines fremden Nodes anhängen können.
  • Ein SFTP-Unterverzeichnis, das über einen symbolischen Verweis aus dem Heimatverzeichnis führt, wird abgewiesen statt eingehängt.
  • Fällige Sicherungen und Suchläufe nach Schadsoftware laufen jetzt nebenläufig an und halten einander nicht mehr auf. Bisher konnte ein langer Lauf dazu führen, dass eine Regel, die kurz danach fällig war, in dieser Nacht gar nicht lief — ohne Meldung.
  • Die Aufbewahrungsfrist des Audit-Logs wirkt. Bisher verhinderte ein Schutz gegen Änderungen auch das Löschen alter Einträge, und das Audit-Log wuchs trotz eingestellter Frist unbegrenzt.
  • Mail lässt sich nicht mehr für eine gleichnamige Maildomain eines anderen Kunden ein- oder ausschalten.
  • Den Node einer Maildomain und einer DNS-Zone sowie Art und Herkunft einer Zone wählt nur noch ein Administrator; ein Kunde bekommt den vorgesehenen Node.
  • Ein Rückspieltest schreibt nicht mehr durch einen symbolischen Verweis im Heimatverzeichnis an eine fremde Stelle.
  • Drift-Berichte eines Nodes werden gedeckelt gespeichert (höchstens 1000 Zeilen je Bericht, Diff gekürzt), statt die Datenbank bei dauerhafter Abweichung zu füllen.
  • Ein Node schreibt nur noch in sein eigenes Update-Protokoll, nicht mehr in das eines anderen.
  • Gleichzeitige Anmeldeversuche können die Control Plane nicht mehr über den Speicher der Passwortprüfung lahmlegen (höchstens vier gleichzeitige Prüfungen, der Rest wartet kurz).
  • Eine Container-Angabe mit einem Bind-Mount in der langen Form außerhalb des Subscription-Verzeichnisses oder mit einem auf 0.0.0.0 veröffentlichten Port wird jetzt ebenfalls abgewiesen.
  • Der Panel-Vhost nennt die nginx-Fassung nicht mehr (server_tokens off), beschränkt die TLS-1.2-Verschlüsselung auf Verfahren mit Vorwärtsgeheimnis (ssl_ciphers), erlaubt per connect-src nur noch Verbindungen zum Panel selbst, sperrt vendor/ unter phpMyAdmin und nimmt unter /api/ höchstens 64 MB an, ohne sie vor der Anmeldung auf die Platte zu puffern. Ein bestehender Vhost bekommt das beim Update nachgetragen; die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-pruefbericht liegen.
  • Ein Einmalcode aus der Authenticator-App lässt sich auch bei zwei gleichzeitigen Anmeldungen nur einmal verwenden.
  • Verbindet sich ein Node neu, während seine alte Verbindung noch abgebaut wird, bleibt er verbunden. Bisher scheiterten seine laufenden Aufgaben dann mit Node nicht erreichbar, und er stand bis zum nächsten Herzschlag als getrennt da.
  • Alarme per Mail oder Webhook werden auf eigenen Fäden zugestellt. Ein langsamer Mailserver oder Webhook hält keinen Rollout und keine Datenbankverbindung mehr auf.
  • Ein Hostname, der kein gültiger Rechnername ist, wird beim Anmelden eines Nodes abgewiesen. Bisher ging er ungeprüft ins Zertifikat und in die Betreffzeile von Alarmmails.
  • Ein Anmelde-Token mit Hostnamen gilt nur noch für genau diesen Namen: ein Rechner, der sich unter einem anderen meldet, wird abgewiesen, und das Token bleibt gültig. Bisher meldete sich damit jeder Rechner unter jedem freien Namen an. Der Befehl unter Nodes › Node aufnehmen nennt dafür den Hostnamen aus dem Token mit.
  • kastractl node token gibt den Befehl für den Node samt Fingerabdruck der CA aus, und als Adresse den Panel-Namen. Bisher fehlte der Fingerabdruck, und der Agent wies den Befehl ab; die Adresse war der Rechnername des Panel-Hosts, auf den das Zertifikat der Control Plane nicht lauten muss.
  • Ein neues FTP-Passwort wird in einem Feld unter dem Zugang eingegeben. Bisher fragte ein Browser-Dialog danach, der es im Klartext zeigte.
  • Passwortfelder für Postfächer, Sicherungsziele, Alarmkanäle und Datenbanken füllt der Browser nicht mehr mit dem gespeicherten Panel-Passwort.
  • Wechselt man die Domain, verschwinden die einmaligen Zugangsdaten einer gerade angelegten ACME-Delegation. Bisher standen sie unter der nächsten Domain weiter da.
  • Auf einem Panel, das vor dem 31. August 2026 eingerichtet wurde, öffnet sich die WildFly-Verwaltungskonsole. Seinem Vhost fehlte die Regel für die Konsole, und kein Update trug sie nach; seit die Konsole auf Port 8447 liegt, meldete der Rahmen nur noch, der Server habe die Verbindung abgelehnt. Das Update trägt Regel und Port jetzt nach, die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsole liegen.
  • Auf einem Panel, das vor dem 1. September 2026 eingerichtet wurde, tragen die Oberfläche und ihre Dateien dieselben Sicherheitskopfzeilen wie auf einer neuen Anlage: Content-Security-Policy, X-Frame-Options, HSTS, nosniff und Referrer-Policy. Bisher kam das Panel dort ohne sie beim Browser an und ließ sich von jeder fremden Seite einrahmen. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-kopfzeilen liegen.
  • Auf einem Panel, das seit dem 1. September 2026 eingerichtet wurde, verbot die Sicherheitsregel des Panels phpMyAdmin das Skript, mit dem es seine Seiten in Gang setzt. phpMyAdmin bekommt jetzt eine eigene Regel, die das zulässt und es weiterhin vor fremden Rahmen schützt. Kartenkacheln für GIS-Daten lädt phpMyAdmin nicht von außen nach. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-phpmyadmin liegen.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

Rendert anders

  • nft — auf dem Node, der das Panel trägt, lässt die Verwaltungsregel neben 22 und 8443 auch Port 8447 zu (WildFly-Konsole), mit derselben Drosselung bzw. denselben Admin-Netzen.
  • wildfly-unit — /etc/systemd/system/kastra-wildfly.service trägt Restart=always statt Restart=on-failure, StartLimitIntervalSec=1800, StartLimitBurst=6 und WorkingDirectory=-/opt/wildfly/standalone. Der Agent zieht eine bestehende Unit nach seinem Start einmal nach; ein laufender WildFly wird dabei nicht neu gestartet, die Werte gelten ab dem nächsten Start.
  • fpm-confd — neu je PHP-Fassung: /etc/php/<fassung>/fpm/conf.d/99-kastra.ini mit opcache.validate_permission = 1, opcache.restrict_api und session.upload_progress.enabled = 0, dazu, was unter Einstellungen › PHP allgemein steht. Alle FPM-Fassungen werden dafür einmal neu geladen. Die Datei gehört ab jetzt Kastra; eine von Hand dort abgelegte Datei mit anderem Namen bleibt unberührt. Eine Notfalldatei wie 99-notfall.ini kann nach dem Update weg.
  • fpm-pool — jeder Pool trägt php_admin_flag[session.upload_progress.enabled] = off. Weitere neue Zeilen (Sitzungs-Cookies, OPcache, Zeitgrenze, Slowlog, allgemeine freie Zeilen) erscheinen nur, wenn jemand einen Wert einstellt.
  • apparmor-php — das Profil von PHP-FPM erlaubt das Schreiben unter /var/log/kastra/subscriptions/ und das Mitlesen eines langsamen Workers für das Protokoll langsamer Anfragen.
  • logrotate — php-slow.log wird mit php-error.log gedreht.
  • mail — auf jedem Node mit Mailserver: unter /etc/rspamd/local.d/ neu milter_headers.conf und settings.conf, geändert actions.conf und classifier-bayes.conf; neu das Verzeichnis /etc/dovecot/kastra-spam/ mit den Sieve-Skripten für Junk-Ordner und Lernen samt zwei Programmen, die rspamc aufrufen und jede Korrektur ins Mailprotokoll schreiben; die Dovecot-Konfiguration bindet sie über sieve_before und IMAPSieve ein. Rspamd und Dovecot werden dafür einmal neu geladen.

26.10.26.11

Eingriff am Node Test 103 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.
  • Unter Einstellungen › PHP gibt es eine allgemeine PHP-Konfiguration für alle Nodes und alle PHP-Fassungen: Grenzen, Fehler und Regionales, Sitzungen, OPcache, FPM-Prozesse und freie php.ini-Zeilen. Jede Domain erbt, was sie nicht selbst setzt; bei jedem Feld steht, wie viele Domains abweichen. Nur für Administratoren.
  • Der Bereich PHP einer Domain zeigt bei jedem Feld, ob der Wert eigen ist oder wie allgemein; ein leeres Feld oder Alles wie allgemein setzt ihn zurück. Neu dort: Sitzungs-Cookies (nur über HTTPS, HttpOnly, SameSite, nur bekannte Kennungen), das OPcache-Prüfintervall, freie php.ini-Zeilen und — für Administratoren — die FPM-Prozesse samt harter Zeitgrenze und Protokoll langsamer Anfragen.
  • Dauert eine PHP-Anfrage länger als eingestellt, steht ihr Aufrufstapel im neuen Protokoll Langsame PHP-Anfragen der Domain.
  • Die PHP-Fassung des Webmails lässt sich im Bereich Mailserver eines Nodes einstellen, unabhängig von den Maildomains. Automatisch bleibt die Voreinstellung und wählt wie bisher die neueste Fassung bis 8.3. Fehlen der gewählten Fassung Erweiterungen, die Roundcube braucht, bleibt das Webmail auf der automatischen Wahl, und der Rollout nennt die fehlenden Pakete. Eine Fassung, auf der das Webmail eingestellt ist, lässt sich unter Laufzeiten nicht entfernen.
  • Kastra prüft die Software auf jedem Node gegen bekannte Sicherheitslücken: jedes installierte Paket — auch PostgreSQL, OpenSSL, OpenSSH und den Kernel —, dazu Node.js, WildFly, phpMyAdmin, Roundcube, Composer und WP-CLI. Die Daten kommen nachts von Debian, Ubuntu, php.net, der Node.js Security-WG, OSV und endoflife.date; der Paketbestand verlässt dafür den Server nicht. Der neue Bereich Sicherheitslücken eines Nodes nennt je Technologie Paket, installierte Fassung, Fix-Fassung, CVE, betroffene Domains und den nächsten Schritt; eine Lücke, die nicht greift, lässt sich mit Begründung quittieren.
  • Die Seite Sicherheitslücken zeigt dasselbe über alle Nodes und beantwortet, ob eine bestimmte Technologie irgendwo betroffen ist. Eingestellt wird unter Einstellungen › Sicherheitslücken: Schwelle des Alarms, Karenz und die Adressen der Quellen (leer schaltet eine Quelle ab, etwa ohne Internet oder mit eigenem Spiegel). Nur für Administratoren.
  • Neue Alarmarten: SCHWACHSTELLE meldet behebbare Lücken ab Dringlichkeit hoch und — kritisch — jede Lücke, die laut CISA aktiv ausgenutzt wird; Fixe, die die automatischen Sicherheitsupdates selbst holen, erst nach 48 Stunden. LEBENSENDE meldet Software ohne Sicherheitsupdates (etwa PHP 8.1 oder Node.js 20), SCHWACHSTELLEN_DATEN eine Quelle, die länger als 72 Stunden nicht abgerufen werden konnte.
  • Im Bereich Sicherheitslücken eines Nodes spielt Aktualisieren den Fix eines Befunds ein, Alle behebbaren aktualisieren alle auf einmal — als Aufgabe mit Protokoll, danach verschwindet der Befund. Das ist auch der Weg für PHP aus sury: die automatischen Sicherheitsupdates holen es weiterhin nicht, weil sury neben PHP neuere Bibliotheken mitbringt. Was sich so nicht beheben lässt (phpMyAdmin, Roundcube, Composer, WP-CLI, ein Kernel, der nur neu starten muss), nennt den Grund.
  • Läuft auf dem Host der Control Plane kein Agent, zeigt die Seite Sicherheitslücken ihn als „nicht erfasst“: PostgreSQL und Java dort werden dann nicht geprüft.
  • Die Control Plane lädt dafür einmal am Tag Daten von security-tracker.debian.org, security-metadata.canonical.com, cisa.gov, php.net, raw.githubusercontent.com, osv-vulnerabilities.storage.googleapis.com und endoflife.date. Sie liegen unter /var/lib/kastra-control-plane/schwachstellen.
  • Erkannter Spam landet im Ordner Junk des Postfachs. Bisher bekam er nur den Kopf X-Spam: Yes und blieb im Posteingang, weil kaum ein Mailprogramm diesen Kopf auswertet. Unter Mail › Spamfilter lässt eine Maildomain ihn auf Wunsch im Posteingang.
  • Der Bereich Mailserver eines Nodes hat einen Abschnitt Spamfilter mit drei Schwellen in Punkten: Greylisting ab (Vorgabe 4), Spam ab (6) und Ablehnen ab (15). Nur für Administratoren.
  • Jede Maildomain führt unter Mail › Spamfilter zwei Absenderlisten: Nie Spam (weder vertagt noch abgelehnt noch im Junk-Ordner) und Immer Spam (immer im Junk-Ordner), je Zeile eine Adresse oder @domain.
  • Verschiebt jemand eine Mail in den Junk-Ordner, lernt der Spamfilter sie als Spam; holt er sie heraus, als erwünscht — in jedem Mailprogramm über IMAP und im Webmail.
  • Eingehende Mail trägt im Kopf X-Spamd-Result mit den Punkten und den Regeln, die angeschlagen haben, und X-Spam-Status. Daran lässt sich ablesen, warum eine Mail im Junk-Ordner liegt.
  • Die Mailstatistik einer Maildomain und eines Nodes hat einen Abschnitt Spamfilter: wie viele eingehende Mails sauber, vertagt, als Spam markiert und abgelehnt wurden, wie oft jemand Spam selbst in den Junk-Ordner gelegt oder erwünschte Post herausgeholt hat, die Quoten Spam erkannt und Fehlalarme mit einer Empfehlung zur Schwelle und die Verteilung der Punkte mit den Schwellen des Nodes. Als Spam bewertete oder abgelehnte versendete Mail steht als Warnung darunter. Gezählt wird ab dem Update.
  • Die Liste Sendungen zeigt bei jeder Mail, die Rspamd bewertet hat, ihre Punkte.
  • Der Bereich Sicherheitslücken prüft auch die Bibliotheken, die eine Software mitbringt: jedes Jar von WildFly, vendor/ von phpMyAdmin und Roundcube, den Inhalt von Composer und WP-CLI und die Go-Module von Programmen aus einer fremden Paketquelle wie CrowdSec. Ein Befund heißt dann etwa io.undertow:undertow-core (wildfly-36.0.1.Final) und sagt, woher der Fix kommt. Ein WildFly 36.0.1 bringt zum Stand dieses Updates rund 90 behebbare Lücken mit, ein wp-cli 2.12.0 ein Composer 2.2.25 mit mehreren hohen.
  • Für Node.js zählt zusätzlich jede Sicherheitsfassung, die nodejs.org für den installierten Major führt — auch eine, die nur OpenSSL, undici oder npm erneuert und dafür keine CVE der Security-WG hat.
  • Unter Einstellungen › Sicherheitslücken stehen drei neue Quellen: Node.js Releases (nodejs.org), OSV Maven und OSV Go. Die Control Plane lädt dafür zusätzlich von nodejs.org; eine leere Adresse schaltet eine Quelle ab.
  • WildFly wird überwacht: fällt er aus oder antwortet er drei Minuten lang nicht, startet Kastra ihn neu — bei einem Hänger nach einem Thread-Dump ins Journal. Zu jedem Ausfall steht unter Laufzeiten › WildFly, wann er war und woran es lag, etwa Speichermangel, ein Absturz der JVM oder ein von außen gesendetes Signal. Nach fünf Neustarts in 30 Minuten gibt Kastra beim nächsten Ausfall auf, hält WildFly an und meldet die neue Alarmart WILDFLY_DOWN mit allen Ursachen. Starten im Panel setzt die Zählung zurück.
  • Eine Domain lässt sich im neuen Bereich Umzug in eine andere Subscription verschieben — zu einem anderen Kunden oder auf einen anderen Node. Sie zieht mit allen Subdomains, Datenbanken, Cronjobs, FTP-Zugängen, Mail und DNS um; eine Domain, die dieselbe Datenbank nutzt, zieht mit. Die Vorprüfung zeigt die ganze Gruppe mit dem Grund je Domain und prüft beim Wechsel des Nodes, ob dort läuft, was die Gruppe braucht (PHP-Fassung und Erweiterungen, Apache, Node.js, Podman, WAF, Objekt-Cache, Composer, MariaDB, Mail, FTP) und ob er den Sicherungsspeicher der Quelle erreicht, über den die Daten gehen. Gespeicherte Pfade in Cronjobs, Compose-Dateien, Zusatzkonfiguration und PHP-Einstellungen werden umgeschrieben; Dateien der Anwendung, die das alte Verzeichnis nennen, meldet die Vorprüfung. Nur für Administratoren.
  • Zieht eine Domain, die auf WildFly zeigt, auf einen anderen Node, zieht WildFly mit — samt Anwendungen, Konfiguration und jeder anderen Domain, die ebenfalls darauf zeigt, auch aus fremden Subscriptions. Die Vorprüfung nennt das in einem eigenen Block und verlangt eine Bestätigung; auf dem Ziel darf noch kein WildFly laufen.
  • Ein gescheiterter Domain-Umzug auf einen anderen Node lässt sich zurücknehmen; Quelle freigeben entfernt danach die alten Daten. Beides steht auch im Bereich Umzug der Subscriptions.

Geändert

  • Ein im Panel angehaltener WildFly bleibt für Kastra angehalten; wer ihn auf dem Node mit systemctl stop anhält, findet ihn dagegen eine Minute später wieder laufend. Ein WildFly, der vor dem Update als angehalten gemeldet war, gilt danach als im Panel angehalten.
  • Archiv erstellen im Dateimanager packt im Hintergrund: über der Liste und in der Leiste unten rechts steht, wie viel schon gepackt ist, und der Dateimanager bleibt währenddessen bedienbar — auch ein Seitenwechsel hält das Packen nicht an. Ein großes Archiv bricht nicht mehr nach fünf Minuten ab; die Grenze liegt jetzt bei einer Stunde.
  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.
  • Der Upload-Fortschritt in PHP-Sitzungen (session.upload_progress.enabled) ist auf jeder Domain aus und lässt sich je Domain nicht wieder einschalten, auch nicht über eine .user.ini. Braucht eine Anwendung ihn, schaltet ihn ein Administrator unter Einstellungen › PHP ein. Anlass ist die für den 21. Oktober 2026 angekündigte PHP-Sicherheitslücke in diesem Handler.
  • opcache_get_status() und opcache_reset() sind für jede Domain gesperrt, und PHP prüft bei jedem Treffer im OPcache, ob der Benutzer die Datei lesen darf. Bisher sah jede Domain die Dateipfade aller anderen Domains derselben PHP-Fassung, und Cache leeren in einer Anwendung leerte ihn allen.
  • PHP-Werte einer Domain, die genau auf der bisherigen Vorgabe standen (etwa memory_limit = 256M), gelten nach dem Update als wie allgemein und folgen künftig der allgemeinen Konfiguration. Auf dem Node ändert sich dadurch nichts; eine Domain, die einen solchen Wert bewusst eingetragen hatte, trägt ihn bei Bedarf neu ein.
  • Freie php.ini-Zeilen je Domain nehmen nur Direktiven an, die eine Anwendung auch selbst über .user.ini oder ini_set() setzen dürfte. Eine Zeile wie sendmail_path hätte im FPM-Pool sonst einen beliebigen Befehl erlaubt.
  • Eingehende Mail mit 15 Punkten oder mehr wird abgelehnt — auch auf bestehenden Nodes. Bisher wurde nichts abgelehnt, auch eindeutiger Spam nicht. Verloren geht dabei nichts unbemerkt: der absendende Server bekommt den Fehler und benachrichtigt seinen Absender. Wer weiterhin nichts ablehnen will, leert im Bereich Mailserver das Feld Ablehnen ab.
  • Der lernende Teil des Spamfilters (Bayes) lernt von selbst nur noch eindeutigen Spam ab der Ablehnschwelle. Bisher lernte er alles ab 6 Punkten als Spam, auch Grenzfälle.
  • Die WildFly-Verwaltungskonsole öffnet sich auf Port 8447 desselben Namens wie das Panel, etwa https://panel.example:8447/console/index.html. Bisher lief sie unter der Adresse des Panels, und ein Skript der Konsole hätte das Panel mit der Sitzung des angemeldeten Administrators bedienen können. Die Firewall von Kastra gibt Port 8447 auf dem Node des Panels frei, unter denselben Regeln wie SSH und das Panel; eine Firewall oder ein eigener Proxy davor muss ihn ebenfalls durchlassen, sonst bleibt der Rahmen leer. Ein bestehender Panel-Vhost bekommt den neuen Server-Block beim Update, die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsolenport liegen.
  • Wer unter Einstellungen › Aktualisierung Repository, Versionsauskunft oder Signaturschlüssel ändert, gibt dazu den Code aus der App oder das aktuelle Passwort an; ein Konto nur mit Passkey braucht eine Anmeldung, die keine zehn Minuten zurückliegt. Beide Adressen müssen http:// oder https:// ohne Leerzeichen, Anmeldedaten, Abfrage oder Anker sein, der Schlüssel ein öffentlicher PGP-Schlüssel. Bisher genügte die Sitzung, und die Adresse ging ungeprüft in die apt-Quelle jedes Nodes.
  • Eine Anmeldung mit falschem Einmalcode, an einem gesperrten oder an einem deaktivierten Konto bekommt dieselbe Meldung wie eine mit falschem Passwort: Benutzername, Passwort oder Einmalcode ist falsch. Der Hinweis darunter nennt die Sperre nach fünf Fehlversuchen als möglichen Grund. Bisher verrieten eigene Meldungen, dass es das Konto gibt, in welchem Zustand es ist oder dass das Passwort stimmte.
  • Von einer Adresse lassen sich höchstens 60 Passkey-Anmeldungen je Minute beginnen; darüber kommt eine Meldung, die Anmeldung mit Passwort bleibt möglich. Die Mengengrenze der ACME-Delegation zählt IPv6-Adressen je /64 statt je Adresse.
  • Je Subscription sind höchstens vier Web-Terminals gleichzeitig offen, je Node 32, und je Node höchstens 64 Live-Protokolle. Darüber nennt das Panel die Grenze, statt ein weiteres zu öffnen.
  • Die privaten Schlüssel der Zertifikate liegen verschlüsselt in der Datenbank, sobald KASTRA_SECRET_KEY gesetzt ist; vorhandene werden beim ersten Start nach dem Update umgestellt.
  • /actuator ist außer /actuator/health nur noch für angemeldete Administratoren erreichbar. Steht die Verbundadresse KASTRA_CLUSTER_BASE_URL nicht auf https://, meldet die Control Plane das beim Start als Fehler.
  • Ein stillgelegter Node wird sofort getrennt. Bisher redete sein Agent weiter, bis er sich von selbst neu verband.
  • Bei einem unerwarteten Fehler sehen nur Administratoren die Ursache im Feld Detail; alle anderen bekommen die Correlation-ID, unter der sie im Protokoll steht.

Behoben

  • Der Bereich FTP einer Subscription oder Domain zeigt auf einem Node, auf dem FTP ausgeschaltet ist, keine Fehlerkarte „kein FTP-Dienst eingerichtet“ mehr; das Protokoll bleibt dort einfach leer.
  • Wird die JVM von WildFly hart beendet (kill -9), startet WildFly wieder. Bisher blieb er in diesem Fall aus, und im Serverprotokoll stand nichts dazu.
  • Ein frisch eingeschalteter Mailserver nimmt Mail von außen an. Bisher horchte Postfix nach dem Einschalten weiter nur auf 127.0.0.1:25, weil der Rollout es nur neu geladen statt neu gestartet hat, und unter Komponenten blieb „horchen auf Port 25 aber nur auf 127.0.0.1“ stehen. Ein Node, der so hängen geblieben ist, kommt mit dem nächsten Rollout nach dem Update von selbst in Ordnung; Postfix startet dabei einmal neu.
  • Das Lebensende von PHP, Node.js und der Distribution wird wieder geladen. Lag auf einem Node WildFly, scheiterte der ganze Abruf von endoflife.date, weil es dort kein Produkt WildFly gibt.
  • Unter Einstellungen › Sicherheitslücken steht eine Quelle, die kein Node braucht, als nicht benötigt statt noch nie abgerufen — etwa php.net, solange kein Node PHP aus sury hat. Die Seite Sicherheitslücken zeigte eine nie abgerufene Quelle bisher als aktuell.
  • Die Schwachstellendaten werden jede Nacht abgerufen. Nach einem Abruf von Hand am Nachmittag fiel bisher die folgende Nacht aus.
  • Alarme per Mail oder Webhook kommen wieder an. Bisher blieben sie oft unzugestellt und standen unter Einstellungen › Alarmierung dauerhaft als wartend — betroffen war jede Alarmart außer der Probemeldung, etwa Node nicht erreichbar oder Verwaltete Dateien verändert.
  • Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
  • Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.
  • Ein gekürzter Hinweis unter einem Eingabefeld zeigt beim Überfahren überall seinen vollen Text, etwa im Formular Tarif bearbeiten. Bisher tat er das nur auf wenigen Seiten.
  • Die Protokolle einer Domain füllen ihren Kasten sofort ganz. Bisher erschien bei einem langen Protokoll nur der obere Teil, der Rest erst beim Rollen.
  • Die Control Plane läuft auf Spring Boot 4.1 (Spring Framework 7, Tomcat 11, Hibernate 7). Damit sind 24 bekannte Lücken in ihren Bibliotheken geschlossen, darunter drei kritische in Tomcat und zwei in BouncyCastle; für die bisherige Spring-Linie gibt es keine freien Sicherheitsupdates mehr. Am Betrieb ändert sich nichts: Einstellungen, Umgebungsvariablen und die Antworten der Schnittstelle bleiben gleich.
  • Auf Ubuntu-Nodes werden die Pakete der Distribution gegen die Sicherheitsdaten von Canonical abgeglichen, und phpMyAdmin, Roundcube, Composer und WP-CLI gegen OSV. Bisher standen sie trotz geladener Daten als nicht erfasst da — es lagen „noch keine Schwachstellendaten vor“.
  • Die nginx-Zusatzkonfiguration einer Domain prüft jetzt jede Anweisung einer Zeile, nicht nur das erste Wort. Eine zweite Anweisung hinter einem Semikolon — etwa expires 1h; proxy_pass … oder ein über Klammern eingeschleuster location-Block mit alias /etc/ — wird mit der ganzen Zeile verworfen und steht unter den Hinweisen des Rollouts. access_log ist nur noch zum Abschalten (off) erlaubt. Bisher kam alles hinter dem ersten Wort ungeprüft durch.
  • Eine Weiterleitung, ein Catch-All-Ziel und der Name eines Versandzugangs nehmen nur noch eine Adresse der eigenen Maildomain an; ein erlaubter Absender ebenso. Bisher ließ sich darüber die Post einer fremden Maildomain auf demselben Node umleiten oder unter ihrem Namen versenden. Ein Versandzugang bekommt nur noch dann eine DKIM-Signatur, wenn die Domain seiner Anmeldung zur Domain im Absender passt.
  • Der Datenbankabzug einer Sicherung folgt im Heimatverzeichnis keinem symbolischen Verweis mehr. Bisher hätte ein Verweis ~/.kastra-sicherung auf ein Systemverzeichnis dieses beim nächsten Sicherungslauf übereignen oder überschreiben können.
  • Das Aufgabenprotokoll zeigt einem Kunden nicht mehr den Rollout-Diff des ganzen Nodes. Bisher stand im Feld der abgeschlossenen Aufgabe die geänderte Konfiguration aller Kunden des Nodes samt Mail-Passwortdatei und privaten Schlüsseln; Administratoren sehen ihn weiterhin.
  • Einen neuen Passkey hinzufügen, TOTP (neu) einrichten und ein API-Token anlegen verlangen jetzt denselben zweiten Nachweis wie das Widerrufen eines Passkeys — einen Code aus der Authenticator-App, das aktuelle Passwort oder eine frische Anmeldung. Bisher genügte dafür die Sitzung, und ein fremder Zugriff auf eine angemeldete Sitzung konnte sich damit dauerhaft einnisten.
  • Die Sperre nach fünf Fehlversuchen trifft nur noch die Passwortanmeldung. Ein Konto ohne Passwortanmeldung zählt keine Fehlversuche mehr, und eine bestehende Sperre hält Passkey und Wiederherstellungscode nicht länger auf. Bisher ließ sich ein Konto, das nur per Passkey erreichbar ist, mit fünf Anfragen aussperren.
  • Meldet sich ein Node mit einem anderen Zertifikat als dem, das bei seiner Anmeldung ausgestellt wurde, wird er abgewiesen. Damit verliert ein ausgetauschter oder abgegebener Rechner seinen Zugang, sobald sich an seiner Stelle ein neuer anmeldet.
  • Eine Subdomain einer fremden Domain lässt sich nicht mehr als eigene Hauptdomain anlegen. Bisher hätte ein Kunde so eine Domain samt eigener DNS-Zone und Zertifikat unter einem fremden Namen beanspruchen können.
  • Ein Virenscan und ein Rückspieltest halten keine Datenbankverbindung mehr über ihre ganze Laufzeit. Bisher konnten mehrere gleichzeitig gestartete Läufe die Control Plane ausbremsen.
  • Grundbausteine der Control Plane sind auf aktuelle, abgesicherte Fassungen gehoben: Spring Boot 3.5.16, gRPC 1.76 (darin Netty mit den Fixes gegen CVE-2025-24970 und CVE-2025-55163 — ein Absturz des gesamten Dienstes über ein präpariertes TLS- bzw. HTTP/2-Paket) und die JWT-Bibliothek 10.0.2 (CVE-2025-53864, ein Lahmlegen über ein verschachteltes Sitzungscookie).
  • READONLY-Konten können kein Web-Terminal mehr öffnen; das war Schreibzugriff und widersprach der Rolle.
  • Ein Kunde kann die Übernahme eines Postfachs nur noch von einem öffentlichen IMAP-Server auf Port 143 oder 993 anstoßen. Bisher ließ sich damit das interne Netz des Nodes abtasten.
  • Die Statusseite zeigt einem Kunden das Gesamtbild, aber nicht mehr die einzelnen Vorfälle anderer Kunden samt Node-Namen.
  • Ein Sicherungsziel lässt sich nur noch auswählen, wenn es auf dem Node der Subscription liegt. Bisher hätte ein Kunde das Ziel eines fremden Nodes anhängen können.
  • Ein SFTP-Unterverzeichnis, das über einen symbolischen Verweis aus dem Heimatverzeichnis führt, wird abgewiesen statt eingehängt.
  • Fällige Sicherungen und Suchläufe nach Schadsoftware laufen jetzt nebenläufig an und halten einander nicht mehr auf. Bisher konnte ein langer Lauf dazu führen, dass eine Regel, die kurz danach fällig war, in dieser Nacht gar nicht lief — ohne Meldung.
  • Die Aufbewahrungsfrist des Audit-Logs wirkt. Bisher verhinderte ein Schutz gegen Änderungen auch das Löschen alter Einträge, und das Audit-Log wuchs trotz eingestellter Frist unbegrenzt.
  • Mail lässt sich nicht mehr für eine gleichnamige Maildomain eines anderen Kunden ein- oder ausschalten.
  • Den Node einer Maildomain und einer DNS-Zone sowie Art und Herkunft einer Zone wählt nur noch ein Administrator; ein Kunde bekommt den vorgesehenen Node.
  • Ein Rückspieltest schreibt nicht mehr durch einen symbolischen Verweis im Heimatverzeichnis an eine fremde Stelle.
  • Drift-Berichte eines Nodes werden gedeckelt gespeichert (höchstens 1000 Zeilen je Bericht, Diff gekürzt), statt die Datenbank bei dauerhafter Abweichung zu füllen.
  • Ein Node schreibt nur noch in sein eigenes Update-Protokoll, nicht mehr in das eines anderen.
  • Gleichzeitige Anmeldeversuche können die Control Plane nicht mehr über den Speicher der Passwortprüfung lahmlegen (höchstens vier gleichzeitige Prüfungen, der Rest wartet kurz).
  • Eine Container-Angabe mit einem Bind-Mount in der langen Form außerhalb des Subscription-Verzeichnisses oder mit einem auf 0.0.0.0 veröffentlichten Port wird jetzt ebenfalls abgewiesen.
  • Der Panel-Vhost nennt die nginx-Fassung nicht mehr (server_tokens off), beschränkt die TLS-1.2-Verschlüsselung auf Verfahren mit Vorwärtsgeheimnis (ssl_ciphers), erlaubt per connect-src nur noch Verbindungen zum Panel selbst, sperrt vendor/ unter phpMyAdmin und nimmt unter /api/ höchstens 64 MB an, ohne sie vor der Anmeldung auf die Platte zu puffern. Ein bestehender Vhost bekommt das beim Update nachgetragen; die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-pruefbericht liegen.
  • Ein Einmalcode aus der Authenticator-App lässt sich auch bei zwei gleichzeitigen Anmeldungen nur einmal verwenden.
  • Verbindet sich ein Node neu, während seine alte Verbindung noch abgebaut wird, bleibt er verbunden. Bisher scheiterten seine laufenden Aufgaben dann mit Node nicht erreichbar, und er stand bis zum nächsten Herzschlag als getrennt da.
  • Alarme per Mail oder Webhook werden auf eigenen Fäden zugestellt. Ein langsamer Mailserver oder Webhook hält keinen Rollout und keine Datenbankverbindung mehr auf.
  • Ein Hostname, der kein gültiger Rechnername ist, wird beim Anmelden eines Nodes abgewiesen. Bisher ging er ungeprüft ins Zertifikat und in die Betreffzeile von Alarmmails.
  • Ein Anmelde-Token mit Hostnamen gilt nur noch für genau diesen Namen: ein Rechner, der sich unter einem anderen meldet, wird abgewiesen, und das Token bleibt gültig. Bisher meldete sich damit jeder Rechner unter jedem freien Namen an. Der Befehl unter Nodes › Node aufnehmen nennt dafür den Hostnamen aus dem Token mit.
  • kastractl node token gibt den Befehl für den Node samt Fingerabdruck der CA aus, und als Adresse den Panel-Namen. Bisher fehlte der Fingerabdruck, und der Agent wies den Befehl ab; die Adresse war der Rechnername des Panel-Hosts, auf den das Zertifikat der Control Plane nicht lauten muss.
  • Ein neues FTP-Passwort wird in einem Feld unter dem Zugang eingegeben. Bisher fragte ein Browser-Dialog danach, der es im Klartext zeigte.
  • Passwortfelder für Postfächer, Sicherungsziele, Alarmkanäle und Datenbanken füllt der Browser nicht mehr mit dem gespeicherten Panel-Passwort.
  • Wechselt man die Domain, verschwinden die einmaligen Zugangsdaten einer gerade angelegten ACME-Delegation. Bisher standen sie unter der nächsten Domain weiter da.
  • Auf einem Panel, das vor dem 31. August 2026 eingerichtet wurde, öffnet sich die WildFly-Verwaltungskonsole. Seinem Vhost fehlte die Regel für die Konsole, und kein Update trug sie nach; seit die Konsole auf Port 8447 liegt, meldete der Rahmen nur noch, der Server habe die Verbindung abgelehnt. Das Update trägt Regel und Port jetzt nach, die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsole liegen.
  • Auf einem Panel, das vor dem 1. September 2026 eingerichtet wurde, tragen die Oberfläche und ihre Dateien dieselben Sicherheitskopfzeilen wie auf einer neuen Anlage: Content-Security-Policy, X-Frame-Options, HSTS, nosniff und Referrer-Policy. Bisher kam das Panel dort ohne sie beim Browser an und ließ sich von jeder fremden Seite einrahmen. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-kopfzeilen liegen.
  • Auf einem Panel, das seit dem 1. September 2026 eingerichtet wurde, verbot die Sicherheitsregel des Panels phpMyAdmin das Skript, mit dem es seine Seiten in Gang setzt. phpMyAdmin bekommt jetzt eine eigene Regel, die das zulässt und es weiterhin vor fremden Rahmen schützt. Kartenkacheln für GIS-Daten lädt phpMyAdmin nicht von außen nach. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-phpmyadmin liegen.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

Rendert anders

  • nft — auf dem Node, der das Panel trägt, lässt die Verwaltungsregel neben 22 und 8443 auch Port 8447 zu (WildFly-Konsole), mit derselben Drosselung bzw. denselben Admin-Netzen.
  • wildfly-unit — /etc/systemd/system/kastra-wildfly.service trägt Restart=always statt Restart=on-failure, StartLimitIntervalSec=1800, StartLimitBurst=6 und WorkingDirectory=-/opt/wildfly/standalone. Der Agent zieht eine bestehende Unit nach seinem Start einmal nach; ein laufender WildFly wird dabei nicht neu gestartet, die Werte gelten ab dem nächsten Start.
  • fpm-confd — neu je PHP-Fassung: /etc/php/<fassung>/fpm/conf.d/99-kastra.ini mit opcache.validate_permission = 1, opcache.restrict_api und session.upload_progress.enabled = 0, dazu, was unter Einstellungen › PHP allgemein steht. Alle FPM-Fassungen werden dafür einmal neu geladen. Die Datei gehört ab jetzt Kastra; eine von Hand dort abgelegte Datei mit anderem Namen bleibt unberührt. Eine Notfalldatei wie 99-notfall.ini kann nach dem Update weg.
  • fpm-pool — jeder Pool trägt php_admin_flag[session.upload_progress.enabled] = off. Weitere neue Zeilen (Sitzungs-Cookies, OPcache, Zeitgrenze, Slowlog, allgemeine freie Zeilen) erscheinen nur, wenn jemand einen Wert einstellt.
  • apparmor-php — das Profil von PHP-FPM erlaubt das Schreiben unter /var/log/kastra/subscriptions/ und das Mitlesen eines langsamen Workers für das Protokoll langsamer Anfragen.
  • logrotate — php-slow.log wird mit php-error.log gedreht.
  • mail — auf jedem Node mit Mailserver: unter /etc/rspamd/local.d/ neu milter_headers.conf und settings.conf, geändert actions.conf und classifier-bayes.conf; neu das Verzeichnis /etc/dovecot/kastra-spam/ mit den Sieve-Skripten für Junk-Ordner und Lernen samt zwei Programmen, die rspamc aufrufen und jede Korrektur ins Mailprotokoll schreiben; die Dovecot-Konfiguration bindet sie über sieve_before und IMAPSieve ein. Rspamd und Dovecot werden dafür einmal neu geladen.

26.10.26.9

Eingriff am Node Test 102 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.
  • Unter Einstellungen › PHP gibt es eine allgemeine PHP-Konfiguration für alle Nodes und alle PHP-Fassungen: Grenzen, Fehler und Regionales, Sitzungen, OPcache, FPM-Prozesse und freie php.ini-Zeilen. Jede Domain erbt, was sie nicht selbst setzt; bei jedem Feld steht, wie viele Domains abweichen. Nur für Administratoren.
  • Der Bereich PHP einer Domain zeigt bei jedem Feld, ob der Wert eigen ist oder wie allgemein; ein leeres Feld oder Alles wie allgemein setzt ihn zurück. Neu dort: Sitzungs-Cookies (nur über HTTPS, HttpOnly, SameSite, nur bekannte Kennungen), das OPcache-Prüfintervall, freie php.ini-Zeilen und — für Administratoren — die FPM-Prozesse samt harter Zeitgrenze und Protokoll langsamer Anfragen.
  • Dauert eine PHP-Anfrage länger als eingestellt, steht ihr Aufrufstapel im neuen Protokoll Langsame PHP-Anfragen der Domain.
  • Die PHP-Fassung des Webmails lässt sich im Bereich Mailserver eines Nodes einstellen, unabhängig von den Maildomains. Automatisch bleibt die Voreinstellung und wählt wie bisher die neueste Fassung bis 8.3. Fehlen der gewählten Fassung Erweiterungen, die Roundcube braucht, bleibt das Webmail auf der automatischen Wahl, und der Rollout nennt die fehlenden Pakete. Eine Fassung, auf der das Webmail eingestellt ist, lässt sich unter Laufzeiten nicht entfernen.
  • Kastra prüft die Software auf jedem Node gegen bekannte Sicherheitslücken: jedes installierte Paket — auch PostgreSQL, OpenSSL, OpenSSH und den Kernel —, dazu Node.js, WildFly, phpMyAdmin, Roundcube, Composer und WP-CLI. Die Daten kommen nachts von Debian, Ubuntu, php.net, der Node.js Security-WG, OSV und endoflife.date; der Paketbestand verlässt dafür den Server nicht. Der neue Bereich Sicherheitslücken eines Nodes nennt je Technologie Paket, installierte Fassung, Fix-Fassung, CVE, betroffene Domains und den nächsten Schritt; eine Lücke, die nicht greift, lässt sich mit Begründung quittieren.
  • Die Seite Sicherheitslücken zeigt dasselbe über alle Nodes und beantwortet, ob eine bestimmte Technologie irgendwo betroffen ist. Eingestellt wird unter Einstellungen › Sicherheitslücken: Schwelle des Alarms, Karenz und die Adressen der Quellen (leer schaltet eine Quelle ab, etwa ohne Internet oder mit eigenem Spiegel). Nur für Administratoren.
  • Neue Alarmarten: SCHWACHSTELLE meldet behebbare Lücken ab Dringlichkeit hoch und — kritisch — jede Lücke, die laut CISA aktiv ausgenutzt wird; Fixe, die die automatischen Sicherheitsupdates selbst holen, erst nach 48 Stunden. LEBENSENDE meldet Software ohne Sicherheitsupdates (etwa PHP 8.1 oder Node.js 20), SCHWACHSTELLEN_DATEN eine Quelle, die länger als 72 Stunden nicht abgerufen werden konnte.
  • Im Bereich Sicherheitslücken eines Nodes spielt Aktualisieren den Fix eines Befunds ein, Alle behebbaren aktualisieren alle auf einmal — als Aufgabe mit Protokoll, danach verschwindet der Befund. Das ist auch der Weg für PHP aus sury: die automatischen Sicherheitsupdates holen es weiterhin nicht, weil sury neben PHP neuere Bibliotheken mitbringt. Was sich so nicht beheben lässt (phpMyAdmin, Roundcube, Composer, WP-CLI, ein Kernel, der nur neu starten muss), nennt den Grund.
  • Läuft auf dem Host der Control Plane kein Agent, zeigt die Seite Sicherheitslücken ihn als „nicht erfasst“: PostgreSQL und Java dort werden dann nicht geprüft.
  • Die Control Plane lädt dafür einmal am Tag Daten von security-tracker.debian.org, security-metadata.canonical.com, cisa.gov, php.net, raw.githubusercontent.com, osv-vulnerabilities.storage.googleapis.com und endoflife.date. Sie liegen unter /var/lib/kastra-control-plane/schwachstellen.
  • Erkannter Spam landet im Ordner Junk des Postfachs. Bisher bekam er nur den Kopf X-Spam: Yes und blieb im Posteingang, weil kaum ein Mailprogramm diesen Kopf auswertet. Unter Mail › Spamfilter lässt eine Maildomain ihn auf Wunsch im Posteingang.
  • Der Bereich Mailserver eines Nodes hat einen Abschnitt Spamfilter mit drei Schwellen in Punkten: Greylisting ab (Vorgabe 4), Spam ab (6) und Ablehnen ab (15). Nur für Administratoren.
  • Jede Maildomain führt unter Mail › Spamfilter zwei Absenderlisten: Nie Spam (weder vertagt noch abgelehnt noch im Junk-Ordner) und Immer Spam (immer im Junk-Ordner), je Zeile eine Adresse oder @domain.
  • Verschiebt jemand eine Mail in den Junk-Ordner, lernt der Spamfilter sie als Spam; holt er sie heraus, als erwünscht — in jedem Mailprogramm über IMAP und im Webmail.
  • Eingehende Mail trägt im Kopf X-Spamd-Result mit den Punkten und den Regeln, die angeschlagen haben, und X-Spam-Status. Daran lässt sich ablesen, warum eine Mail im Junk-Ordner liegt.
  • Die Mailstatistik einer Maildomain und eines Nodes hat einen Abschnitt Spamfilter: wie viele eingehende Mails sauber, vertagt, als Spam markiert und abgelehnt wurden, wie oft jemand Spam selbst in den Junk-Ordner gelegt oder erwünschte Post herausgeholt hat, die Quoten Spam erkannt und Fehlalarme mit einer Empfehlung zur Schwelle und die Verteilung der Punkte mit den Schwellen des Nodes. Als Spam bewertete oder abgelehnte versendete Mail steht als Warnung darunter. Gezählt wird ab dem Update.
  • Die Liste Sendungen zeigt bei jeder Mail, die Rspamd bewertet hat, ihre Punkte.
  • Der Bereich Sicherheitslücken prüft auch die Bibliotheken, die eine Software mitbringt: jedes Jar von WildFly, vendor/ von phpMyAdmin und Roundcube, den Inhalt von Composer und WP-CLI und die Go-Module von Programmen aus einer fremden Paketquelle wie CrowdSec. Ein Befund heißt dann etwa io.undertow:undertow-core (wildfly-36.0.1.Final) und sagt, woher der Fix kommt. Ein WildFly 36.0.1 bringt zum Stand dieses Updates rund 90 behebbare Lücken mit, ein wp-cli 2.12.0 ein Composer 2.2.25 mit mehreren hohen.
  • Für Node.js zählt zusätzlich jede Sicherheitsfassung, die nodejs.org für den installierten Major führt — auch eine, die nur OpenSSL, undici oder npm erneuert und dafür keine CVE der Security-WG hat.
  • Unter Einstellungen › Sicherheitslücken stehen drei neue Quellen: Node.js Releases (nodejs.org), OSV Maven und OSV Go. Die Control Plane lädt dafür zusätzlich von nodejs.org; eine leere Adresse schaltet eine Quelle ab.
  • WildFly wird überwacht: fällt er aus oder antwortet er drei Minuten lang nicht, startet Kastra ihn neu — bei einem Hänger nach einem Thread-Dump ins Journal. Zu jedem Ausfall steht unter Laufzeiten › WildFly, wann er war und woran es lag, etwa Speichermangel, ein Absturz der JVM oder ein von außen gesendetes Signal. Nach fünf Neustarts in 30 Minuten gibt Kastra beim nächsten Ausfall auf, hält WildFly an und meldet die neue Alarmart WILDFLY_DOWN mit allen Ursachen. Starten im Panel setzt die Zählung zurück.
  • Eine Domain lässt sich im neuen Bereich Umzug in eine andere Subscription verschieben — zu einem anderen Kunden oder auf einen anderen Node. Sie zieht mit allen Subdomains, Datenbanken, Cronjobs, FTP-Zugängen, Mail und DNS um; eine Domain, die dieselbe Datenbank nutzt, zieht mit. Die Vorprüfung zeigt die ganze Gruppe mit dem Grund je Domain und prüft beim Wechsel des Nodes, ob dort läuft, was die Gruppe braucht (PHP-Fassung und Erweiterungen, Apache, Node.js, Podman, WAF, Objekt-Cache, Composer, MariaDB, Mail, FTP) und ob er den Sicherungsspeicher der Quelle erreicht, über den die Daten gehen. Gespeicherte Pfade in Cronjobs, Compose-Dateien, Zusatzkonfiguration und PHP-Einstellungen werden umgeschrieben; Dateien der Anwendung, die das alte Verzeichnis nennen, meldet die Vorprüfung. Nur für Administratoren.
  • Zieht eine Domain, die auf WildFly zeigt, auf einen anderen Node, zieht WildFly mit — samt Anwendungen, Konfiguration und jeder anderen Domain, die ebenfalls darauf zeigt, auch aus fremden Subscriptions. Die Vorprüfung nennt das in einem eigenen Block und verlangt eine Bestätigung; auf dem Ziel darf noch kein WildFly laufen.
  • Ein gescheiterter Domain-Umzug auf einen anderen Node lässt sich zurücknehmen; Quelle freigeben entfernt danach die alten Daten. Beides steht auch im Bereich Umzug der Subscriptions.

Geändert

  • Ein im Panel angehaltener WildFly bleibt für Kastra angehalten; wer ihn auf dem Node mit systemctl stop anhält, findet ihn dagegen eine Minute später wieder laufend. Ein WildFly, der vor dem Update als angehalten gemeldet war, gilt danach als im Panel angehalten.
  • Archiv erstellen im Dateimanager packt im Hintergrund: über der Liste und in der Leiste unten rechts steht, wie viel schon gepackt ist, und der Dateimanager bleibt währenddessen bedienbar — auch ein Seitenwechsel hält das Packen nicht an. Ein großes Archiv bricht nicht mehr nach fünf Minuten ab; die Grenze liegt jetzt bei einer Stunde.
  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.
  • Der Upload-Fortschritt in PHP-Sitzungen (session.upload_progress.enabled) ist auf jeder Domain aus und lässt sich je Domain nicht wieder einschalten, auch nicht über eine .user.ini. Braucht eine Anwendung ihn, schaltet ihn ein Administrator unter Einstellungen › PHP ein. Anlass ist die für den 21. Oktober 2026 angekündigte PHP-Sicherheitslücke in diesem Handler.
  • opcache_get_status() und opcache_reset() sind für jede Domain gesperrt, und PHP prüft bei jedem Treffer im OPcache, ob der Benutzer die Datei lesen darf. Bisher sah jede Domain die Dateipfade aller anderen Domains derselben PHP-Fassung, und Cache leeren in einer Anwendung leerte ihn allen.
  • PHP-Werte einer Domain, die genau auf der bisherigen Vorgabe standen (etwa memory_limit = 256M), gelten nach dem Update als wie allgemein und folgen künftig der allgemeinen Konfiguration. Auf dem Node ändert sich dadurch nichts; eine Domain, die einen solchen Wert bewusst eingetragen hatte, trägt ihn bei Bedarf neu ein.
  • Freie php.ini-Zeilen je Domain nehmen nur Direktiven an, die eine Anwendung auch selbst über .user.ini oder ini_set() setzen dürfte. Eine Zeile wie sendmail_path hätte im FPM-Pool sonst einen beliebigen Befehl erlaubt.
  • Eingehende Mail mit 15 Punkten oder mehr wird abgelehnt — auch auf bestehenden Nodes. Bisher wurde nichts abgelehnt, auch eindeutiger Spam nicht. Verloren geht dabei nichts unbemerkt: der absendende Server bekommt den Fehler und benachrichtigt seinen Absender. Wer weiterhin nichts ablehnen will, leert im Bereich Mailserver das Feld Ablehnen ab.
  • Der lernende Teil des Spamfilters (Bayes) lernt von selbst nur noch eindeutigen Spam ab der Ablehnschwelle. Bisher lernte er alles ab 6 Punkten als Spam, auch Grenzfälle.
  • Die WildFly-Verwaltungskonsole öffnet sich auf Port 8447 desselben Namens wie das Panel, etwa https://panel.example:8447/console/index.html. Bisher lief sie unter der Adresse des Panels, und ein Skript der Konsole hätte das Panel mit der Sitzung des angemeldeten Administrators bedienen können. Die Firewall von Kastra gibt Port 8447 auf dem Node des Panels frei, unter denselben Regeln wie SSH und das Panel; eine Firewall oder ein eigener Proxy davor muss ihn ebenfalls durchlassen, sonst bleibt der Rahmen leer. Ein bestehender Panel-Vhost bekommt den neuen Server-Block beim Update, die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsolenport liegen.
  • Wer unter Einstellungen › Aktualisierung Repository, Versionsauskunft oder Signaturschlüssel ändert, gibt dazu den Code aus der App oder das aktuelle Passwort an; ein Konto nur mit Passkey braucht eine Anmeldung, die keine zehn Minuten zurückliegt. Beide Adressen müssen http:// oder https:// ohne Leerzeichen, Anmeldedaten, Abfrage oder Anker sein, der Schlüssel ein öffentlicher PGP-Schlüssel. Bisher genügte die Sitzung, und die Adresse ging ungeprüft in die apt-Quelle jedes Nodes.
  • Eine Anmeldung mit falschem Einmalcode, an einem gesperrten oder an einem deaktivierten Konto bekommt dieselbe Meldung wie eine mit falschem Passwort: Benutzername, Passwort oder Einmalcode ist falsch. Der Hinweis darunter nennt die Sperre nach fünf Fehlversuchen als möglichen Grund. Bisher verrieten eigene Meldungen, dass es das Konto gibt, in welchem Zustand es ist oder dass das Passwort stimmte.
  • Von einer Adresse lassen sich höchstens 60 Passkey-Anmeldungen je Minute beginnen; darüber kommt eine Meldung, die Anmeldung mit Passwort bleibt möglich. Die Mengengrenze der ACME-Delegation zählt IPv6-Adressen je /64 statt je Adresse.
  • Je Subscription sind höchstens vier Web-Terminals gleichzeitig offen, je Node 32, und je Node höchstens 64 Live-Protokolle. Darüber nennt das Panel die Grenze, statt ein weiteres zu öffnen.
  • Die privaten Schlüssel der Zertifikate liegen verschlüsselt in der Datenbank, sobald KASTRA_SECRET_KEY gesetzt ist; vorhandene werden beim ersten Start nach dem Update umgestellt.
  • /actuator ist außer /actuator/health nur noch für angemeldete Administratoren erreichbar. Steht die Verbundadresse KASTRA_CLUSTER_BASE_URL nicht auf https://, meldet die Control Plane das beim Start als Fehler.
  • Ein stillgelegter Node wird sofort getrennt. Bisher redete sein Agent weiter, bis er sich von selbst neu verband.
  • Bei einem unerwarteten Fehler sehen nur Administratoren die Ursache im Feld Detail; alle anderen bekommen die Correlation-ID, unter der sie im Protokoll steht.

Behoben

  • Der Bereich FTP einer Subscription oder Domain zeigt auf einem Node, auf dem FTP ausgeschaltet ist, keine Fehlerkarte „kein FTP-Dienst eingerichtet“ mehr; das Protokoll bleibt dort einfach leer.
  • Wird die JVM von WildFly hart beendet (kill -9), startet WildFly wieder. Bisher blieb er in diesem Fall aus, und im Serverprotokoll stand nichts dazu.
  • Das Lebensende von PHP, Node.js und der Distribution wird wieder geladen. Lag auf einem Node WildFly, scheiterte der ganze Abruf von endoflife.date, weil es dort kein Produkt WildFly gibt.
  • Unter Einstellungen › Sicherheitslücken steht eine Quelle, die kein Node braucht, als nicht benötigt statt noch nie abgerufen — etwa php.net, solange kein Node PHP aus sury hat. Die Seite Sicherheitslücken zeigte eine nie abgerufene Quelle bisher als aktuell.
  • Die Schwachstellendaten werden jede Nacht abgerufen. Nach einem Abruf von Hand am Nachmittag fiel bisher die folgende Nacht aus.
  • Alarme per Mail oder Webhook kommen wieder an. Bisher blieben sie oft unzugestellt und standen unter Einstellungen › Alarmierung dauerhaft als wartend — betroffen war jede Alarmart außer der Probemeldung, etwa Node nicht erreichbar oder Verwaltete Dateien verändert.
  • Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
  • Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.
  • Ein gekürzter Hinweis unter einem Eingabefeld zeigt beim Überfahren überall seinen vollen Text, etwa im Formular Tarif bearbeiten. Bisher tat er das nur auf wenigen Seiten.
  • Die Protokolle einer Domain füllen ihren Kasten sofort ganz. Bisher erschien bei einem langen Protokoll nur der obere Teil, der Rest erst beim Rollen.
  • Die Control Plane läuft auf Spring Boot 4.1 (Spring Framework 7, Tomcat 11, Hibernate 7). Damit sind 24 bekannte Lücken in ihren Bibliotheken geschlossen, darunter drei kritische in Tomcat und zwei in BouncyCastle; für die bisherige Spring-Linie gibt es keine freien Sicherheitsupdates mehr. Am Betrieb ändert sich nichts: Einstellungen, Umgebungsvariablen und die Antworten der Schnittstelle bleiben gleich.
  • Auf Ubuntu-Nodes werden die Pakete der Distribution gegen die Sicherheitsdaten von Canonical abgeglichen, und phpMyAdmin, Roundcube, Composer und WP-CLI gegen OSV. Bisher standen sie trotz geladener Daten als nicht erfasst da — es lagen „noch keine Schwachstellendaten vor“.
  • Die nginx-Zusatzkonfiguration einer Domain prüft jetzt jede Anweisung einer Zeile, nicht nur das erste Wort. Eine zweite Anweisung hinter einem Semikolon — etwa expires 1h; proxy_pass … oder ein über Klammern eingeschleuster location-Block mit alias /etc/ — wird mit der ganzen Zeile verworfen und steht unter den Hinweisen des Rollouts. access_log ist nur noch zum Abschalten (off) erlaubt. Bisher kam alles hinter dem ersten Wort ungeprüft durch.
  • Eine Weiterleitung, ein Catch-All-Ziel und der Name eines Versandzugangs nehmen nur noch eine Adresse der eigenen Maildomain an; ein erlaubter Absender ebenso. Bisher ließ sich darüber die Post einer fremden Maildomain auf demselben Node umleiten oder unter ihrem Namen versenden. Ein Versandzugang bekommt nur noch dann eine DKIM-Signatur, wenn die Domain seiner Anmeldung zur Domain im Absender passt.
  • Der Datenbankabzug einer Sicherung folgt im Heimatverzeichnis keinem symbolischen Verweis mehr. Bisher hätte ein Verweis ~/.kastra-sicherung auf ein Systemverzeichnis dieses beim nächsten Sicherungslauf übereignen oder überschreiben können.
  • Das Aufgabenprotokoll zeigt einem Kunden nicht mehr den Rollout-Diff des ganzen Nodes. Bisher stand im Feld der abgeschlossenen Aufgabe die geänderte Konfiguration aller Kunden des Nodes samt Mail-Passwortdatei und privaten Schlüsseln; Administratoren sehen ihn weiterhin.
  • Einen neuen Passkey hinzufügen, TOTP (neu) einrichten und ein API-Token anlegen verlangen jetzt denselben zweiten Nachweis wie das Widerrufen eines Passkeys — einen Code aus der Authenticator-App, das aktuelle Passwort oder eine frische Anmeldung. Bisher genügte dafür die Sitzung, und ein fremder Zugriff auf eine angemeldete Sitzung konnte sich damit dauerhaft einnisten.
  • Die Sperre nach fünf Fehlversuchen trifft nur noch die Passwortanmeldung. Ein Konto ohne Passwortanmeldung zählt keine Fehlversuche mehr, und eine bestehende Sperre hält Passkey und Wiederherstellungscode nicht länger auf. Bisher ließ sich ein Konto, das nur per Passkey erreichbar ist, mit fünf Anfragen aussperren.
  • Meldet sich ein Node mit einem anderen Zertifikat als dem, das bei seiner Anmeldung ausgestellt wurde, wird er abgewiesen. Damit verliert ein ausgetauschter oder abgegebener Rechner seinen Zugang, sobald sich an seiner Stelle ein neuer anmeldet.
  • Eine Subdomain einer fremden Domain lässt sich nicht mehr als eigene Hauptdomain anlegen. Bisher hätte ein Kunde so eine Domain samt eigener DNS-Zone und Zertifikat unter einem fremden Namen beanspruchen können.
  • Ein Virenscan und ein Rückspieltest halten keine Datenbankverbindung mehr über ihre ganze Laufzeit. Bisher konnten mehrere gleichzeitig gestartete Läufe die Control Plane ausbremsen.
  • Grundbausteine der Control Plane sind auf aktuelle, abgesicherte Fassungen gehoben: Spring Boot 3.5.16, gRPC 1.76 (darin Netty mit den Fixes gegen CVE-2025-24970 und CVE-2025-55163 — ein Absturz des gesamten Dienstes über ein präpariertes TLS- bzw. HTTP/2-Paket) und die JWT-Bibliothek 10.0.2 (CVE-2025-53864, ein Lahmlegen über ein verschachteltes Sitzungscookie).
  • READONLY-Konten können kein Web-Terminal mehr öffnen; das war Schreibzugriff und widersprach der Rolle.
  • Ein Kunde kann die Übernahme eines Postfachs nur noch von einem öffentlichen IMAP-Server auf Port 143 oder 993 anstoßen. Bisher ließ sich damit das interne Netz des Nodes abtasten.
  • Die Statusseite zeigt einem Kunden das Gesamtbild, aber nicht mehr die einzelnen Vorfälle anderer Kunden samt Node-Namen.
  • Ein Sicherungsziel lässt sich nur noch auswählen, wenn es auf dem Node der Subscription liegt. Bisher hätte ein Kunde das Ziel eines fremden Nodes anhängen können.
  • Ein SFTP-Unterverzeichnis, das über einen symbolischen Verweis aus dem Heimatverzeichnis führt, wird abgewiesen statt eingehängt.
  • Fällige Sicherungen und Suchläufe nach Schadsoftware laufen jetzt nebenläufig an und halten einander nicht mehr auf. Bisher konnte ein langer Lauf dazu führen, dass eine Regel, die kurz danach fällig war, in dieser Nacht gar nicht lief — ohne Meldung.
  • Die Aufbewahrungsfrist des Audit-Logs wirkt. Bisher verhinderte ein Schutz gegen Änderungen auch das Löschen alter Einträge, und das Audit-Log wuchs trotz eingestellter Frist unbegrenzt.
  • Mail lässt sich nicht mehr für eine gleichnamige Maildomain eines anderen Kunden ein- oder ausschalten.
  • Den Node einer Maildomain und einer DNS-Zone sowie Art und Herkunft einer Zone wählt nur noch ein Administrator; ein Kunde bekommt den vorgesehenen Node.
  • Ein Rückspieltest schreibt nicht mehr durch einen symbolischen Verweis im Heimatverzeichnis an eine fremde Stelle.
  • Drift-Berichte eines Nodes werden gedeckelt gespeichert (höchstens 1000 Zeilen je Bericht, Diff gekürzt), statt die Datenbank bei dauerhafter Abweichung zu füllen.
  • Ein Node schreibt nur noch in sein eigenes Update-Protokoll, nicht mehr in das eines anderen.
  • Gleichzeitige Anmeldeversuche können die Control Plane nicht mehr über den Speicher der Passwortprüfung lahmlegen (höchstens vier gleichzeitige Prüfungen, der Rest wartet kurz).
  • Eine Container-Angabe mit einem Bind-Mount in der langen Form außerhalb des Subscription-Verzeichnisses oder mit einem auf 0.0.0.0 veröffentlichten Port wird jetzt ebenfalls abgewiesen.
  • Der Panel-Vhost nennt die nginx-Fassung nicht mehr (server_tokens off), beschränkt die TLS-1.2-Verschlüsselung auf Verfahren mit Vorwärtsgeheimnis (ssl_ciphers), erlaubt per connect-src nur noch Verbindungen zum Panel selbst, sperrt vendor/ unter phpMyAdmin und nimmt unter /api/ höchstens 64 MB an, ohne sie vor der Anmeldung auf die Platte zu puffern. Ein bestehender Vhost bekommt das beim Update nachgetragen; die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-pruefbericht liegen.
  • Ein Einmalcode aus der Authenticator-App lässt sich auch bei zwei gleichzeitigen Anmeldungen nur einmal verwenden.
  • Verbindet sich ein Node neu, während seine alte Verbindung noch abgebaut wird, bleibt er verbunden. Bisher scheiterten seine laufenden Aufgaben dann mit Node nicht erreichbar, und er stand bis zum nächsten Herzschlag als getrennt da.
  • Alarme per Mail oder Webhook werden auf eigenen Fäden zugestellt. Ein langsamer Mailserver oder Webhook hält keinen Rollout und keine Datenbankverbindung mehr auf.
  • Ein Hostname, der kein gültiger Rechnername ist, wird beim Anmelden eines Nodes abgewiesen. Bisher ging er ungeprüft ins Zertifikat und in die Betreffzeile von Alarmmails.
  • Ein Anmelde-Token mit Hostnamen gilt nur noch für genau diesen Namen: ein Rechner, der sich unter einem anderen meldet, wird abgewiesen, und das Token bleibt gültig. Bisher meldete sich damit jeder Rechner unter jedem freien Namen an. Der Befehl unter Nodes › Node aufnehmen nennt dafür den Hostnamen aus dem Token mit.
  • kastractl node token gibt den Befehl für den Node samt Fingerabdruck der CA aus, und als Adresse den Panel-Namen. Bisher fehlte der Fingerabdruck, und der Agent wies den Befehl ab; die Adresse war der Rechnername des Panel-Hosts, auf den das Zertifikat der Control Plane nicht lauten muss.
  • Ein neues FTP-Passwort wird in einem Feld unter dem Zugang eingegeben. Bisher fragte ein Browser-Dialog danach, der es im Klartext zeigte.
  • Passwortfelder für Postfächer, Sicherungsziele, Alarmkanäle und Datenbanken füllt der Browser nicht mehr mit dem gespeicherten Panel-Passwort.
  • Wechselt man die Domain, verschwinden die einmaligen Zugangsdaten einer gerade angelegten ACME-Delegation. Bisher standen sie unter der nächsten Domain weiter da.
  • Auf einem Panel, das vor dem 31. August 2026 eingerichtet wurde, öffnet sich die WildFly-Verwaltungskonsole. Seinem Vhost fehlte die Regel für die Konsole, und kein Update trug sie nach; seit die Konsole auf Port 8447 liegt, meldete der Rahmen nur noch, der Server habe die Verbindung abgelehnt. Das Update trägt Regel und Port jetzt nach, die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsole liegen.
  • Auf einem Panel, das vor dem 1. September 2026 eingerichtet wurde, tragen die Oberfläche und ihre Dateien dieselben Sicherheitskopfzeilen wie auf einer neuen Anlage: Content-Security-Policy, X-Frame-Options, HSTS, nosniff und Referrer-Policy. Bisher kam das Panel dort ohne sie beim Browser an und ließ sich von jeder fremden Seite einrahmen. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-kopfzeilen liegen.
  • Auf einem Panel, das seit dem 1. September 2026 eingerichtet wurde, verbot die Sicherheitsregel des Panels phpMyAdmin das Skript, mit dem es seine Seiten in Gang setzt. phpMyAdmin bekommt jetzt eine eigene Regel, die das zulässt und es weiterhin vor fremden Rahmen schützt. Kartenkacheln für GIS-Daten lädt phpMyAdmin nicht von außen nach. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-phpmyadmin liegen.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

Rendert anders

  • nft — auf dem Node, der das Panel trägt, lässt die Verwaltungsregel neben 22 und 8443 auch Port 8447 zu (WildFly-Konsole), mit derselben Drosselung bzw. denselben Admin-Netzen.
  • wildfly-unit — /etc/systemd/system/kastra-wildfly.service trägt Restart=always statt Restart=on-failure, StartLimitIntervalSec=1800, StartLimitBurst=6 und WorkingDirectory=-/opt/wildfly/standalone. Der Agent zieht eine bestehende Unit nach seinem Start einmal nach; ein laufender WildFly wird dabei nicht neu gestartet, die Werte gelten ab dem nächsten Start.
  • fpm-confd — neu je PHP-Fassung: /etc/php/<fassung>/fpm/conf.d/99-kastra.ini mit opcache.validate_permission = 1, opcache.restrict_api und session.upload_progress.enabled = 0, dazu, was unter Einstellungen › PHP allgemein steht. Alle FPM-Fassungen werden dafür einmal neu geladen. Die Datei gehört ab jetzt Kastra; eine von Hand dort abgelegte Datei mit anderem Namen bleibt unberührt. Eine Notfalldatei wie 99-notfall.ini kann nach dem Update weg.
  • fpm-pool — jeder Pool trägt php_admin_flag[session.upload_progress.enabled] = off. Weitere neue Zeilen (Sitzungs-Cookies, OPcache, Zeitgrenze, Slowlog, allgemeine freie Zeilen) erscheinen nur, wenn jemand einen Wert einstellt.
  • apparmor-php — das Profil von PHP-FPM erlaubt das Schreiben unter /var/log/kastra/subscriptions/ und das Mitlesen eines langsamen Workers für das Protokoll langsamer Anfragen.
  • logrotate — php-slow.log wird mit php-error.log gedreht.
  • mail — auf jedem Node mit Mailserver: unter /etc/rspamd/local.d/ neu milter_headers.conf und settings.conf, geändert actions.conf und classifier-bayes.conf; neu das Verzeichnis /etc/dovecot/kastra-spam/ mit den Sieve-Skripten für Junk-Ordner und Lernen samt zwei Programmen, die rspamc aufrufen und jede Korrektur ins Mailprotokoll schreiben; die Dovecot-Konfiguration bindet sie über sieve_before und IMAPSieve ein. Rspamd und Dovecot werden dafür einmal neu geladen.

26.10.26.7

Eingriff am Node Test 100 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.
  • Unter Einstellungen › PHP gibt es eine allgemeine PHP-Konfiguration für alle Nodes und alle PHP-Fassungen: Grenzen, Fehler und Regionales, Sitzungen, OPcache, FPM-Prozesse und freie php.ini-Zeilen. Jede Domain erbt, was sie nicht selbst setzt; bei jedem Feld steht, wie viele Domains abweichen. Nur für Administratoren.
  • Der Bereich PHP einer Domain zeigt bei jedem Feld, ob der Wert eigen ist oder wie allgemein; ein leeres Feld oder Alles wie allgemein setzt ihn zurück. Neu dort: Sitzungs-Cookies (nur über HTTPS, HttpOnly, SameSite, nur bekannte Kennungen), das OPcache-Prüfintervall, freie php.ini-Zeilen und — für Administratoren — die FPM-Prozesse samt harter Zeitgrenze und Protokoll langsamer Anfragen.
  • Dauert eine PHP-Anfrage länger als eingestellt, steht ihr Aufrufstapel im neuen Protokoll Langsame PHP-Anfragen der Domain.
  • Die PHP-Fassung des Webmails lässt sich im Bereich Mailserver eines Nodes einstellen, unabhängig von den Maildomains. Automatisch bleibt die Voreinstellung und wählt wie bisher die neueste Fassung bis 8.3. Fehlen der gewählten Fassung Erweiterungen, die Roundcube braucht, bleibt das Webmail auf der automatischen Wahl, und der Rollout nennt die fehlenden Pakete. Eine Fassung, auf der das Webmail eingestellt ist, lässt sich unter Laufzeiten nicht entfernen.
  • Kastra prüft die Software auf jedem Node gegen bekannte Sicherheitslücken: jedes installierte Paket — auch PostgreSQL, OpenSSL, OpenSSH und den Kernel —, dazu Node.js, WildFly, phpMyAdmin, Roundcube, Composer und WP-CLI. Die Daten kommen nachts von Debian, Ubuntu, php.net, der Node.js Security-WG, OSV und endoflife.date; der Paketbestand verlässt dafür den Server nicht. Der neue Bereich Sicherheitslücken eines Nodes nennt je Technologie Paket, installierte Fassung, Fix-Fassung, CVE, betroffene Domains und den nächsten Schritt; eine Lücke, die nicht greift, lässt sich mit Begründung quittieren.
  • Die Seite Sicherheitslücken zeigt dasselbe über alle Nodes und beantwortet, ob eine bestimmte Technologie irgendwo betroffen ist. Eingestellt wird unter Einstellungen › Sicherheitslücken: Schwelle des Alarms, Karenz und die Adressen der Quellen (leer schaltet eine Quelle ab, etwa ohne Internet oder mit eigenem Spiegel). Nur für Administratoren.
  • Neue Alarmarten: SCHWACHSTELLE meldet behebbare Lücken ab Dringlichkeit hoch und — kritisch — jede Lücke, die laut CISA aktiv ausgenutzt wird; Fixe, die die automatischen Sicherheitsupdates selbst holen, erst nach 48 Stunden. LEBENSENDE meldet Software ohne Sicherheitsupdates (etwa PHP 8.1 oder Node.js 20), SCHWACHSTELLEN_DATEN eine Quelle, die länger als 72 Stunden nicht abgerufen werden konnte.
  • Im Bereich Sicherheitslücken eines Nodes spielt Aktualisieren den Fix eines Befunds ein, Alle behebbaren aktualisieren alle auf einmal — als Aufgabe mit Protokoll, danach verschwindet der Befund. Das ist auch der Weg für PHP aus sury: die automatischen Sicherheitsupdates holen es weiterhin nicht, weil sury neben PHP neuere Bibliotheken mitbringt. Was sich so nicht beheben lässt (phpMyAdmin, Roundcube, Composer, WP-CLI, ein Kernel, der nur neu starten muss), nennt den Grund.
  • Läuft auf dem Host der Control Plane kein Agent, zeigt die Seite Sicherheitslücken ihn als „nicht erfasst“: PostgreSQL und Java dort werden dann nicht geprüft.
  • Die Control Plane lädt dafür einmal am Tag Daten von security-tracker.debian.org, security-metadata.canonical.com, cisa.gov, php.net, raw.githubusercontent.com, osv-vulnerabilities.storage.googleapis.com und endoflife.date. Sie liegen unter /var/lib/kastra-control-plane/schwachstellen.
  • Erkannter Spam landet im Ordner Junk des Postfachs. Bisher bekam er nur den Kopf X-Spam: Yes und blieb im Posteingang, weil kaum ein Mailprogramm diesen Kopf auswertet. Unter Mail › Spamfilter lässt eine Maildomain ihn auf Wunsch im Posteingang.
  • Der Bereich Mailserver eines Nodes hat einen Abschnitt Spamfilter mit drei Schwellen in Punkten: Greylisting ab (Vorgabe 4), Spam ab (6) und Ablehnen ab (15). Nur für Administratoren.
  • Jede Maildomain führt unter Mail › Spamfilter zwei Absenderlisten: Nie Spam (weder vertagt noch abgelehnt noch im Junk-Ordner) und Immer Spam (immer im Junk-Ordner), je Zeile eine Adresse oder @domain.
  • Verschiebt jemand eine Mail in den Junk-Ordner, lernt der Spamfilter sie als Spam; holt er sie heraus, als erwünscht — in jedem Mailprogramm über IMAP und im Webmail.
  • Eingehende Mail trägt im Kopf X-Spamd-Result mit den Punkten und den Regeln, die angeschlagen haben, und X-Spam-Status. Daran lässt sich ablesen, warum eine Mail im Junk-Ordner liegt.
  • Die Mailstatistik einer Maildomain und eines Nodes hat einen Abschnitt Spamfilter: wie viele eingehende Mails sauber, vertagt, als Spam markiert und abgelehnt wurden, wie oft jemand Spam selbst in den Junk-Ordner gelegt oder erwünschte Post herausgeholt hat, die Quoten Spam erkannt und Fehlalarme mit einer Empfehlung zur Schwelle und die Verteilung der Punkte mit den Schwellen des Nodes. Als Spam bewertete oder abgelehnte versendete Mail steht als Warnung darunter. Gezählt wird ab dem Update.
  • Die Liste Sendungen zeigt bei jeder Mail, die Rspamd bewertet hat, ihre Punkte.
  • Der Bereich Sicherheitslücken prüft auch die Bibliotheken, die eine Software mitbringt: jedes Jar von WildFly, vendor/ von phpMyAdmin und Roundcube, den Inhalt von Composer und WP-CLI und die Go-Module von Programmen aus einer fremden Paketquelle wie CrowdSec. Ein Befund heißt dann etwa io.undertow:undertow-core (wildfly-36.0.1.Final) und sagt, woher der Fix kommt. Ein WildFly 36.0.1 bringt zum Stand dieses Updates rund 90 behebbare Lücken mit, ein wp-cli 2.12.0 ein Composer 2.2.25 mit mehreren hohen.
  • Für Node.js zählt zusätzlich jede Sicherheitsfassung, die nodejs.org für den installierten Major führt — auch eine, die nur OpenSSL, undici oder npm erneuert und dafür keine CVE der Security-WG hat.
  • Unter Einstellungen › Sicherheitslücken stehen drei neue Quellen: Node.js Releases (nodejs.org), OSV Maven und OSV Go. Die Control Plane lädt dafür zusätzlich von nodejs.org; eine leere Adresse schaltet eine Quelle ab.
  • WildFly wird überwacht: fällt er aus oder antwortet er drei Minuten lang nicht, startet Kastra ihn neu — bei einem Hänger nach einem Thread-Dump ins Journal. Zu jedem Ausfall steht unter Laufzeiten › WildFly, wann er war und woran es lag, etwa Speichermangel, ein Absturz der JVM oder ein von außen gesendetes Signal. Nach fünf Neustarts in 30 Minuten gibt Kastra beim nächsten Ausfall auf, hält WildFly an und meldet die neue Alarmart WILDFLY_DOWN mit allen Ursachen. Starten im Panel setzt die Zählung zurück.
  • Eine Domain lässt sich im neuen Bereich Umzug in eine andere Subscription verschieben — zu einem anderen Kunden oder auf einen anderen Node. Sie zieht mit allen Subdomains, Datenbanken, Cronjobs, FTP-Zugängen, Mail und DNS um; eine Domain, die dieselbe Datenbank nutzt, zieht mit. Die Vorprüfung zeigt die ganze Gruppe mit dem Grund je Domain und prüft beim Wechsel des Nodes, ob dort läuft, was die Gruppe braucht (PHP-Fassung und Erweiterungen, Apache, Node.js, Podman, WAF, Objekt-Cache, Composer, MariaDB, Mail, FTP). Gespeicherte Pfade in Cronjobs, Compose-Dateien, Zusatzkonfiguration und PHP-Einstellungen werden umgeschrieben; Dateien der Anwendung, die das alte Verzeichnis nennen, meldet die Vorprüfung. Nur für Administratoren.
  • Zieht eine Domain, die auf WildFly zeigt, auf einen anderen Node, zieht WildFly mit — samt Anwendungen, Konfiguration und jeder anderen Domain, die ebenfalls darauf zeigt, auch aus fremden Subscriptions. Die Vorprüfung nennt das in einem eigenen Block und verlangt eine Bestätigung; auf dem Ziel darf noch kein WildFly laufen.
  • Ein gescheiterter Domain-Umzug auf einen anderen Node lässt sich zurücknehmen; Quelle freigeben entfernt danach die alten Daten. Beides steht auch im Bereich Umzug der Subscriptions.

Geändert

  • Ein im Panel angehaltener WildFly bleibt für Kastra angehalten; wer ihn auf dem Node mit systemctl stop anhält, findet ihn dagegen eine Minute später wieder laufend. Ein WildFly, der vor dem Update als angehalten gemeldet war, gilt danach als im Panel angehalten.
  • Archiv erstellen im Dateimanager packt im Hintergrund: über der Liste und in der Leiste unten rechts steht, wie viel schon gepackt ist, und der Dateimanager bleibt währenddessen bedienbar — auch ein Seitenwechsel hält das Packen nicht an. Ein großes Archiv bricht nicht mehr nach fünf Minuten ab; die Grenze liegt jetzt bei einer Stunde.
  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.
  • Der Upload-Fortschritt in PHP-Sitzungen (session.upload_progress.enabled) ist auf jeder Domain aus und lässt sich je Domain nicht wieder einschalten, auch nicht über eine .user.ini. Braucht eine Anwendung ihn, schaltet ihn ein Administrator unter Einstellungen › PHP ein. Anlass ist die für den 21. Oktober 2026 angekündigte PHP-Sicherheitslücke in diesem Handler.
  • opcache_get_status() und opcache_reset() sind für jede Domain gesperrt, und PHP prüft bei jedem Treffer im OPcache, ob der Benutzer die Datei lesen darf. Bisher sah jede Domain die Dateipfade aller anderen Domains derselben PHP-Fassung, und Cache leeren in einer Anwendung leerte ihn allen.
  • PHP-Werte einer Domain, die genau auf der bisherigen Vorgabe standen (etwa memory_limit = 256M), gelten nach dem Update als wie allgemein und folgen künftig der allgemeinen Konfiguration. Auf dem Node ändert sich dadurch nichts; eine Domain, die einen solchen Wert bewusst eingetragen hatte, trägt ihn bei Bedarf neu ein.
  • Freie php.ini-Zeilen je Domain nehmen nur Direktiven an, die eine Anwendung auch selbst über .user.ini oder ini_set() setzen dürfte. Eine Zeile wie sendmail_path hätte im FPM-Pool sonst einen beliebigen Befehl erlaubt.
  • Eingehende Mail mit 15 Punkten oder mehr wird abgelehnt — auch auf bestehenden Nodes. Bisher wurde nichts abgelehnt, auch eindeutiger Spam nicht. Verloren geht dabei nichts unbemerkt: der absendende Server bekommt den Fehler und benachrichtigt seinen Absender. Wer weiterhin nichts ablehnen will, leert im Bereich Mailserver das Feld Ablehnen ab.
  • Der lernende Teil des Spamfilters (Bayes) lernt von selbst nur noch eindeutigen Spam ab der Ablehnschwelle. Bisher lernte er alles ab 6 Punkten als Spam, auch Grenzfälle.
  • Die WildFly-Verwaltungskonsole öffnet sich auf Port 8447 desselben Namens wie das Panel, etwa https://panel.example:8447/console/index.html. Bisher lief sie unter der Adresse des Panels, und ein Skript der Konsole hätte das Panel mit der Sitzung des angemeldeten Administrators bedienen können. Die Firewall von Kastra gibt Port 8447 auf dem Node des Panels frei, unter denselben Regeln wie SSH und das Panel; eine Firewall oder ein eigener Proxy davor muss ihn ebenfalls durchlassen, sonst bleibt der Rahmen leer. Ein bestehender Panel-Vhost bekommt den neuen Server-Block beim Update, die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsolenport liegen.
  • Wer unter Einstellungen › Aktualisierung Repository, Versionsauskunft oder Signaturschlüssel ändert, gibt dazu den Code aus der App oder das aktuelle Passwort an; ein Konto nur mit Passkey braucht eine Anmeldung, die keine zehn Minuten zurückliegt. Beide Adressen müssen http:// oder https:// ohne Leerzeichen, Anmeldedaten, Abfrage oder Anker sein, der Schlüssel ein öffentlicher PGP-Schlüssel. Bisher genügte die Sitzung, und die Adresse ging ungeprüft in die apt-Quelle jedes Nodes.
  • Eine Anmeldung mit falschem Einmalcode, an einem gesperrten oder an einem deaktivierten Konto bekommt dieselbe Meldung wie eine mit falschem Passwort: Benutzername, Passwort oder Einmalcode ist falsch. Der Hinweis darunter nennt die Sperre nach fünf Fehlversuchen als möglichen Grund. Bisher verrieten eigene Meldungen, dass es das Konto gibt, in welchem Zustand es ist oder dass das Passwort stimmte.
  • Von einer Adresse lassen sich höchstens 60 Passkey-Anmeldungen je Minute beginnen; darüber kommt eine Meldung, die Anmeldung mit Passwort bleibt möglich. Die Mengengrenze der ACME-Delegation zählt IPv6-Adressen je /64 statt je Adresse.
  • Je Subscription sind höchstens vier Web-Terminals gleichzeitig offen, je Node 32, und je Node höchstens 64 Live-Protokolle. Darüber nennt das Panel die Grenze, statt ein weiteres zu öffnen.
  • Die privaten Schlüssel der Zertifikate liegen verschlüsselt in der Datenbank, sobald KASTRA_SECRET_KEY gesetzt ist; vorhandene werden beim ersten Start nach dem Update umgestellt.
  • /actuator ist außer /actuator/health nur noch für angemeldete Administratoren erreichbar. Steht die Verbundadresse KASTRA_CLUSTER_BASE_URL nicht auf https://, meldet die Control Plane das beim Start als Fehler.
  • Ein stillgelegter Node wird sofort getrennt. Bisher redete sein Agent weiter, bis er sich von selbst neu verband.
  • Bei einem unerwarteten Fehler sehen nur Administratoren die Ursache im Feld Detail; alle anderen bekommen die Correlation-ID, unter der sie im Protokoll steht.

Behoben

  • Der Bereich FTP einer Subscription oder Domain zeigt auf einem Node, auf dem FTP ausgeschaltet ist, keine Fehlerkarte „kein FTP-Dienst eingerichtet“ mehr; das Protokoll bleibt dort einfach leer.
  • Wird die JVM von WildFly hart beendet (kill -9), startet WildFly wieder. Bisher blieb er in diesem Fall aus, und im Serverprotokoll stand nichts dazu.
  • Das Lebensende von PHP, Node.js und der Distribution wird wieder geladen. Lag auf einem Node WildFly, scheiterte der ganze Abruf von endoflife.date, weil es dort kein Produkt WildFly gibt.
  • Unter Einstellungen › Sicherheitslücken steht eine Quelle, die kein Node braucht, als nicht benötigt statt noch nie abgerufen — etwa php.net, solange kein Node PHP aus sury hat. Die Seite Sicherheitslücken zeigte eine nie abgerufene Quelle bisher als aktuell.
  • Die Schwachstellendaten werden jede Nacht abgerufen. Nach einem Abruf von Hand am Nachmittag fiel bisher die folgende Nacht aus.
  • Alarme per Mail oder Webhook kommen wieder an. Bisher blieben sie oft unzugestellt und standen unter Einstellungen › Alarmierung dauerhaft als wartend — betroffen war jede Alarmart außer der Probemeldung, etwa Node nicht erreichbar oder Verwaltete Dateien verändert.
  • Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
  • Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.
  • Ein gekürzter Hinweis unter einem Eingabefeld zeigt beim Überfahren überall seinen vollen Text, etwa im Formular Tarif bearbeiten. Bisher tat er das nur auf wenigen Seiten.
  • Die Protokolle einer Domain füllen ihren Kasten sofort ganz. Bisher erschien bei einem langen Protokoll nur der obere Teil, der Rest erst beim Rollen.
  • Die Control Plane läuft auf Spring Boot 4.1 (Spring Framework 7, Tomcat 11, Hibernate 7). Damit sind 24 bekannte Lücken in ihren Bibliotheken geschlossen, darunter drei kritische in Tomcat und zwei in BouncyCastle; für die bisherige Spring-Linie gibt es keine freien Sicherheitsupdates mehr. Am Betrieb ändert sich nichts: Einstellungen, Umgebungsvariablen und die Antworten der Schnittstelle bleiben gleich.
  • Auf Ubuntu-Nodes werden die Pakete der Distribution gegen die Sicherheitsdaten von Canonical abgeglichen, und phpMyAdmin, Roundcube, Composer und WP-CLI gegen OSV. Bisher standen sie trotz geladener Daten als nicht erfasst da — es lagen „noch keine Schwachstellendaten vor“.
  • Die nginx-Zusatzkonfiguration einer Domain prüft jetzt jede Anweisung einer Zeile, nicht nur das erste Wort. Eine zweite Anweisung hinter einem Semikolon — etwa expires 1h; proxy_pass … oder ein über Klammern eingeschleuster location-Block mit alias /etc/ — wird mit der ganzen Zeile verworfen und steht unter den Hinweisen des Rollouts. access_log ist nur noch zum Abschalten (off) erlaubt. Bisher kam alles hinter dem ersten Wort ungeprüft durch.
  • Eine Weiterleitung, ein Catch-All-Ziel und der Name eines Versandzugangs nehmen nur noch eine Adresse der eigenen Maildomain an; ein erlaubter Absender ebenso. Bisher ließ sich darüber die Post einer fremden Maildomain auf demselben Node umleiten oder unter ihrem Namen versenden. Ein Versandzugang bekommt nur noch dann eine DKIM-Signatur, wenn die Domain seiner Anmeldung zur Domain im Absender passt.
  • Der Datenbankabzug einer Sicherung folgt im Heimatverzeichnis keinem symbolischen Verweis mehr. Bisher hätte ein Verweis ~/.kastra-sicherung auf ein Systemverzeichnis dieses beim nächsten Sicherungslauf übereignen oder überschreiben können.
  • Das Aufgabenprotokoll zeigt einem Kunden nicht mehr den Rollout-Diff des ganzen Nodes. Bisher stand im Feld der abgeschlossenen Aufgabe die geänderte Konfiguration aller Kunden des Nodes samt Mail-Passwortdatei und privaten Schlüsseln; Administratoren sehen ihn weiterhin.
  • Einen neuen Passkey hinzufügen, TOTP (neu) einrichten und ein API-Token anlegen verlangen jetzt denselben zweiten Nachweis wie das Widerrufen eines Passkeys — einen Code aus der Authenticator-App, das aktuelle Passwort oder eine frische Anmeldung. Bisher genügte dafür die Sitzung, und ein fremder Zugriff auf eine angemeldete Sitzung konnte sich damit dauerhaft einnisten.
  • Die Sperre nach fünf Fehlversuchen trifft nur noch die Passwortanmeldung. Ein Konto ohne Passwortanmeldung zählt keine Fehlversuche mehr, und eine bestehende Sperre hält Passkey und Wiederherstellungscode nicht länger auf. Bisher ließ sich ein Konto, das nur per Passkey erreichbar ist, mit fünf Anfragen aussperren.
  • Meldet sich ein Node mit einem anderen Zertifikat als dem, das bei seiner Anmeldung ausgestellt wurde, wird er abgewiesen. Damit verliert ein ausgetauschter oder abgegebener Rechner seinen Zugang, sobald sich an seiner Stelle ein neuer anmeldet.
  • Eine Subdomain einer fremden Domain lässt sich nicht mehr als eigene Hauptdomain anlegen. Bisher hätte ein Kunde so eine Domain samt eigener DNS-Zone und Zertifikat unter einem fremden Namen beanspruchen können.
  • Ein Virenscan und ein Rückspieltest halten keine Datenbankverbindung mehr über ihre ganze Laufzeit. Bisher konnten mehrere gleichzeitig gestartete Läufe die Control Plane ausbremsen.
  • Grundbausteine der Control Plane sind auf aktuelle, abgesicherte Fassungen gehoben: Spring Boot 3.5.16, gRPC 1.76 (darin Netty mit den Fixes gegen CVE-2025-24970 und CVE-2025-55163 — ein Absturz des gesamten Dienstes über ein präpariertes TLS- bzw. HTTP/2-Paket) und die JWT-Bibliothek 10.0.2 (CVE-2025-53864, ein Lahmlegen über ein verschachteltes Sitzungscookie).
  • READONLY-Konten können kein Web-Terminal mehr öffnen; das war Schreibzugriff und widersprach der Rolle.
  • Ein Kunde kann die Übernahme eines Postfachs nur noch von einem öffentlichen IMAP-Server auf Port 143 oder 993 anstoßen. Bisher ließ sich damit das interne Netz des Nodes abtasten.
  • Die Statusseite zeigt einem Kunden das Gesamtbild, aber nicht mehr die einzelnen Vorfälle anderer Kunden samt Node-Namen.
  • Ein Sicherungsziel lässt sich nur noch auswählen, wenn es auf dem Node der Subscription liegt. Bisher hätte ein Kunde das Ziel eines fremden Nodes anhängen können.
  • Ein SFTP-Unterverzeichnis, das über einen symbolischen Verweis aus dem Heimatverzeichnis führt, wird abgewiesen statt eingehängt.
  • Fällige Sicherungen und Suchläufe nach Schadsoftware laufen jetzt nebenläufig an und halten einander nicht mehr auf. Bisher konnte ein langer Lauf dazu führen, dass eine Regel, die kurz danach fällig war, in dieser Nacht gar nicht lief — ohne Meldung.
  • Die Aufbewahrungsfrist des Audit-Logs wirkt. Bisher verhinderte ein Schutz gegen Änderungen auch das Löschen alter Einträge, und das Audit-Log wuchs trotz eingestellter Frist unbegrenzt.
  • Mail lässt sich nicht mehr für eine gleichnamige Maildomain eines anderen Kunden ein- oder ausschalten.
  • Den Node einer Maildomain und einer DNS-Zone sowie Art und Herkunft einer Zone wählt nur noch ein Administrator; ein Kunde bekommt den vorgesehenen Node.
  • Ein Rückspieltest schreibt nicht mehr durch einen symbolischen Verweis im Heimatverzeichnis an eine fremde Stelle.
  • Drift-Berichte eines Nodes werden gedeckelt gespeichert (höchstens 1000 Zeilen je Bericht, Diff gekürzt), statt die Datenbank bei dauerhafter Abweichung zu füllen.
  • Ein Node schreibt nur noch in sein eigenes Update-Protokoll, nicht mehr in das eines anderen.
  • Gleichzeitige Anmeldeversuche können die Control Plane nicht mehr über den Speicher der Passwortprüfung lahmlegen (höchstens vier gleichzeitige Prüfungen, der Rest wartet kurz).
  • Eine Container-Angabe mit einem Bind-Mount in der langen Form außerhalb des Subscription-Verzeichnisses oder mit einem auf 0.0.0.0 veröffentlichten Port wird jetzt ebenfalls abgewiesen.
  • Der Panel-Vhost nennt die nginx-Fassung nicht mehr (server_tokens off), beschränkt die TLS-1.2-Verschlüsselung auf Verfahren mit Vorwärtsgeheimnis (ssl_ciphers), erlaubt per connect-src nur noch Verbindungen zum Panel selbst, sperrt vendor/ unter phpMyAdmin und nimmt unter /api/ höchstens 64 MB an, ohne sie vor der Anmeldung auf die Platte zu puffern. Ein bestehender Vhost bekommt das beim Update nachgetragen; die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-pruefbericht liegen.
  • Ein Einmalcode aus der Authenticator-App lässt sich auch bei zwei gleichzeitigen Anmeldungen nur einmal verwenden.
  • Verbindet sich ein Node neu, während seine alte Verbindung noch abgebaut wird, bleibt er verbunden. Bisher scheiterten seine laufenden Aufgaben dann mit Node nicht erreichbar, und er stand bis zum nächsten Herzschlag als getrennt da.
  • Alarme per Mail oder Webhook werden auf eigenen Fäden zugestellt. Ein langsamer Mailserver oder Webhook hält keinen Rollout und keine Datenbankverbindung mehr auf.
  • Ein Hostname, der kein gültiger Rechnername ist, wird beim Anmelden eines Nodes abgewiesen. Bisher ging er ungeprüft ins Zertifikat und in die Betreffzeile von Alarmmails.
  • Ein neues FTP-Passwort wird in einem Feld unter dem Zugang eingegeben. Bisher fragte ein Browser-Dialog danach, der es im Klartext zeigte.
  • Passwortfelder für Postfächer, Sicherungsziele, Alarmkanäle und Datenbanken füllt der Browser nicht mehr mit dem gespeicherten Panel-Passwort.
  • Wechselt man die Domain, verschwinden die einmaligen Zugangsdaten einer gerade angelegten ACME-Delegation. Bisher standen sie unter der nächsten Domain weiter da.
  • Auf einem Panel, das vor dem 31. August 2026 eingerichtet wurde, öffnet sich die WildFly-Verwaltungskonsole. Seinem Vhost fehlte die Regel für die Konsole, und kein Update trug sie nach; seit die Konsole auf Port 8447 liegt, meldete der Rahmen nur noch, der Server habe die Verbindung abgelehnt. Das Update trägt Regel und Port jetzt nach, die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsole liegen.
  • Auf einem Panel, das vor dem 1. September 2026 eingerichtet wurde, tragen die Oberfläche und ihre Dateien dieselben Sicherheitskopfzeilen wie auf einer neuen Anlage: Content-Security-Policy, X-Frame-Options, HSTS, nosniff und Referrer-Policy. Bisher kam das Panel dort ohne sie beim Browser an und ließ sich von jeder fremden Seite einrahmen. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-kopfzeilen liegen.
  • Auf einem Panel, das seit dem 1. September 2026 eingerichtet wurde, verbot die Sicherheitsregel des Panels phpMyAdmin das Skript, mit dem es seine Seiten in Gang setzt. phpMyAdmin bekommt jetzt eine eigene Regel, die das zulässt und es weiterhin vor fremden Rahmen schützt. Kartenkacheln für GIS-Daten lädt phpMyAdmin nicht von außen nach. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-phpmyadmin liegen.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

Rendert anders

  • nft — auf dem Node, der das Panel trägt, lässt die Verwaltungsregel neben 22 und 8443 auch Port 8447 zu (WildFly-Konsole), mit derselben Drosselung bzw. denselben Admin-Netzen.
  • wildfly-unit — /etc/systemd/system/kastra-wildfly.service trägt Restart=always statt Restart=on-failure, StartLimitIntervalSec=1800, StartLimitBurst=6 und WorkingDirectory=-/opt/wildfly/standalone. Der Agent zieht eine bestehende Unit nach seinem Start einmal nach; ein laufender WildFly wird dabei nicht neu gestartet, die Werte gelten ab dem nächsten Start.
  • fpm-confd — neu je PHP-Fassung: /etc/php/<fassung>/fpm/conf.d/99-kastra.ini mit opcache.validate_permission = 1, opcache.restrict_api und session.upload_progress.enabled = 0, dazu, was unter Einstellungen › PHP allgemein steht. Alle FPM-Fassungen werden dafür einmal neu geladen. Die Datei gehört ab jetzt Kastra; eine von Hand dort abgelegte Datei mit anderem Namen bleibt unberührt. Eine Notfalldatei wie 99-notfall.ini kann nach dem Update weg.
  • fpm-pool — jeder Pool trägt php_admin_flag[session.upload_progress.enabled] = off. Weitere neue Zeilen (Sitzungs-Cookies, OPcache, Zeitgrenze, Slowlog, allgemeine freie Zeilen) erscheinen nur, wenn jemand einen Wert einstellt.
  • apparmor-php — das Profil von PHP-FPM erlaubt das Schreiben unter /var/log/kastra/subscriptions/ und das Mitlesen eines langsamen Workers für das Protokoll langsamer Anfragen.
  • logrotate — php-slow.log wird mit php-error.log gedreht.
  • mail — auf jedem Node mit Mailserver: unter /etc/rspamd/local.d/ neu milter_headers.conf und settings.conf, geändert actions.conf und classifier-bayes.conf; neu das Verzeichnis /etc/dovecot/kastra-spam/ mit den Sieve-Skripten für Junk-Ordner und Lernen samt zwei Programmen, die rspamc aufrufen und jede Korrektur ins Mailprotokoll schreiben; die Dovecot-Konfiguration bindet sie über sieve_before und IMAPSieve ein. Rspamd und Dovecot werden dafür einmal neu geladen.

26.10.26.4

Eingriff am Node Test 96 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.
  • Unter Einstellungen › PHP gibt es eine allgemeine PHP-Konfiguration für alle Nodes und alle PHP-Fassungen: Grenzen, Fehler und Regionales, Sitzungen, OPcache, FPM-Prozesse und freie php.ini-Zeilen. Jede Domain erbt, was sie nicht selbst setzt; bei jedem Feld steht, wie viele Domains abweichen. Nur für Administratoren.
  • Der Bereich PHP einer Domain zeigt bei jedem Feld, ob der Wert eigen ist oder wie allgemein; ein leeres Feld oder Alles wie allgemein setzt ihn zurück. Neu dort: Sitzungs-Cookies (nur über HTTPS, HttpOnly, SameSite, nur bekannte Kennungen), das OPcache-Prüfintervall, freie php.ini-Zeilen und — für Administratoren — die FPM-Prozesse samt harter Zeitgrenze und Protokoll langsamer Anfragen.
  • Dauert eine PHP-Anfrage länger als eingestellt, steht ihr Aufrufstapel im neuen Protokoll Langsame PHP-Anfragen der Domain.
  • Die PHP-Fassung des Webmails lässt sich im Bereich Mailserver eines Nodes einstellen, unabhängig von den Maildomains. Automatisch bleibt die Voreinstellung und wählt wie bisher die neueste Fassung bis 8.3. Fehlen der gewählten Fassung Erweiterungen, die Roundcube braucht, bleibt das Webmail auf der automatischen Wahl, und der Rollout nennt die fehlenden Pakete. Eine Fassung, auf der das Webmail eingestellt ist, lässt sich unter Laufzeiten nicht entfernen.
  • Kastra prüft die Software auf jedem Node gegen bekannte Sicherheitslücken: jedes installierte Paket — auch PostgreSQL, OpenSSL, OpenSSH und den Kernel —, dazu Node.js, WildFly, phpMyAdmin, Roundcube, Composer und WP-CLI. Die Daten kommen nachts von Debian, Ubuntu, php.net, der Node.js Security-WG, OSV und endoflife.date; der Paketbestand verlässt dafür den Server nicht. Der neue Bereich Sicherheitslücken eines Nodes nennt je Technologie Paket, installierte Fassung, Fix-Fassung, CVE, betroffene Domains und den nächsten Schritt; eine Lücke, die nicht greift, lässt sich mit Begründung quittieren.
  • Die Seite Sicherheitslücken zeigt dasselbe über alle Nodes und beantwortet, ob eine bestimmte Technologie irgendwo betroffen ist. Eingestellt wird unter Einstellungen › Sicherheitslücken: Schwelle des Alarms, Karenz und die Adressen der Quellen (leer schaltet eine Quelle ab, etwa ohne Internet oder mit eigenem Spiegel). Nur für Administratoren.
  • Neue Alarmarten: SCHWACHSTELLE meldet behebbare Lücken ab Dringlichkeit hoch und — kritisch — jede Lücke, die laut CISA aktiv ausgenutzt wird; Fixe, die die automatischen Sicherheitsupdates selbst holen, erst nach 48 Stunden. LEBENSENDE meldet Software ohne Sicherheitsupdates (etwa PHP 8.1 oder Node.js 20), SCHWACHSTELLEN_DATEN eine Quelle, die länger als 72 Stunden nicht abgerufen werden konnte.
  • Im Bereich Sicherheitslücken eines Nodes spielt Aktualisieren den Fix eines Befunds ein, Alle behebbaren aktualisieren alle auf einmal — als Aufgabe mit Protokoll, danach verschwindet der Befund. Das ist auch der Weg für PHP aus sury: die automatischen Sicherheitsupdates holen es weiterhin nicht, weil sury neben PHP neuere Bibliotheken mitbringt. Was sich so nicht beheben lässt (phpMyAdmin, Roundcube, Composer, WP-CLI, ein Kernel, der nur neu starten muss), nennt den Grund.
  • Läuft auf dem Host der Control Plane kein Agent, zeigt die Seite Sicherheitslücken ihn als „nicht erfasst“: PostgreSQL und Java dort werden dann nicht geprüft.
  • Die Control Plane lädt dafür einmal am Tag Daten von security-tracker.debian.org, security-metadata.canonical.com, cisa.gov, php.net, raw.githubusercontent.com, osv-vulnerabilities.storage.googleapis.com und endoflife.date. Sie liegen unter /var/lib/kastra-control-plane/schwachstellen.
  • Erkannter Spam landet im Ordner Junk des Postfachs. Bisher bekam er nur den Kopf X-Spam: Yes und blieb im Posteingang, weil kaum ein Mailprogramm diesen Kopf auswertet. Unter Mail › Spamfilter lässt eine Maildomain ihn auf Wunsch im Posteingang.
  • Der Bereich Mailserver eines Nodes hat einen Abschnitt Spamfilter mit drei Schwellen in Punkten: Greylisting ab (Vorgabe 4), Spam ab (6) und Ablehnen ab (15). Nur für Administratoren.
  • Jede Maildomain führt unter Mail › Spamfilter zwei Absenderlisten: Nie Spam (weder vertagt noch abgelehnt noch im Junk-Ordner) und Immer Spam (immer im Junk-Ordner), je Zeile eine Adresse oder @domain.
  • Verschiebt jemand eine Mail in den Junk-Ordner, lernt der Spamfilter sie als Spam; holt er sie heraus, als erwünscht — in jedem Mailprogramm über IMAP und im Webmail.
  • Eingehende Mail trägt im Kopf X-Spamd-Result mit den Punkten und den Regeln, die angeschlagen haben, und X-Spam-Status. Daran lässt sich ablesen, warum eine Mail im Junk-Ordner liegt.
  • Die Mailstatistik einer Maildomain und eines Nodes hat einen Abschnitt Spamfilter: wie viele eingehende Mails sauber, vertagt, als Spam markiert und abgelehnt wurden, wie oft jemand Spam selbst in den Junk-Ordner gelegt oder erwünschte Post herausgeholt hat, die Quoten Spam erkannt und Fehlalarme mit einer Empfehlung zur Schwelle und die Verteilung der Punkte mit den Schwellen des Nodes. Als Spam bewertete oder abgelehnte versendete Mail steht als Warnung darunter. Gezählt wird ab dem Update.
  • Die Liste Sendungen zeigt bei jeder Mail, die Rspamd bewertet hat, ihre Punkte.
  • Der Bereich Sicherheitslücken prüft auch die Bibliotheken, die eine Software mitbringt: jedes Jar von WildFly, vendor/ von phpMyAdmin und Roundcube, den Inhalt von Composer und WP-CLI und die Go-Module von Programmen aus einer fremden Paketquelle wie CrowdSec. Ein Befund heißt dann etwa io.undertow:undertow-core (wildfly-36.0.1.Final) und sagt, woher der Fix kommt. Ein WildFly 36.0.1 bringt zum Stand dieses Updates rund 90 behebbare Lücken mit, ein wp-cli 2.12.0 ein Composer 2.2.25 mit mehreren hohen.
  • Für Node.js zählt zusätzlich jede Sicherheitsfassung, die nodejs.org für den installierten Major führt — auch eine, die nur OpenSSL, undici oder npm erneuert und dafür keine CVE der Security-WG hat.
  • Unter Einstellungen › Sicherheitslücken stehen drei neue Quellen: Node.js Releases (nodejs.org), OSV Maven und OSV Go. Die Control Plane lädt dafür zusätzlich von nodejs.org; eine leere Adresse schaltet eine Quelle ab.
  • WildFly wird überwacht: fällt er aus oder antwortet er drei Minuten lang nicht, startet Kastra ihn neu — bei einem Hänger nach einem Thread-Dump ins Journal. Zu jedem Ausfall steht unter Laufzeiten › WildFly, wann er war und woran es lag, etwa Speichermangel, ein Absturz der JVM oder ein von außen gesendetes Signal. Nach fünf Neustarts in 30 Minuten gibt Kastra beim nächsten Ausfall auf, hält WildFly an und meldet die neue Alarmart WILDFLY_DOWN mit allen Ursachen. Starten im Panel setzt die Zählung zurück.

Geändert

  • Ein im Panel angehaltener WildFly bleibt für Kastra angehalten; wer ihn auf dem Node mit systemctl stop anhält, findet ihn dagegen eine Minute später wieder laufend. Ein WildFly, der vor dem Update als angehalten gemeldet war, gilt danach als im Panel angehalten.
  • Archiv erstellen im Dateimanager packt im Hintergrund: über der Liste und in der Leiste unten rechts steht, wie viel schon gepackt ist, und der Dateimanager bleibt währenddessen bedienbar — auch ein Seitenwechsel hält das Packen nicht an. Ein großes Archiv bricht nicht mehr nach fünf Minuten ab; die Grenze liegt jetzt bei einer Stunde.
  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.
  • Der Upload-Fortschritt in PHP-Sitzungen (session.upload_progress.enabled) ist auf jeder Domain aus und lässt sich je Domain nicht wieder einschalten, auch nicht über eine .user.ini. Braucht eine Anwendung ihn, schaltet ihn ein Administrator unter Einstellungen › PHP ein. Anlass ist die für den 21. Oktober 2026 angekündigte PHP-Sicherheitslücke in diesem Handler.
  • opcache_get_status() und opcache_reset() sind für jede Domain gesperrt, und PHP prüft bei jedem Treffer im OPcache, ob der Benutzer die Datei lesen darf. Bisher sah jede Domain die Dateipfade aller anderen Domains derselben PHP-Fassung, und Cache leeren in einer Anwendung leerte ihn allen.
  • PHP-Werte einer Domain, die genau auf der bisherigen Vorgabe standen (etwa memory_limit = 256M), gelten nach dem Update als wie allgemein und folgen künftig der allgemeinen Konfiguration. Auf dem Node ändert sich dadurch nichts; eine Domain, die einen solchen Wert bewusst eingetragen hatte, trägt ihn bei Bedarf neu ein.
  • Freie php.ini-Zeilen je Domain nehmen nur Direktiven an, die eine Anwendung auch selbst über .user.ini oder ini_set() setzen dürfte. Eine Zeile wie sendmail_path hätte im FPM-Pool sonst einen beliebigen Befehl erlaubt.
  • Eingehende Mail mit 15 Punkten oder mehr wird abgelehnt — auch auf bestehenden Nodes. Bisher wurde nichts abgelehnt, auch eindeutiger Spam nicht. Verloren geht dabei nichts unbemerkt: der absendende Server bekommt den Fehler und benachrichtigt seinen Absender. Wer weiterhin nichts ablehnen will, leert im Bereich Mailserver das Feld Ablehnen ab.
  • Der lernende Teil des Spamfilters (Bayes) lernt von selbst nur noch eindeutigen Spam ab der Ablehnschwelle. Bisher lernte er alles ab 6 Punkten als Spam, auch Grenzfälle.
  • Die WildFly-Verwaltungskonsole öffnet sich auf Port 8447 desselben Namens wie das Panel, etwa https://panel.example:8447/console/index.html. Bisher lief sie unter der Adresse des Panels, und ein Skript der Konsole hätte das Panel mit der Sitzung des angemeldeten Administrators bedienen können. Die Firewall von Kastra gibt Port 8447 auf dem Node des Panels frei, unter denselben Regeln wie SSH und das Panel; eine Firewall oder ein eigener Proxy davor muss ihn ebenfalls durchlassen, sonst bleibt der Rahmen leer. Ein bestehender Panel-Vhost bekommt den neuen Server-Block beim Update, die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsolenport liegen.
  • Wer unter Einstellungen › Aktualisierung Repository, Versionsauskunft oder Signaturschlüssel ändert, gibt dazu den Code aus der App oder das aktuelle Passwort an; ein Konto nur mit Passkey braucht eine Anmeldung, die keine zehn Minuten zurückliegt. Beide Adressen müssen http:// oder https:// ohne Leerzeichen, Anmeldedaten, Abfrage oder Anker sein, der Schlüssel ein öffentlicher PGP-Schlüssel. Bisher genügte die Sitzung, und die Adresse ging ungeprüft in die apt-Quelle jedes Nodes.
  • Eine Anmeldung mit falschem Einmalcode, an einem gesperrten oder an einem deaktivierten Konto bekommt dieselbe Meldung wie eine mit falschem Passwort: Benutzername, Passwort oder Einmalcode ist falsch. Der Hinweis darunter nennt die Sperre nach fünf Fehlversuchen als möglichen Grund. Bisher verrieten eigene Meldungen, dass es das Konto gibt, in welchem Zustand es ist oder dass das Passwort stimmte.
  • Von einer Adresse lassen sich höchstens 60 Passkey-Anmeldungen je Minute beginnen; darüber kommt eine Meldung, die Anmeldung mit Passwort bleibt möglich. Die Mengengrenze der ACME-Delegation zählt IPv6-Adressen je /64 statt je Adresse.
  • Je Subscription sind höchstens vier Web-Terminals gleichzeitig offen, je Node 32, und je Node höchstens 64 Live-Protokolle. Darüber nennt das Panel die Grenze, statt ein weiteres zu öffnen.
  • Die privaten Schlüssel der Zertifikate liegen verschlüsselt in der Datenbank, sobald KASTRA_SECRET_KEY gesetzt ist; vorhandene werden beim ersten Start nach dem Update umgestellt.
  • /actuator ist außer /actuator/health nur noch für angemeldete Administratoren erreichbar. Steht die Verbundadresse KASTRA_CLUSTER_BASE_URL nicht auf https://, meldet die Control Plane das beim Start als Fehler.
  • Ein stillgelegter Node wird sofort getrennt. Bisher redete sein Agent weiter, bis er sich von selbst neu verband.
  • Bei einem unerwarteten Fehler sehen nur Administratoren die Ursache im Feld Detail; alle anderen bekommen die Correlation-ID, unter der sie im Protokoll steht.

Behoben

  • Wird die JVM von WildFly hart beendet (kill -9), startet WildFly wieder. Bisher blieb er in diesem Fall aus, und im Serverprotokoll stand nichts dazu.
  • Das Lebensende von PHP, Node.js und der Distribution wird wieder geladen. Lag auf einem Node WildFly, scheiterte der ganze Abruf von endoflife.date, weil es dort kein Produkt WildFly gibt.
  • Unter Einstellungen › Sicherheitslücken steht eine Quelle, die kein Node braucht, als nicht benötigt statt noch nie abgerufen — etwa php.net, solange kein Node PHP aus sury hat. Die Seite Sicherheitslücken zeigte eine nie abgerufene Quelle bisher als aktuell.
  • Die Schwachstellendaten werden jede Nacht abgerufen. Nach einem Abruf von Hand am Nachmittag fiel bisher die folgende Nacht aus.
  • Alarme per Mail oder Webhook kommen wieder an. Bisher blieben sie oft unzugestellt und standen unter Einstellungen › Alarmierung dauerhaft als wartend — betroffen war jede Alarmart außer der Probemeldung, etwa Node nicht erreichbar oder Verwaltete Dateien verändert.
  • Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
  • Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.
  • Ein gekürzter Hinweis unter einem Eingabefeld zeigt beim Überfahren überall seinen vollen Text, etwa im Formular Tarif bearbeiten. Bisher tat er das nur auf wenigen Seiten.
  • Die Protokolle einer Domain füllen ihren Kasten sofort ganz. Bisher erschien bei einem langen Protokoll nur der obere Teil, der Rest erst beim Rollen.
  • Die Control Plane läuft auf Spring Boot 4.1 (Spring Framework 7, Tomcat 11, Hibernate 7). Damit sind 24 bekannte Lücken in ihren Bibliotheken geschlossen, darunter drei kritische in Tomcat und zwei in BouncyCastle; für die bisherige Spring-Linie gibt es keine freien Sicherheitsupdates mehr. Am Betrieb ändert sich nichts: Einstellungen, Umgebungsvariablen und die Antworten der Schnittstelle bleiben gleich.
  • Auf Ubuntu-Nodes werden die Pakete der Distribution gegen die Sicherheitsdaten von Canonical abgeglichen, und phpMyAdmin, Roundcube, Composer und WP-CLI gegen OSV. Bisher standen sie trotz geladener Daten als nicht erfasst da — es lagen „noch keine Schwachstellendaten vor“.
  • Die nginx-Zusatzkonfiguration einer Domain prüft jetzt jede Anweisung einer Zeile, nicht nur das erste Wort. Eine zweite Anweisung hinter einem Semikolon — etwa expires 1h; proxy_pass … oder ein über Klammern eingeschleuster location-Block mit alias /etc/ — wird mit der ganzen Zeile verworfen und steht unter den Hinweisen des Rollouts. access_log ist nur noch zum Abschalten (off) erlaubt. Bisher kam alles hinter dem ersten Wort ungeprüft durch.
  • Eine Weiterleitung, ein Catch-All-Ziel und der Name eines Versandzugangs nehmen nur noch eine Adresse der eigenen Maildomain an; ein erlaubter Absender ebenso. Bisher ließ sich darüber die Post einer fremden Maildomain auf demselben Node umleiten oder unter ihrem Namen versenden. Ein Versandzugang bekommt nur noch dann eine DKIM-Signatur, wenn die Domain seiner Anmeldung zur Domain im Absender passt.
  • Der Datenbankabzug einer Sicherung folgt im Heimatverzeichnis keinem symbolischen Verweis mehr. Bisher hätte ein Verweis ~/.kastra-sicherung auf ein Systemverzeichnis dieses beim nächsten Sicherungslauf übereignen oder überschreiben können.
  • Das Aufgabenprotokoll zeigt einem Kunden nicht mehr den Rollout-Diff des ganzen Nodes. Bisher stand im Feld der abgeschlossenen Aufgabe die geänderte Konfiguration aller Kunden des Nodes samt Mail-Passwortdatei und privaten Schlüsseln; Administratoren sehen ihn weiterhin.
  • Einen neuen Passkey hinzufügen, TOTP (neu) einrichten und ein API-Token anlegen verlangen jetzt denselben zweiten Nachweis wie das Widerrufen eines Passkeys — einen Code aus der Authenticator-App, das aktuelle Passwort oder eine frische Anmeldung. Bisher genügte dafür die Sitzung, und ein fremder Zugriff auf eine angemeldete Sitzung konnte sich damit dauerhaft einnisten.
  • Die Sperre nach fünf Fehlversuchen trifft nur noch die Passwortanmeldung. Ein Konto ohne Passwortanmeldung zählt keine Fehlversuche mehr, und eine bestehende Sperre hält Passkey und Wiederherstellungscode nicht länger auf. Bisher ließ sich ein Konto, das nur per Passkey erreichbar ist, mit fünf Anfragen aussperren.
  • Meldet sich ein Node mit einem anderen Zertifikat als dem, das bei seiner Anmeldung ausgestellt wurde, wird er abgewiesen. Damit verliert ein ausgetauschter oder abgegebener Rechner seinen Zugang, sobald sich an seiner Stelle ein neuer anmeldet.
  • Eine Subdomain einer fremden Domain lässt sich nicht mehr als eigene Hauptdomain anlegen. Bisher hätte ein Kunde so eine Domain samt eigener DNS-Zone und Zertifikat unter einem fremden Namen beanspruchen können.
  • Ein Virenscan und ein Rückspieltest halten keine Datenbankverbindung mehr über ihre ganze Laufzeit. Bisher konnten mehrere gleichzeitig gestartete Läufe die Control Plane ausbremsen.
  • Grundbausteine der Control Plane sind auf aktuelle, abgesicherte Fassungen gehoben: Spring Boot 3.5.16, gRPC 1.76 (darin Netty mit den Fixes gegen CVE-2025-24970 und CVE-2025-55163 — ein Absturz des gesamten Dienstes über ein präpariertes TLS- bzw. HTTP/2-Paket) und die JWT-Bibliothek 10.0.2 (CVE-2025-53864, ein Lahmlegen über ein verschachteltes Sitzungscookie).
  • READONLY-Konten können kein Web-Terminal mehr öffnen; das war Schreibzugriff und widersprach der Rolle.
  • Ein Kunde kann die Übernahme eines Postfachs nur noch von einem öffentlichen IMAP-Server auf Port 143 oder 993 anstoßen. Bisher ließ sich damit das interne Netz des Nodes abtasten.
  • Die Statusseite zeigt einem Kunden das Gesamtbild, aber nicht mehr die einzelnen Vorfälle anderer Kunden samt Node-Namen.
  • Ein Sicherungsziel lässt sich nur noch auswählen, wenn es auf dem Node der Subscription liegt. Bisher hätte ein Kunde das Ziel eines fremden Nodes anhängen können.
  • Ein SFTP-Unterverzeichnis, das über einen symbolischen Verweis aus dem Heimatverzeichnis führt, wird abgewiesen statt eingehängt.
  • Fällige Sicherungen und Suchläufe nach Schadsoftware laufen jetzt nebenläufig an und halten einander nicht mehr auf. Bisher konnte ein langer Lauf dazu führen, dass eine Regel, die kurz danach fällig war, in dieser Nacht gar nicht lief — ohne Meldung.
  • Die Aufbewahrungsfrist des Audit-Logs wirkt. Bisher verhinderte ein Schutz gegen Änderungen auch das Löschen alter Einträge, und das Audit-Log wuchs trotz eingestellter Frist unbegrenzt.
  • Mail lässt sich nicht mehr für eine gleichnamige Maildomain eines anderen Kunden ein- oder ausschalten.
  • Den Node einer Maildomain und einer DNS-Zone sowie Art und Herkunft einer Zone wählt nur noch ein Administrator; ein Kunde bekommt den vorgesehenen Node.
  • Ein Rückspieltest schreibt nicht mehr durch einen symbolischen Verweis im Heimatverzeichnis an eine fremde Stelle.
  • Drift-Berichte eines Nodes werden gedeckelt gespeichert (höchstens 1000 Zeilen je Bericht, Diff gekürzt), statt die Datenbank bei dauerhafter Abweichung zu füllen.
  • Ein Node schreibt nur noch in sein eigenes Update-Protokoll, nicht mehr in das eines anderen.
  • Gleichzeitige Anmeldeversuche können die Control Plane nicht mehr über den Speicher der Passwortprüfung lahmlegen (höchstens vier gleichzeitige Prüfungen, der Rest wartet kurz).
  • Eine Container-Angabe mit einem Bind-Mount in der langen Form außerhalb des Subscription-Verzeichnisses oder mit einem auf 0.0.0.0 veröffentlichten Port wird jetzt ebenfalls abgewiesen.
  • Der Panel-Vhost nennt die nginx-Fassung nicht mehr (server_tokens off), beschränkt die TLS-1.2-Verschlüsselung auf Verfahren mit Vorwärtsgeheimnis (ssl_ciphers), erlaubt per connect-src nur noch Verbindungen zum Panel selbst, sperrt vendor/ unter phpMyAdmin und nimmt unter /api/ höchstens 64 MB an, ohne sie vor der Anmeldung auf die Platte zu puffern. Ein bestehender Vhost bekommt das beim Update nachgetragen; die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-pruefbericht liegen.
  • Ein Einmalcode aus der Authenticator-App lässt sich auch bei zwei gleichzeitigen Anmeldungen nur einmal verwenden.
  • Verbindet sich ein Node neu, während seine alte Verbindung noch abgebaut wird, bleibt er verbunden. Bisher scheiterten seine laufenden Aufgaben dann mit Node nicht erreichbar, und er stand bis zum nächsten Herzschlag als getrennt da.
  • Alarme per Mail oder Webhook werden auf eigenen Fäden zugestellt. Ein langsamer Mailserver oder Webhook hält keinen Rollout und keine Datenbankverbindung mehr auf.
  • Ein Hostname, der kein gültiger Rechnername ist, wird beim Anmelden eines Nodes abgewiesen. Bisher ging er ungeprüft ins Zertifikat und in die Betreffzeile von Alarmmails.
  • Ein neues FTP-Passwort wird in einem Feld unter dem Zugang eingegeben. Bisher fragte ein Browser-Dialog danach, der es im Klartext zeigte.
  • Passwortfelder für Postfächer, Sicherungsziele, Alarmkanäle und Datenbanken füllt der Browser nicht mehr mit dem gespeicherten Panel-Passwort.
  • Wechselt man die Domain, verschwinden die einmaligen Zugangsdaten einer gerade angelegten ACME-Delegation. Bisher standen sie unter der nächsten Domain weiter da.
  • Auf einem Panel, das vor dem 31. August 2026 eingerichtet wurde, öffnet sich die WildFly-Verwaltungskonsole. Seinem Vhost fehlte die Regel für die Konsole, und kein Update trug sie nach; seit die Konsole auf Port 8447 liegt, meldete der Rahmen nur noch, der Server habe die Verbindung abgelehnt. Das Update trägt Regel und Port jetzt nach, die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsole liegen.
  • Auf einem Panel, das vor dem 1. September 2026 eingerichtet wurde, tragen die Oberfläche und ihre Dateien dieselben Sicherheitskopfzeilen wie auf einer neuen Anlage: Content-Security-Policy, X-Frame-Options, HSTS, nosniff und Referrer-Policy. Bisher kam das Panel dort ohne sie beim Browser an und ließ sich von jeder fremden Seite einrahmen. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-kopfzeilen liegen.
  • Auf einem Panel, das seit dem 1. September 2026 eingerichtet wurde, verbot die Sicherheitsregel des Panels phpMyAdmin das Skript, mit dem es seine Seiten in Gang setzt. phpMyAdmin bekommt jetzt eine eigene Regel, die das zulässt und es weiterhin vor fremden Rahmen schützt. Kartenkacheln für GIS-Daten lädt phpMyAdmin nicht von außen nach. Die Fassung von vorher bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-phpmyadmin liegen.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

Rendert anders

  • nft — auf dem Node, der das Panel trägt, lässt die Verwaltungsregel neben 22 und 8443 auch Port 8447 zu (WildFly-Konsole), mit derselben Drosselung bzw. denselben Admin-Netzen.
  • wildfly-unit — /etc/systemd/system/kastra-wildfly.service trägt Restart=always statt Restart=on-failure, StartLimitIntervalSec=1800, StartLimitBurst=6 und WorkingDirectory=-/opt/wildfly/standalone. Der Agent zieht eine bestehende Unit nach seinem Start einmal nach; ein laufender WildFly wird dabei nicht neu gestartet, die Werte gelten ab dem nächsten Start.
  • fpm-confd — neu je PHP-Fassung: /etc/php/<fassung>/fpm/conf.d/99-kastra.ini mit opcache.validate_permission = 1, opcache.restrict_api und session.upload_progress.enabled = 0, dazu, was unter Einstellungen › PHP allgemein steht. Alle FPM-Fassungen werden dafür einmal neu geladen. Die Datei gehört ab jetzt Kastra; eine von Hand dort abgelegte Datei mit anderem Namen bleibt unberührt. Eine Notfalldatei wie 99-notfall.ini kann nach dem Update weg.
  • fpm-pool — jeder Pool trägt php_admin_flag[session.upload_progress.enabled] = off. Weitere neue Zeilen (Sitzungs-Cookies, OPcache, Zeitgrenze, Slowlog, allgemeine freie Zeilen) erscheinen nur, wenn jemand einen Wert einstellt.
  • apparmor-php — das Profil von PHP-FPM erlaubt das Schreiben unter /var/log/kastra/subscriptions/ und das Mitlesen eines langsamen Workers für das Protokoll langsamer Anfragen.
  • logrotate — php-slow.log wird mit php-error.log gedreht.
  • mail — auf jedem Node mit Mailserver: unter /etc/rspamd/local.d/ neu milter_headers.conf und settings.conf, geändert actions.conf und classifier-bayes.conf; neu das Verzeichnis /etc/dovecot/kastra-spam/ mit den Sieve-Skripten für Junk-Ordner und Lernen samt zwei Programmen, die rspamc aufrufen und jede Korrektur ins Mailprotokoll schreiben; die Dovecot-Konfiguration bindet sie über sieve_before und IMAPSieve ein. Rspamd und Dovecot werden dafür einmal neu geladen.

26.10.24.18

Eingriff am Node Test 88 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.
  • Unter Einstellungen › PHP gibt es eine allgemeine PHP-Konfiguration für alle Nodes und alle PHP-Fassungen: Grenzen, Fehler und Regionales, Sitzungen, OPcache, FPM-Prozesse und freie php.ini-Zeilen. Jede Domain erbt, was sie nicht selbst setzt; bei jedem Feld steht, wie viele Domains abweichen. Nur für Administratoren.
  • Der Bereich PHP einer Domain zeigt bei jedem Feld, ob der Wert eigen ist oder wie allgemein; ein leeres Feld oder Alles wie allgemein setzt ihn zurück. Neu dort: Sitzungs-Cookies (nur über HTTPS, HttpOnly, SameSite, nur bekannte Kennungen), das OPcache-Prüfintervall, freie php.ini-Zeilen und — für Administratoren — die FPM-Prozesse samt harter Zeitgrenze und Protokoll langsamer Anfragen.
  • Dauert eine PHP-Anfrage länger als eingestellt, steht ihr Aufrufstapel im neuen Protokoll Langsame PHP-Anfragen der Domain.
  • Die PHP-Fassung des Webmails lässt sich im Bereich Mailserver eines Nodes einstellen, unabhängig von den Maildomains. Automatisch bleibt die Voreinstellung und wählt wie bisher die neueste Fassung bis 8.3. Fehlen der gewählten Fassung Erweiterungen, die Roundcube braucht, bleibt das Webmail auf der automatischen Wahl, und der Rollout nennt die fehlenden Pakete. Eine Fassung, auf der das Webmail eingestellt ist, lässt sich unter Laufzeiten nicht entfernen.
  • Kastra prüft die Software auf jedem Node gegen bekannte Sicherheitslücken: jedes installierte Paket — auch PostgreSQL, OpenSSL, OpenSSH und den Kernel —, dazu Node.js, WildFly, phpMyAdmin, Roundcube, Composer und WP-CLI. Die Daten kommen nachts von Debian, Ubuntu, php.net, der Node.js Security-WG, OSV und endoflife.date; der Paketbestand verlässt dafür den Server nicht. Der neue Bereich Sicherheitslücken eines Nodes nennt je Technologie Paket, installierte Fassung, Fix-Fassung, CVE, betroffene Domains und den nächsten Schritt; eine Lücke, die nicht greift, lässt sich mit Begründung quittieren.
  • Die Seite Sicherheitslücken zeigt dasselbe über alle Nodes und beantwortet, ob eine bestimmte Technologie irgendwo betroffen ist. Eingestellt wird unter Einstellungen › Sicherheitslücken: Schwelle des Alarms, Karenz und die Adressen der Quellen (leer schaltet eine Quelle ab, etwa ohne Internet oder mit eigenem Spiegel). Nur für Administratoren.
  • Neue Alarmarten: SCHWACHSTELLE meldet behebbare Lücken ab Dringlichkeit hoch und — kritisch — jede Lücke, die laut CISA aktiv ausgenutzt wird; Fixe, die die automatischen Sicherheitsupdates selbst holen, erst nach 48 Stunden. LEBENSENDE meldet Software ohne Sicherheitsupdates (etwa PHP 8.1 oder Node.js 20), SCHWACHSTELLEN_DATEN eine Quelle, die länger als 72 Stunden nicht abgerufen werden konnte.
  • Im Bereich Sicherheitslücken eines Nodes spielt Aktualisieren den Fix eines Befunds ein, Alle behebbaren aktualisieren alle auf einmal — als Aufgabe mit Protokoll, danach verschwindet der Befund. Das ist auch der Weg für PHP aus sury: die automatischen Sicherheitsupdates holen es weiterhin nicht, weil sury neben PHP neuere Bibliotheken mitbringt. Was sich so nicht beheben lässt (phpMyAdmin, Roundcube, Composer, WP-CLI, ein Kernel, der nur neu starten muss), nennt den Grund.
  • Läuft auf dem Host der Control Plane kein Agent, zeigt die Seite Sicherheitslücken ihn als „nicht erfasst“: PostgreSQL und Java dort werden dann nicht geprüft.
  • Die Control Plane lädt dafür einmal am Tag Daten von security-tracker.debian.org, security-metadata.canonical.com, cisa.gov, php.net, raw.githubusercontent.com, osv-vulnerabilities.storage.googleapis.com und endoflife.date. Sie liegen unter /var/lib/kastra-control-plane/schwachstellen.
  • Erkannter Spam landet im Ordner Junk des Postfachs. Bisher bekam er nur den Kopf X-Spam: Yes und blieb im Posteingang, weil kaum ein Mailprogramm diesen Kopf auswertet. Unter Mail › Spamfilter lässt eine Maildomain ihn auf Wunsch im Posteingang.
  • Der Bereich Mailserver eines Nodes hat einen Abschnitt Spamfilter mit drei Schwellen in Punkten: Greylisting ab (Vorgabe 4), Spam ab (6) und Ablehnen ab (15). Nur für Administratoren.
  • Jede Maildomain führt unter Mail › Spamfilter zwei Absenderlisten: Nie Spam (weder vertagt noch abgelehnt noch im Junk-Ordner) und Immer Spam (immer im Junk-Ordner), je Zeile eine Adresse oder @domain.
  • Verschiebt jemand eine Mail in den Junk-Ordner, lernt der Spamfilter sie als Spam; holt er sie heraus, als erwünscht — in jedem Mailprogramm über IMAP und im Webmail.
  • Eingehende Mail trägt im Kopf X-Spamd-Result mit den Punkten und den Regeln, die angeschlagen haben, und X-Spam-Status. Daran lässt sich ablesen, warum eine Mail im Junk-Ordner liegt.
  • Die Mailstatistik einer Maildomain und eines Nodes hat einen Abschnitt Spamfilter: wie viele eingehende Mails sauber, vertagt, als Spam markiert und abgelehnt wurden, wie oft jemand Spam selbst in den Junk-Ordner gelegt oder erwünschte Post herausgeholt hat, die Quoten Spam erkannt und Fehlalarme mit einer Empfehlung zur Schwelle und die Verteilung der Punkte mit den Schwellen des Nodes. Als Spam bewertete oder abgelehnte versendete Mail steht als Warnung darunter. Gezählt wird ab dem Update.
  • Die Liste Sendungen zeigt bei jeder Mail, die Rspamd bewertet hat, ihre Punkte.
  • WildFly wird überwacht: fällt er aus oder antwortet er drei Minuten lang nicht, startet Kastra ihn neu — bei einem Hänger nach einem Thread-Dump ins Journal. Zu jedem Ausfall steht unter Laufzeiten › WildFly, wann er war und woran es lag, etwa Speichermangel, ein Absturz der JVM oder ein von außen gesendetes Signal. Nach fünf Neustarts in 30 Minuten gibt Kastra beim nächsten Ausfall auf, hält WildFly an und meldet die neue Alarmart WILDFLY_DOWN mit allen Ursachen. Starten im Panel setzt die Zählung zurück.

Geändert

  • Ein im Panel angehaltener WildFly bleibt für Kastra angehalten; wer ihn auf dem Node mit systemctl stop anhält, findet ihn dagegen eine Minute später wieder laufend. Ein WildFly, der vor dem Update als angehalten gemeldet war, gilt danach als im Panel angehalten.
  • Archiv erstellen im Dateimanager packt im Hintergrund: über der Liste und in der Leiste unten rechts steht, wie viel schon gepackt ist, und der Dateimanager bleibt währenddessen bedienbar — auch ein Seitenwechsel hält das Packen nicht an. Ein großes Archiv bricht nicht mehr nach fünf Minuten ab; die Grenze liegt jetzt bei einer Stunde.
  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.
  • Der Upload-Fortschritt in PHP-Sitzungen (session.upload_progress.enabled) ist auf jeder Domain aus und lässt sich je Domain nicht wieder einschalten, auch nicht über eine .user.ini. Braucht eine Anwendung ihn, schaltet ihn ein Administrator unter Einstellungen › PHP ein. Anlass ist die für den 21. Oktober 2026 angekündigte PHP-Sicherheitslücke in diesem Handler.
  • opcache_get_status() und opcache_reset() sind für jede Domain gesperrt, und PHP prüft bei jedem Treffer im OPcache, ob der Benutzer die Datei lesen darf. Bisher sah jede Domain die Dateipfade aller anderen Domains derselben PHP-Fassung, und Cache leeren in einer Anwendung leerte ihn allen.
  • PHP-Werte einer Domain, die genau auf der bisherigen Vorgabe standen (etwa memory_limit = 256M), gelten nach dem Update als wie allgemein und folgen künftig der allgemeinen Konfiguration. Auf dem Node ändert sich dadurch nichts; eine Domain, die einen solchen Wert bewusst eingetragen hatte, trägt ihn bei Bedarf neu ein.
  • Freie php.ini-Zeilen je Domain nehmen nur Direktiven an, die eine Anwendung auch selbst über .user.ini oder ini_set() setzen dürfte. Eine Zeile wie sendmail_path hätte im FPM-Pool sonst einen beliebigen Befehl erlaubt.
  • Eingehende Mail mit 15 Punkten oder mehr wird abgelehnt — auch auf bestehenden Nodes. Bisher wurde nichts abgelehnt, auch eindeutiger Spam nicht. Verloren geht dabei nichts unbemerkt: der absendende Server bekommt den Fehler und benachrichtigt seinen Absender. Wer weiterhin nichts ablehnen will, leert im Bereich Mailserver das Feld Ablehnen ab.
  • Der lernende Teil des Spamfilters (Bayes) lernt von selbst nur noch eindeutigen Spam ab der Ablehnschwelle. Bisher lernte er alles ab 6 Punkten als Spam, auch Grenzfälle.
  • Die WildFly-Verwaltungskonsole öffnet sich auf Port 8447 desselben Namens wie das Panel, etwa https://panel.example:8447/console/index.html. Bisher lief sie unter der Adresse des Panels, und ein Skript der Konsole hätte das Panel mit der Sitzung des angemeldeten Administrators bedienen können. Die Firewall von Kastra gibt Port 8447 auf dem Node des Panels frei, unter denselben Regeln wie SSH und das Panel; eine Firewall oder ein eigener Proxy davor muss ihn ebenfalls durchlassen, sonst bleibt der Rahmen leer. Ein bestehender Panel-Vhost bekommt den neuen Server-Block beim Update, die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-konsole liegen.
  • Wer unter Einstellungen › Aktualisierung Repository, Versionsauskunft oder Signaturschlüssel ändert, gibt dazu den Code aus der App oder das aktuelle Passwort an; ein Konto nur mit Passkey braucht eine Anmeldung, die keine zehn Minuten zurückliegt. Beide Adressen müssen http:// oder https:// ohne Leerzeichen, Anmeldedaten, Abfrage oder Anker sein, der Schlüssel ein öffentlicher PGP-Schlüssel. Bisher genügte die Sitzung, und die Adresse ging ungeprüft in die apt-Quelle jedes Nodes.
  • Eine Anmeldung mit falschem Einmalcode, an einem gesperrten oder an einem deaktivierten Konto bekommt dieselbe Meldung wie eine mit falschem Passwort: Benutzername, Passwort oder Einmalcode ist falsch. Der Hinweis darunter nennt die Sperre nach fünf Fehlversuchen als möglichen Grund. Bisher verrieten eigene Meldungen, dass es das Konto gibt, in welchem Zustand es ist oder dass das Passwort stimmte.
  • Von einer Adresse lassen sich höchstens 60 Passkey-Anmeldungen je Minute beginnen; darüber kommt eine Meldung, die Anmeldung mit Passwort bleibt möglich. Die Mengengrenze der ACME-Delegation zählt IPv6-Adressen je /64 statt je Adresse.
  • Je Subscription sind höchstens vier Web-Terminals gleichzeitig offen, je Node 32, und je Node höchstens 64 Live-Protokolle. Darüber nennt das Panel die Grenze, statt ein weiteres zu öffnen.
  • Die privaten Schlüssel der Zertifikate liegen verschlüsselt in der Datenbank, sobald KASTRA_SECRET_KEY gesetzt ist; vorhandene werden beim ersten Start nach dem Update umgestellt.
  • /actuator ist außer /actuator/health nur noch für angemeldete Administratoren erreichbar. Steht die Verbundadresse KASTRA_CLUSTER_BASE_URL nicht auf https://, meldet die Control Plane das beim Start als Fehler.
  • Ein stillgelegter Node wird sofort getrennt. Bisher redete sein Agent weiter, bis er sich von selbst neu verband.
  • Bei einem unerwarteten Fehler sehen nur Administratoren die Ursache im Feld Detail; alle anderen bekommen die Correlation-ID, unter der sie im Protokoll steht.

Behoben

  • Wird die JVM von WildFly hart beendet (kill -9), startet WildFly wieder. Bisher blieb er in diesem Fall aus, und im Serverprotokoll stand nichts dazu.
  • Das Lebensende von PHP, Node.js und der Distribution wird wieder geladen. Lag auf einem Node WildFly, scheiterte der ganze Abruf von endoflife.date, weil es dort kein Produkt WildFly gibt.
  • Unter Einstellungen › Sicherheitslücken steht eine Quelle, die kein Node braucht, als nicht benötigt statt noch nie abgerufen — etwa php.net, solange kein Node PHP aus sury hat. Die Seite Sicherheitslücken zeigte eine nie abgerufene Quelle bisher als aktuell.
  • Die Schwachstellendaten werden jede Nacht abgerufen. Nach einem Abruf von Hand am Nachmittag fiel bisher die folgende Nacht aus.
  • Alarme per Mail oder Webhook kommen wieder an. Bisher blieben sie oft unzugestellt und standen unter Einstellungen › Alarmierung dauerhaft als wartend — betroffen war jede Alarmart außer der Probemeldung, etwa Node nicht erreichbar oder Verwaltete Dateien verändert.
  • Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
  • Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.
  • Ein gekürzter Hinweis unter einem Eingabefeld zeigt beim Überfahren überall seinen vollen Text, etwa im Formular Tarif bearbeiten. Bisher tat er das nur auf wenigen Seiten.
  • Die Protokolle einer Domain füllen ihren Kasten sofort ganz. Bisher erschien bei einem langen Protokoll nur der obere Teil, der Rest erst beim Rollen.
  • Die nginx-Zusatzkonfiguration einer Domain prüft jetzt jede Anweisung einer Zeile, nicht nur das erste Wort. Eine zweite Anweisung hinter einem Semikolon — etwa expires 1h; proxy_pass … oder ein über Klammern eingeschleuster location-Block mit alias /etc/ — wird mit der ganzen Zeile verworfen und steht unter den Hinweisen des Rollouts. access_log ist nur noch zum Abschalten (off) erlaubt. Bisher kam alles hinter dem ersten Wort ungeprüft durch.
  • Eine Weiterleitung, ein Catch-All-Ziel und der Name eines Versandzugangs nehmen nur noch eine Adresse der eigenen Maildomain an; ein erlaubter Absender ebenso. Bisher ließ sich darüber die Post einer fremden Maildomain auf demselben Node umleiten oder unter ihrem Namen versenden. Ein Versandzugang bekommt nur noch dann eine DKIM-Signatur, wenn die Domain seiner Anmeldung zur Domain im Absender passt.
  • Der Datenbankabzug einer Sicherung folgt im Heimatverzeichnis keinem symbolischen Verweis mehr. Bisher hätte ein Verweis ~/.kastra-sicherung auf ein Systemverzeichnis dieses beim nächsten Sicherungslauf übereignen oder überschreiben können.
  • Das Aufgabenprotokoll zeigt einem Kunden nicht mehr den Rollout-Diff des ganzen Nodes. Bisher stand im Feld der abgeschlossenen Aufgabe die geänderte Konfiguration aller Kunden des Nodes samt Mail-Passwortdatei und privaten Schlüsseln; Administratoren sehen ihn weiterhin.
  • Einen neuen Passkey hinzufügen, TOTP (neu) einrichten und ein API-Token anlegen verlangen jetzt denselben zweiten Nachweis wie das Widerrufen eines Passkeys — einen Code aus der Authenticator-App, das aktuelle Passwort oder eine frische Anmeldung. Bisher genügte dafür die Sitzung, und ein fremder Zugriff auf eine angemeldete Sitzung konnte sich damit dauerhaft einnisten.
  • Die Sperre nach fünf Fehlversuchen trifft nur noch die Passwortanmeldung. Ein Konto ohne Passwortanmeldung zählt keine Fehlversuche mehr, und eine bestehende Sperre hält Passkey und Wiederherstellungscode nicht länger auf. Bisher ließ sich ein Konto, das nur per Passkey erreichbar ist, mit fünf Anfragen aussperren.
  • Meldet sich ein Node mit einem anderen Zertifikat als dem, das bei seiner Anmeldung ausgestellt wurde, wird er abgewiesen. Damit verliert ein ausgetauschter oder abgegebener Rechner seinen Zugang, sobald sich an seiner Stelle ein neuer anmeldet.
  • Eine Subdomain einer fremden Domain lässt sich nicht mehr als eigene Hauptdomain anlegen. Bisher hätte ein Kunde so eine Domain samt eigener DNS-Zone und Zertifikat unter einem fremden Namen beanspruchen können.
  • Ein Virenscan und ein Rückspieltest halten keine Datenbankverbindung mehr über ihre ganze Laufzeit. Bisher konnten mehrere gleichzeitig gestartete Läufe die Control Plane ausbremsen.
  • Grundbausteine der Control Plane sind auf aktuelle, abgesicherte Fassungen gehoben: Spring Boot 3.5.16, gRPC 1.76 (darin Netty mit den Fixes gegen CVE-2025-24970 und CVE-2025-55163 — ein Absturz des gesamten Dienstes über ein präpariertes TLS- bzw. HTTP/2-Paket) und die JWT-Bibliothek 10.0.2 (CVE-2025-53864, ein Lahmlegen über ein verschachteltes Sitzungscookie).
  • READONLY-Konten können kein Web-Terminal mehr öffnen; das war Schreibzugriff und widersprach der Rolle.
  • Ein Kunde kann die Übernahme eines Postfachs nur noch von einem öffentlichen IMAP-Server auf Port 143 oder 993 anstoßen. Bisher ließ sich damit das interne Netz des Nodes abtasten.
  • Die Statusseite zeigt einem Kunden das Gesamtbild, aber nicht mehr die einzelnen Vorfälle anderer Kunden samt Node-Namen.
  • Ein Sicherungsziel lässt sich nur noch auswählen, wenn es auf dem Node der Subscription liegt. Bisher hätte ein Kunde das Ziel eines fremden Nodes anhängen können.
  • Ein SFTP-Unterverzeichnis, das über einen symbolischen Verweis aus dem Heimatverzeichnis führt, wird abgewiesen statt eingehängt.
  • Fällige Sicherungen und Suchläufe nach Schadsoftware laufen jetzt nebenläufig an und halten einander nicht mehr auf. Bisher konnte ein langer Lauf dazu führen, dass eine Regel, die kurz danach fällig war, in dieser Nacht gar nicht lief — ohne Meldung.
  • Die Aufbewahrungsfrist des Audit-Logs wirkt. Bisher verhinderte ein Schutz gegen Änderungen auch das Löschen alter Einträge, und das Audit-Log wuchs trotz eingestellter Frist unbegrenzt.
  • Mail lässt sich nicht mehr für eine gleichnamige Maildomain eines anderen Kunden ein- oder ausschalten.
  • Den Node einer Maildomain und einer DNS-Zone sowie Art und Herkunft einer Zone wählt nur noch ein Administrator; ein Kunde bekommt den vorgesehenen Node.
  • Ein Rückspieltest schreibt nicht mehr durch einen symbolischen Verweis im Heimatverzeichnis an eine fremde Stelle.
  • Drift-Berichte eines Nodes werden gedeckelt gespeichert (höchstens 1000 Zeilen je Bericht, Diff gekürzt), statt die Datenbank bei dauerhafter Abweichung zu füllen.
  • Ein Node schreibt nur noch in sein eigenes Update-Protokoll, nicht mehr in das eines anderen.
  • Gleichzeitige Anmeldeversuche können die Control Plane nicht mehr über den Speicher der Passwortprüfung lahmlegen (höchstens vier gleichzeitige Prüfungen, der Rest wartet kurz).
  • Eine Container-Angabe mit einem Bind-Mount in der langen Form außerhalb des Subscription-Verzeichnisses oder mit einem auf 0.0.0.0 veröffentlichten Port wird jetzt ebenfalls abgewiesen.
  • Der Panel-Vhost nennt die nginx-Fassung nicht mehr (server_tokens off), beschränkt die TLS-1.2-Verschlüsselung auf Verfahren mit Vorwärtsgeheimnis (ssl_ciphers), erlaubt per connect-src nur noch Verbindungen zum Panel selbst, sperrt vendor/ unter phpMyAdmin und nimmt unter /api/ höchstens 64 MB an, ohne sie vor der Anmeldung auf die Platte zu puffern. Ein bestehender Vhost bekommt das beim Update nachgetragen; die vorherige Fassung bleibt als /etc/nginx/conf.d/kastra-panel.conf.vor-pruefbericht liegen.
  • Ein Einmalcode aus der Authenticator-App lässt sich auch bei zwei gleichzeitigen Anmeldungen nur einmal verwenden.
  • Verbindet sich ein Node neu, während seine alte Verbindung noch abgebaut wird, bleibt er verbunden. Bisher scheiterten seine laufenden Aufgaben dann mit Node nicht erreichbar, und er stand bis zum nächsten Herzschlag als getrennt da.
  • Alarme per Mail oder Webhook werden auf eigenen Fäden zugestellt. Ein langsamer Mailserver oder Webhook hält keinen Rollout und keine Datenbankverbindung mehr auf.
  • Ein Hostname, der kein gültiger Rechnername ist, wird beim Anmelden eines Nodes abgewiesen. Bisher ging er ungeprüft ins Zertifikat und in die Betreffzeile von Alarmmails.
  • Ein neues FTP-Passwort wird in einem Feld unter dem Zugang eingegeben. Bisher fragte ein Browser-Dialog danach, der es im Klartext zeigte.
  • Passwortfelder für Postfächer, Sicherungsziele, Alarmkanäle und Datenbanken füllt der Browser nicht mehr mit dem gespeicherten Panel-Passwort.
  • Wechselt man die Domain, verschwinden die einmaligen Zugangsdaten einer gerade angelegten ACME-Delegation. Bisher standen sie unter der nächsten Domain weiter da.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

Rendert anders

  • nft — auf dem Node, der das Panel trägt, lässt die Verwaltungsregel neben 22 und 8443 auch Port 8447 zu (WildFly-Konsole), mit derselben Drosselung bzw. denselben Admin-Netzen.
  • wildfly-unit — /etc/systemd/system/kastra-wildfly.service trägt Restart=always statt Restart=on-failure, StartLimitIntervalSec=1800, StartLimitBurst=6 und WorkingDirectory=-/opt/wildfly/standalone. Der Agent zieht eine bestehende Unit nach seinem Start einmal nach; ein laufender WildFly wird dabei nicht neu gestartet, die Werte gelten ab dem nächsten Start.
  • fpm-confd — neu je PHP-Fassung: /etc/php/<fassung>/fpm/conf.d/99-kastra.ini mit opcache.validate_permission = 1, opcache.restrict_api und session.upload_progress.enabled = 0, dazu, was unter Einstellungen › PHP allgemein steht. Alle FPM-Fassungen werden dafür einmal neu geladen. Die Datei gehört ab jetzt Kastra; eine von Hand dort abgelegte Datei mit anderem Namen bleibt unberührt. Eine Notfalldatei wie 99-notfall.ini kann nach dem Update weg.
  • fpm-pool — jeder Pool trägt php_admin_flag[session.upload_progress.enabled] = off. Weitere neue Zeilen (Sitzungs-Cookies, OPcache, Zeitgrenze, Slowlog, allgemeine freie Zeilen) erscheinen nur, wenn jemand einen Wert einstellt.
  • apparmor-php — das Profil von PHP-FPM erlaubt das Schreiben unter /var/log/kastra/subscriptions/ und das Mitlesen eines langsamen Workers für das Protokoll langsamer Anfragen.
  • logrotate — php-slow.log wird mit php-error.log gedreht.
  • mail — auf jedem Node mit Mailserver: unter /etc/rspamd/local.d/ neu milter_headers.conf und settings.conf, geändert actions.conf und classifier-bayes.conf; neu das Verzeichnis /etc/dovecot/kastra-spam/ mit den Sieve-Skripten für Junk-Ordner und Lernen samt zwei Programmen, die rspamc aufrufen und jede Korrektur ins Mailprotokoll schreiben; die Dovecot-Konfiguration bindet sie über sieve_before und IMAPSieve ein. Rspamd und Dovecot werden dafür einmal neu geladen.

26.10.23.15

Eingriff am Node Test 39 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.
  • Unter Einstellungen › PHP gibt es eine allgemeine PHP-Konfiguration für alle Nodes und alle PHP-Fassungen: Grenzen, Fehler und Regionales, Sitzungen, OPcache, FPM-Prozesse und freie php.ini-Zeilen. Jede Domain erbt, was sie nicht selbst setzt; bei jedem Feld steht, wie viele Domains abweichen. Nur für Administratoren.
  • Der Bereich PHP einer Domain zeigt bei jedem Feld, ob der Wert eigen ist oder wie allgemein; ein leeres Feld oder Alles wie allgemein setzt ihn zurück. Neu dort: Sitzungs-Cookies (nur über HTTPS, HttpOnly, SameSite, nur bekannte Kennungen), das OPcache-Prüfintervall, freie php.ini-Zeilen und — für Administratoren — die FPM-Prozesse samt harter Zeitgrenze und Protokoll langsamer Anfragen.
  • Dauert eine PHP-Anfrage länger als eingestellt, steht ihr Aufrufstapel im neuen Protokoll Langsame PHP-Anfragen der Domain.
  • Die PHP-Fassung des Webmails lässt sich im Bereich Mailserver eines Nodes einstellen, unabhängig von den Maildomains. Automatisch bleibt die Voreinstellung und wählt wie bisher die neueste Fassung bis 8.3. Fehlen der gewählten Fassung Erweiterungen, die Roundcube braucht, bleibt das Webmail auf der automatischen Wahl, und der Rollout nennt die fehlenden Pakete. Eine Fassung, auf der das Webmail eingestellt ist, lässt sich unter Laufzeiten nicht entfernen.
  • Kastra prüft die Software auf jedem Node gegen bekannte Sicherheitslücken: jedes installierte Paket — auch PostgreSQL, OpenSSL, OpenSSH und den Kernel —, dazu Node.js, WildFly, phpMyAdmin, Roundcube, Composer und WP-CLI. Die Daten kommen nachts von Debian, Ubuntu, php.net, der Node.js Security-WG, OSV und endoflife.date; der Paketbestand verlässt dafür den Server nicht. Der neue Bereich Sicherheitslücken eines Nodes nennt je Technologie Paket, installierte Fassung, Fix-Fassung, CVE, betroffene Domains und den nächsten Schritt; eine Lücke, die nicht greift, lässt sich mit Begründung quittieren.
  • Die Seite Sicherheitslücken zeigt dasselbe über alle Nodes und beantwortet, ob eine bestimmte Technologie irgendwo betroffen ist. Eingestellt wird unter Einstellungen › Sicherheitslücken: Schwelle des Alarms, Karenz und die Adressen der Quellen (leer schaltet eine Quelle ab, etwa ohne Internet oder mit eigenem Spiegel). Nur für Administratoren.
  • Neue Alarmarten: SCHWACHSTELLE meldet behebbare Lücken ab Dringlichkeit hoch und — kritisch — jede Lücke, die laut CISA aktiv ausgenutzt wird; Fixe, die die automatischen Sicherheitsupdates selbst holen, erst nach 48 Stunden. LEBENSENDE meldet Software ohne Sicherheitsupdates (etwa PHP 8.1 oder Node.js 20), SCHWACHSTELLEN_DATEN eine Quelle, die länger als 72 Stunden nicht abgerufen werden konnte.
  • Im Bereich Sicherheitslücken eines Nodes spielt Aktualisieren den Fix eines Befunds ein, Alle behebbaren aktualisieren alle auf einmal — als Aufgabe mit Protokoll, danach verschwindet der Befund. Das ist auch der Weg für PHP aus sury: die automatischen Sicherheitsupdates holen es weiterhin nicht, weil sury neben PHP neuere Bibliotheken mitbringt. Was sich so nicht beheben lässt (phpMyAdmin, Roundcube, Composer, WP-CLI, ein Kernel, der nur neu starten muss), nennt den Grund.
  • Läuft auf dem Host der Control Plane kein Agent, zeigt die Seite Sicherheitslücken ihn als „nicht erfasst“: PostgreSQL und Java dort werden dann nicht geprüft.
  • Die Control Plane lädt dafür einmal am Tag Daten von security-tracker.debian.org, security-metadata.canonical.com, cisa.gov, php.net, raw.githubusercontent.com, osv-vulnerabilities.storage.googleapis.com und endoflife.date. Sie liegen unter /var/lib/kastra-control-plane/schwachstellen.
  • Erkannter Spam landet im Ordner Junk des Postfachs. Bisher bekam er nur den Kopf X-Spam: Yes und blieb im Posteingang, weil kaum ein Mailprogramm diesen Kopf auswertet. Unter Mail › Spamfilter lässt eine Maildomain ihn auf Wunsch im Posteingang.
  • Der Bereich Mailserver eines Nodes hat einen Abschnitt Spamfilter mit drei Schwellen in Punkten: Greylisting ab (Vorgabe 4), Spam ab (6) und Ablehnen ab (15). Nur für Administratoren.
  • Jede Maildomain führt unter Mail › Spamfilter zwei Absenderlisten: Nie Spam (weder vertagt noch abgelehnt noch im Junk-Ordner) und Immer Spam (immer im Junk-Ordner), je Zeile eine Adresse oder @domain.
  • Verschiebt jemand eine Mail in den Junk-Ordner, lernt der Spamfilter sie als Spam; holt er sie heraus, als erwünscht — in jedem Mailprogramm über IMAP und im Webmail.
  • Eingehende Mail trägt im Kopf X-Spamd-Result mit den Punkten und den Regeln, die angeschlagen haben, und X-Spam-Status. Daran lässt sich ablesen, warum eine Mail im Junk-Ordner liegt.
  • Die Mailstatistik einer Maildomain und eines Nodes hat einen Abschnitt Spamfilter: wie viele eingehende Mails sauber, vertagt, als Spam markiert und abgelehnt wurden, wie oft jemand Spam selbst in den Junk-Ordner gelegt oder erwünschte Post herausgeholt hat, die Quoten Spam erkannt und Fehlalarme mit einer Empfehlung zur Schwelle und die Verteilung der Punkte mit den Schwellen des Nodes. Als Spam bewertete oder abgelehnte versendete Mail steht als Warnung darunter. Gezählt wird ab dem Update.
  • Die Liste Sendungen zeigt bei jeder Mail, die Rspamd bewertet hat, ihre Punkte.

Geändert

  • Archiv erstellen im Dateimanager packt im Hintergrund: über der Liste und in der Leiste unten rechts steht, wie viel schon gepackt ist, und der Dateimanager bleibt währenddessen bedienbar — auch ein Seitenwechsel hält das Packen nicht an. Ein großes Archiv bricht nicht mehr nach fünf Minuten ab; die Grenze liegt jetzt bei einer Stunde.
  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.
  • Der Upload-Fortschritt in PHP-Sitzungen (session.upload_progress.enabled) ist auf jeder Domain aus und lässt sich je Domain nicht wieder einschalten, auch nicht über eine .user.ini. Braucht eine Anwendung ihn, schaltet ihn ein Administrator unter Einstellungen › PHP ein. Anlass ist die für den 21. Oktober 2026 angekündigte PHP-Sicherheitslücke in diesem Handler.
  • opcache_get_status() und opcache_reset() sind für jede Domain gesperrt, und PHP prüft bei jedem Treffer im OPcache, ob der Benutzer die Datei lesen darf. Bisher sah jede Domain die Dateipfade aller anderen Domains derselben PHP-Fassung, und Cache leeren in einer Anwendung leerte ihn allen.
  • PHP-Werte einer Domain, die genau auf der bisherigen Vorgabe standen (etwa memory_limit = 256M), gelten nach dem Update als wie allgemein und folgen künftig der allgemeinen Konfiguration. Auf dem Node ändert sich dadurch nichts; eine Domain, die einen solchen Wert bewusst eingetragen hatte, trägt ihn bei Bedarf neu ein.
  • Freie php.ini-Zeilen je Domain nehmen nur Direktiven an, die eine Anwendung auch selbst über .user.ini oder ini_set() setzen dürfte. Eine Zeile wie sendmail_path hätte im FPM-Pool sonst einen beliebigen Befehl erlaubt.
  • Eingehende Mail mit 15 Punkten oder mehr wird abgelehnt — auch auf bestehenden Nodes. Bisher wurde nichts abgelehnt, auch eindeutiger Spam nicht. Verloren geht dabei nichts unbemerkt: der absendende Server bekommt den Fehler und benachrichtigt seinen Absender. Wer weiterhin nichts ablehnen will, leert im Bereich Mailserver das Feld Ablehnen ab.
  • Der lernende Teil des Spamfilters (Bayes) lernt von selbst nur noch eindeutigen Spam ab der Ablehnschwelle. Bisher lernte er alles ab 6 Punkten als Spam, auch Grenzfälle.

Behoben

  • Alarme per Mail oder Webhook kommen wieder an. Bisher blieben sie oft unzugestellt und standen unter Einstellungen › Alarmierung dauerhaft als wartend — betroffen war jede Alarmart außer der Probemeldung, etwa Node nicht erreichbar oder Verwaltete Dateien verändert.
  • Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
  • Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.
  • Ein gekürzter Hinweis unter einem Eingabefeld zeigt beim Überfahren überall seinen vollen Text, etwa im Formular Tarif bearbeiten. Bisher tat er das nur auf wenigen Seiten.
  • Die Protokolle einer Domain füllen ihren Kasten sofort ganz. Bisher erschien bei einem langen Protokoll nur der obere Teil, der Rest erst beim Rollen.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

Rendert anders

  • fpm-confd — neu je PHP-Fassung: /etc/php/<fassung>/fpm/conf.d/99-kastra.ini mit opcache.validate_permission = 1, opcache.restrict_api und session.upload_progress.enabled = 0, dazu, was unter Einstellungen › PHP allgemein steht. Alle FPM-Fassungen werden dafür einmal neu geladen. Die Datei gehört ab jetzt Kastra; eine von Hand dort abgelegte Datei mit anderem Namen bleibt unberührt. Eine Notfalldatei wie 99-notfall.ini kann nach dem Update weg.
  • fpm-pool — jeder Pool trägt php_admin_flag[session.upload_progress.enabled] = off. Weitere neue Zeilen (Sitzungs-Cookies, OPcache, Zeitgrenze, Slowlog, allgemeine freie Zeilen) erscheinen nur, wenn jemand einen Wert einstellt.
  • apparmor-php — das Profil von PHP-FPM erlaubt das Schreiben unter /var/log/kastra/subscriptions/ und das Mitlesen eines langsamen Workers für das Protokoll langsamer Anfragen.
  • logrotate — php-slow.log wird mit php-error.log gedreht.
  • mail — auf jedem Node mit Mailserver: unter /etc/rspamd/local.d/ neu milter_headers.conf und settings.conf, geändert actions.conf und classifier-bayes.conf; neu das Verzeichnis /etc/dovecot/kastra-spam/ mit den Sieve-Skripten für Junk-Ordner und Lernen samt zwei Programmen, die rspamc aufrufen und jede Korrektur ins Mailprotokoll schreiben; die Dovecot-Konfiguration bindet sie über sieve_before und IMAPSieve ein. Rspamd und Dovecot werden dafür einmal neu geladen.

26.10.23.10

Eingriff am Node Test 36 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.
  • Unter Einstellungen › PHP gibt es eine allgemeine PHP-Konfiguration für alle Nodes und alle PHP-Fassungen: Grenzen, Fehler und Regionales, Sitzungen, OPcache, FPM-Prozesse und freie php.ini-Zeilen. Jede Domain erbt, was sie nicht selbst setzt; bei jedem Feld steht, wie viele Domains abweichen. Nur für Administratoren.
  • Der Bereich PHP einer Domain zeigt bei jedem Feld, ob der Wert eigen ist oder wie allgemein; ein leeres Feld oder Alles wie allgemein setzt ihn zurück. Neu dort: Sitzungs-Cookies (nur über HTTPS, HttpOnly, SameSite, nur bekannte Kennungen), das OPcache-Prüfintervall, freie php.ini-Zeilen und — für Administratoren — die FPM-Prozesse samt harter Zeitgrenze und Protokoll langsamer Anfragen.
  • Dauert eine PHP-Anfrage länger als eingestellt, steht ihr Aufrufstapel im neuen Protokoll Langsame PHP-Anfragen der Domain.
  • Die PHP-Fassung des Webmails lässt sich im Bereich Mailserver eines Nodes einstellen, unabhängig von den Maildomains. Automatisch bleibt die Voreinstellung und wählt wie bisher die neueste Fassung bis 8.3. Fehlen der gewählten Fassung Erweiterungen, die Roundcube braucht, bleibt das Webmail auf der automatischen Wahl, und der Rollout nennt die fehlenden Pakete. Eine Fassung, auf der das Webmail eingestellt ist, lässt sich unter Laufzeiten nicht entfernen.
  • Kastra prüft die Software auf jedem Node gegen bekannte Sicherheitslücken: jedes installierte Paket — auch PostgreSQL, OpenSSL, OpenSSH und den Kernel —, dazu Node.js, WildFly, phpMyAdmin, Roundcube, Composer und WP-CLI. Die Daten kommen nachts von Debian, Ubuntu, php.net, der Node.js Security-WG, OSV und endoflife.date; der Paketbestand verlässt dafür den Server nicht. Der neue Bereich Sicherheitslücken eines Nodes nennt je Technologie Paket, installierte Fassung, Fix-Fassung, CVE, betroffene Domains und den nächsten Schritt; eine Lücke, die nicht greift, lässt sich mit Begründung quittieren.
  • Die Seite Sicherheitslücken zeigt dasselbe über alle Nodes und beantwortet, ob eine bestimmte Technologie irgendwo betroffen ist. Eingestellt wird unter Einstellungen › Sicherheitslücken: Schwelle des Alarms, Karenz und die Adressen der Quellen (leer schaltet eine Quelle ab, etwa ohne Internet oder mit eigenem Spiegel). Nur für Administratoren.
  • Neue Alarmarten: SCHWACHSTELLE meldet behebbare Lücken ab Dringlichkeit hoch und — kritisch — jede Lücke, die laut CISA aktiv ausgenutzt wird; Fixe, die die automatischen Sicherheitsupdates selbst holen, erst nach 48 Stunden. LEBENSENDE meldet Software ohne Sicherheitsupdates (etwa PHP 8.1 oder Node.js 20), SCHWACHSTELLEN_DATEN eine Quelle, die länger als 72 Stunden nicht abgerufen werden konnte.
  • Im Bereich Sicherheitslücken eines Nodes spielt Aktualisieren den Fix eines Befunds ein, Alle behebbaren aktualisieren alle auf einmal — als Aufgabe mit Protokoll, danach verschwindet der Befund. Das ist auch der Weg für PHP aus sury: die automatischen Sicherheitsupdates holen es weiterhin nicht, weil sury neben PHP neuere Bibliotheken mitbringt. Was sich so nicht beheben lässt (phpMyAdmin, Roundcube, Composer, WP-CLI, ein Kernel, der nur neu starten muss), nennt den Grund.
  • Läuft auf dem Host der Control Plane kein Agent, zeigt die Seite Sicherheitslücken ihn als „nicht erfasst“: PostgreSQL und Java dort werden dann nicht geprüft.
  • Die Control Plane lädt dafür einmal am Tag Daten von security-tracker.debian.org, security-metadata.canonical.com, cisa.gov, php.net, raw.githubusercontent.com, osv-vulnerabilities.storage.googleapis.com und endoflife.date. Sie liegen unter /var/lib/kastra-control-plane/schwachstellen.
  • Erkannter Spam landet im Ordner Junk des Postfachs. Bisher bekam er nur den Kopf X-Spam: Yes und blieb im Posteingang, weil kaum ein Mailprogramm diesen Kopf auswertet. Unter Mail › Spamfilter lässt eine Maildomain ihn auf Wunsch im Posteingang.
  • Der Bereich Mailserver eines Nodes hat einen Abschnitt Spamfilter mit drei Schwellen in Punkten: Greylisting ab (Vorgabe 4), Spam ab (6) und Ablehnen ab (15). Nur für Administratoren.
  • Jede Maildomain führt unter Mail › Spamfilter zwei Absenderlisten: Nie Spam (weder vertagt noch abgelehnt noch im Junk-Ordner) und Immer Spam (immer im Junk-Ordner), je Zeile eine Adresse oder @domain.
  • Verschiebt jemand eine Mail in den Junk-Ordner, lernt der Spamfilter sie als Spam; holt er sie heraus, als erwünscht — in jedem Mailprogramm über IMAP und im Webmail.
  • Eingehende Mail trägt im Kopf X-Spamd-Result mit den Punkten und den Regeln, die angeschlagen haben, und X-Spam-Status. Daran lässt sich ablesen, warum eine Mail im Junk-Ordner liegt.

Geändert

  • Archiv erstellen im Dateimanager packt im Hintergrund: über der Liste und in der Leiste unten rechts steht, wie viel schon gepackt ist, und der Dateimanager bleibt währenddessen bedienbar — auch ein Seitenwechsel hält das Packen nicht an. Ein großes Archiv bricht nicht mehr nach fünf Minuten ab; die Grenze liegt jetzt bei einer Stunde.
  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.
  • Der Upload-Fortschritt in PHP-Sitzungen (session.upload_progress.enabled) ist auf jeder Domain aus und lässt sich je Domain nicht wieder einschalten, auch nicht über eine .user.ini. Braucht eine Anwendung ihn, schaltet ihn ein Administrator unter Einstellungen › PHP ein. Anlass ist die für den 21. Oktober 2026 angekündigte PHP-Sicherheitslücke in diesem Handler.
  • opcache_get_status() und opcache_reset() sind für jede Domain gesperrt, und PHP prüft bei jedem Treffer im OPcache, ob der Benutzer die Datei lesen darf. Bisher sah jede Domain die Dateipfade aller anderen Domains derselben PHP-Fassung, und Cache leeren in einer Anwendung leerte ihn allen.
  • PHP-Werte einer Domain, die genau auf der bisherigen Vorgabe standen (etwa memory_limit = 256M), gelten nach dem Update als wie allgemein und folgen künftig der allgemeinen Konfiguration. Auf dem Node ändert sich dadurch nichts; eine Domain, die einen solchen Wert bewusst eingetragen hatte, trägt ihn bei Bedarf neu ein.
  • Freie php.ini-Zeilen je Domain nehmen nur Direktiven an, die eine Anwendung auch selbst über .user.ini oder ini_set() setzen dürfte. Eine Zeile wie sendmail_path hätte im FPM-Pool sonst einen beliebigen Befehl erlaubt.
  • Eingehende Mail mit 15 Punkten oder mehr wird abgelehnt — auch auf bestehenden Nodes. Bisher wurde nichts abgelehnt, auch eindeutiger Spam nicht. Verloren geht dabei nichts unbemerkt: der absendende Server bekommt den Fehler und benachrichtigt seinen Absender. Wer weiterhin nichts ablehnen will, leert im Bereich Mailserver das Feld Ablehnen ab.
  • Der lernende Teil des Spamfilters (Bayes) lernt von selbst nur noch eindeutigen Spam ab der Ablehnschwelle. Bisher lernte er alles ab 6 Punkten als Spam, auch Grenzfälle.

Behoben

  • Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
  • Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.
  • Ein gekürzter Hinweis unter einem Eingabefeld zeigt beim Überfahren überall seinen vollen Text, etwa im Formular Tarif bearbeiten. Bisher tat er das nur auf wenigen Seiten.
  • Die Protokolle einer Domain füllen ihren Kasten sofort ganz. Bisher erschien bei einem langen Protokoll nur der obere Teil, der Rest erst beim Rollen.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

Rendert anders

  • fpm-confd — neu je PHP-Fassung: /etc/php/<fassung>/fpm/conf.d/99-kastra.ini mit opcache.validate_permission = 1, opcache.restrict_api und session.upload_progress.enabled = 0, dazu, was unter Einstellungen › PHP allgemein steht. Alle FPM-Fassungen werden dafür einmal neu geladen. Die Datei gehört ab jetzt Kastra; eine von Hand dort abgelegte Datei mit anderem Namen bleibt unberührt. Eine Notfalldatei wie 99-notfall.ini kann nach dem Update weg.
  • fpm-pool — jeder Pool trägt php_admin_flag[session.upload_progress.enabled] = off. Weitere neue Zeilen (Sitzungs-Cookies, OPcache, Zeitgrenze, Slowlog, allgemeine freie Zeilen) erscheinen nur, wenn jemand einen Wert einstellt.
  • apparmor-php — das Profil von PHP-FPM erlaubt das Schreiben unter /var/log/kastra/subscriptions/ und das Mitlesen eines langsamen Workers für das Protokoll langsamer Anfragen.
  • logrotate — php-slow.log wird mit php-error.log gedreht.
  • mail — auf jedem Node mit Mailserver: unter /etc/rspamd/local.d/ neu milter_headers.conf und settings.conf, geändert actions.conf und classifier-bayes.conf; neu das Verzeichnis /etc/dovecot/kastra-spam/ mit den Sieve-Skripten für Junk-Ordner und Lernen samt zwei Programmen, die rspamc aufrufen; die Dovecot-Konfiguration bindet sie über sieve_before und IMAPSieve ein. Rspamd und Dovecot werden dafür einmal neu geladen.

26.10.23.3

Eingriff am Node Test 22 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.
  • Unter Einstellungen › PHP gibt es eine allgemeine PHP-Konfiguration für alle Nodes und alle PHP-Fassungen: Grenzen, Fehler und Regionales, Sitzungen, OPcache, FPM-Prozesse und freie php.ini-Zeilen. Jede Domain erbt, was sie nicht selbst setzt; bei jedem Feld steht, wie viele Domains abweichen. Nur für Administratoren.
  • Der Bereich PHP einer Domain zeigt bei jedem Feld, ob der Wert eigen ist oder wie allgemein; ein leeres Feld oder Alles wie allgemein setzt ihn zurück. Neu dort: Sitzungs-Cookies (nur über HTTPS, HttpOnly, SameSite, nur bekannte Kennungen), das OPcache-Prüfintervall, freie php.ini-Zeilen und — für Administratoren — die FPM-Prozesse samt harter Zeitgrenze und Protokoll langsamer Anfragen.
  • Dauert eine PHP-Anfrage länger als eingestellt, steht ihr Aufrufstapel im neuen Protokoll Langsame PHP-Anfragen der Domain.
  • Die PHP-Fassung des Webmails lässt sich im Bereich Mailserver eines Nodes einstellen, unabhängig von den Maildomains. Automatisch bleibt die Voreinstellung und wählt wie bisher die neueste Fassung bis 8.3. Fehlen der gewählten Fassung Erweiterungen, die Roundcube braucht, bleibt das Webmail auf der automatischen Wahl, und der Rollout nennt die fehlenden Pakete. Eine Fassung, auf der das Webmail eingestellt ist, lässt sich unter Laufzeiten nicht entfernen.

Geändert

  • Archiv erstellen im Dateimanager packt im Hintergrund: über der Liste und in der Leiste unten rechts steht, wie viel schon gepackt ist, und der Dateimanager bleibt währenddessen bedienbar — auch ein Seitenwechsel hält das Packen nicht an. Ein großes Archiv bricht nicht mehr nach fünf Minuten ab; die Grenze liegt jetzt bei einer Stunde.
  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.
  • Der Upload-Fortschritt in PHP-Sitzungen (session.upload_progress.enabled) ist auf jeder Domain aus und lässt sich je Domain nicht wieder einschalten, auch nicht über eine .user.ini. Braucht eine Anwendung ihn, schaltet ihn ein Administrator unter Einstellungen › PHP ein. Anlass ist die für den 21. Oktober 2026 angekündigte PHP-Sicherheitslücke in diesem Handler.
  • opcache_get_status() und opcache_reset() sind für jede Domain gesperrt, und PHP prüft bei jedem Treffer im OPcache, ob der Benutzer die Datei lesen darf. Bisher sah jede Domain die Dateipfade aller anderen Domains derselben PHP-Fassung, und Cache leeren in einer Anwendung leerte ihn allen.
  • PHP-Werte einer Domain, die genau auf der bisherigen Vorgabe standen (etwa memory_limit = 256M), gelten nach dem Update als wie allgemein und folgen künftig der allgemeinen Konfiguration. Auf dem Node ändert sich dadurch nichts; eine Domain, die einen solchen Wert bewusst eingetragen hatte, trägt ihn bei Bedarf neu ein.
  • Freie php.ini-Zeilen je Domain nehmen nur Direktiven an, die eine Anwendung auch selbst über .user.ini oder ini_set() setzen dürfte. Eine Zeile wie sendmail_path hätte im FPM-Pool sonst einen beliebigen Befehl erlaubt.

Behoben

  • Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
  • Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.
  • Ein gekürzter Hinweis unter einem Eingabefeld zeigt beim Überfahren überall seinen vollen Text, etwa im Formular Tarif bearbeiten. Bisher tat er das nur auf wenigen Seiten.
  • Die Protokolle einer Domain füllen ihren Kasten sofort ganz. Bisher erschien bei einem langen Protokoll nur der obere Teil, der Rest erst beim Rollen.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

Rendert anders

  • fpm-confd — neu je PHP-Fassung: /etc/php/<fassung>/fpm/conf.d/99-kastra.ini mit opcache.validate_permission = 1, opcache.restrict_api und session.upload_progress.enabled = 0, dazu, was unter Einstellungen › PHP allgemein steht. Alle FPM-Fassungen werden dafür einmal neu geladen. Die Datei gehört ab jetzt Kastra; eine von Hand dort abgelegte Datei mit anderem Namen bleibt unberührt. Eine Notfalldatei wie 99-notfall.ini kann nach dem Update weg.
  • fpm-pool — jeder Pool trägt php_admin_flag[session.upload_progress.enabled] = off. Weitere neue Zeilen (Sitzungs-Cookies, OPcache, Zeitgrenze, Slowlog, allgemeine freie Zeilen) erscheinen nur, wenn jemand einen Wert einstellt.
  • apparmor-php — das Profil von PHP-FPM erlaubt das Schreiben unter /var/log/kastra/subscriptions/ und das Mitlesen eines langsamen Workers für das Protokoll langsamer Anfragen.
  • logrotate — php-slow.log wird mit php-error.log gedreht.

26.10.21.1

Eingriff am Node Test 20 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.
  • Unter Einstellungen › PHP gibt es eine allgemeine PHP-Konfiguration für alle Nodes und alle PHP-Fassungen: Grenzen, Fehler und Regionales, Sitzungen, OPcache, FPM-Prozesse und freie php.ini-Zeilen. Jede Domain erbt, was sie nicht selbst setzt; bei jedem Feld steht, wie viele Domains abweichen. Nur für Administratoren.
  • Der Bereich PHP einer Domain zeigt bei jedem Feld, ob der Wert eigen ist oder wie allgemein; ein leeres Feld oder Alles wie allgemein setzt ihn zurück. Neu dort: Sitzungs-Cookies (nur über HTTPS, HttpOnly, SameSite, nur bekannte Kennungen), das OPcache-Prüfintervall, freie php.ini-Zeilen und — für Administratoren — die FPM-Prozesse samt harter Zeitgrenze und Protokoll langsamer Anfragen.
  • Dauert eine PHP-Anfrage länger als eingestellt, steht ihr Aufrufstapel im neuen Protokoll Langsame PHP-Anfragen der Domain.

Geändert

  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.
  • Der Upload-Fortschritt in PHP-Sitzungen (session.upload_progress.enabled) ist auf jeder Domain aus und lässt sich je Domain nicht wieder einschalten, auch nicht über eine .user.ini. Braucht eine Anwendung ihn, schaltet ihn ein Administrator unter Einstellungen › PHP ein. Anlass ist die für den 21. Oktober 2026 angekündigte PHP-Sicherheitslücke in diesem Handler.
  • opcache_get_status() und opcache_reset() sind für jede Domain gesperrt, und PHP prüft bei jedem Treffer im OPcache, ob der Benutzer die Datei lesen darf. Bisher sah jede Domain die Dateipfade aller anderen Domains derselben PHP-Fassung, und Cache leeren in einer Anwendung leerte ihn allen.
  • PHP-Werte einer Domain, die genau auf der bisherigen Vorgabe standen (etwa memory_limit = 256M), gelten nach dem Update als wie allgemein und folgen künftig der allgemeinen Konfiguration. Auf dem Node ändert sich dadurch nichts; eine Domain, die einen solchen Wert bewusst eingetragen hatte, trägt ihn bei Bedarf neu ein.
  • Freie php.ini-Zeilen je Domain nehmen nur Direktiven an, die eine Anwendung auch selbst über .user.ini oder ini_set() setzen dürfte. Eine Zeile wie sendmail_path hätte im FPM-Pool sonst einen beliebigen Befehl erlaubt.

Behoben

  • Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
  • Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.
  • Ein gekürzter Hinweis unter einem Eingabefeld zeigt beim Überfahren überall seinen vollen Text, etwa im Formular Tarif bearbeiten. Bisher tat er das nur auf wenigen Seiten.
  • Die Protokolle einer Domain füllen ihren Kasten sofort ganz. Bisher erschien bei einem langen Protokoll nur der obere Teil, der Rest erst beim Rollen.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

Rendert anders

  • fpm-confd — neu je PHP-Fassung: /etc/php/<fassung>/fpm/conf.d/99-kastra.ini mit opcache.validate_permission = 1, opcache.restrict_api und session.upload_progress.enabled = 0, dazu, was unter Einstellungen › PHP allgemein steht. Alle FPM-Fassungen werden dafür einmal neu geladen. Die Datei gehört ab jetzt Kastra; eine von Hand dort abgelegte Datei mit anderem Namen bleibt unberührt. Eine Notfalldatei wie 99-notfall.ini kann nach dem Update weg.
  • fpm-pool — jeder Pool trägt php_admin_flag[session.upload_progress.enabled] = off. Weitere neue Zeilen (Sitzungs-Cookies, OPcache, Zeitgrenze, Slowlog, allgemeine freie Zeilen) erscheinen nur, wenn jemand einen Wert einstellt.
  • apparmor-php — das Profil von PHP-FPM erlaubt das Schreiben unter /var/log/kastra/subscriptions/ und das Mitlesen eines langsamen Workers für das Protokoll langsamer Anfragen.
  • logrotate — php-slow.log wird mit php-error.log gedreht.

26.10.18.1

Eingriff am Node Test 9 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.

Geändert

  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.

Behoben

  • Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
  • Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.
  • Ein gekürzter Hinweis unter einem Eingabefeld zeigt beim Überfahren überall seinen vollen Text, etwa im Formular Tarif bearbeiten. Bisher tat er das nur auf wenigen Seiten.
  • Die Protokolle einer Domain füllen ihren Kasten sofort ganz. Bisher erschien bei einem langen Protokoll nur der obere Teil, der Rest erst beim Rollen.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

26.10.15.1

Eingriff am Node Test 7 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.

Geändert

  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.

Behoben

  • Eine Einzelseitenanwendung (Flutter, Angular, React) lässt sich über die Zusatzkonfiguration einrichten: ein eigenes try_files im location-Kontext ersetzt das von Kastra erzeugte. Bisher standen dann zwei nebeneinander, und der Rollout scheiterte mit NGINX_CONFIG_INVALID.
  • Setzt die Zusatzkonfiguration im location-Kontext ein eigenes add_header, etwa Cache-Control, behält die Domain trotzdem HSTS und ihre Sicherheits-Header. Bisher fielen beide dabei still weg.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

26.10.14.2

Eingriff am Node Test 5 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
  • Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart OOM_KILL — mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf.
  • Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.

Geändert

  • Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als KASTRA_JAVA_OPTS in /etc/kastra/control-plane.env.

Eingriffe am Node

  • W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei /kastra.swap an (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in /etc/fstab ein und setzt über /etc/sysctl.d/90-kastra-swap.conf vm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar: swapoff /kastra.swap, die Zeile aus /etc/fstab nehmen, /kastra.swap und /etc/sysctl.d/90-kastra-swap.conf löschen.

26.10.13.2

Normal Test 1 Punkte

Neu

  • Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.

26.10.12.1

Eingriff am Node Test Stabil 76 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).
  • Lange Listen laden seitenweise. Domains, Subscriptions, Kunden, Datenbanken, Maildomains, Zonen, Benutzer und Container zeigen ab 500 Einträgen Mehr laden. Eine Anlage mit weniger Einträgen sieht keinen Unterschied.
  • Das Protokoll einer Aufgabe und die Ausgabe eines Rollouts lassen sich vollständig herunterladen.
  • Mailstatistik. Eine Maildomain hat den Reiter Statistik: was heute, in den letzten 7 und 30 Tagen eingegangen und versendet wurde, was gescheitert ist — unzustellbar, abgewiesen, als Spam abgewiesen — und was gerade wartet, dazu ein Verlauf über 30 Tage und die Zahlen je Postfach, Weiterleitung und Versandzugang. Jede Zahl führt zur Liste der Sendungen dahinter — zugestellt, zurückgestellt, gescheitert, gelöscht, je Empfänger mit Grund, Zahl der Versuche und Sprung ins Protokoll, filterbar nach Zeitraum, Status, Richtung und Adresse. Der Bereich Mailserver eines Nodes zeigt dieselben Zahlen und Sendungen für den ganzen Node, je Maildomain aufgeschlüsselt. Nach dem Update liest jeder Node beim ersten Lauf bis zu 30 Tage nach, soweit sein Journal so weit reicht.
  • Mehrere Sendungen auf einmal. Was noch in der Warteschlange liegt, lässt sich aus der Liste der Sendungen und aus der Warteschlange heraus einzeln, für eine Auswahl per Kästchen oder für alle erneut versuchen oder löschen; im Bereich Mailserver eines Nodes auch anhalten und freigeben. Danach meldet das Panel, wie viele erledigt und wie viele übersprungen wurden — etwa weil eine Sendung inzwischen zugestellt war.
  • Die Aufbewahrung der einzelnen Sendungen stellt KASTRA_MAIL_STATISTIK_SENDUNGEN_TAGE ein (Vorgabe 30 Tage).
  • Alarm bei Stau in der Warteschlange (MAIL_QUEUE_STAU): ab 100 wartenden Sendungen oder wenn eine seit 6 Stunden wartet. Beide Schwellen sind über KASTRA_MAIL_STATISTIK_STAU_ANZAHL und KASTRA_MAIL_STATISTIK_STAU_ALTER_STUNDEN einstellbar.
  • Repositories auf einen Blick. Eine Subscription hat den Bereich Repositories: alle Repositories ihrer Domains in einer Tabelle, je Zeile die Domain, der geholte Commit und der jüngste Commit des Branches bei GitHub. Oben steht, wie viele aktuell sind und wo bei GitHub schon ein neuerer Stand liegt; Nicht aktuelle holen zieht sie in einem Zug nach.
  • Warum ein Container nicht startet, steht im Panel. Der Bereich Container einer Domain nennt den Schritt, an dem der letzte Start gescheitert ist oder gerade steht — Bauen, Starten oder die Gegenprobe —, zeigt die Schritte mit ihrem Ergebnis und die Ausgabe genau dieses Laufs, etwa den Abbruch von npm ci im Bau. Hat systemd nach fünf Versuchen die Startsperre gezogen, steht das dort mit Sperre lösen und neu starten. Die Übersicht unter Container zeigt dieselbe Marke je Domain.

Geändert

  • **Ein Rollout, der nicht ganz rund lief, steht als Mit Warnungen da** statt als Erfolgreich — etwa wenn eine Zeile der Zusatzkonfiguration verworfen wurde oder ein Dienst sich nicht neu laden ließ. Die Meldung nennt die Zahl der Warnungen, das Protokoll die betroffenen Zeilen; die Seite, von der aus ausgerollt wurde, meldet „Ausgerollt, aber mit … Warnungen“.
  • Die Meldung, dass journald die Zeitgrenze des Journals noch nicht gelesen hat, erscheint nur noch in dem Rollout, der sie geändert hat — nicht mehr in jedem.
  • Die Zusatzkonfiguration einer Domain übernimmt jetzt proxy_buffers, proxy_buffer_size und proxy_busy_buffers_size. Bisher wurden die Zeilen beim Ausrollen verworfen; wer hinter einem Reverse Proxy „upstream sent too big header“ sah, konnte die Puffer nicht vergrößern.
  • Cronjobs melden sich per Mail, wenn man es will. Je Cronjob lassen sich ein oder mehrere Empfänger eintragen und wann eine Mail kommt: nur bei Fehler (mit Ausgabe und Rückgabewert), sobald der Befehl etwas ausgibt, nach jedem Lauf oder gar nicht. Einstellbar beim Anlegen und über Mail in der Zeile des Jobs. Bisher ging die Ausgabe an den Unix-Benutzer der Subscription, wo sie niemand las; bestehende Cronjobs stehen nach dem Update auf Keine Mail.
  • Scheitert Neu starten an einer Container-Domain, nennt die Meldung den gescheiterten Schritt, und in den Details steht die Ausgabe des Laufs statt nur „Job failed, see journalctl“.
  • Die Warteschlange einer Maildomain zeigt nur noch deren Sendungen — und Kunden sehen sie jetzt auch; bisher kam für sie nur ein Fehler. Dort lässt sich eine Sendung erneut versuchen oder löschen. Anhalten, Freigeben und Zustellung aller Sendungen erzwingen stehen jetzt im Bereich Mailserver des Nodes, weil sie den ganzen Mailserver betreffen.
  • Postfix vergibt lange Warteschlangenkennungen (enable_long_queue_ids), damit sich eine Kennung über die 30 Tage, die die Sendungen aufbewahrt werden, nicht wiederholt. Mails, die beim Update schon in der Warteschlange liegen, behalten ihre kurze Kennung und werden normal zugestellt.

  • Ein Rollout startet Container und Objekt-Caches nur noch neu, wenn sich ihre Konfiguration geändert hat. Der Rollout einer fremden Domain lässt sie laufen, der Cache bleibt gefüllt. Bisher warf jeder Rollout — auch einer ohne jede Änderung — alle Container und alle Caches des Nodes weg.

    Eine Änderung nur an der Dockerfile oder an eigenen Dateien der Anwendung baut den Container deshalb beim nächsten Rollout nicht mehr neu. Dafür gibt es Neu starten im Bereich Container.

  • Ein Rollout schreibt, sichert und lädt nur noch, was sich wirklich geändert hat. „Datei(en) geschrieben“ im Aufgabenprotokoll zählt nur diese Dateien, und PHP-FPM wird nur für die Fassungen neu geladen, deren Pools betroffen sind.
  • Der Healthcheck nach dem Rollout prüft die Domains gleichzeitig. Ein Rollout wartet nicht mehr eine Minute je Domain, die nicht antwortet, und eine Anwendung, die mit einem eigenen Fehlercode antwortet, wird nicht mehr viermal abgefragt.
  • Eine Abweichung, die nach der Korrektur sofort wiederkommt, löst nicht mehr alle fünf Minuten einen vollständigen Rollout aus. Der Abstand verdoppelt sich bis zu zwei Stunden; gemeldet wird die Abweichung weiter im gewohnten Takt.
  • Das Panel überträgt beim ersten Aufruf etwa ein Viertel der bisherigen Datenmenge. Skripte, Stilvorlagen und Antworten der API gehen komprimiert hinaus, und die Stilvorlage des Code-Editors lädt erst mit dem Editor. Ein bestehender Panel-Host bekommt die Komprimierung beim Update in seinen nginx-Vhost nachgetragen; die vorherige Fassung bleibt als kastra-panel.conf.vor-gzip daneben liegen.
  • Lange Protokolle und große Verzeichnisse bleiben im Panel flüssig. Angezeigt werden die letzten 1 000 Zeilen eines Protokolls, die letzten 2 000 Zeilen eines Rollouts und die ersten 500 Einträge eines Verzeichnisses; der Rest steht im Download oder wird nachgelegt. Das Protokoll einer Aufgabe öffnet am Ende statt am Anfang.
  • Die Übersicht, die Statusseite und die Container-Seite holen, was sie von den Nodes brauchen, in einer einzigen Anfrage an die Control Plane statt in einer je Node oder je Container.
  • Ein Panel in einem Tab im Hintergrund fragt die Control Plane nicht mehr ab; beim Zurückkommen holt es sofort nach.
  • Angaben wie „vor 3 Minuten“ werden erst beim nächsten Laden der Seite weitergezählt.
  • Die Hinweise in den Verlaufsbalken von Status und Auslastung erscheinen als schlichter Hinweis des Browsers.
  • Das Web-Terminal zeichnet über die Grafikkarte und bleibt auch bei viel Ausgabe flüssig.
  • Mehrere Änderungen an einem Node kurz hintereinander werden zusammen ausgerollt. Jede behält ihre Aufgabe; die erste trägt das Protokoll des Nodes, die übrigen zeigen „Wird zusammen mit Aufgabe … ausgerollt“ und enden mit demselben Ergebnis.

Behoben

  • Das Panel ist auf dem Telefon besser bedienbar.
  • Tabellen (Audit-Log, Firewall, Instanzen, Alarmierung, Aliase) rollen waagerecht, statt Adressen und Marken Zeichen für Zeichen untereinander zu stellen.
  • Hinweise und Fehlermeldungen unter einem Feld brechen auf Telefon und Tablet um, statt mit „…“ abgeschnitten zu bleiben.
  • Auf der Anmeldeseite passen die drei Reiter nebeneinander, ohne Blätterpfeile.
  • In den Bereichen PHP und Webserver einer Domain sind die Feldbeschriftungen nicht mehr oben abgeschnitten.
  • Eingabefelder neben einem Knopf (Alias, Passkey, Passwort, API-Token) gehen in eine eigene Zeile, statt auf eine Handbreit zu schrumpfen; ebenso die Filter im Audit-Log und der Zeitraum unter Sperren.
  • Im Handbuch klappt das Verzeichnis über einem geöffneten Artikel ein.
  • DNS-Einträge zeigen den Namen lesbar, und das iPhone zoomt beim Antippen eines Feldes nicht mehr in die Seite.
  • Im Bereich Komponenten eines Nodes und auf der Statusseite steht bei einem nicht erreichbaren Node die Meldung statt „[object Object]“.
  • Die Übersicht zeigt bei nur einem Node nicht mehr „Ausfallreserve NaN %“.
  • Im Bereich Wartung haben Schalter, Überschriften und Knöpfe wieder Abstand zueinander.
  • Eine Node.js-Anwendung, deren Version auf dem Standard des Nodes steht, zeigt diese Fassung in der Auswahl statt eines leeren Feldes mit dem Hinweis, sie liege nicht auf dem Node.
  • **Der Bereich Anwendung zeigt die Node.js-Anwendung nur noch einmal.** Eine Domain, die mit eingeschaltetem Mischbetrieb von PHP oder Statisch auf Node.js, Proxy oder Container umgestellt wurde, behielt den Mischbetrieb im Hintergrund. Bei Node.js stand die Anwendung dann zweimal untereinander, und die Routen der Domain wurden weiter ausgerollt. Der Wechsel der Laufzeit schaltet den Mischbetrieb jetzt ab; betroffene Domains werden beim Update bereinigt.
  • Dialoge nehmen auf dem Telefon und im Querformat die volle Breite ein. Vorher stand etwa der Dateieditor bei einer Datei mit kurzen Zeilen als schmale Spalte in der Mitte.
  • Dateien lassen sich auf dem Telefon bearbeiten, ohne in die Desktop-Ansicht des Browsers zu wechseln. Auf Telefon und Tablet öffnen Dateimanager, Zusatzkonfiguration, Compose-Datei, composer.json, WildFly-Konfiguration und Fehlerseiten ein einfaches Textfeld über die volle Höhe des Dialogs; Tastatur, Markieren und Einfügen kommen vom Telefon. Syntaxhervorhebung und Zeilennummern gibt es dort nicht mehr — am Rechner bleibt der Editor wie bisher.
  • Auf einem Node mit vielen Domains kommen neue Domains wieder online. Ab etwa 400 Domains durfte nginx nicht mehr genug Dateien offen halten – je Domain gehören zwei Protokolle dazu –, und sein Neuladen brach mit „Too many open files“ ab. nginx lieferte dann still die vorherige Konfiguration weiter; die zuletzt angelegten Domains kannte er nicht, und der Rollout nahm genau sie mit der Meldung Healthcheck fehlgeschlagen wieder zurück. Die Grenze hebt der Eingriff W-002 an (siehe unten).
  • Ein Rollout meldet nicht mehr Erfolg, wenn nginx die neue Konfiguration gar nicht übernommen hat. Bisher galt der Rollout als ausgerollt, sobald das Signal zum Neuladen zugestellt war – ob nginx sie auch annahm, blieb ungeprüft. Jetzt endet er mit NGINX_RELOAD_FAILED, stellt die vorherige Konfiguration wieder her und nennt im Detail die Zeilen aus dem Fehlerprotokoll von nginx, die den Grund tragen.
  • Heißt der Node selbst wie eine Kundendomain (Mail-Hostname kunde.de statt mail.kunde.de), hält Postfix diese Domain nicht mehr für lokal. Bisher lehnte eine Domain im Modus nur Versand jede Mail an sich selbst mit „User unknown in local recipient table“ ab – etwa die Testmail eines WordPress an info@kunde.de –, statt sie zum Postfach beim bisherigen Anbieter zu schicken.
  • Eine PHP-Domain, die auf Node.js, Container oder Proxy umgestellt wird, geht nicht mehr weiter an Apache. Bisher blieb der Webserver-Modus nginx + Apache stehen, und Besucher bekamen den Quelltext der index.php statt der Anwendung zu sehen. Domains, die schon so umgestellt wurden, richtet das Update selbst.
  • Ein Download aus dem Dateimanager belastet die Control Plane nicht mehr mit der Dateigröße. Bisher lag eine Datei zweimal vollständig in ihrem Speicher.
  • Ein langsamer oder hängender Node hält Rollout, Terminal und Dateimanager der anderen Nodes nicht mehr an, und offene Protokollfenster legen die Control Plane nicht mehr still.
  • Ein Web-Terminal mit viel Ausgabe hält Heartbeat, Rollout-Ergebnisse und Protokolle seines Nodes nicht mehr an.
  • Ein langer nächtlicher Lauf wie der monatliche Wiederherstellungs-Probelauf verzögert die Erkennung ausgefallener Nodes nicht mehr.
  • Das Protokoll eines Rollouts kommt in Stapeln an; ein Selbstupdate schreibt nicht mehr für jede Zeile die ganze Tabelle nach.
  • Eine Adressänderung eines DNS-Nodes löst einen Rollout aus, nicht einen je Zone, und der Start der Control Plane wartet nicht mehr auf den Abgleich aller Zonen.
  • Die Aufgabenliste eines Kunden ist vollständig, auch wenn andere Kunden mehr Aufgaben haben.
  • Die SSH-Übersicht lädt auf Nodes mit vielen Anmeldeversuchen nicht mehr Hunderte Megabyte Journal in den Speicher des Agents.
  • Die Seite Komponenten eines Nodes öffnet deutlich schneller, und die Bereiche Composer und Dateien antworten in großen Verzeichnissen schneller.
  • Wer viele Domains kurz hintereinander anlegt, etwa über die API, bekommt nicht mehr ab etwa der hundertsten einen unerwarteten Fehler. Die Rollouts dahinter warteten bisher jeder für sich und liefen über.
  • Eine DNS-Zone, die von Master auf Slave umgestellt wird, erlaubt einem eingetragenen Secondary danach keinen Transfer mehr und benachrichtigt ihn nicht mehr; bisher blieben beide Einstellungen aus ihrer Zeit als Master stehen.
  • Der Bereich Protokolle einer Domain zeigte nur zwei Zeilen. Die Anzeige wächst jetzt mit dem Protokoll bis zur Fensterhöhe, auch auf dem Telefon; lange Zeilen rollen waagerecht, statt umzubrechen.
  • Mail an einen Benutzer des Nodes selbst — etwa die Ausgabe eines Cronjobs an den Unix-User der Subscription — wird wieder zugestellt. Bisher blieb sie mit „hash:/etc/aliases is unavailable“ in der Warteschlange liegen und füllte das Mailprotokoll alle paar Minuten mit Warnungen. Was dort schon wartet, stellt Postfix beim nächsten Versuch nach /var/mail/<user> zu.
  • Scheitert die Installation von WordPress, Nextcloud oder Matomo, bleibt keine Datenbank mehr auf dem Node zurück. Bisher blieb sie unsichtbar liegen, und ein zweiter Versuch auf derselben Subscription bekam sie samt altem Inhalt zurück — Nextcloud brach dann mit „The Login is already being used“ ab.
  • Bricht ein Systembefehl auf dem Node ab, weil seine Zeitgrenze erreicht ist oder ein Signal ihn beendet, steht der Grund jetzt in der Meldung. Bisher endete etwa die Mail „Suchlauf nach Schadsoftware fehlgeschlagen“ mit „(exit -1):“ und einer leeren Fehlerausgabe.
  • Sicherheit des Agents: Die HTTP/2-Anbindung zwischen Agent und Control Plane hatte fünf bekannte Lücken, darunter CVE-2026-78669 — möglich waren Abstürze, Speichererschöpfung durch Trailer-Header und überhöhte CPU-Last. Der Agent bringt jetzt die bereinigten Fassungen von golang.org/x/net (0.60.0) und golang.org/x/crypto (0.57.0) mit. Zu tun ist nichts; das Update des Agents genügt.

Eingriffe am Node

  • W-002-nginx-dateigrenze — legt /etc/systemd/system/nginx.service.d/kastra-dateigrenze.conf mit LimitNOFILE=65535 an und startet nginx einmal neu, damit die Grenze gilt (ein Neuladen übernimmt sie nicht). Läuft nginx schon mit der Grenze, passiert nichts. Zurücknehmbar: Datei löschen, systemctl daemon-reload, nginx neu starten.

Rendert anders

  • nginx-vhost — nur bei einer Domain mit Laufzeit Node.js oder Proxy, die aus der Zeit vor dem Wechsel noch den Mischbetrieb trug: die location-Blöcke ihrer Routen entfallen. Sie hängt ganz an ihrer Anwendung.
  • podman-unit — jede Unit /etc/systemd/system/kastra-podman-sub<n>-<id>.service trägt SyslogIdentifier=kastra-podman-sub<n>-<id>. Die Ausgabe von compose build und compose down steht im Journal unter diesem Namen statt unter podman-compose; journalctl -t kastra-podman-sub<n>-<id> findet sie.
  • postfix-main — nur auf einem Node, dessen Mail-Hostname eine Kundendomain ist: myorigin = localhost und mydestination = localhost.
  • postfix-main — main.cf trägt enable_long_queue_ids = yes.
  • postfix-main — main.cf trägt alias_maps = inline:{ postmaster=root } und ein leeres alias_database; /etc/aliases liest Postfix nicht mehr.
  • crontab — jede Datei /etc/cron.d/kastra-sub<n> trägt am Kopf MAILTO="" und vor jeder aktiven Jobzeile eine eigene MAILTO-Zeile. Jobs mit Mail nur bei Fehler oder nach jedem Lauf laufen über /usr/local/bin/kastra-agent cronlauf.
  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.
  • wildfly-zugriff — neu ist /var/lib/kastra/wildfly-zugriff.json, einmal je Node: die Domains, deren Verzeichnis zuletzt für WildFly freigegeben war. Auf einem Node ohne Freigabe steht dort eine leere Liste.

26.10.11.3

Eingriff am Node Test 75 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).
  • Lange Listen laden seitenweise. Domains, Subscriptions, Kunden, Datenbanken, Maildomains, Zonen, Benutzer und Container zeigen ab 500 Einträgen Mehr laden. Eine Anlage mit weniger Einträgen sieht keinen Unterschied.
  • Das Protokoll einer Aufgabe und die Ausgabe eines Rollouts lassen sich vollständig herunterladen.
  • Mailstatistik. Eine Maildomain hat den Reiter Statistik: was heute, in den letzten 7 und 30 Tagen eingegangen und versendet wurde, was gescheitert ist — unzustellbar, abgewiesen, als Spam abgewiesen — und was gerade wartet, dazu ein Verlauf über 30 Tage und die Zahlen je Postfach, Weiterleitung und Versandzugang. Jede Zahl führt zur Liste der Sendungen dahinter — zugestellt, zurückgestellt, gescheitert, gelöscht, je Empfänger mit Grund, Zahl der Versuche und Sprung ins Protokoll, filterbar nach Zeitraum, Status, Richtung und Adresse. Der Bereich Mailserver eines Nodes zeigt dieselben Zahlen und Sendungen für den ganzen Node, je Maildomain aufgeschlüsselt. Nach dem Update liest jeder Node beim ersten Lauf bis zu 30 Tage nach, soweit sein Journal so weit reicht.
  • Mehrere Sendungen auf einmal. Was noch in der Warteschlange liegt, lässt sich aus der Liste der Sendungen und aus der Warteschlange heraus einzeln, für eine Auswahl per Kästchen oder für alle erneut versuchen oder löschen; im Bereich Mailserver eines Nodes auch anhalten und freigeben. Danach meldet das Panel, wie viele erledigt und wie viele übersprungen wurden — etwa weil eine Sendung inzwischen zugestellt war.
  • Die Aufbewahrung der einzelnen Sendungen stellt KASTRA_MAIL_STATISTIK_SENDUNGEN_TAGE ein (Vorgabe 30 Tage).
  • Alarm bei Stau in der Warteschlange (MAIL_QUEUE_STAU): ab 100 wartenden Sendungen oder wenn eine seit 6 Stunden wartet. Beide Schwellen sind über KASTRA_MAIL_STATISTIK_STAU_ANZAHL und KASTRA_MAIL_STATISTIK_STAU_ALTER_STUNDEN einstellbar.
  • Repositories auf einen Blick. Eine Subscription hat den Bereich Repositories: alle Repositories ihrer Domains in einer Tabelle, je Zeile die Domain, der geholte Commit und der jüngste Commit des Branches bei GitHub. Oben steht, wie viele aktuell sind und wo bei GitHub schon ein neuerer Stand liegt; Nicht aktuelle holen zieht sie in einem Zug nach.
  • Warum ein Container nicht startet, steht im Panel. Der Bereich Container einer Domain nennt den Schritt, an dem der letzte Start gescheitert ist oder gerade steht — Bauen, Starten oder die Gegenprobe —, zeigt die Schritte mit ihrem Ergebnis und die Ausgabe genau dieses Laufs, etwa den Abbruch von npm ci im Bau. Hat systemd nach fünf Versuchen die Startsperre gezogen, steht das dort mit Sperre lösen und neu starten. Die Übersicht unter Container zeigt dieselbe Marke je Domain.

Geändert

  • **Ein Rollout, der nicht ganz rund lief, steht als Mit Warnungen da** statt als Erfolgreich — etwa wenn eine Zeile der Zusatzkonfiguration verworfen wurde oder ein Dienst sich nicht neu laden ließ. Die Meldung nennt die Zahl der Warnungen, das Protokoll die betroffenen Zeilen; die Seite, von der aus ausgerollt wurde, meldet „Ausgerollt, aber mit … Warnungen“.
  • Die Meldung, dass journald die Zeitgrenze des Journals noch nicht gelesen hat, erscheint nur noch in dem Rollout, der sie geändert hat — nicht mehr in jedem.
  • Die Zusatzkonfiguration einer Domain übernimmt jetzt proxy_buffers, proxy_buffer_size und proxy_busy_buffers_size. Bisher wurden die Zeilen beim Ausrollen verworfen; wer hinter einem Reverse Proxy „upstream sent too big header“ sah, konnte die Puffer nicht vergrößern.
  • Cronjobs melden sich per Mail, wenn man es will. Je Cronjob lassen sich ein oder mehrere Empfänger eintragen und wann eine Mail kommt: nur bei Fehler (mit Ausgabe und Rückgabewert), sobald der Befehl etwas ausgibt, nach jedem Lauf oder gar nicht. Einstellbar beim Anlegen und über Mail in der Zeile des Jobs. Bisher ging die Ausgabe an den Unix-Benutzer der Subscription, wo sie niemand las; bestehende Cronjobs stehen nach dem Update auf Keine Mail.
  • Scheitert Neu starten an einer Container-Domain, nennt die Meldung den gescheiterten Schritt, und in den Details steht die Ausgabe des Laufs statt nur „Job failed, see journalctl“.
  • Die Warteschlange einer Maildomain zeigt nur noch deren Sendungen — und Kunden sehen sie jetzt auch; bisher kam für sie nur ein Fehler. Dort lässt sich eine Sendung erneut versuchen oder löschen. Anhalten, Freigeben und Zustellung aller Sendungen erzwingen stehen jetzt im Bereich Mailserver des Nodes, weil sie den ganzen Mailserver betreffen.
  • Postfix vergibt lange Warteschlangenkennungen (enable_long_queue_ids), damit sich eine Kennung über die 30 Tage, die die Sendungen aufbewahrt werden, nicht wiederholt. Mails, die beim Update schon in der Warteschlange liegen, behalten ihre kurze Kennung und werden normal zugestellt.
  • Ein Rollout startet Container und Objekt-Caches nur noch neu, wenn sich ihre Konfiguration geändert hat. Der Rollout einer fremden Domain lässt sie laufen, der Cache bleibt gefüllt. Bisher warf jeder Rollout — auch einer ohne jede Änderung — alle Container und alle Caches des Nodes weg. Eine Änderung nur an der Dockerfile oder an eigenen Dateien der Anwendung baut den Container deshalb beim nächsten Rollout nicht mehr neu. Dafür gibt es Neu starten im Bereich Container.
  • Ein Rollout schreibt, sichert und lädt nur noch, was sich wirklich geändert hat. „Datei(en) geschrieben“ im Aufgabenprotokoll zählt nur diese Dateien, und PHP-FPM wird nur für die Fassungen neu geladen, deren Pools betroffen sind.
  • Der Healthcheck nach dem Rollout prüft die Domains gleichzeitig. Ein Rollout wartet nicht mehr eine Minute je Domain, die nicht antwortet, und eine Anwendung, die mit einem eigenen Fehlercode antwortet, wird nicht mehr viermal abgefragt.
  • Eine Abweichung, die nach der Korrektur sofort wiederkommt, löst nicht mehr alle fünf Minuten einen vollständigen Rollout aus. Der Abstand verdoppelt sich bis zu zwei Stunden; gemeldet wird die Abweichung weiter im gewohnten Takt.
  • Das Panel überträgt beim ersten Aufruf etwa ein Viertel der bisherigen Datenmenge. Skripte, Stilvorlagen und Antworten der API gehen komprimiert hinaus, und die Stilvorlage des Code-Editors lädt erst mit dem Editor. Ein bestehender Panel-Host bekommt die Komprimierung beim Update in seinen nginx-Vhost nachgetragen; die vorherige Fassung bleibt als kastra-panel.conf.vor-gzip daneben liegen.
  • Lange Protokolle und große Verzeichnisse bleiben im Panel flüssig. Angezeigt werden die letzten 1 000 Zeilen eines Protokolls, die letzten 2 000 Zeilen eines Rollouts und die ersten 500 Einträge eines Verzeichnisses; der Rest steht im Download oder wird nachgelegt. Das Protokoll einer Aufgabe öffnet am Ende statt am Anfang.
  • Die Übersicht, die Statusseite und die Container-Seite holen, was sie von den Nodes brauchen, in einer einzigen Anfrage an die Control Plane statt in einer je Node oder je Container.
  • Ein Panel in einem Tab im Hintergrund fragt die Control Plane nicht mehr ab; beim Zurückkommen holt es sofort nach.
  • Angaben wie „vor 3 Minuten“ werden erst beim nächsten Laden der Seite weitergezählt.
  • Die Hinweise in den Verlaufsbalken von Status und Auslastung erscheinen als schlichter Hinweis des Browsers.
  • Das Web-Terminal zeichnet über die Grafikkarte und bleibt auch bei viel Ausgabe flüssig.
  • Mehrere Änderungen an einem Node kurz hintereinander werden zusammen ausgerollt. Jede behält ihre Aufgabe; die erste trägt das Protokoll des Nodes, die übrigen zeigen „Wird zusammen mit Aufgabe … ausgerollt“ und enden mit demselben Ergebnis.

Behoben

  • Das Panel ist auf dem Telefon besser bedienbar.
  • Tabellen (Audit-Log, Firewall, Instanzen, Alarmierung, Aliase) rollen waagerecht, statt Adressen und Marken Zeichen für Zeichen untereinander zu stellen.
  • Hinweise und Fehlermeldungen unter einem Feld brechen auf Telefon und Tablet um, statt mit „…“ abgeschnitten zu bleiben.
  • Auf der Anmeldeseite passen die drei Reiter nebeneinander, ohne Blätterpfeile.
  • In den Bereichen PHP und Webserver einer Domain sind die Feldbeschriftungen nicht mehr oben abgeschnitten.
  • Eingabefelder neben einem Knopf (Alias, Passkey, Passwort, API-Token) gehen in eine eigene Zeile, statt auf eine Handbreit zu schrumpfen; ebenso die Filter im Audit-Log und der Zeitraum unter Sperren.
  • Im Handbuch klappt das Verzeichnis über einem geöffneten Artikel ein.
  • DNS-Einträge zeigen den Namen lesbar, und das iPhone zoomt beim Antippen eines Feldes nicht mehr in die Seite.
  • Im Bereich Komponenten eines Nodes und auf der Statusseite steht bei einem nicht erreichbaren Node die Meldung statt „[object Object]“.
  • Die Übersicht zeigt bei nur einem Node nicht mehr „Ausfallreserve NaN %“.
  • Im Bereich Wartung haben Schalter, Überschriften und Knöpfe wieder Abstand zueinander.
  • Eine Node.js-Anwendung, deren Version auf dem Standard des Nodes steht, zeigt diese Fassung in der Auswahl statt eines leeren Feldes mit dem Hinweis, sie liege nicht auf dem Node.
  • **Der Bereich Anwendung zeigt die Node.js-Anwendung nur noch einmal.** Eine Domain, die mit eingeschaltetem Mischbetrieb von PHP oder Statisch auf Node.js, Proxy oder Container umgestellt wurde, behielt den Mischbetrieb im Hintergrund. Bei Node.js stand die Anwendung dann zweimal untereinander, und die Routen der Domain wurden weiter ausgerollt. Der Wechsel der Laufzeit schaltet den Mischbetrieb jetzt ab; betroffene Domains werden beim Update bereinigt.
  • Dialoge nehmen auf dem Telefon und im Querformat die volle Breite ein. Vorher stand etwa der Dateieditor bei einer Datei mit kurzen Zeilen als schmale Spalte in der Mitte.
  • Dateien lassen sich auf dem Telefon bearbeiten, ohne in die Desktop-Ansicht des Browsers zu wechseln. Auf Telefon und Tablet öffnen Dateimanager, Zusatzkonfiguration, Compose-Datei, composer.json, WildFly-Konfiguration und Fehlerseiten ein einfaches Textfeld über die volle Höhe des Dialogs; Tastatur, Markieren und Einfügen kommen vom Telefon. Syntaxhervorhebung und Zeilennummern gibt es dort nicht mehr — am Rechner bleibt der Editor wie bisher.
  • Auf einem Node mit vielen Domains kommen neue Domains wieder online. Ab etwa 400 Domains durfte nginx nicht mehr genug Dateien offen halten – je Domain gehören zwei Protokolle dazu –, und sein Neuladen brach mit „Too many open files“ ab. nginx lieferte dann still die vorherige Konfiguration weiter; die zuletzt angelegten Domains kannte er nicht, und der Rollout nahm genau sie mit der Meldung Healthcheck fehlgeschlagen wieder zurück. Die Grenze hebt der Eingriff W-002 an (siehe unten).
  • Ein Rollout meldet nicht mehr Erfolg, wenn nginx die neue Konfiguration gar nicht übernommen hat. Bisher galt der Rollout als ausgerollt, sobald das Signal zum Neuladen zugestellt war – ob nginx sie auch annahm, blieb ungeprüft. Jetzt endet er mit NGINX_RELOAD_FAILED, stellt die vorherige Konfiguration wieder her und nennt im Detail die Zeilen aus dem Fehlerprotokoll von nginx, die den Grund tragen.
  • Heißt der Node selbst wie eine Kundendomain (Mail-Hostname kunde.de statt mail.kunde.de), hält Postfix diese Domain nicht mehr für lokal. Bisher lehnte eine Domain im Modus nur Versand jede Mail an sich selbst mit „User unknown in local recipient table“ ab – etwa die Testmail eines WordPress an info@kunde.de –, statt sie zum Postfach beim bisherigen Anbieter zu schicken.
  • Eine PHP-Domain, die auf Node.js, Container oder Proxy umgestellt wird, geht nicht mehr weiter an Apache. Bisher blieb der Webserver-Modus nginx + Apache stehen, und Besucher bekamen den Quelltext der index.php statt der Anwendung zu sehen. Domains, die schon so umgestellt wurden, richtet das Update selbst.
  • Ein Download aus dem Dateimanager belastet die Control Plane nicht mehr mit der Dateigröße. Bisher lag eine Datei zweimal vollständig in ihrem Speicher.
  • Ein langsamer oder hängender Node hält Rollout, Terminal und Dateimanager der anderen Nodes nicht mehr an, und offene Protokollfenster legen die Control Plane nicht mehr still.
  • Ein Web-Terminal mit viel Ausgabe hält Heartbeat, Rollout-Ergebnisse und Protokolle seines Nodes nicht mehr an.
  • Ein langer nächtlicher Lauf wie der monatliche Wiederherstellungs-Probelauf verzögert die Erkennung ausgefallener Nodes nicht mehr.
  • Das Protokoll eines Rollouts kommt in Stapeln an; ein Selbstupdate schreibt nicht mehr für jede Zeile die ganze Tabelle nach.
  • Eine Adressänderung eines DNS-Nodes löst einen Rollout aus, nicht einen je Zone, und der Start der Control Plane wartet nicht mehr auf den Abgleich aller Zonen.
  • Die Aufgabenliste eines Kunden ist vollständig, auch wenn andere Kunden mehr Aufgaben haben.
  • Die SSH-Übersicht lädt auf Nodes mit vielen Anmeldeversuchen nicht mehr Hunderte Megabyte Journal in den Speicher des Agents.
  • Die Seite Komponenten eines Nodes öffnet deutlich schneller, und die Bereiche Composer und Dateien antworten in großen Verzeichnissen schneller.
  • Wer viele Domains kurz hintereinander anlegt, etwa über die API, bekommt nicht mehr ab etwa der hundertsten einen unerwarteten Fehler. Die Rollouts dahinter warteten bisher jeder für sich und liefen über.
  • Eine DNS-Zone, die von Master auf Slave umgestellt wird, erlaubt einem eingetragenen Secondary danach keinen Transfer mehr und benachrichtigt ihn nicht mehr; bisher blieben beide Einstellungen aus ihrer Zeit als Master stehen.
  • Der Bereich Protokolle einer Domain zeigte nur zwei Zeilen. Die Anzeige wächst jetzt mit dem Protokoll bis zur Fensterhöhe, auch auf dem Telefon; lange Zeilen rollen waagerecht, statt umzubrechen.
  • Mail an einen Benutzer des Nodes selbst — etwa die Ausgabe eines Cronjobs an den Unix-User der Subscription — wird wieder zugestellt. Bisher blieb sie mit „hash:/etc/aliases is unavailable“ in der Warteschlange liegen und füllte das Mailprotokoll alle paar Minuten mit Warnungen. Was dort schon wartet, stellt Postfix beim nächsten Versuch nach /var/mail/<user> zu.
  • Scheitert die Installation von WordPress, Nextcloud oder Matomo, bleibt keine Datenbank mehr auf dem Node zurück. Bisher blieb sie unsichtbar liegen, und ein zweiter Versuch auf derselben Subscription bekam sie samt altem Inhalt zurück — Nextcloud brach dann mit „The Login is already being used“ ab.
  • Bricht ein Systembefehl auf dem Node ab, weil seine Zeitgrenze erreicht ist oder ein Signal ihn beendet, steht der Grund jetzt in der Meldung. Bisher endete etwa die Mail „Suchlauf nach Schadsoftware fehlgeschlagen“ mit „(exit -1):“ und einer leeren Fehlerausgabe.

Eingriffe am Node

  • W-002-nginx-dateigrenze — legt /etc/systemd/system/nginx.service.d/kastra-dateigrenze.conf mit LimitNOFILE=65535 an und startet nginx einmal neu, damit die Grenze gilt (ein Neuladen übernimmt sie nicht). Läuft nginx schon mit der Grenze, passiert nichts. Zurücknehmbar: Datei löschen, systemctl daemon-reload, nginx neu starten.

Rendert anders

  • nginx-vhost — nur bei einer Domain mit Laufzeit Node.js oder Proxy, die aus der Zeit vor dem Wechsel noch den Mischbetrieb trug: die location-Blöcke ihrer Routen entfallen. Sie hängt ganz an ihrer Anwendung.
  • podman-unit — jede Unit /etc/systemd/system/kastra-podman-sub<n>-<id>.service trägt SyslogIdentifier=kastra-podman-sub<n>-<id>. Die Ausgabe von compose build und compose down steht im Journal unter diesem Namen statt unter podman-compose; journalctl -t kastra-podman-sub<n>-<id> findet sie.
  • postfix-main — nur auf einem Node, dessen Mail-Hostname eine Kundendomain ist: myorigin = localhost und mydestination = localhost.
  • postfix-main — main.cf trägt enable_long_queue_ids = yes.
  • postfix-main — main.cf trägt alias_maps = inline:{ postmaster=root } und ein leeres alias_database; /etc/aliases liest Postfix nicht mehr.
  • crontab — jede Datei /etc/cron.d/kastra-sub<n> trägt am Kopf MAILTO="" und vor jeder aktiven Jobzeile eine eigene MAILTO-Zeile. Jobs mit Mail nur bei Fehler oder nach jedem Lauf laufen über /usr/local/bin/kastra-agent cronlauf.
  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.
  • wildfly-zugriff — neu ist /var/lib/kastra/wildfly-zugriff.json, einmal je Node: die Domains, deren Verzeichnis zuletzt für WildFly freigegeben war. Auf einem Node ohne Freigabe steht dort eine leere Liste.

26.10.08.6

Eingriff am Node Test 73 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).
  • Lange Listen laden seitenweise. Domains, Subscriptions, Kunden, Datenbanken, Maildomains, Zonen, Benutzer und Container zeigen ab 500 Einträgen Mehr laden. Eine Anlage mit weniger Einträgen sieht keinen Unterschied.
  • Das Protokoll einer Aufgabe und die Ausgabe eines Rollouts lassen sich vollständig herunterladen.
  • Mailstatistik. Eine Maildomain hat den Reiter Statistik: was heute, in den letzten 7 und 30 Tagen eingegangen und versendet wurde, was gescheitert ist — unzustellbar, abgewiesen, als Spam abgewiesen — und was gerade wartet, dazu ein Verlauf über 30 Tage und die Zahlen je Postfach, Weiterleitung und Versandzugang. Jede Zahl führt zur Liste der Sendungen dahinter — zugestellt, zurückgestellt, gescheitert, gelöscht, je Empfänger mit Grund, Zahl der Versuche und Sprung ins Protokoll, filterbar nach Zeitraum, Status, Richtung und Adresse. Der Bereich Mailserver eines Nodes zeigt dieselben Zahlen und Sendungen für den ganzen Node, je Maildomain aufgeschlüsselt. Nach dem Update liest jeder Node beim ersten Lauf bis zu 30 Tage nach, soweit sein Journal so weit reicht.
  • Mehrere Sendungen auf einmal. Was noch in der Warteschlange liegt, lässt sich aus der Liste der Sendungen und aus der Warteschlange heraus einzeln, für eine Auswahl per Kästchen oder für alle erneut versuchen oder löschen; im Bereich Mailserver eines Nodes auch anhalten und freigeben. Danach meldet das Panel, wie viele erledigt und wie viele übersprungen wurden — etwa weil eine Sendung inzwischen zugestellt war.
  • Die Aufbewahrung der einzelnen Sendungen stellt KASTRA_MAIL_STATISTIK_SENDUNGEN_TAGE ein (Vorgabe 30 Tage).
  • Alarm bei Stau in der Warteschlange (MAIL_QUEUE_STAU): ab 100 wartenden Sendungen oder wenn eine seit 6 Stunden wartet. Beide Schwellen sind über KASTRA_MAIL_STATISTIK_STAU_ANZAHL und KASTRA_MAIL_STATISTIK_STAU_ALTER_STUNDEN einstellbar.
  • Repositories auf einen Blick. Eine Subscription hat den Bereich Repositories: alle Repositories ihrer Domains in einer Tabelle, je Zeile die Domain, der geholte Commit und der jüngste Commit des Branches bei GitHub. Oben steht, wie viele aktuell sind und wo bei GitHub schon ein neuerer Stand liegt; Nicht aktuelle holen zieht sie in einem Zug nach.
  • Warum ein Container nicht startet, steht im Panel. Der Bereich Container einer Domain nennt den Schritt, an dem der letzte Start gescheitert ist oder gerade steht — Bauen, Starten oder die Gegenprobe —, zeigt die Schritte mit ihrem Ergebnis und die Ausgabe genau dieses Laufs, etwa den Abbruch von npm ci im Bau. Hat systemd nach fünf Versuchen die Startsperre gezogen, steht das dort mit Sperre lösen und neu starten. Die Übersicht unter Container zeigt dieselbe Marke je Domain.

Geändert

  • **Ein Rollout, der nicht ganz rund lief, steht als Mit Warnungen da** statt als Erfolgreich — etwa wenn eine Zeile der Zusatzkonfiguration verworfen wurde oder ein Dienst sich nicht neu laden ließ. Die Meldung nennt die Zahl der Warnungen, das Protokoll die betroffenen Zeilen; die Seite, von der aus ausgerollt wurde, meldet „Ausgerollt, aber mit … Warnungen“.
  • Die Meldung, dass journald die Zeitgrenze des Journals noch nicht gelesen hat, erscheint nur noch in dem Rollout, der sie geändert hat — nicht mehr in jedem.
  • Die Zusatzkonfiguration einer Domain übernimmt jetzt proxy_buffers, proxy_buffer_size und proxy_busy_buffers_size. Bisher wurden die Zeilen beim Ausrollen verworfen; wer hinter einem Reverse Proxy „upstream sent too big header“ sah, konnte die Puffer nicht vergrößern.
  • Cronjobs melden sich per Mail, wenn man es will. Je Cronjob lassen sich ein oder mehrere Empfänger eintragen und wann eine Mail kommt: nur bei Fehler (mit Ausgabe und Rückgabewert), sobald der Befehl etwas ausgibt, nach jedem Lauf oder gar nicht. Einstellbar beim Anlegen und über Mail in der Zeile des Jobs. Bisher ging die Ausgabe an den Unix-Benutzer der Subscription, wo sie niemand las; bestehende Cronjobs stehen nach dem Update auf Keine Mail.
  • Scheitert Neu starten an einer Container-Domain, nennt die Meldung den gescheiterten Schritt, und in den Details steht die Ausgabe des Laufs statt nur „Job failed, see journalctl“.
  • Die Warteschlange einer Maildomain zeigt nur noch deren Sendungen — und Kunden sehen sie jetzt auch; bisher kam für sie nur ein Fehler. Dort lässt sich eine Sendung erneut versuchen oder löschen. Anhalten, Freigeben und Zustellung aller Sendungen erzwingen stehen jetzt im Bereich Mailserver des Nodes, weil sie den ganzen Mailserver betreffen.
  • Postfix vergibt lange Warteschlangenkennungen (enable_long_queue_ids), damit sich eine Kennung über die 30 Tage, die die Sendungen aufbewahrt werden, nicht wiederholt. Mails, die beim Update schon in der Warteschlange liegen, behalten ihre kurze Kennung und werden normal zugestellt.
  • Ein Rollout startet Container und Objekt-Caches nur noch neu, wenn sich ihre Konfiguration geändert hat. Der Rollout einer fremden Domain lässt sie laufen, der Cache bleibt gefüllt. Bisher warf jeder Rollout — auch einer ohne jede Änderung — alle Container und alle Caches des Nodes weg. Eine Änderung nur an der Dockerfile oder an eigenen Dateien der Anwendung baut den Container deshalb beim nächsten Rollout nicht mehr neu. Dafür gibt es Neu starten im Bereich Container.
  • Ein Rollout schreibt, sichert und lädt nur noch, was sich wirklich geändert hat. „Datei(en) geschrieben“ im Aufgabenprotokoll zählt nur diese Dateien, und PHP-FPM wird nur für die Fassungen neu geladen, deren Pools betroffen sind.
  • Der Healthcheck nach dem Rollout prüft die Domains gleichzeitig. Ein Rollout wartet nicht mehr eine Minute je Domain, die nicht antwortet, und eine Anwendung, die mit einem eigenen Fehlercode antwortet, wird nicht mehr viermal abgefragt.
  • Eine Abweichung, die nach der Korrektur sofort wiederkommt, löst nicht mehr alle fünf Minuten einen vollständigen Rollout aus. Der Abstand verdoppelt sich bis zu zwei Stunden; gemeldet wird die Abweichung weiter im gewohnten Takt.
  • Das Panel überträgt beim ersten Aufruf etwa ein Viertel der bisherigen Datenmenge. Skripte, Stilvorlagen und Antworten der API gehen komprimiert hinaus, und die Stilvorlage des Code-Editors lädt erst mit dem Editor. Ein bestehender Panel-Host bekommt die Komprimierung beim Update in seinen nginx-Vhost nachgetragen; die vorherige Fassung bleibt als kastra-panel.conf.vor-gzip daneben liegen.
  • Lange Protokolle und große Verzeichnisse bleiben im Panel flüssig. Angezeigt werden die letzten 1 000 Zeilen eines Protokolls, die letzten 2 000 Zeilen eines Rollouts und die ersten 500 Einträge eines Verzeichnisses; der Rest steht im Download oder wird nachgelegt. Das Protokoll einer Aufgabe öffnet am Ende statt am Anfang.
  • Die Übersicht, die Statusseite und die Container-Seite holen, was sie von den Nodes brauchen, in einer einzigen Anfrage an die Control Plane statt in einer je Node oder je Container.
  • Ein Panel in einem Tab im Hintergrund fragt die Control Plane nicht mehr ab; beim Zurückkommen holt es sofort nach.
  • Angaben wie „vor 3 Minuten“ werden erst beim nächsten Laden der Seite weitergezählt.
  • Die Hinweise in den Verlaufsbalken von Status und Auslastung erscheinen als schlichter Hinweis des Browsers.
  • Das Web-Terminal zeichnet über die Grafikkarte und bleibt auch bei viel Ausgabe flüssig.
  • Mehrere Änderungen an einem Node kurz hintereinander werden zusammen ausgerollt. Jede behält ihre Aufgabe; die erste trägt das Protokoll des Nodes, die übrigen zeigen „Wird zusammen mit Aufgabe … ausgerollt“ und enden mit demselben Ergebnis.

Behoben

  • Das Panel ist auf dem Telefon besser bedienbar.
  • Tabellen (Audit-Log, Firewall, Instanzen, Alarmierung, Aliase) rollen waagerecht, statt Adressen und Marken Zeichen für Zeichen untereinander zu stellen.
  • Hinweise und Fehlermeldungen unter einem Feld brechen auf Telefon und Tablet um, statt mit „…“ abgeschnitten zu bleiben.
  • Auf der Anmeldeseite passen die drei Reiter nebeneinander, ohne Blätterpfeile.
  • In den Bereichen PHP und Webserver einer Domain sind die Feldbeschriftungen nicht mehr oben abgeschnitten.
  • Eingabefelder neben einem Knopf (Alias, Passkey, Passwort, API-Token) gehen in eine eigene Zeile, statt auf eine Handbreit zu schrumpfen; ebenso die Filter im Audit-Log und der Zeitraum unter Sperren.
  • Im Handbuch klappt das Verzeichnis über einem geöffneten Artikel ein.
  • DNS-Einträge zeigen den Namen lesbar, und das iPhone zoomt beim Antippen eines Feldes nicht mehr in die Seite.
  • Im Bereich Komponenten eines Nodes und auf der Statusseite steht bei einem nicht erreichbaren Node die Meldung statt „[object Object]“.
  • Die Übersicht zeigt bei nur einem Node nicht mehr „Ausfallreserve NaN %“.
  • Im Bereich Wartung haben Schalter, Überschriften und Knöpfe wieder Abstand zueinander.
  • Eine Node.js-Anwendung, deren Version auf dem Standard des Nodes steht, zeigt diese Fassung in der Auswahl statt eines leeren Feldes mit dem Hinweis, sie liege nicht auf dem Node.
  • **Der Bereich Anwendung zeigt die Node.js-Anwendung nur noch einmal.** Eine Domain, die mit eingeschaltetem Mischbetrieb von PHP oder Statisch auf Node.js, Proxy oder Container umgestellt wurde, behielt den Mischbetrieb im Hintergrund. Bei Node.js stand die Anwendung dann zweimal untereinander, und die Routen der Domain wurden weiter ausgerollt. Der Wechsel der Laufzeit schaltet den Mischbetrieb jetzt ab; betroffene Domains werden beim Update bereinigt.
  • Dialoge nehmen auf dem Telefon und im Querformat die volle Breite ein. Vorher stand etwa der Dateieditor bei einer Datei mit kurzen Zeilen als schmale Spalte in der Mitte.
  • Dateien lassen sich auf dem Telefon bearbeiten, ohne in die Desktop-Ansicht des Browsers zu wechseln. Auf Telefon und Tablet öffnen Dateimanager, Zusatzkonfiguration, Compose-Datei, composer.json, WildFly-Konfiguration und Fehlerseiten ein einfaches Textfeld über die volle Höhe des Dialogs; Tastatur, Markieren und Einfügen kommen vom Telefon. Syntaxhervorhebung und Zeilennummern gibt es dort nicht mehr — am Rechner bleibt der Editor wie bisher.
  • Auf einem Node mit vielen Domains kommen neue Domains wieder online. Ab etwa 400 Domains durfte nginx nicht mehr genug Dateien offen halten – je Domain gehören zwei Protokolle dazu –, und sein Neuladen brach mit „Too many open files“ ab. nginx lieferte dann still die vorherige Konfiguration weiter; die zuletzt angelegten Domains kannte er nicht, und der Rollout nahm genau sie mit der Meldung Healthcheck fehlgeschlagen wieder zurück. Die Grenze hebt der Eingriff W-002 an (siehe unten).
  • Ein Rollout meldet nicht mehr Erfolg, wenn nginx die neue Konfiguration gar nicht übernommen hat. Bisher galt der Rollout als ausgerollt, sobald das Signal zum Neuladen zugestellt war – ob nginx sie auch annahm, blieb ungeprüft. Jetzt endet er mit NGINX_RELOAD_FAILED, stellt die vorherige Konfiguration wieder her und nennt im Detail die Zeilen aus dem Fehlerprotokoll von nginx, die den Grund tragen.
  • Heißt der Node selbst wie eine Kundendomain (Mail-Hostname kunde.de statt mail.kunde.de), hält Postfix diese Domain nicht mehr für lokal. Bisher lehnte eine Domain im Modus nur Versand jede Mail an sich selbst mit „User unknown in local recipient table“ ab – etwa die Testmail eines WordPress an info@kunde.de –, statt sie zum Postfach beim bisherigen Anbieter zu schicken.
  • Eine PHP-Domain, die auf Node.js, Container oder Proxy umgestellt wird, geht nicht mehr weiter an Apache. Bisher blieb der Webserver-Modus nginx + Apache stehen, und Besucher bekamen den Quelltext der index.php statt der Anwendung zu sehen. Domains, die schon so umgestellt wurden, richtet das Update selbst.
  • Ein Download aus dem Dateimanager belastet die Control Plane nicht mehr mit der Dateigröße. Bisher lag eine Datei zweimal vollständig in ihrem Speicher.
  • Ein langsamer oder hängender Node hält Rollout, Terminal und Dateimanager der anderen Nodes nicht mehr an, und offene Protokollfenster legen die Control Plane nicht mehr still.
  • Ein Web-Terminal mit viel Ausgabe hält Heartbeat, Rollout-Ergebnisse und Protokolle seines Nodes nicht mehr an.
  • Ein langer nächtlicher Lauf wie der monatliche Wiederherstellungs-Probelauf verzögert die Erkennung ausgefallener Nodes nicht mehr.
  • Das Protokoll eines Rollouts kommt in Stapeln an; ein Selbstupdate schreibt nicht mehr für jede Zeile die ganze Tabelle nach.
  • Eine Adressänderung eines DNS-Nodes löst einen Rollout aus, nicht einen je Zone, und der Start der Control Plane wartet nicht mehr auf den Abgleich aller Zonen.
  • Die Aufgabenliste eines Kunden ist vollständig, auch wenn andere Kunden mehr Aufgaben haben.
  • Die SSH-Übersicht lädt auf Nodes mit vielen Anmeldeversuchen nicht mehr Hunderte Megabyte Journal in den Speicher des Agents.
  • Die Seite Komponenten eines Nodes öffnet deutlich schneller, und die Bereiche Composer und Dateien antworten in großen Verzeichnissen schneller.
  • Wer viele Domains kurz hintereinander anlegt, etwa über die API, bekommt nicht mehr ab etwa der hundertsten einen unerwarteten Fehler. Die Rollouts dahinter warteten bisher jeder für sich und liefen über.
  • Eine DNS-Zone, die von Master auf Slave umgestellt wird, erlaubt einem eingetragenen Secondary danach keinen Transfer mehr und benachrichtigt ihn nicht mehr; bisher blieben beide Einstellungen aus ihrer Zeit als Master stehen.
  • Der Bereich Protokolle einer Domain zeigte nur zwei Zeilen. Die Anzeige wächst jetzt mit dem Protokoll bis zur Fensterhöhe, auch auf dem Telefon; lange Zeilen rollen waagerecht, statt umzubrechen.
  • Mail an einen Benutzer des Nodes selbst — etwa die Ausgabe eines Cronjobs an den Unix-User der Subscription — wird wieder zugestellt. Bisher blieb sie mit „hash:/etc/aliases is unavailable“ in der Warteschlange liegen und füllte das Mailprotokoll alle paar Minuten mit Warnungen. Was dort schon wartet, stellt Postfix beim nächsten Versuch nach /var/mail/<user> zu.

Eingriffe am Node

  • W-002-nginx-dateigrenze — legt /etc/systemd/system/nginx.service.d/kastra-dateigrenze.conf mit LimitNOFILE=65535 an und startet nginx einmal neu, damit die Grenze gilt (ein Neuladen übernimmt sie nicht). Läuft nginx schon mit der Grenze, passiert nichts. Zurücknehmbar: Datei löschen, systemctl daemon-reload, nginx neu starten.

Rendert anders

  • nginx-vhost — nur bei einer Domain mit Laufzeit Node.js oder Proxy, die aus der Zeit vor dem Wechsel noch den Mischbetrieb trug: die location-Blöcke ihrer Routen entfallen. Sie hängt ganz an ihrer Anwendung.
  • podman-unit — jede Unit /etc/systemd/system/kastra-podman-sub<n>-<id>.service trägt SyslogIdentifier=kastra-podman-sub<n>-<id>. Die Ausgabe von compose build und compose down steht im Journal unter diesem Namen statt unter podman-compose; journalctl -t kastra-podman-sub<n>-<id> findet sie.
  • postfix-main — nur auf einem Node, dessen Mail-Hostname eine Kundendomain ist: myorigin = localhost und mydestination = localhost.
  • postfix-main — main.cf trägt enable_long_queue_ids = yes.
  • postfix-main — main.cf trägt alias_maps = inline:{ postmaster=root } und ein leeres alias_database; /etc/aliases liest Postfix nicht mehr.
  • crontab — jede Datei /etc/cron.d/kastra-sub<n> trägt am Kopf MAILTO="" und vor jeder aktiven Jobzeile eine eigene MAILTO-Zeile. Jobs mit Mail nur bei Fehler oder nach jedem Lauf laufen über /usr/local/bin/kastra-agent cronlauf.
  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.
  • wildfly-zugriff — neu ist /var/lib/kastra/wildfly-zugriff.json, einmal je Node: die Domains, deren Verzeichnis zuletzt für WildFly freigegeben war. Auf einem Node ohne Freigabe steht dort eine leere Liste.

26.10.08.5

Eingriff am Node Test 72 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).
  • Lange Listen laden seitenweise. Domains, Subscriptions, Kunden, Datenbanken, Maildomains, Zonen, Benutzer und Container zeigen ab 500 Einträgen Mehr laden. Eine Anlage mit weniger Einträgen sieht keinen Unterschied.
  • Das Protokoll einer Aufgabe und die Ausgabe eines Rollouts lassen sich vollständig herunterladen.
  • Mailstatistik. Eine Maildomain hat den Reiter Statistik: was heute, in den letzten 7 und 30 Tagen eingegangen und versendet wurde, was gescheitert ist — unzustellbar, abgewiesen, als Spam abgewiesen — und was gerade wartet, dazu ein Verlauf über 30 Tage und die Zahlen je Postfach, Weiterleitung und Versandzugang. Jede Zahl führt zur Liste der Sendungen dahinter — zugestellt, zurückgestellt, gescheitert, gelöscht, je Empfänger mit Grund, Zahl der Versuche und Sprung ins Protokoll, filterbar nach Zeitraum, Status, Richtung und Adresse. Der Bereich Mailserver eines Nodes zeigt dieselben Zahlen und Sendungen für den ganzen Node, je Maildomain aufgeschlüsselt. Nach dem Update liest jeder Node beim ersten Lauf bis zu 30 Tage nach, soweit sein Journal so weit reicht.
  • Mehrere Sendungen auf einmal. Was noch in der Warteschlange liegt, lässt sich aus der Liste der Sendungen und aus der Warteschlange heraus einzeln, für eine Auswahl per Kästchen oder für alle erneut versuchen oder löschen; im Bereich Mailserver eines Nodes auch anhalten und freigeben. Danach meldet das Panel, wie viele erledigt und wie viele übersprungen wurden — etwa weil eine Sendung inzwischen zugestellt war.
  • Die Aufbewahrung der einzelnen Sendungen stellt KASTRA_MAIL_STATISTIK_SENDUNGEN_TAGE ein (Vorgabe 30 Tage).
  • Alarm bei Stau in der Warteschlange (MAIL_QUEUE_STAU): ab 100 wartenden Sendungen oder wenn eine seit 6 Stunden wartet. Beide Schwellen sind über KASTRA_MAIL_STATISTIK_STAU_ANZAHL und KASTRA_MAIL_STATISTIK_STAU_ALTER_STUNDEN einstellbar.
  • Repositories auf einen Blick. Eine Subscription hat den Bereich Repositories: alle Repositories ihrer Domains in einer Tabelle, je Zeile die Domain, der geholte Commit und der jüngste Commit des Branches bei GitHub. Oben steht, wie viele aktuell sind und wo bei GitHub schon ein neuerer Stand liegt; Nicht aktuelle holen zieht sie in einem Zug nach.
  • Warum ein Container nicht startet, steht im Panel. Der Bereich Container einer Domain nennt den Schritt, an dem der letzte Start gescheitert ist oder gerade steht — Bauen, Starten oder die Gegenprobe —, zeigt die Schritte mit ihrem Ergebnis und die Ausgabe genau dieses Laufs, etwa den Abbruch von npm ci im Bau. Hat systemd nach fünf Versuchen die Startsperre gezogen, steht das dort mit Sperre lösen und neu starten. Die Übersicht unter Container zeigt dieselbe Marke je Domain.

Geändert

  • **Ein Rollout, der nicht ganz rund lief, steht als Mit Warnungen da** statt als Erfolgreich — etwa wenn eine Zeile der Zusatzkonfiguration verworfen wurde oder ein Dienst sich nicht neu laden ließ. Die Meldung nennt die Zahl der Warnungen, das Protokoll die betroffenen Zeilen; die Seite, von der aus ausgerollt wurde, meldet „Ausgerollt, aber mit … Warnungen“.
  • Die Meldung, dass journald die Zeitgrenze des Journals noch nicht gelesen hat, erscheint nur noch in dem Rollout, der sie geändert hat — nicht mehr in jedem.
  • Die Zusatzkonfiguration einer Domain übernimmt jetzt proxy_buffers, proxy_buffer_size und proxy_busy_buffers_size. Bisher wurden die Zeilen beim Ausrollen verworfen; wer hinter einem Reverse Proxy „upstream sent too big header“ sah, konnte die Puffer nicht vergrößern.
  • Cronjobs melden sich per Mail, wenn man es will. Je Cronjob lassen sich ein oder mehrere Empfänger eintragen und wann eine Mail kommt: nur bei Fehler (mit Ausgabe und Rückgabewert), sobald der Befehl etwas ausgibt, nach jedem Lauf oder gar nicht. Einstellbar beim Anlegen und über Mail in der Zeile des Jobs. Bisher ging die Ausgabe an den Unix-Benutzer der Subscription, wo sie niemand las; bestehende Cronjobs stehen nach dem Update auf Keine Mail.
  • Scheitert Neu starten an einer Container-Domain, nennt die Meldung den gescheiterten Schritt, und in den Details steht die Ausgabe des Laufs statt nur „Job failed, see journalctl“.
  • Die Warteschlange einer Maildomain zeigt nur noch deren Sendungen — und Kunden sehen sie jetzt auch; bisher kam für sie nur ein Fehler. Dort lässt sich eine Sendung erneut versuchen oder löschen. Anhalten, Freigeben und Zustellung aller Sendungen erzwingen stehen jetzt im Bereich Mailserver des Nodes, weil sie den ganzen Mailserver betreffen.
  • Postfix vergibt lange Warteschlangenkennungen (enable_long_queue_ids), damit sich eine Kennung über die 30 Tage, die die Sendungen aufbewahrt werden, nicht wiederholt. Mails, die beim Update schon in der Warteschlange liegen, behalten ihre kurze Kennung und werden normal zugestellt.
  • Ein Rollout startet Container und Objekt-Caches nur noch neu, wenn sich ihre Konfiguration geändert hat. Der Rollout einer fremden Domain lässt sie laufen, der Cache bleibt gefüllt. Bisher warf jeder Rollout — auch einer ohne jede Änderung — alle Container und alle Caches des Nodes weg. Eine Änderung nur an der Dockerfile oder an eigenen Dateien der Anwendung baut den Container deshalb beim nächsten Rollout nicht mehr neu. Dafür gibt es Neu starten im Bereich Container.
  • Ein Rollout schreibt, sichert und lädt nur noch, was sich wirklich geändert hat. „Datei(en) geschrieben“ im Aufgabenprotokoll zählt nur diese Dateien, und PHP-FPM wird nur für die Fassungen neu geladen, deren Pools betroffen sind.
  • Der Healthcheck nach dem Rollout prüft die Domains gleichzeitig. Ein Rollout wartet nicht mehr eine Minute je Domain, die nicht antwortet, und eine Anwendung, die mit einem eigenen Fehlercode antwortet, wird nicht mehr viermal abgefragt.
  • Eine Abweichung, die nach der Korrektur sofort wiederkommt, löst nicht mehr alle fünf Minuten einen vollständigen Rollout aus. Der Abstand verdoppelt sich bis zu zwei Stunden; gemeldet wird die Abweichung weiter im gewohnten Takt.
  • Das Panel überträgt beim ersten Aufruf etwa ein Viertel der bisherigen Datenmenge. Skripte, Stilvorlagen und Antworten der API gehen komprimiert hinaus, und die Stilvorlage des Code-Editors lädt erst mit dem Editor. Ein bestehender Panel-Host bekommt die Komprimierung beim Update in seinen nginx-Vhost nachgetragen; die vorherige Fassung bleibt als kastra-panel.conf.vor-gzip daneben liegen.
  • Lange Protokolle und große Verzeichnisse bleiben im Panel flüssig. Angezeigt werden die letzten 1 000 Zeilen eines Protokolls, die letzten 2 000 Zeilen eines Rollouts und die ersten 500 Einträge eines Verzeichnisses; der Rest steht im Download oder wird nachgelegt. Das Protokoll einer Aufgabe öffnet am Ende statt am Anfang.
  • Die Übersicht, die Statusseite und die Container-Seite holen, was sie von den Nodes brauchen, in einer einzigen Anfrage an die Control Plane statt in einer je Node oder je Container.
  • Ein Panel in einem Tab im Hintergrund fragt die Control Plane nicht mehr ab; beim Zurückkommen holt es sofort nach.
  • Angaben wie „vor 3 Minuten“ werden erst beim nächsten Laden der Seite weitergezählt.
  • Die Hinweise in den Verlaufsbalken von Status und Auslastung erscheinen als schlichter Hinweis des Browsers.
  • Das Web-Terminal zeichnet über die Grafikkarte und bleibt auch bei viel Ausgabe flüssig.
  • Mehrere Änderungen an einem Node kurz hintereinander werden zusammen ausgerollt. Jede behält ihre Aufgabe; die erste trägt das Protokoll des Nodes, die übrigen zeigen „Wird zusammen mit Aufgabe … ausgerollt“ und enden mit demselben Ergebnis.

Behoben

  • Das Panel ist auf dem Telefon besser bedienbar.
  • Tabellen (Audit-Log, Firewall, Instanzen, Alarmierung, Aliase) rollen waagerecht, statt Adressen und Marken Zeichen für Zeichen untereinander zu stellen.
  • Hinweise und Fehlermeldungen unter einem Feld brechen auf Telefon und Tablet um, statt mit „…“ abgeschnitten zu bleiben.
  • Auf der Anmeldeseite passen die drei Reiter nebeneinander, ohne Blätterpfeile.
  • In den Bereichen PHP und Webserver einer Domain sind die Feldbeschriftungen nicht mehr oben abgeschnitten.
  • Eingabefelder neben einem Knopf (Alias, Passkey, Passwort, API-Token) gehen in eine eigene Zeile, statt auf eine Handbreit zu schrumpfen; ebenso die Filter im Audit-Log und der Zeitraum unter Sperren.
  • Im Handbuch klappt das Verzeichnis über einem geöffneten Artikel ein.
  • DNS-Einträge zeigen den Namen lesbar, und das iPhone zoomt beim Antippen eines Feldes nicht mehr in die Seite.
  • Im Bereich Komponenten eines Nodes und auf der Statusseite steht bei einem nicht erreichbaren Node die Meldung statt „[object Object]“.
  • Die Übersicht zeigt bei nur einem Node nicht mehr „Ausfallreserve NaN %“.
  • Im Bereich Wartung haben Schalter, Überschriften und Knöpfe wieder Abstand zueinander.
  • Eine Node.js-Anwendung, deren Version auf dem Standard des Nodes steht, zeigt diese Fassung in der Auswahl statt eines leeren Feldes mit dem Hinweis, sie liege nicht auf dem Node.
  • **Der Bereich Anwendung zeigt die Node.js-Anwendung nur noch einmal.** Eine Domain, die mit eingeschaltetem Mischbetrieb von PHP oder Statisch auf Node.js, Proxy oder Container umgestellt wurde, behielt den Mischbetrieb im Hintergrund. Bei Node.js stand die Anwendung dann zweimal untereinander, und die Routen der Domain wurden weiter ausgerollt. Der Wechsel der Laufzeit schaltet den Mischbetrieb jetzt ab; betroffene Domains werden beim Update bereinigt.
  • Dateien lassen sich auf dem Telefon bearbeiten, ohne in die Desktop-Ansicht des Browsers zu wechseln. Auf Telefon und Tablet öffnen Dateimanager, Zusatzkonfiguration, Compose-Datei, composer.json, WildFly-Konfiguration und Fehlerseiten ein einfaches Textfeld über die volle Höhe des Dialogs; Tastatur, Markieren und Einfügen kommen vom Telefon. Syntaxhervorhebung und Zeilennummern gibt es dort nicht mehr — am Rechner bleibt der Editor wie bisher.
  • Auf einem Node mit vielen Domains kommen neue Domains wieder online. Ab etwa 400 Domains durfte nginx nicht mehr genug Dateien offen halten – je Domain gehören zwei Protokolle dazu –, und sein Neuladen brach mit „Too many open files“ ab. nginx lieferte dann still die vorherige Konfiguration weiter; die zuletzt angelegten Domains kannte er nicht, und der Rollout nahm genau sie mit der Meldung Healthcheck fehlgeschlagen wieder zurück. Die Grenze hebt der Eingriff W-002 an (siehe unten).
  • Ein Rollout meldet nicht mehr Erfolg, wenn nginx die neue Konfiguration gar nicht übernommen hat. Bisher galt der Rollout als ausgerollt, sobald das Signal zum Neuladen zugestellt war – ob nginx sie auch annahm, blieb ungeprüft. Jetzt endet er mit NGINX_RELOAD_FAILED, stellt die vorherige Konfiguration wieder her und nennt im Detail die Zeilen aus dem Fehlerprotokoll von nginx, die den Grund tragen.
  • Heißt der Node selbst wie eine Kundendomain (Mail-Hostname kunde.de statt mail.kunde.de), hält Postfix diese Domain nicht mehr für lokal. Bisher lehnte eine Domain im Modus nur Versand jede Mail an sich selbst mit „User unknown in local recipient table“ ab – etwa die Testmail eines WordPress an info@kunde.de –, statt sie zum Postfach beim bisherigen Anbieter zu schicken.
  • Eine PHP-Domain, die auf Node.js, Container oder Proxy umgestellt wird, geht nicht mehr weiter an Apache. Bisher blieb der Webserver-Modus nginx + Apache stehen, und Besucher bekamen den Quelltext der index.php statt der Anwendung zu sehen. Domains, die schon so umgestellt wurden, richtet das Update selbst.
  • Ein Download aus dem Dateimanager belastet die Control Plane nicht mehr mit der Dateigröße. Bisher lag eine Datei zweimal vollständig in ihrem Speicher.
  • Ein langsamer oder hängender Node hält Rollout, Terminal und Dateimanager der anderen Nodes nicht mehr an, und offene Protokollfenster legen die Control Plane nicht mehr still.
  • Ein Web-Terminal mit viel Ausgabe hält Heartbeat, Rollout-Ergebnisse und Protokolle seines Nodes nicht mehr an.
  • Ein langer nächtlicher Lauf wie der monatliche Wiederherstellungs-Probelauf verzögert die Erkennung ausgefallener Nodes nicht mehr.
  • Das Protokoll eines Rollouts kommt in Stapeln an; ein Selbstupdate schreibt nicht mehr für jede Zeile die ganze Tabelle nach.
  • Eine Adressänderung eines DNS-Nodes löst einen Rollout aus, nicht einen je Zone, und der Start der Control Plane wartet nicht mehr auf den Abgleich aller Zonen.
  • Die Aufgabenliste eines Kunden ist vollständig, auch wenn andere Kunden mehr Aufgaben haben.
  • Die SSH-Übersicht lädt auf Nodes mit vielen Anmeldeversuchen nicht mehr Hunderte Megabyte Journal in den Speicher des Agents.
  • Die Seite Komponenten eines Nodes öffnet deutlich schneller, und die Bereiche Composer und Dateien antworten in großen Verzeichnissen schneller.
  • Wer viele Domains kurz hintereinander anlegt, etwa über die API, bekommt nicht mehr ab etwa der hundertsten einen unerwarteten Fehler. Die Rollouts dahinter warteten bisher jeder für sich und liefen über.
  • Eine DNS-Zone, die von Master auf Slave umgestellt wird, erlaubt einem eingetragenen Secondary danach keinen Transfer mehr und benachrichtigt ihn nicht mehr; bisher blieben beide Einstellungen aus ihrer Zeit als Master stehen.
  • Der Bereich Protokolle einer Domain zeigte nur zwei Zeilen. Die Anzeige wächst jetzt mit dem Protokoll bis zur Fensterhöhe, auch auf dem Telefon; lange Zeilen rollen waagerecht, statt umzubrechen.
  • Mail an einen Benutzer des Nodes selbst — etwa die Ausgabe eines Cronjobs an den Unix-User der Subscription — wird wieder zugestellt. Bisher blieb sie mit „hash:/etc/aliases is unavailable“ in der Warteschlange liegen und füllte das Mailprotokoll alle paar Minuten mit Warnungen. Was dort schon wartet, stellt Postfix beim nächsten Versuch nach /var/mail/<user> zu.

Eingriffe am Node

  • W-002-nginx-dateigrenze — legt /etc/systemd/system/nginx.service.d/kastra-dateigrenze.conf mit LimitNOFILE=65535 an und startet nginx einmal neu, damit die Grenze gilt (ein Neuladen übernimmt sie nicht). Läuft nginx schon mit der Grenze, passiert nichts. Zurücknehmbar: Datei löschen, systemctl daemon-reload, nginx neu starten.

Rendert anders

  • nginx-vhost — nur bei einer Domain mit Laufzeit Node.js oder Proxy, die aus der Zeit vor dem Wechsel noch den Mischbetrieb trug: die location-Blöcke ihrer Routen entfallen. Sie hängt ganz an ihrer Anwendung.
  • podman-unit — jede Unit /etc/systemd/system/kastra-podman-sub<n>-<id>.service trägt SyslogIdentifier=kastra-podman-sub<n>-<id>. Die Ausgabe von compose build und compose down steht im Journal unter diesem Namen statt unter podman-compose; journalctl -t kastra-podman-sub<n>-<id> findet sie.
  • postfix-main — nur auf einem Node, dessen Mail-Hostname eine Kundendomain ist: myorigin = localhost und mydestination = localhost.
  • postfix-main — main.cf trägt enable_long_queue_ids = yes.
  • postfix-main — main.cf trägt alias_maps = inline:{ postmaster=root } und ein leeres alias_database; /etc/aliases liest Postfix nicht mehr.
  • crontab — jede Datei /etc/cron.d/kastra-sub<n> trägt am Kopf MAILTO="" und vor jeder aktiven Jobzeile eine eigene MAILTO-Zeile. Jobs mit Mail nur bei Fehler oder nach jedem Lauf laufen über /usr/local/bin/kastra-agent cronlauf.
  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.
  • wildfly-zugriff — neu ist /var/lib/kastra/wildfly-zugriff.json, einmal je Node: die Domains, deren Verzeichnis zuletzt für WildFly freigegeben war. Auf einem Node ohne Freigabe steht dort eine leere Liste.

26.09.22.3

Normal Test 53 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).
  • Lange Listen laden seitenweise. Domains, Subscriptions, Kunden, Datenbanken, Maildomains, Zonen, Benutzer und Container zeigen ab 500 Einträgen Mehr laden. Eine Anlage mit weniger Einträgen sieht keinen Unterschied.
  • Das Protokoll einer Aufgabe und die Ausgabe eines Rollouts lassen sich vollständig herunterladen.
  • Mailstatistik. Eine Maildomain hat den Reiter Statistik: was heute, in den letzten 7 und 30 Tagen eingegangen und versendet wurde, was gescheitert ist — unzustellbar, abgewiesen, als Spam abgewiesen — und was gerade wartet, dazu ein Verlauf über 30 Tage und die Zahlen je Postfach, Weiterleitung und Versandzugang. Jede Zahl führt zur Liste der Sendungen dahinter — zugestellt, zurückgestellt, gescheitert, gelöscht, je Empfänger mit Grund, Zahl der Versuche und Sprung ins Protokoll, filterbar nach Zeitraum, Status, Richtung und Adresse. Der Bereich Mailserver eines Nodes zeigt dieselben Zahlen und Sendungen für den ganzen Node, je Maildomain aufgeschlüsselt. Nach dem Update liest jeder Node beim ersten Lauf bis zu 30 Tage nach, soweit sein Journal so weit reicht.
  • Mehrere Sendungen auf einmal. Was noch in der Warteschlange liegt, lässt sich aus der Liste der Sendungen und aus der Warteschlange heraus einzeln, für eine Auswahl per Kästchen oder für alle erneut versuchen oder löschen; im Bereich Mailserver eines Nodes auch anhalten und freigeben. Danach meldet das Panel, wie viele erledigt und wie viele übersprungen wurden — etwa weil eine Sendung inzwischen zugestellt war.
  • Die Aufbewahrung der einzelnen Sendungen stellt KASTRA_MAIL_STATISTIK_SENDUNGEN_TAGE ein (Vorgabe 30 Tage).
  • Alarm bei Stau in der Warteschlange (MAIL_QUEUE_STAU): ab 100 wartenden Sendungen oder wenn eine seit 6 Stunden wartet. Beide Schwellen sind über KASTRA_MAIL_STATISTIK_STAU_ANZAHL und KASTRA_MAIL_STATISTIK_STAU_ALTER_STUNDEN einstellbar.
  • Repositories auf einen Blick. Eine Subscription hat den Bereich Repositories: alle Repositories ihrer Domains in einer Tabelle, je Zeile die Domain, der geholte Commit und der jüngste Commit des Branches bei GitHub. Oben steht, wie viele aktuell sind und wo bei GitHub schon ein neuerer Stand liegt; Nicht aktuelle holen zieht sie in einem Zug nach.
  • Warum ein Container nicht startet, steht im Panel. Der Bereich Container einer Domain nennt den Schritt, an dem der letzte Start gescheitert ist oder gerade steht — Bauen, Starten oder die Gegenprobe —, zeigt die Schritte mit ihrem Ergebnis und die Ausgabe genau dieses Laufs, etwa den Abbruch von npm ci im Bau. Hat systemd nach fünf Versuchen die Startsperre gezogen, steht das dort mit Sperre lösen und neu starten. Die Übersicht unter Container zeigt dieselbe Marke je Domain.

Geändert

  • **Ein Rollout, der nicht ganz rund lief, steht als Mit Warnungen da** statt als Erfolgreich — etwa wenn eine Zeile der Zusatzkonfiguration verworfen wurde oder ein Dienst sich nicht neu laden ließ. Die Meldung nennt die Zahl der Warnungen, das Protokoll die betroffenen Zeilen; die Seite, von der aus ausgerollt wurde, meldet „Ausgerollt, aber mit … Warnungen“.
  • Die Meldung, dass journald die Zeitgrenze des Journals noch nicht gelesen hat, erscheint nur noch in dem Rollout, der sie geändert hat — nicht mehr in jedem.
  • Die Zusatzkonfiguration einer Domain übernimmt jetzt proxy_buffers, proxy_buffer_size und proxy_busy_buffers_size. Bisher wurden die Zeilen beim Ausrollen verworfen; wer hinter einem Reverse Proxy „upstream sent too big header“ sah, konnte die Puffer nicht vergrößern.
  • Cronjobs melden sich per Mail, wenn man es will. Je Cronjob lassen sich ein oder mehrere Empfänger eintragen und wann eine Mail kommt: nur bei Fehler (mit Ausgabe und Rückgabewert), sobald der Befehl etwas ausgibt, nach jedem Lauf oder gar nicht. Einstellbar beim Anlegen und über Mail in der Zeile des Jobs. Bisher ging die Ausgabe an den Unix-Benutzer der Subscription, wo sie niemand las; bestehende Cronjobs stehen nach dem Update auf Keine Mail.
  • Scheitert Neu starten an einer Container-Domain, nennt die Meldung den gescheiterten Schritt, und in den Details steht die Ausgabe des Laufs statt nur „Job failed, see journalctl“.
  • Die Warteschlange einer Maildomain zeigt nur noch deren Sendungen — und Kunden sehen sie jetzt auch; bisher kam für sie nur ein Fehler. Dort lässt sich eine Sendung erneut versuchen oder löschen. Anhalten, Freigeben und Zustellung aller Sendungen erzwingen stehen jetzt im Bereich Mailserver des Nodes, weil sie den ganzen Mailserver betreffen.
  • Postfix vergibt lange Warteschlangenkennungen (enable_long_queue_ids), damit sich eine Kennung über die 30 Tage, die die Sendungen aufbewahrt werden, nicht wiederholt. Mails, die beim Update schon in der Warteschlange liegen, behalten ihre kurze Kennung und werden normal zugestellt.
  • Ein Rollout startet Container und Objekt-Caches nur noch neu, wenn sich ihre Konfiguration geändert hat. Der Rollout einer fremden Domain lässt sie laufen, der Cache bleibt gefüllt. Bisher warf jeder Rollout — auch einer ohne jede Änderung — alle Container und alle Caches des Nodes weg. Eine Änderung nur an der Dockerfile oder an eigenen Dateien der Anwendung baut den Container deshalb beim nächsten Rollout nicht mehr neu. Dafür gibt es Neu starten im Bereich Container.
  • Ein Rollout schreibt, sichert und lädt nur noch, was sich wirklich geändert hat. „Datei(en) geschrieben“ im Aufgabenprotokoll zählt nur diese Dateien, und PHP-FPM wird nur für die Fassungen neu geladen, deren Pools betroffen sind.
  • Der Healthcheck nach dem Rollout prüft die Domains gleichzeitig. Ein Rollout wartet nicht mehr eine Minute je Domain, die nicht antwortet, und eine Anwendung, die mit einem eigenen Fehlercode antwortet, wird nicht mehr viermal abgefragt.
  • Eine Abweichung, die nach der Korrektur sofort wiederkommt, löst nicht mehr alle fünf Minuten einen vollständigen Rollout aus. Der Abstand verdoppelt sich bis zu zwei Stunden; gemeldet wird die Abweichung weiter im gewohnten Takt.
  • Das Panel überträgt beim ersten Aufruf etwa ein Viertel der bisherigen Datenmenge. Skripte, Stilvorlagen und Antworten der API gehen komprimiert hinaus, und die Stilvorlage des Code-Editors lädt erst mit dem Editor. Ein bestehender Panel-Host bekommt die Komprimierung beim Update in seinen nginx-Vhost nachgetragen; die vorherige Fassung bleibt als kastra-panel.conf.vor-gzip daneben liegen.
  • Lange Protokolle und große Verzeichnisse bleiben im Panel flüssig. Angezeigt werden die letzten 1 000 Zeilen eines Protokolls, die letzten 2 000 Zeilen eines Rollouts und die ersten 500 Einträge eines Verzeichnisses; der Rest steht im Download oder wird nachgelegt. Das Protokoll einer Aufgabe öffnet am Ende statt am Anfang.
  • Die Übersicht, die Statusseite und die Container-Seite holen, was sie von den Nodes brauchen, in einer einzigen Anfrage an die Control Plane statt in einer je Node oder je Container.
  • Ein Panel in einem Tab im Hintergrund fragt die Control Plane nicht mehr ab; beim Zurückkommen holt es sofort nach.
  • Angaben wie „vor 3 Minuten“ werden erst beim nächsten Laden der Seite weitergezählt.
  • Die Hinweise in den Verlaufsbalken von Status und Auslastung erscheinen als schlichter Hinweis des Browsers.
  • Das Web-Terminal zeichnet über die Grafikkarte und bleibt auch bei viel Ausgabe flüssig.
  • Mehrere Änderungen an einem Node kurz hintereinander werden zusammen ausgerollt. Jede behält ihre Aufgabe; die erste trägt das Protokoll des Nodes, die übrigen zeigen „Wird zusammen mit Aufgabe … ausgerollt“ und enden mit demselben Ergebnis.

Behoben

  • Heißt der Node selbst wie eine Kundendomain (Mail-Hostname kunde.de statt mail.kunde.de), hält Postfix diese Domain nicht mehr für lokal. Bisher lehnte eine Domain im Modus nur Versand jede Mail an sich selbst mit „User unknown in local recipient table“ ab – etwa die Testmail eines WordPress an info@kunde.de –, statt sie zum Postfach beim bisherigen Anbieter zu schicken.
  • Eine PHP-Domain, die auf Node.js, Container oder Proxy umgestellt wird, geht nicht mehr weiter an Apache. Bisher blieb der Webserver-Modus nginx + Apache stehen, und Besucher bekamen den Quelltext der index.php statt der Anwendung zu sehen. Domains, die schon so umgestellt wurden, richtet das Update selbst.
  • Ein Download aus dem Dateimanager belastet die Control Plane nicht mehr mit der Dateigröße. Bisher lag eine Datei zweimal vollständig in ihrem Speicher.
  • Ein langsamer oder hängender Node hält Rollout, Terminal und Dateimanager der anderen Nodes nicht mehr an, und offene Protokollfenster legen die Control Plane nicht mehr still.
  • Ein Web-Terminal mit viel Ausgabe hält Heartbeat, Rollout-Ergebnisse und Protokolle seines Nodes nicht mehr an.
  • Ein langer nächtlicher Lauf wie der monatliche Wiederherstellungs-Probelauf verzögert die Erkennung ausgefallener Nodes nicht mehr.
  • Das Protokoll eines Rollouts kommt in Stapeln an; ein Selbstupdate schreibt nicht mehr für jede Zeile die ganze Tabelle nach.
  • Eine Adressänderung eines DNS-Nodes löst einen Rollout aus, nicht einen je Zone, und der Start der Control Plane wartet nicht mehr auf den Abgleich aller Zonen.
  • Die Aufgabenliste eines Kunden ist vollständig, auch wenn andere Kunden mehr Aufgaben haben.
  • Die SSH-Übersicht lädt auf Nodes mit vielen Anmeldeversuchen nicht mehr Hunderte Megabyte Journal in den Speicher des Agents.
  • Die Seite Komponenten eines Nodes öffnet deutlich schneller, und die Bereiche Composer und Dateien antworten in großen Verzeichnissen schneller.
  • Wer viele Domains kurz hintereinander anlegt, etwa über die API, bekommt nicht mehr ab etwa der hundertsten einen unerwarteten Fehler. Die Rollouts dahinter warteten bisher jeder für sich und liefen über.
  • Eine DNS-Zone, die von Master auf Slave umgestellt wird, erlaubt einem eingetragenen Secondary danach keinen Transfer mehr und benachrichtigt ihn nicht mehr; bisher blieben beide Einstellungen aus ihrer Zeit als Master stehen.
  • Der Bereich Protokolle einer Domain zeigte nur zwei Zeilen. Die Anzeige wächst jetzt mit dem Protokoll bis zur Fensterhöhe, auch auf dem Telefon; lange Zeilen rollen waagerecht, statt umzubrechen.
  • Mail an einen Benutzer des Nodes selbst — etwa die Ausgabe eines Cronjobs an den Unix-User der Subscription — wird wieder zugestellt. Bisher blieb sie mit „hash:/etc/aliases is unavailable“ in der Warteschlange liegen und füllte das Mailprotokoll alle paar Minuten mit Warnungen. Was dort schon wartet, stellt Postfix beim nächsten Versuch nach /var/mail/<user> zu.

Rendert anders

  • postfix-main — nur auf einem Node, dessen Mail-Hostname eine Kundendomain ist: myorigin = localhost und mydestination = localhost.
  • postfix-main — main.cf trägt enable_long_queue_ids = yes.
  • postfix-main — main.cf trägt alias_maps = inline:{ postmaster=root } und ein leeres alias_database; /etc/aliases liest Postfix nicht mehr.
  • crontab — jede Datei /etc/cron.d/kastra-sub<n> trägt am Kopf MAILTO="" und vor jeder aktiven Jobzeile eine eigene MAILTO-Zeile. Jobs mit Mail nur bei Fehler oder nach jedem Lauf laufen über /usr/local/bin/kastra-agent cronlauf.
  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.
  • wildfly-zugriff — neu ist /var/lib/kastra/wildfly-zugriff.json, einmal je Node: die Domains, deren Verzeichnis zuletzt für WildFly freigegeben war. Auf einem Node ohne Freigabe steht dort eine leere Liste.

26.09.21.3

Normal Test 48 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).
  • Lange Listen laden seitenweise. Domains, Subscriptions, Kunden, Datenbanken, Maildomains, Zonen, Benutzer und Container zeigen ab 500 Einträgen Mehr laden. Eine Anlage mit weniger Einträgen sieht keinen Unterschied.
  • Das Protokoll einer Aufgabe und die Ausgabe eines Rollouts lassen sich vollständig herunterladen.
  • Mailstatistik. Eine Maildomain hat den Reiter Statistik: was heute, in den letzten 7 und 30 Tagen eingegangen und versendet wurde, was gescheitert ist — unzustellbar, abgewiesen, als Spam abgewiesen — und was gerade wartet, dazu ein Verlauf über 30 Tage und die Zahlen je Postfach, Weiterleitung und Versandzugang. Jede Zahl führt zur Liste der Sendungen dahinter — zugestellt, zurückgestellt, gescheitert, gelöscht, je Empfänger mit Grund, Zahl der Versuche und Sprung ins Protokoll, filterbar nach Zeitraum, Status, Richtung und Adresse. Der Bereich Mailserver eines Nodes zeigt dieselben Zahlen und Sendungen für den ganzen Node, je Maildomain aufgeschlüsselt. Nach dem Update liest jeder Node beim ersten Lauf bis zu 30 Tage nach, soweit sein Journal so weit reicht.
  • Mehrere Sendungen auf einmal. Was noch in der Warteschlange liegt, lässt sich aus der Liste der Sendungen und aus der Warteschlange heraus einzeln, für eine Auswahl per Kästchen oder für alle erneut versuchen oder löschen; im Bereich Mailserver eines Nodes auch anhalten und freigeben. Danach meldet das Panel, wie viele erledigt und wie viele übersprungen wurden — etwa weil eine Sendung inzwischen zugestellt war.
  • Die Aufbewahrung der einzelnen Sendungen stellt KASTRA_MAIL_STATISTIK_SENDUNGEN_TAGE ein (Vorgabe 30 Tage).
  • Alarm bei Stau in der Warteschlange (MAIL_QUEUE_STAU): ab 100 wartenden Sendungen oder wenn eine seit 6 Stunden wartet. Beide Schwellen sind über KASTRA_MAIL_STATISTIK_STAU_ANZAHL und KASTRA_MAIL_STATISTIK_STAU_ALTER_STUNDEN einstellbar.
  • Repositories auf einen Blick. Eine Subscription hat den Bereich Repositories: alle Repositories ihrer Domains in einer Tabelle, je Zeile die Domain, der geholte Commit und der jüngste Commit des Branches bei GitHub. Oben steht, wie viele aktuell sind und wo bei GitHub schon ein neuerer Stand liegt; Nicht aktuelle holen zieht sie in einem Zug nach.
  • Warum ein Container nicht startet, steht im Panel. Der Bereich Container einer Domain nennt den Schritt, an dem der letzte Start gescheitert ist oder gerade steht — Bauen, Starten oder die Gegenprobe —, zeigt die Schritte mit ihrem Ergebnis und die Ausgabe genau dieses Laufs, etwa den Abbruch von npm ci im Bau. Hat systemd nach fünf Versuchen die Startsperre gezogen, steht das dort mit Sperre lösen und neu starten. Die Übersicht unter Container zeigt dieselbe Marke je Domain.

Geändert

  • Cronjobs melden sich per Mail, wenn man es will. Je Cronjob lassen sich ein oder mehrere Empfänger eintragen und wann eine Mail kommt: nur bei Fehler (mit Ausgabe und Rückgabewert), sobald der Befehl etwas ausgibt, nach jedem Lauf oder gar nicht. Einstellbar beim Anlegen und über Mail in der Zeile des Jobs. Bisher ging die Ausgabe an den Unix-Benutzer der Subscription, wo sie niemand las; bestehende Cronjobs stehen nach dem Update auf Keine Mail.
  • Scheitert Neu starten an einer Container-Domain, nennt die Meldung den gescheiterten Schritt, und in den Details steht die Ausgabe des Laufs statt nur „Job failed, see journalctl“.
  • Die Warteschlange einer Maildomain zeigt nur noch deren Sendungen — und Kunden sehen sie jetzt auch; bisher kam für sie nur ein Fehler. Dort lässt sich eine Sendung erneut versuchen oder löschen. Anhalten, Freigeben und Zustellung aller Sendungen erzwingen stehen jetzt im Bereich Mailserver des Nodes, weil sie den ganzen Mailserver betreffen.
  • Postfix vergibt lange Warteschlangenkennungen (enable_long_queue_ids), damit sich eine Kennung über die 30 Tage, die die Sendungen aufbewahrt werden, nicht wiederholt. Mails, die beim Update schon in der Warteschlange liegen, behalten ihre kurze Kennung und werden normal zugestellt.
  • Ein Rollout startet Container und Objekt-Caches nur noch neu, wenn sich ihre Konfiguration geändert hat. Der Rollout einer fremden Domain lässt sie laufen, der Cache bleibt gefüllt. Bisher warf jeder Rollout — auch einer ohne jede Änderung — alle Container und alle Caches des Nodes weg. Eine Änderung nur an der Dockerfile oder an eigenen Dateien der Anwendung baut den Container deshalb beim nächsten Rollout nicht mehr neu. Dafür gibt es Neu starten im Bereich Container.
  • Ein Rollout schreibt, sichert und lädt nur noch, was sich wirklich geändert hat. „Datei(en) geschrieben“ im Aufgabenprotokoll zählt nur diese Dateien, und PHP-FPM wird nur für die Fassungen neu geladen, deren Pools betroffen sind.
  • Der Healthcheck nach dem Rollout prüft die Domains gleichzeitig. Ein Rollout wartet nicht mehr eine Minute je Domain, die nicht antwortet, und eine Anwendung, die mit einem eigenen Fehlercode antwortet, wird nicht mehr viermal abgefragt.
  • Eine Abweichung, die nach der Korrektur sofort wiederkommt, löst nicht mehr alle fünf Minuten einen vollständigen Rollout aus. Der Abstand verdoppelt sich bis zu zwei Stunden; gemeldet wird die Abweichung weiter im gewohnten Takt.
  • Das Panel überträgt beim ersten Aufruf etwa ein Viertel der bisherigen Datenmenge. Skripte, Stilvorlagen und Antworten der API gehen komprimiert hinaus, und die Stilvorlage des Code-Editors lädt erst mit dem Editor. Ein bestehender Panel-Host bekommt die Komprimierung beim Update in seinen nginx-Vhost nachgetragen; die vorherige Fassung bleibt als kastra-panel.conf.vor-gzip daneben liegen.
  • Lange Protokolle und große Verzeichnisse bleiben im Panel flüssig. Angezeigt werden die letzten 1 000 Zeilen eines Protokolls, die letzten 2 000 Zeilen eines Rollouts und die ersten 500 Einträge eines Verzeichnisses; der Rest steht im Download oder wird nachgelegt. Das Protokoll einer Aufgabe öffnet am Ende statt am Anfang.
  • Die Übersicht, die Statusseite und die Container-Seite holen, was sie von den Nodes brauchen, in einer einzigen Anfrage an die Control Plane statt in einer je Node oder je Container.
  • Ein Panel in einem Tab im Hintergrund fragt die Control Plane nicht mehr ab; beim Zurückkommen holt es sofort nach.
  • Angaben wie „vor 3 Minuten“ werden erst beim nächsten Laden der Seite weitergezählt.
  • Die Hinweise in den Verlaufsbalken von Status und Auslastung erscheinen als schlichter Hinweis des Browsers.
  • Das Web-Terminal zeichnet über die Grafikkarte und bleibt auch bei viel Ausgabe flüssig.
  • Mehrere Änderungen an einem Node kurz hintereinander werden zusammen ausgerollt. Jede behält ihre Aufgabe; die erste trägt das Protokoll des Nodes, die übrigen zeigen „Wird zusammen mit Aufgabe … ausgerollt“ und enden mit demselben Ergebnis.

Behoben

  • Eine PHP-Domain, die auf Node.js, Container oder Proxy umgestellt wird, geht nicht mehr weiter an Apache. Bisher blieb der Webserver-Modus nginx + Apache stehen, und Besucher bekamen den Quelltext der index.php statt der Anwendung zu sehen. Domains, die schon so umgestellt wurden, richtet das Update selbst.
  • Ein Download aus dem Dateimanager belastet die Control Plane nicht mehr mit der Dateigröße. Bisher lag eine Datei zweimal vollständig in ihrem Speicher.
  • Ein langsamer oder hängender Node hält Rollout, Terminal und Dateimanager der anderen Nodes nicht mehr an, und offene Protokollfenster legen die Control Plane nicht mehr still.
  • Ein Web-Terminal mit viel Ausgabe hält Heartbeat, Rollout-Ergebnisse und Protokolle seines Nodes nicht mehr an.
  • Ein langer nächtlicher Lauf wie der monatliche Wiederherstellungs-Probelauf verzögert die Erkennung ausgefallener Nodes nicht mehr.
  • Das Protokoll eines Rollouts kommt in Stapeln an; ein Selbstupdate schreibt nicht mehr für jede Zeile die ganze Tabelle nach.
  • Eine Adressänderung eines DNS-Nodes löst einen Rollout aus, nicht einen je Zone, und der Start der Control Plane wartet nicht mehr auf den Abgleich aller Zonen.
  • Die Aufgabenliste eines Kunden ist vollständig, auch wenn andere Kunden mehr Aufgaben haben.
  • Die SSH-Übersicht lädt auf Nodes mit vielen Anmeldeversuchen nicht mehr Hunderte Megabyte Journal in den Speicher des Agents.
  • Die Seite Komponenten eines Nodes öffnet deutlich schneller, und die Bereiche Composer und Dateien antworten in großen Verzeichnissen schneller.
  • Wer viele Domains kurz hintereinander anlegt, etwa über die API, bekommt nicht mehr ab etwa der hundertsten einen unerwarteten Fehler. Die Rollouts dahinter warteten bisher jeder für sich und liefen über.
  • Eine DNS-Zone, die von Master auf Slave umgestellt wird, erlaubt einem eingetragenen Secondary danach keinen Transfer mehr und benachrichtigt ihn nicht mehr; bisher blieben beide Einstellungen aus ihrer Zeit als Master stehen.
  • Der Bereich Protokolle einer Domain zeigte nur zwei Zeilen. Die Anzeige wächst jetzt mit dem Protokoll bis zur Fensterhöhe, auch auf dem Telefon; lange Zeilen rollen waagerecht, statt umzubrechen.
  • Mail an einen Benutzer des Nodes selbst — etwa die Ausgabe eines Cronjobs an den Unix-User der Subscription — wird wieder zugestellt. Bisher blieb sie mit „hash:/etc/aliases is unavailable“ in der Warteschlange liegen und füllte das Mailprotokoll alle paar Minuten mit Warnungen. Was dort schon wartet, stellt Postfix beim nächsten Versuch nach /var/mail/<user> zu.

Rendert anders

  • postfix-main — main.cf trägt enable_long_queue_ids = yes.
  • postfix-main — main.cf trägt alias_maps = inline:{ postmaster=root } und ein leeres alias_database; /etc/aliases liest Postfix nicht mehr.
  • crontab — jede Datei /etc/cron.d/kastra-sub<n> trägt am Kopf MAILTO="" und vor jeder aktiven Jobzeile eine eigene MAILTO-Zeile. Jobs mit Mail nur bei Fehler oder nach jedem Lauf laufen über /usr/local/bin/kastra-agent cronlauf.
  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.
  • wildfly-zugriff — neu ist /var/lib/kastra/wildfly-zugriff.json, einmal je Node: die Domains, deren Verzeichnis zuletzt für WildFly freigegeben war. Auf einem Node ohne Freigabe steht dort eine leere Liste.

26.09.21.1

Normal Test 44 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).
  • Lange Listen laden seitenweise. Domains, Subscriptions, Kunden, Datenbanken, Maildomains, Zonen, Benutzer und Container zeigen ab 500 Einträgen Mehr laden. Eine Anlage mit weniger Einträgen sieht keinen Unterschied.
  • Das Protokoll einer Aufgabe und die Ausgabe eines Rollouts lassen sich vollständig herunterladen.
  • Mailstatistik. Eine Maildomain hat den Reiter Statistik: was heute, in den letzten 7 und 30 Tagen eingegangen und versendet wurde, was gescheitert ist — unzustellbar, abgewiesen, als Spam abgewiesen — und was gerade wartet, dazu ein Verlauf über 30 Tage und die Zahlen je Postfach, Weiterleitung und Versandzugang. Jede Zahl führt zur Liste der Sendungen dahinter — zugestellt, zurückgestellt, gescheitert, gelöscht, je Empfänger mit Grund, Zahl der Versuche und Sprung ins Protokoll, filterbar nach Zeitraum, Status, Richtung und Adresse. Der Bereich Mailserver eines Nodes zeigt dieselben Zahlen und Sendungen für den ganzen Node, je Maildomain aufgeschlüsselt. Nach dem Update liest jeder Node beim ersten Lauf bis zu 30 Tage nach, soweit sein Journal so weit reicht.
  • Mehrere Sendungen auf einmal. Was noch in der Warteschlange liegt, lässt sich aus der Liste der Sendungen und aus der Warteschlange heraus einzeln, für eine Auswahl per Kästchen oder für alle erneut versuchen oder löschen; im Bereich Mailserver eines Nodes auch anhalten und freigeben. Danach meldet das Panel, wie viele erledigt und wie viele übersprungen wurden — etwa weil eine Sendung inzwischen zugestellt war.
  • Die Aufbewahrung der einzelnen Sendungen stellt KASTRA_MAIL_STATISTIK_SENDUNGEN_TAGE ein (Vorgabe 30 Tage).
  • Alarm bei Stau in der Warteschlange (MAIL_QUEUE_STAU): ab 100 wartenden Sendungen oder wenn eine seit 6 Stunden wartet. Beide Schwellen sind über KASTRA_MAIL_STATISTIK_STAU_ANZAHL und KASTRA_MAIL_STATISTIK_STAU_ALTER_STUNDEN einstellbar.
  • Repositories auf einen Blick. Eine Subscription hat den Bereich Repositories: alle Repositories ihrer Domains in einer Tabelle, je Zeile die Domain, der geholte Commit und der jüngste Commit des Branches bei GitHub. Oben steht, wie viele aktuell sind und wo bei GitHub schon ein neuerer Stand liegt; Nicht aktuelle holen zieht sie in einem Zug nach.
  • Warum ein Container nicht startet, steht im Panel. Der Bereich Container einer Domain nennt den Schritt, an dem der letzte Start gescheitert ist oder gerade steht — Bauen, Starten oder die Gegenprobe —, zeigt die Schritte mit ihrem Ergebnis und die Ausgabe genau dieses Laufs, etwa den Abbruch von npm ci im Bau. Hat systemd nach fünf Versuchen die Startsperre gezogen, steht das dort mit Sperre lösen und neu starten. Die Übersicht unter Container zeigt dieselbe Marke je Domain.

Geändert

  • Scheitert Neu starten an einer Container-Domain, nennt die Meldung den gescheiterten Schritt, und in den Details steht die Ausgabe des Laufs statt nur „Job failed, see journalctl“.
  • Die Warteschlange einer Maildomain zeigt nur noch deren Sendungen — und Kunden sehen sie jetzt auch; bisher kam für sie nur ein Fehler. Dort lässt sich eine Sendung erneut versuchen oder löschen. Anhalten, Freigeben und Zustellung aller Sendungen erzwingen stehen jetzt im Bereich Mailserver des Nodes, weil sie den ganzen Mailserver betreffen.
  • Postfix vergibt lange Warteschlangenkennungen (enable_long_queue_ids), damit sich eine Kennung über die 30 Tage, die die Sendungen aufbewahrt werden, nicht wiederholt. Mails, die beim Update schon in der Warteschlange liegen, behalten ihre kurze Kennung und werden normal zugestellt.
  • Ein Rollout startet Container und Objekt-Caches nur noch neu, wenn sich ihre Konfiguration geändert hat. Der Rollout einer fremden Domain lässt sie laufen, der Cache bleibt gefüllt. Bisher warf jeder Rollout — auch einer ohne jede Änderung — alle Container und alle Caches des Nodes weg. Eine Änderung nur an der Dockerfile oder an eigenen Dateien der Anwendung baut den Container deshalb beim nächsten Rollout nicht mehr neu. Dafür gibt es Neu starten im Bereich Container.
  • Ein Rollout schreibt, sichert und lädt nur noch, was sich wirklich geändert hat. „Datei(en) geschrieben“ im Aufgabenprotokoll zählt nur diese Dateien, und PHP-FPM wird nur für die Fassungen neu geladen, deren Pools betroffen sind.
  • Der Healthcheck nach dem Rollout prüft die Domains gleichzeitig. Ein Rollout wartet nicht mehr eine Minute je Domain, die nicht antwortet, und eine Anwendung, die mit einem eigenen Fehlercode antwortet, wird nicht mehr viermal abgefragt.
  • Eine Abweichung, die nach der Korrektur sofort wiederkommt, löst nicht mehr alle fünf Minuten einen vollständigen Rollout aus. Der Abstand verdoppelt sich bis zu zwei Stunden; gemeldet wird die Abweichung weiter im gewohnten Takt.
  • Das Panel überträgt beim ersten Aufruf etwa ein Viertel der bisherigen Datenmenge. Skripte, Stilvorlagen und Antworten der API gehen komprimiert hinaus, und die Stilvorlage des Code-Editors lädt erst mit dem Editor. Ein bestehender Panel-Host bekommt die Komprimierung beim Update in seinen nginx-Vhost nachgetragen; die vorherige Fassung bleibt als kastra-panel.conf.vor-gzip daneben liegen.
  • Lange Protokolle und große Verzeichnisse bleiben im Panel flüssig. Angezeigt werden die letzten 1 000 Zeilen eines Protokolls, die letzten 2 000 Zeilen eines Rollouts und die ersten 500 Einträge eines Verzeichnisses; der Rest steht im Download oder wird nachgelegt. Das Protokoll einer Aufgabe öffnet am Ende statt am Anfang.
  • Die Übersicht, die Statusseite und die Container-Seite holen, was sie von den Nodes brauchen, in einer einzigen Anfrage an die Control Plane statt in einer je Node oder je Container.
  • Ein Panel in einem Tab im Hintergrund fragt die Control Plane nicht mehr ab; beim Zurückkommen holt es sofort nach.
  • Angaben wie „vor 3 Minuten“ werden erst beim nächsten Laden der Seite weitergezählt.
  • Die Hinweise in den Verlaufsbalken von Status und Auslastung erscheinen als schlichter Hinweis des Browsers.
  • Das Web-Terminal zeichnet über die Grafikkarte und bleibt auch bei viel Ausgabe flüssig.
  • Mehrere Änderungen an einem Node kurz hintereinander werden zusammen ausgerollt. Jede behält ihre Aufgabe; die erste trägt das Protokoll des Nodes, die übrigen zeigen „Wird zusammen mit Aufgabe … ausgerollt“ und enden mit demselben Ergebnis.

Behoben

  • Eine PHP-Domain, die auf Node.js, Container oder Proxy umgestellt wird, geht nicht mehr weiter an Apache. Bisher blieb der Webserver-Modus nginx + Apache stehen, und Besucher bekamen den Quelltext der index.php statt der Anwendung zu sehen. Domains, die schon so umgestellt wurden, richtet das Update selbst.
  • Ein Download aus dem Dateimanager belastet die Control Plane nicht mehr mit der Dateigröße. Bisher lag eine Datei zweimal vollständig in ihrem Speicher.
  • Ein langsamer oder hängender Node hält Rollout, Terminal und Dateimanager der anderen Nodes nicht mehr an, und offene Protokollfenster legen die Control Plane nicht mehr still.
  • Ein Web-Terminal mit viel Ausgabe hält Heartbeat, Rollout-Ergebnisse und Protokolle seines Nodes nicht mehr an.
  • Ein langer nächtlicher Lauf wie der monatliche Wiederherstellungs-Probelauf verzögert die Erkennung ausgefallener Nodes nicht mehr.
  • Das Protokoll eines Rollouts kommt in Stapeln an; ein Selbstupdate schreibt nicht mehr für jede Zeile die ganze Tabelle nach.
  • Eine Adressänderung eines DNS-Nodes löst einen Rollout aus, nicht einen je Zone, und der Start der Control Plane wartet nicht mehr auf den Abgleich aller Zonen.
  • Die Aufgabenliste eines Kunden ist vollständig, auch wenn andere Kunden mehr Aufgaben haben.
  • Die SSH-Übersicht lädt auf Nodes mit vielen Anmeldeversuchen nicht mehr Hunderte Megabyte Journal in den Speicher des Agents.
  • Die Seite Komponenten eines Nodes öffnet deutlich schneller, und die Bereiche Composer und Dateien antworten in großen Verzeichnissen schneller.
  • Wer viele Domains kurz hintereinander anlegt, etwa über die API, bekommt nicht mehr ab etwa der hundertsten einen unerwarteten Fehler. Die Rollouts dahinter warteten bisher jeder für sich und liefen über.
  • Eine DNS-Zone, die von Master auf Slave umgestellt wird, erlaubt einem eingetragenen Secondary danach keinen Transfer mehr und benachrichtigt ihn nicht mehr; bisher blieben beide Einstellungen aus ihrer Zeit als Master stehen.
  • Der Bereich Protokolle einer Domain zeigte nur zwei Zeilen. Die Anzeige wächst jetzt mit dem Protokoll bis zur Fensterhöhe, auch auf dem Telefon; lange Zeilen rollen waagerecht, statt umzubrechen.

Rendert anders

  • postfix-main — main.cf trägt enable_long_queue_ids = yes.
  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.
  • wildfly-zugriff — neu ist /var/lib/kastra/wildfly-zugriff.json, einmal je Node: die Domains, deren Verzeichnis zuletzt für WildFly freigegeben war. Auf einem Node ohne Freigabe steht dort eine leere Liste.

26.09.15.6

Normal Test 43 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).
  • Lange Listen laden seitenweise. Domains, Subscriptions, Kunden, Datenbanken, Maildomains, Zonen, Benutzer und Container zeigen ab 500 Einträgen Mehr laden. Eine Anlage mit weniger Einträgen sieht keinen Unterschied.
  • Das Protokoll einer Aufgabe und die Ausgabe eines Rollouts lassen sich vollständig herunterladen.
  • Mailstatistik. Eine Maildomain hat den Reiter Statistik: was heute, in den letzten 7 und 30 Tagen eingegangen und versendet wurde, was gescheitert ist — unzustellbar, abgewiesen, als Spam abgewiesen — und was gerade wartet, dazu ein Verlauf über 30 Tage und die Zahlen je Postfach, Weiterleitung und Versandzugang. Jede Zahl führt zur Liste der Sendungen dahinter — zugestellt, zurückgestellt, gescheitert, gelöscht, je Empfänger mit Grund, Zahl der Versuche und Sprung ins Protokoll, filterbar nach Zeitraum, Status, Richtung und Adresse. Der Bereich Mailserver eines Nodes zeigt dieselben Zahlen und Sendungen für den ganzen Node, je Maildomain aufgeschlüsselt. Nach dem Update liest jeder Node beim ersten Lauf bis zu 30 Tage nach, soweit sein Journal so weit reicht.
  • Mehrere Sendungen auf einmal. Was noch in der Warteschlange liegt, lässt sich aus der Liste der Sendungen und aus der Warteschlange heraus einzeln, für eine Auswahl per Kästchen oder für alle erneut versuchen oder löschen; im Bereich Mailserver eines Nodes auch anhalten und freigeben. Danach meldet das Panel, wie viele erledigt und wie viele übersprungen wurden — etwa weil eine Sendung inzwischen zugestellt war.
  • Die Aufbewahrung der einzelnen Sendungen stellt KASTRA_MAIL_STATISTIK_SENDUNGEN_TAGE ein (Vorgabe 30 Tage).
  • Alarm bei Stau in der Warteschlange (MAIL_QUEUE_STAU): ab 100 wartenden Sendungen oder wenn eine seit 6 Stunden wartet. Beide Schwellen sind über KASTRA_MAIL_STATISTIK_STAU_ANZAHL und KASTRA_MAIL_STATISTIK_STAU_ALTER_STUNDEN einstellbar.
  • Repositories auf einen Blick. Eine Subscription hat den Bereich Repositories: alle Repositories ihrer Domains in einer Tabelle, je Zeile die Domain, der geholte Commit und der jüngste Commit des Branches bei GitHub. Oben steht, wie viele aktuell sind und wo bei GitHub schon ein neuerer Stand liegt; Nicht aktuelle holen zieht sie in einem Zug nach.
  • Warum ein Container nicht startet, steht im Panel. Der Bereich Container einer Domain nennt den Schritt, an dem der letzte Start gescheitert ist oder gerade steht — Bauen, Starten oder die Gegenprobe —, zeigt die Schritte mit ihrem Ergebnis und die Ausgabe genau dieses Laufs, etwa den Abbruch von npm ci im Bau. Hat systemd nach fünf Versuchen die Startsperre gezogen, steht das dort mit Sperre lösen und neu starten. Die Übersicht unter Container zeigt dieselbe Marke je Domain.

Geändert

  • Scheitert Neu starten an einer Container-Domain, nennt die Meldung den gescheiterten Schritt, und in den Details steht die Ausgabe des Laufs statt nur „Job failed, see journalctl“.
  • Die Warteschlange einer Maildomain zeigt nur noch deren Sendungen — und Kunden sehen sie jetzt auch; bisher kam für sie nur ein Fehler. Dort lässt sich eine Sendung erneut versuchen oder löschen. Anhalten, Freigeben und Zustellung aller Sendungen erzwingen stehen jetzt im Bereich Mailserver des Nodes, weil sie den ganzen Mailserver betreffen.
  • Postfix vergibt lange Warteschlangenkennungen (enable_long_queue_ids), damit sich eine Kennung über die 30 Tage, die die Sendungen aufbewahrt werden, nicht wiederholt. Mails, die beim Update schon in der Warteschlange liegen, behalten ihre kurze Kennung und werden normal zugestellt.
  • Ein Rollout startet Container und Objekt-Caches nur noch neu, wenn sich ihre Konfiguration geändert hat. Der Rollout einer fremden Domain lässt sie laufen, der Cache bleibt gefüllt. Bisher warf jeder Rollout — auch einer ohne jede Änderung — alle Container und alle Caches des Nodes weg. Eine Änderung nur an der Dockerfile oder an eigenen Dateien der Anwendung baut den Container deshalb beim nächsten Rollout nicht mehr neu. Dafür gibt es Neu starten im Bereich Container.
  • Ein Rollout schreibt, sichert und lädt nur noch, was sich wirklich geändert hat. „Datei(en) geschrieben“ im Aufgabenprotokoll zählt nur diese Dateien, und PHP-FPM wird nur für die Fassungen neu geladen, deren Pools betroffen sind.
  • Der Healthcheck nach dem Rollout prüft die Domains gleichzeitig. Ein Rollout wartet nicht mehr eine Minute je Domain, die nicht antwortet, und eine Anwendung, die mit einem eigenen Fehlercode antwortet, wird nicht mehr viermal abgefragt.
  • Eine Abweichung, die nach der Korrektur sofort wiederkommt, löst nicht mehr alle fünf Minuten einen vollständigen Rollout aus. Der Abstand verdoppelt sich bis zu zwei Stunden; gemeldet wird die Abweichung weiter im gewohnten Takt.
  • Das Panel überträgt beim ersten Aufruf etwa ein Viertel der bisherigen Datenmenge. Skripte, Stilvorlagen und Antworten der API gehen komprimiert hinaus, und die Stilvorlage des Code-Editors lädt erst mit dem Editor. Ein bestehender Panel-Host bekommt die Komprimierung beim Update in seinen nginx-Vhost nachgetragen; die vorherige Fassung bleibt als kastra-panel.conf.vor-gzip daneben liegen.
  • Lange Protokolle und große Verzeichnisse bleiben im Panel flüssig. Angezeigt werden die letzten 1 000 Zeilen eines Protokolls, die letzten 2 000 Zeilen eines Rollouts und die ersten 500 Einträge eines Verzeichnisses; der Rest steht im Download oder wird nachgelegt. Das Protokoll einer Aufgabe öffnet am Ende statt am Anfang.
  • Die Übersicht, die Statusseite und die Container-Seite holen, was sie von den Nodes brauchen, in einer einzigen Anfrage an die Control Plane statt in einer je Node oder je Container.
  • Ein Panel in einem Tab im Hintergrund fragt die Control Plane nicht mehr ab; beim Zurückkommen holt es sofort nach.
  • Angaben wie „vor 3 Minuten“ werden erst beim nächsten Laden der Seite weitergezählt.
  • Die Hinweise in den Verlaufsbalken von Status und Auslastung erscheinen als schlichter Hinweis des Browsers.
  • Das Web-Terminal zeichnet über die Grafikkarte und bleibt auch bei viel Ausgabe flüssig.
  • Mehrere Änderungen an einem Node kurz hintereinander werden zusammen ausgerollt. Jede behält ihre Aufgabe; die erste trägt das Protokoll des Nodes, die übrigen zeigen „Wird zusammen mit Aufgabe … ausgerollt“ und enden mit demselben Ergebnis.

Behoben

  • Ein Download aus dem Dateimanager belastet die Control Plane nicht mehr mit der Dateigröße. Bisher lag eine Datei zweimal vollständig in ihrem Speicher.
  • Ein langsamer oder hängender Node hält Rollout, Terminal und Dateimanager der anderen Nodes nicht mehr an, und offene Protokollfenster legen die Control Plane nicht mehr still.
  • Ein Web-Terminal mit viel Ausgabe hält Heartbeat, Rollout-Ergebnisse und Protokolle seines Nodes nicht mehr an.
  • Ein langer nächtlicher Lauf wie der monatliche Wiederherstellungs-Probelauf verzögert die Erkennung ausgefallener Nodes nicht mehr.
  • Das Protokoll eines Rollouts kommt in Stapeln an; ein Selbstupdate schreibt nicht mehr für jede Zeile die ganze Tabelle nach.
  • Eine Adressänderung eines DNS-Nodes löst einen Rollout aus, nicht einen je Zone, und der Start der Control Plane wartet nicht mehr auf den Abgleich aller Zonen.
  • Die Aufgabenliste eines Kunden ist vollständig, auch wenn andere Kunden mehr Aufgaben haben.
  • Die SSH-Übersicht lädt auf Nodes mit vielen Anmeldeversuchen nicht mehr Hunderte Megabyte Journal in den Speicher des Agents.
  • Die Seite Komponenten eines Nodes öffnet deutlich schneller, und die Bereiche Composer und Dateien antworten in großen Verzeichnissen schneller.
  • Wer viele Domains kurz hintereinander anlegt, etwa über die API, bekommt nicht mehr ab etwa der hundertsten einen unerwarteten Fehler. Die Rollouts dahinter warteten bisher jeder für sich und liefen über.
  • Eine DNS-Zone, die von Master auf Slave umgestellt wird, erlaubt einem eingetragenen Secondary danach keinen Transfer mehr und benachrichtigt ihn nicht mehr; bisher blieben beide Einstellungen aus ihrer Zeit als Master stehen.
  • Der Bereich Protokolle einer Domain zeigte nur zwei Zeilen. Die Anzeige wächst jetzt mit dem Protokoll bis zur Fensterhöhe, auch auf dem Telefon; lange Zeilen rollen waagerecht, statt umzubrechen.

Rendert anders

  • postfix-main — main.cf trägt enable_long_queue_ids = yes.
  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.
  • wildfly-zugriff — neu ist /var/lib/kastra/wildfly-zugriff.json, einmal je Node: die Domains, deren Verzeichnis zuletzt für WildFly freigegeben war. Auf einem Node ohne Freigabe steht dort eine leere Liste.

26.09.15.4

Normal Test 41 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).
  • Lange Listen laden seitenweise. Domains, Subscriptions, Kunden, Datenbanken, Maildomains, Zonen, Benutzer und Container zeigen ab 500 Einträgen Mehr laden. Eine Anlage mit weniger Einträgen sieht keinen Unterschied.
  • Das Protokoll einer Aufgabe und die Ausgabe eines Rollouts lassen sich vollständig herunterladen.
  • Mailstatistik. Eine Maildomain hat den Reiter Statistik: was heute, in den letzten 7 und 30 Tagen eingegangen und versendet wurde, was gescheitert ist — unzustellbar, abgewiesen, als Spam abgewiesen — und was gerade wartet, dazu ein Verlauf über 30 Tage und die Zahlen je Postfach, Weiterleitung und Versandzugang. Jede Zahl führt zur Liste der Sendungen dahinter — zugestellt, zurückgestellt, gescheitert, gelöscht, je Empfänger mit Grund, Zahl der Versuche und Sprung ins Protokoll, filterbar nach Zeitraum, Status, Richtung und Adresse. Der Bereich Mailserver eines Nodes zeigt dieselben Zahlen und Sendungen für den ganzen Node, je Maildomain aufgeschlüsselt. Nach dem Update liest jeder Node beim ersten Lauf bis zu 30 Tage nach, soweit sein Journal so weit reicht.
  • Mehrere Sendungen auf einmal. Was noch in der Warteschlange liegt, lässt sich aus der Liste der Sendungen und aus der Warteschlange heraus einzeln, für eine Auswahl per Kästchen oder für alle erneut versuchen oder löschen; im Bereich Mailserver eines Nodes auch anhalten und freigeben. Danach meldet das Panel, wie viele erledigt und wie viele übersprungen wurden — etwa weil eine Sendung inzwischen zugestellt war.
  • Die Aufbewahrung der einzelnen Sendungen stellt KASTRA_MAIL_STATISTIK_SENDUNGEN_TAGE ein (Vorgabe 30 Tage).
  • Alarm bei Stau in der Warteschlange (MAIL_QUEUE_STAU): ab 100 wartenden Sendungen oder wenn eine seit 6 Stunden wartet. Beide Schwellen sind über KASTRA_MAIL_STATISTIK_STAU_ANZAHL und KASTRA_MAIL_STATISTIK_STAU_ALTER_STUNDEN einstellbar.
  • Repositories auf einen Blick. Eine Subscription hat den Bereich Repositories: alle Repositories ihrer Domains in einer Tabelle, je Zeile die Domain, der geholte Commit und der jüngste Commit des Branches bei GitHub. Oben steht, wie viele aktuell sind und wo bei GitHub schon ein neuerer Stand liegt; Nicht aktuelle holen zieht sie in einem Zug nach.

Geändert

  • Die Warteschlange einer Maildomain zeigt nur noch deren Sendungen — und Kunden sehen sie jetzt auch; bisher kam für sie nur ein Fehler. Dort lässt sich eine Sendung erneut versuchen oder löschen. Anhalten, Freigeben und Zustellung aller Sendungen erzwingen stehen jetzt im Bereich Mailserver des Nodes, weil sie den ganzen Mailserver betreffen.
  • Postfix vergibt lange Warteschlangenkennungen (enable_long_queue_ids), damit sich eine Kennung über die 30 Tage, die die Sendungen aufbewahrt werden, nicht wiederholt. Mails, die beim Update schon in der Warteschlange liegen, behalten ihre kurze Kennung und werden normal zugestellt.
  • Ein Rollout startet Container und Objekt-Caches nur noch neu, wenn sich ihre Konfiguration geändert hat. Der Rollout einer fremden Domain lässt sie laufen, der Cache bleibt gefüllt. Bisher warf jeder Rollout — auch einer ohne jede Änderung — alle Container und alle Caches des Nodes weg. Eine Änderung nur an der Dockerfile oder an eigenen Dateien der Anwendung baut den Container deshalb beim nächsten Rollout nicht mehr neu. Dafür gibt es Neu starten im Bereich Container.
  • Ein Rollout schreibt, sichert und lädt nur noch, was sich wirklich geändert hat. „Datei(en) geschrieben“ im Aufgabenprotokoll zählt nur diese Dateien, und PHP-FPM wird nur für die Fassungen neu geladen, deren Pools betroffen sind.
  • Der Healthcheck nach dem Rollout prüft die Domains gleichzeitig. Ein Rollout wartet nicht mehr eine Minute je Domain, die nicht antwortet, und eine Anwendung, die mit einem eigenen Fehlercode antwortet, wird nicht mehr viermal abgefragt.
  • Eine Abweichung, die nach der Korrektur sofort wiederkommt, löst nicht mehr alle fünf Minuten einen vollständigen Rollout aus. Der Abstand verdoppelt sich bis zu zwei Stunden; gemeldet wird die Abweichung weiter im gewohnten Takt.
  • Das Panel überträgt beim ersten Aufruf etwa ein Viertel der bisherigen Datenmenge. Skripte, Stilvorlagen und Antworten der API gehen komprimiert hinaus, und die Stilvorlage des Code-Editors lädt erst mit dem Editor. Ein bestehender Panel-Host bekommt die Komprimierung beim Update in seinen nginx-Vhost nachgetragen; die vorherige Fassung bleibt als kastra-panel.conf.vor-gzip daneben liegen.
  • Lange Protokolle und große Verzeichnisse bleiben im Panel flüssig. Angezeigt werden die letzten 1 000 Zeilen eines Protokolls, die letzten 2 000 Zeilen eines Rollouts und die ersten 500 Einträge eines Verzeichnisses; der Rest steht im Download oder wird nachgelegt. Das Protokoll einer Aufgabe öffnet am Ende statt am Anfang.
  • Die Übersicht, die Statusseite und die Container-Seite holen, was sie von den Nodes brauchen, in einer einzigen Anfrage an die Control Plane statt in einer je Node oder je Container.
  • Ein Panel in einem Tab im Hintergrund fragt die Control Plane nicht mehr ab; beim Zurückkommen holt es sofort nach.
  • Angaben wie „vor 3 Minuten“ werden erst beim nächsten Laden der Seite weitergezählt.
  • Die Hinweise in den Verlaufsbalken von Status und Auslastung erscheinen als schlichter Hinweis des Browsers.
  • Das Web-Terminal zeichnet über die Grafikkarte und bleibt auch bei viel Ausgabe flüssig.
  • Mehrere Änderungen an einem Node kurz hintereinander werden zusammen ausgerollt. Jede behält ihre Aufgabe; die erste trägt das Protokoll des Nodes, die übrigen zeigen „Wird zusammen mit Aufgabe … ausgerollt“ und enden mit demselben Ergebnis.

Behoben

  • Ein Download aus dem Dateimanager belastet die Control Plane nicht mehr mit der Dateigröße. Bisher lag eine Datei zweimal vollständig in ihrem Speicher.
  • Ein langsamer oder hängender Node hält Rollout, Terminal und Dateimanager der anderen Nodes nicht mehr an, und offene Protokollfenster legen die Control Plane nicht mehr still.
  • Ein Web-Terminal mit viel Ausgabe hält Heartbeat, Rollout-Ergebnisse und Protokolle seines Nodes nicht mehr an.
  • Ein langer nächtlicher Lauf wie der monatliche Wiederherstellungs-Probelauf verzögert die Erkennung ausgefallener Nodes nicht mehr.
  • Das Protokoll eines Rollouts kommt in Stapeln an; ein Selbstupdate schreibt nicht mehr für jede Zeile die ganze Tabelle nach.
  • Eine Adressänderung eines DNS-Nodes löst einen Rollout aus, nicht einen je Zone, und der Start der Control Plane wartet nicht mehr auf den Abgleich aller Zonen.
  • Die Aufgabenliste eines Kunden ist vollständig, auch wenn andere Kunden mehr Aufgaben haben.
  • Die SSH-Übersicht lädt auf Nodes mit vielen Anmeldeversuchen nicht mehr Hunderte Megabyte Journal in den Speicher des Agents.
  • Die Seite Komponenten eines Nodes öffnet deutlich schneller, und die Bereiche Composer und Dateien antworten in großen Verzeichnissen schneller.
  • Wer viele Domains kurz hintereinander anlegt, etwa über die API, bekommt nicht mehr ab etwa der hundertsten einen unerwarteten Fehler. Die Rollouts dahinter warteten bisher jeder für sich und liefen über.
  • Eine DNS-Zone, die von Master auf Slave umgestellt wird, erlaubt einem eingetragenen Secondary danach keinen Transfer mehr und benachrichtigt ihn nicht mehr; bisher blieben beide Einstellungen aus ihrer Zeit als Master stehen.
  • Der Bereich Protokolle einer Domain zeigte nur zwei Zeilen. Die Anzeige wächst jetzt mit dem Protokoll bis zur Fensterhöhe, auch auf dem Telefon; lange Zeilen rollen waagerecht, statt umzubrechen.

Rendert anders

  • postfix-main — main.cf trägt enable_long_queue_ids = yes.
  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.
  • wildfly-zugriff — neu ist /var/lib/kastra/wildfly-zugriff.json, einmal je Node: die Domains, deren Verzeichnis zuletzt für WildFly freigegeben war. Auf einem Node ohne Freigabe steht dort eine leere Liste.

26.09.15.3

Normal Test 40 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).
  • Lange Listen laden seitenweise. Domains, Subscriptions, Kunden, Datenbanken, Maildomains, Zonen, Benutzer und Container zeigen ab 500 Einträgen Mehr laden. Eine Anlage mit weniger Einträgen sieht keinen Unterschied.
  • Das Protokoll einer Aufgabe und die Ausgabe eines Rollouts lassen sich vollständig herunterladen.
  • Mailstatistik. Eine Maildomain hat den Reiter Statistik: was heute, in den letzten 7 und 30 Tagen eingegangen und versendet wurde, was gescheitert ist — unzustellbar, abgewiesen, als Spam abgewiesen — und was gerade wartet, dazu ein Verlauf über 30 Tage und die Zahlen je Postfach, Weiterleitung und Versandzugang. Jede Zahl führt zur Liste der Sendungen dahinter — zugestellt, zurückgestellt, gescheitert, gelöscht, je Empfänger mit Grund, Zahl der Versuche und Sprung ins Protokoll, filterbar nach Zeitraum, Status, Richtung und Adresse. Der Bereich Mailserver eines Nodes zeigt dieselben Zahlen und Sendungen für den ganzen Node, je Maildomain aufgeschlüsselt. Nach dem Update liest jeder Node beim ersten Lauf bis zu 30 Tage nach, soweit sein Journal so weit reicht.
  • Mehrere Sendungen auf einmal. Was noch in der Warteschlange liegt, lässt sich aus der Liste der Sendungen und aus der Warteschlange heraus einzeln, für eine Auswahl per Kästchen oder für alle erneut versuchen oder löschen; im Bereich Mailserver eines Nodes auch anhalten und freigeben. Danach meldet das Panel, wie viele erledigt und wie viele übersprungen wurden — etwa weil eine Sendung inzwischen zugestellt war.
  • Die Aufbewahrung der einzelnen Sendungen stellt KASTRA_MAIL_STATISTIK_SENDUNGEN_TAGE ein (Vorgabe 30 Tage).
  • Alarm bei Stau in der Warteschlange (MAIL_QUEUE_STAU): ab 100 wartenden Sendungen oder wenn eine seit 6 Stunden wartet. Beide Schwellen sind über KASTRA_MAIL_STATISTIK_STAU_ANZAHL und KASTRA_MAIL_STATISTIK_STAU_ALTER_STUNDEN einstellbar.
  • Repositories auf einen Blick. Eine Subscription hat den Bereich Repositories: alle Repositories ihrer Domains in einer Tabelle, je Zeile die Domain, der geholte Commit und der jüngste Commit des Branches bei GitHub. Oben steht, wie viele aktuell sind und wo bei GitHub schon ein neuerer Stand liegt; Nicht aktuelle holen zieht sie in einem Zug nach.

Geändert

  • Die Warteschlange einer Maildomain zeigt nur noch deren Sendungen — und Kunden sehen sie jetzt auch; bisher kam für sie nur ein Fehler. Dort lässt sich eine Sendung erneut versuchen oder löschen. Anhalten, Freigeben und Zustellung aller Sendungen erzwingen stehen jetzt im Bereich Mailserver des Nodes, weil sie den ganzen Mailserver betreffen.
  • Postfix vergibt lange Warteschlangenkennungen (enable_long_queue_ids), damit sich eine Kennung über die 30 Tage, die die Sendungen aufbewahrt werden, nicht wiederholt. Mails, die beim Update schon in der Warteschlange liegen, behalten ihre kurze Kennung und werden normal zugestellt.
  • Ein Rollout startet Container und Objekt-Caches nur noch neu, wenn sich ihre Konfiguration geändert hat. Der Rollout einer fremden Domain lässt sie laufen, der Cache bleibt gefüllt. Bisher warf jeder Rollout — auch einer ohne jede Änderung — alle Container und alle Caches des Nodes weg. Eine Änderung nur an der Dockerfile oder an eigenen Dateien der Anwendung baut den Container deshalb beim nächsten Rollout nicht mehr neu. Dafür gibt es Neu starten im Bereich Container.
  • Ein Rollout schreibt, sichert und lädt nur noch, was sich wirklich geändert hat. „Datei(en) geschrieben“ im Aufgabenprotokoll zählt nur diese Dateien, und PHP-FPM wird nur für die Fassungen neu geladen, deren Pools betroffen sind.
  • Der Healthcheck nach dem Rollout prüft die Domains gleichzeitig. Ein Rollout wartet nicht mehr eine Minute je Domain, die nicht antwortet, und eine Anwendung, die mit einem eigenen Fehlercode antwortet, wird nicht mehr viermal abgefragt.
  • Eine Abweichung, die nach der Korrektur sofort wiederkommt, löst nicht mehr alle fünf Minuten einen vollständigen Rollout aus. Der Abstand verdoppelt sich bis zu zwei Stunden; gemeldet wird die Abweichung weiter im gewohnten Takt.
  • Das Panel überträgt beim ersten Aufruf etwa ein Viertel der bisherigen Datenmenge. Skripte, Stilvorlagen und Antworten der API gehen komprimiert hinaus, und die Stilvorlage des Code-Editors lädt erst mit dem Editor. Ein bestehender Panel-Host bekommt die Komprimierung beim Update in seinen nginx-Vhost nachgetragen; die vorherige Fassung bleibt als kastra-panel.conf.vor-gzip daneben liegen.
  • Lange Protokolle und große Verzeichnisse bleiben im Panel flüssig. Angezeigt werden die letzten 1 000 Zeilen eines Protokolls, die letzten 2 000 Zeilen eines Rollouts und die ersten 500 Einträge eines Verzeichnisses; der Rest steht im Download oder wird nachgelegt. Das Protokoll einer Aufgabe öffnet am Ende statt am Anfang.
  • Die Übersicht, die Statusseite und die Container-Seite holen, was sie von den Nodes brauchen, in einer einzigen Anfrage an die Control Plane statt in einer je Node oder je Container.
  • Ein Panel in einem Tab im Hintergrund fragt die Control Plane nicht mehr ab; beim Zurückkommen holt es sofort nach.
  • Angaben wie „vor 3 Minuten“ werden erst beim nächsten Laden der Seite weitergezählt.
  • Die Hinweise in den Verlaufsbalken von Status und Auslastung erscheinen als schlichter Hinweis des Browsers.
  • Das Web-Terminal zeichnet über die Grafikkarte und bleibt auch bei viel Ausgabe flüssig.
  • Mehrere Änderungen an einem Node kurz hintereinander werden zusammen ausgerollt. Jede behält ihre Aufgabe; die erste trägt das Protokoll des Nodes, die übrigen zeigen „Wird zusammen mit Aufgabe … ausgerollt“ und enden mit demselben Ergebnis.

Behoben

  • Ein Download aus dem Dateimanager belastet die Control Plane nicht mehr mit der Dateigröße. Bisher lag eine Datei zweimal vollständig in ihrem Speicher.
  • Ein langsamer oder hängender Node hält Rollout, Terminal und Dateimanager der anderen Nodes nicht mehr an, und offene Protokollfenster legen die Control Plane nicht mehr still.
  • Ein Web-Terminal mit viel Ausgabe hält Heartbeat, Rollout-Ergebnisse und Protokolle seines Nodes nicht mehr an.
  • Ein langer nächtlicher Lauf wie der monatliche Wiederherstellungs-Probelauf verzögert die Erkennung ausgefallener Nodes nicht mehr.
  • Das Protokoll eines Rollouts kommt in Stapeln an; ein Selbstupdate schreibt nicht mehr für jede Zeile die ganze Tabelle nach.
  • Eine Adressänderung eines DNS-Nodes löst einen Rollout aus, nicht einen je Zone, und der Start der Control Plane wartet nicht mehr auf den Abgleich aller Zonen.
  • Die Aufgabenliste eines Kunden ist vollständig, auch wenn andere Kunden mehr Aufgaben haben.
  • Die SSH-Übersicht lädt auf Nodes mit vielen Anmeldeversuchen nicht mehr Hunderte Megabyte Journal in den Speicher des Agents.
  • Die Seite Komponenten eines Nodes öffnet deutlich schneller, und die Bereiche Composer und Dateien antworten in großen Verzeichnissen schneller.
  • Wer viele Domains kurz hintereinander anlegt, etwa über die API, bekommt nicht mehr ab etwa der hundertsten einen unerwarteten Fehler. Die Rollouts dahinter warteten bisher jeder für sich und liefen über.
  • Eine DNS-Zone, die von Master auf Slave umgestellt wird, erlaubt einem eingetragenen Secondary danach keinen Transfer mehr und benachrichtigt ihn nicht mehr; bisher blieben beide Einstellungen aus ihrer Zeit als Master stehen.

Rendert anders

  • postfix-main — main.cf trägt enable_long_queue_ids = yes.
  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.
  • wildfly-zugriff — neu ist /var/lib/kastra/wildfly-zugriff.json, einmal je Node: die Domains, deren Verzeichnis zuletzt für WildFly freigegeben war. Auf einem Node ohne Freigabe steht dort eine leere Liste.

26.09.15.1

Normal Test 39 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).
  • Lange Listen laden seitenweise. Domains, Subscriptions, Kunden, Datenbanken, Maildomains, Zonen, Benutzer und Container zeigen ab 500 Einträgen Mehr laden. Eine Anlage mit weniger Einträgen sieht keinen Unterschied.
  • Das Protokoll einer Aufgabe und die Ausgabe eines Rollouts lassen sich vollständig herunterladen.
  • Mailstatistik. Eine Maildomain hat den Reiter Statistik: was heute, in den letzten 7 und 30 Tagen eingegangen und versendet wurde, was gescheitert ist — unzustellbar, abgewiesen, als Spam abgewiesen — und was gerade wartet, dazu ein Verlauf über 30 Tage und die Zahlen je Postfach, Weiterleitung und Versandzugang. Jede Zahl führt zur Liste der Sendungen dahinter — zugestellt, zurückgestellt, gescheitert, gelöscht, je Empfänger mit Grund, Zahl der Versuche und Sprung ins Protokoll, filterbar nach Zeitraum, Status, Richtung und Adresse. Der Bereich Mailserver eines Nodes zeigt dieselben Zahlen und Sendungen für den ganzen Node, je Maildomain aufgeschlüsselt. Nach dem Update liest jeder Node beim ersten Lauf bis zu 30 Tage nach, soweit sein Journal so weit reicht.
  • Mehrere Sendungen auf einmal. Was noch in der Warteschlange liegt, lässt sich aus der Liste der Sendungen und aus der Warteschlange heraus einzeln, für eine Auswahl per Kästchen oder für alle erneut versuchen oder löschen; im Bereich Mailserver eines Nodes auch anhalten und freigeben. Danach meldet das Panel, wie viele erledigt und wie viele übersprungen wurden — etwa weil eine Sendung inzwischen zugestellt war.
  • Die Aufbewahrung der einzelnen Sendungen stellt KASTRA_MAIL_STATISTIK_SENDUNGEN_TAGE ein (Vorgabe 30 Tage).
  • Alarm bei Stau in der Warteschlange (MAIL_QUEUE_STAU): ab 100 wartenden Sendungen oder wenn eine seit 6 Stunden wartet. Beide Schwellen sind über KASTRA_MAIL_STATISTIK_STAU_ANZAHL und KASTRA_MAIL_STATISTIK_STAU_ALTER_STUNDEN einstellbar.

Geändert

  • Die Warteschlange einer Maildomain zeigt nur noch deren Sendungen — und Kunden sehen sie jetzt auch; bisher kam für sie nur ein Fehler. Dort lässt sich eine Sendung erneut versuchen oder löschen. Anhalten, Freigeben und Zustellung aller Sendungen erzwingen stehen jetzt im Bereich Mailserver des Nodes, weil sie den ganzen Mailserver betreffen.
  • Postfix vergibt lange Warteschlangenkennungen (enable_long_queue_ids), damit sich eine Kennung über die 30 Tage, die die Sendungen aufbewahrt werden, nicht wiederholt. Mails, die beim Update schon in der Warteschlange liegen, behalten ihre kurze Kennung und werden normal zugestellt.
  • Ein Rollout startet Container und Objekt-Caches nur noch neu, wenn sich ihre Konfiguration geändert hat. Der Rollout einer fremden Domain lässt sie laufen, der Cache bleibt gefüllt. Bisher warf jeder Rollout — auch einer ohne jede Änderung — alle Container und alle Caches des Nodes weg. Eine Änderung nur an der Dockerfile oder an eigenen Dateien der Anwendung baut den Container deshalb beim nächsten Rollout nicht mehr neu. Dafür gibt es Neu starten im Bereich Container.
  • Ein Rollout schreibt, sichert und lädt nur noch, was sich wirklich geändert hat. „Datei(en) geschrieben“ im Aufgabenprotokoll zählt nur diese Dateien, und PHP-FPM wird nur für die Fassungen neu geladen, deren Pools betroffen sind.
  • Der Healthcheck nach dem Rollout prüft die Domains gleichzeitig. Ein Rollout wartet nicht mehr eine Minute je Domain, die nicht antwortet, und eine Anwendung, die mit einem eigenen Fehlercode antwortet, wird nicht mehr viermal abgefragt.
  • Eine Abweichung, die nach der Korrektur sofort wiederkommt, löst nicht mehr alle fünf Minuten einen vollständigen Rollout aus. Der Abstand verdoppelt sich bis zu zwei Stunden; gemeldet wird die Abweichung weiter im gewohnten Takt.
  • Das Panel überträgt beim ersten Aufruf etwa ein Viertel der bisherigen Datenmenge. Skripte, Stilvorlagen und Antworten der API gehen komprimiert hinaus, und die Stilvorlage des Code-Editors lädt erst mit dem Editor. Ein bestehender Panel-Host bekommt die Komprimierung beim Update in seinen nginx-Vhost nachgetragen; die vorherige Fassung bleibt als kastra-panel.conf.vor-gzip daneben liegen.
  • Lange Protokolle und große Verzeichnisse bleiben im Panel flüssig. Angezeigt werden die letzten 1 000 Zeilen eines Protokolls, die letzten 2 000 Zeilen eines Rollouts und die ersten 500 Einträge eines Verzeichnisses; der Rest steht im Download oder wird nachgelegt. Das Protokoll einer Aufgabe öffnet am Ende statt am Anfang.
  • Die Übersicht, die Statusseite und die Container-Seite holen, was sie von den Nodes brauchen, in einer einzigen Anfrage an die Control Plane statt in einer je Node oder je Container.
  • Ein Panel in einem Tab im Hintergrund fragt die Control Plane nicht mehr ab; beim Zurückkommen holt es sofort nach.
  • Angaben wie „vor 3 Minuten“ werden erst beim nächsten Laden der Seite weitergezählt.
  • Die Hinweise in den Verlaufsbalken von Status und Auslastung erscheinen als schlichter Hinweis des Browsers.
  • Das Web-Terminal zeichnet über die Grafikkarte und bleibt auch bei viel Ausgabe flüssig.
  • Mehrere Änderungen an einem Node kurz hintereinander werden zusammen ausgerollt. Jede behält ihre Aufgabe; die erste trägt das Protokoll des Nodes, die übrigen zeigen „Wird zusammen mit Aufgabe … ausgerollt“ und enden mit demselben Ergebnis.

Behoben

  • Ein Download aus dem Dateimanager belastet die Control Plane nicht mehr mit der Dateigröße. Bisher lag eine Datei zweimal vollständig in ihrem Speicher.
  • Ein langsamer oder hängender Node hält Rollout, Terminal und Dateimanager der anderen Nodes nicht mehr an, und offene Protokollfenster legen die Control Plane nicht mehr still.
  • Ein Web-Terminal mit viel Ausgabe hält Heartbeat, Rollout-Ergebnisse und Protokolle seines Nodes nicht mehr an.
  • Ein langer nächtlicher Lauf wie der monatliche Wiederherstellungs-Probelauf verzögert die Erkennung ausgefallener Nodes nicht mehr.
  • Das Protokoll eines Rollouts kommt in Stapeln an; ein Selbstupdate schreibt nicht mehr für jede Zeile die ganze Tabelle nach.
  • Eine Adressänderung eines DNS-Nodes löst einen Rollout aus, nicht einen je Zone, und der Start der Control Plane wartet nicht mehr auf den Abgleich aller Zonen.
  • Die Aufgabenliste eines Kunden ist vollständig, auch wenn andere Kunden mehr Aufgaben haben.
  • Die SSH-Übersicht lädt auf Nodes mit vielen Anmeldeversuchen nicht mehr Hunderte Megabyte Journal in den Speicher des Agents.
  • Die Seite Komponenten eines Nodes öffnet deutlich schneller, und die Bereiche Composer und Dateien antworten in großen Verzeichnissen schneller.
  • Wer viele Domains kurz hintereinander anlegt, etwa über die API, bekommt nicht mehr ab etwa der hundertsten einen unerwarteten Fehler. Die Rollouts dahinter warteten bisher jeder für sich und liefen über.
  • Eine DNS-Zone, die von Master auf Slave umgestellt wird, erlaubt einem eingetragenen Secondary danach keinen Transfer mehr und benachrichtigt ihn nicht mehr; bisher blieben beide Einstellungen aus ihrer Zeit als Master stehen.

Rendert anders

  • postfix-main — main.cf trägt enable_long_queue_ids = yes.
  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.
  • wildfly-zugriff — neu ist /var/lib/kastra/wildfly-zugriff.json, einmal je Node: die Domains, deren Verzeichnis zuletzt für WildFly freigegeben war. Auf einem Node ohne Freigabe steht dort eine leere Liste.

26.09.14.12

Normal Test 39 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).
  • Lange Listen laden seitenweise. Domains, Subscriptions, Kunden, Datenbanken, Maildomains, Zonen, Benutzer und Container zeigen ab 500 Einträgen Mehr laden. Eine Anlage mit weniger Einträgen sieht keinen Unterschied.
  • Das Protokoll einer Aufgabe und die Ausgabe eines Rollouts lassen sich vollständig herunterladen.
  • Mailstatistik. Eine Maildomain hat den Reiter Statistik: was heute, in den letzten 7 und 30 Tagen eingegangen und versendet wurde, was gescheitert ist — unzustellbar, abgewiesen, als Spam abgewiesen — und was gerade wartet, dazu ein Verlauf über 30 Tage und die Zahlen je Postfach, Weiterleitung und Versandzugang. Jede Zahl führt zur Liste der Sendungen dahinter — zugestellt, zurückgestellt, gescheitert, gelöscht, je Empfänger mit Grund, Zahl der Versuche und Sprung ins Protokoll, filterbar nach Zeitraum, Status, Richtung und Adresse. Der Bereich Mailserver eines Nodes zeigt dieselben Zahlen und Sendungen für den ganzen Node, je Maildomain aufgeschlüsselt. Nach dem Update liest jeder Node beim ersten Lauf bis zu 30 Tage nach, soweit sein Journal so weit reicht.
  • Mehrere Sendungen auf einmal. Was noch in der Warteschlange liegt, lässt sich aus der Liste der Sendungen und aus der Warteschlange heraus einzeln, für eine Auswahl per Kästchen oder für alle erneut versuchen oder löschen; im Bereich Mailserver eines Nodes auch anhalten und freigeben. Danach meldet das Panel, wie viele erledigt und wie viele übersprungen wurden — etwa weil eine Sendung inzwischen zugestellt war.
  • Die Aufbewahrung der einzelnen Sendungen stellt KASTRA_MAIL_STATISTIK_SENDUNGEN_TAGE ein (Vorgabe 30 Tage).
  • Alarm bei Stau in der Warteschlange (MAIL_QUEUE_STAU): ab 100 wartenden Sendungen oder wenn eine seit 6 Stunden wartet. Beide Schwellen sind über KASTRA_MAIL_STATISTIK_STAU_ANZAHL und KASTRA_MAIL_STATISTIK_STAU_ALTER_STUNDEN einstellbar.

Geändert

  • Die Warteschlange einer Maildomain zeigt nur noch deren Sendungen — und Kunden sehen sie jetzt auch; bisher kam für sie nur ein Fehler. Dort lässt sich eine Sendung erneut versuchen oder löschen. Anhalten, Freigeben und Zustellung aller Sendungen erzwingen stehen jetzt im Bereich Mailserver des Nodes, weil sie den ganzen Mailserver betreffen.
  • Postfix vergibt lange Warteschlangenkennungen (enable_long_queue_ids), damit sich eine Kennung über die 30 Tage, die die Sendungen aufbewahrt werden, nicht wiederholt. Mails, die beim Update schon in der Warteschlange liegen, behalten ihre kurze Kennung und werden normal zugestellt.
  • Ein Rollout startet Container und Objekt-Caches nur noch neu, wenn sich ihre Konfiguration geändert hat. Der Rollout einer fremden Domain lässt sie laufen, der Cache bleibt gefüllt. Bisher warf jeder Rollout — auch einer ohne jede Änderung — alle Container und alle Caches des Nodes weg. Eine Änderung nur an der Dockerfile oder an eigenen Dateien der Anwendung baut den Container deshalb beim nächsten Rollout nicht mehr neu. Dafür gibt es Neu starten im Bereich Container.
  • Ein Rollout schreibt, sichert und lädt nur noch, was sich wirklich geändert hat. „Datei(en) geschrieben“ im Aufgabenprotokoll zählt nur diese Dateien, und PHP-FPM wird nur für die Fassungen neu geladen, deren Pools betroffen sind.
  • Der Healthcheck nach dem Rollout prüft die Domains gleichzeitig. Ein Rollout wartet nicht mehr eine Minute je Domain, die nicht antwortet, und eine Anwendung, die mit einem eigenen Fehlercode antwortet, wird nicht mehr viermal abgefragt.
  • Eine Abweichung, die nach der Korrektur sofort wiederkommt, löst nicht mehr alle fünf Minuten einen vollständigen Rollout aus. Der Abstand verdoppelt sich bis zu zwei Stunden; gemeldet wird die Abweichung weiter im gewohnten Takt.
  • Das Panel überträgt beim ersten Aufruf etwa ein Viertel der bisherigen Datenmenge. Skripte, Stilvorlagen und Antworten der API gehen komprimiert hinaus, und die Stilvorlage des Code-Editors lädt erst mit dem Editor. Ein bestehender Panel-Host bekommt die Komprimierung beim Update in seinen nginx-Vhost nachgetragen; die vorherige Fassung bleibt als kastra-panel.conf.vor-gzip daneben liegen.
  • Lange Protokolle und große Verzeichnisse bleiben im Panel flüssig. Angezeigt werden die letzten 1 000 Zeilen eines Protokolls, die letzten 2 000 Zeilen eines Rollouts und die ersten 500 Einträge eines Verzeichnisses; der Rest steht im Download oder wird nachgelegt. Das Protokoll einer Aufgabe öffnet am Ende statt am Anfang.
  • Die Übersicht, die Statusseite und die Container-Seite holen, was sie von den Nodes brauchen, in einer einzigen Anfrage an die Control Plane statt in einer je Node oder je Container.
  • Ein Panel in einem Tab im Hintergrund fragt die Control Plane nicht mehr ab; beim Zurückkommen holt es sofort nach.
  • Angaben wie „vor 3 Minuten“ werden erst beim nächsten Laden der Seite weitergezählt.
  • Die Hinweise in den Verlaufsbalken von Status und Auslastung erscheinen als schlichter Hinweis des Browsers.
  • Das Web-Terminal zeichnet über die Grafikkarte und bleibt auch bei viel Ausgabe flüssig.
  • Mehrere Änderungen an einem Node kurz hintereinander werden zusammen ausgerollt. Jede behält ihre Aufgabe; die erste trägt das Protokoll des Nodes, die übrigen zeigen „Wird zusammen mit Aufgabe … ausgerollt“ und enden mit demselben Ergebnis.

Behoben

  • Ein Download aus dem Dateimanager belastet die Control Plane nicht mehr mit der Dateigröße. Bisher lag eine Datei zweimal vollständig in ihrem Speicher.
  • Ein langsamer oder hängender Node hält Rollout, Terminal und Dateimanager der anderen Nodes nicht mehr an, und offene Protokollfenster legen die Control Plane nicht mehr still.
  • Ein Web-Terminal mit viel Ausgabe hält Heartbeat, Rollout-Ergebnisse und Protokolle seines Nodes nicht mehr an.
  • Ein langer nächtlicher Lauf wie der monatliche Wiederherstellungs-Probelauf verzögert die Erkennung ausgefallener Nodes nicht mehr.
  • Das Protokoll eines Rollouts kommt in Stapeln an; ein Selbstupdate schreibt nicht mehr für jede Zeile die ganze Tabelle nach.
  • Eine Adressänderung eines DNS-Nodes löst einen Rollout aus, nicht einen je Zone, und der Start der Control Plane wartet nicht mehr auf den Abgleich aller Zonen.
  • Die Aufgabenliste eines Kunden ist vollständig, auch wenn andere Kunden mehr Aufgaben haben.
  • Die SSH-Übersicht lädt auf Nodes mit vielen Anmeldeversuchen nicht mehr Hunderte Megabyte Journal in den Speicher des Agents.
  • Die Seite Komponenten eines Nodes öffnet deutlich schneller, und die Bereiche Composer und Dateien antworten in großen Verzeichnissen schneller.
  • Wer viele Domains kurz hintereinander anlegt, etwa über die API, bekommt nicht mehr ab etwa der hundertsten einen unerwarteten Fehler. Die Rollouts dahinter warteten bisher jeder für sich und liefen über.
  • Eine DNS-Zone, die von Master auf Slave umgestellt wird, erlaubt einem eingetragenen Secondary danach keinen Transfer mehr und benachrichtigt ihn nicht mehr; bisher blieben beide Einstellungen aus ihrer Zeit als Master stehen.

Rendert anders

  • postfix-main — main.cf trägt enable_long_queue_ids = yes.
  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.
  • wildfly-zugriff — neu ist /var/lib/kastra/wildfly-zugriff.json, einmal je Node: die Domains, deren Verzeichnis zuletzt für WildFly freigegeben war. Auf einem Node ohne Freigabe steht dort eine leere Liste.

26.09.14.6

Normal Test 34 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).
  • Lange Listen laden seitenweise. Domains, Subscriptions, Kunden, Datenbanken, Maildomains, Zonen, Benutzer und Container zeigen ab 500 Einträgen Mehr laden. Eine Anlage mit weniger Einträgen sieht keinen Unterschied.
  • Das Protokoll einer Aufgabe und die Ausgabe eines Rollouts lassen sich vollständig herunterladen.
  • Mailstatistik. Eine Maildomain hat den Reiter Statistik: was heute, in den letzten 7 und 30 Tagen eingegangen und versendet wurde, was gescheitert ist — unzustellbar, abgewiesen, als Spam abgewiesen — und was gerade wartet, dazu ein Verlauf über 30 Tage, die Zahlen je Postfach, Weiterleitung und Versandzugang und die einzelnen Fehlschläge mit Grund und Sprung ins Protokoll. Der Bereich Mailserver eines Nodes zeigt dieselben Zahlen für den ganzen Node, je Maildomain aufgeschlüsselt. Nach dem Update liest jeder Node beim ersten Lauf bis zu 30 Tage nach, soweit sein Journal so weit reicht.
  • Alarm bei Stau in der Warteschlange (MAIL_QUEUE_STAU): ab 100 wartenden Sendungen oder wenn eine seit 6 Stunden wartet. Beide Schwellen sind über KASTRA_MAIL_STATISTIK_STAU_ANZAHL und KASTRA_MAIL_STATISTIK_STAU_ALTER_STUNDEN einstellbar.

Geändert

  • Die Warteschlange einer Maildomain zeigt nur noch deren Sendungen — und Kunden sehen sie jetzt auch; bisher kam für sie nur ein Fehler. Dort lässt sich eine Sendung erneut versuchen oder löschen. Anhalten, Freigeben und Zustellung aller Sendungen erzwingen stehen jetzt im Bereich Mailserver des Nodes, weil sie den ganzen Mailserver betreffen.
  • Ein Rollout startet Container und Objekt-Caches nur noch neu, wenn sich ihre Konfiguration geändert hat. Der Rollout einer fremden Domain lässt sie laufen, der Cache bleibt gefüllt. Bisher warf jeder Rollout — auch einer ohne jede Änderung — alle Container und alle Caches des Nodes weg. Eine Änderung nur an der Dockerfile oder an eigenen Dateien der Anwendung baut den Container deshalb beim nächsten Rollout nicht mehr neu. Dafür gibt es Neu starten im Bereich Container.
  • Ein Rollout schreibt, sichert und lädt nur noch, was sich wirklich geändert hat. „Datei(en) geschrieben“ im Aufgabenprotokoll zählt nur diese Dateien, und PHP-FPM wird nur für die Fassungen neu geladen, deren Pools betroffen sind.
  • Der Healthcheck nach dem Rollout prüft die Domains gleichzeitig. Ein Rollout wartet nicht mehr eine Minute je Domain, die nicht antwortet, und eine Anwendung, die mit einem eigenen Fehlercode antwortet, wird nicht mehr viermal abgefragt.
  • Eine Abweichung, die nach der Korrektur sofort wiederkommt, löst nicht mehr alle fünf Minuten einen vollständigen Rollout aus. Der Abstand verdoppelt sich bis zu zwei Stunden; gemeldet wird die Abweichung weiter im gewohnten Takt.
  • Das Panel überträgt beim ersten Aufruf etwa ein Viertel der bisherigen Datenmenge. Skripte, Stilvorlagen und Antworten der API gehen komprimiert hinaus, und die Stilvorlage des Code-Editors lädt erst mit dem Editor. Ein bestehender Panel-Host bekommt die Komprimierung beim Update in seinen nginx-Vhost nachgetragen; die vorherige Fassung bleibt als kastra-panel.conf.vor-gzip daneben liegen.
  • Lange Protokolle und große Verzeichnisse bleiben im Panel flüssig. Angezeigt werden die letzten 1 000 Zeilen eines Protokolls, die letzten 2 000 Zeilen eines Rollouts und die ersten 500 Einträge eines Verzeichnisses; der Rest steht im Download oder wird nachgelegt. Das Protokoll einer Aufgabe öffnet am Ende statt am Anfang.
  • Die Übersicht, die Statusseite und die Container-Seite holen, was sie von den Nodes brauchen, in einer einzigen Anfrage an die Control Plane statt in einer je Node oder je Container.
  • Ein Panel in einem Tab im Hintergrund fragt die Control Plane nicht mehr ab; beim Zurückkommen holt es sofort nach.
  • Angaben wie „vor 3 Minuten“ werden erst beim nächsten Laden der Seite weitergezählt.
  • Die Hinweise in den Verlaufsbalken von Status und Auslastung erscheinen als schlichter Hinweis des Browsers.
  • Das Web-Terminal zeichnet über die Grafikkarte und bleibt auch bei viel Ausgabe flüssig.
  • Mehrere Änderungen an einem Node kurz hintereinander werden zusammen ausgerollt. Jede behält ihre Aufgabe; die erste trägt das Protokoll des Nodes, die übrigen zeigen „Wird zusammen mit Aufgabe … ausgerollt“ und enden mit demselben Ergebnis.

Behoben

  • Ein Download aus dem Dateimanager belastet die Control Plane nicht mehr mit der Dateigröße. Bisher lag eine Datei zweimal vollständig in ihrem Speicher.
  • Ein langsamer oder hängender Node hält Rollout, Terminal und Dateimanager der anderen Nodes nicht mehr an, und offene Protokollfenster legen die Control Plane nicht mehr still.
  • Ein Web-Terminal mit viel Ausgabe hält Heartbeat, Rollout-Ergebnisse und Protokolle seines Nodes nicht mehr an.
  • Ein langer nächtlicher Lauf wie der monatliche Wiederherstellungs-Probelauf verzögert die Erkennung ausgefallener Nodes nicht mehr.
  • Das Protokoll eines Rollouts kommt in Stapeln an; ein Selbstupdate schreibt nicht mehr für jede Zeile die ganze Tabelle nach.
  • Eine Adressänderung eines DNS-Nodes löst einen Rollout aus, nicht einen je Zone, und der Start der Control Plane wartet nicht mehr auf den Abgleich aller Zonen.
  • Die Aufgabenliste eines Kunden ist vollständig, auch wenn andere Kunden mehr Aufgaben haben.
  • Die SSH-Übersicht lädt auf Nodes mit vielen Anmeldeversuchen nicht mehr Hunderte Megabyte Journal in den Speicher des Agents.
  • Die Seite Komponenten eines Nodes öffnet deutlich schneller, und die Bereiche Composer und Dateien antworten in großen Verzeichnissen schneller.
  • Wer viele Domains kurz hintereinander anlegt, etwa über die API, bekommt nicht mehr ab etwa der hundertsten einen unerwarteten Fehler. Die Rollouts dahinter warteten bisher jeder für sich und liefen über.

Rendert anders

  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.
  • wildfly-zugriff — neu ist /var/lib/kastra/wildfly-zugriff.json, einmal je Node: die Domains, deren Verzeichnis zuletzt für WildFly freigegeben war. Auf einem Node ohne Freigabe steht dort eine leere Liste.

26.09.14.5

Normal Test 31 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).
  • Lange Listen laden seitenweise. Domains, Subscriptions, Kunden, Datenbanken, Maildomains, Zonen, Benutzer und Container zeigen ab 500 Einträgen Mehr laden. Eine Anlage mit weniger Einträgen sieht keinen Unterschied.
  • Das Protokoll einer Aufgabe und die Ausgabe eines Rollouts lassen sich vollständig herunterladen.

Geändert

  • Ein Rollout startet Container und Objekt-Caches nur noch neu, wenn sich ihre Konfiguration geändert hat. Der Rollout einer fremden Domain lässt sie laufen, der Cache bleibt gefüllt. Bisher warf jeder Rollout — auch einer ohne jede Änderung — alle Container und alle Caches des Nodes weg. Eine Änderung nur an der Dockerfile oder an eigenen Dateien der Anwendung baut den Container deshalb beim nächsten Rollout nicht mehr neu. Dafür gibt es Neu starten im Bereich Container.
  • Ein Rollout schreibt, sichert und lädt nur noch, was sich wirklich geändert hat. „Datei(en) geschrieben“ im Aufgabenprotokoll zählt nur diese Dateien, und PHP-FPM wird nur für die Fassungen neu geladen, deren Pools betroffen sind.
  • Der Healthcheck nach dem Rollout prüft die Domains gleichzeitig. Ein Rollout wartet nicht mehr eine Minute je Domain, die nicht antwortet, und eine Anwendung, die mit einem eigenen Fehlercode antwortet, wird nicht mehr viermal abgefragt.
  • Eine Abweichung, die nach der Korrektur sofort wiederkommt, löst nicht mehr alle fünf Minuten einen vollständigen Rollout aus. Der Abstand verdoppelt sich bis zu zwei Stunden; gemeldet wird die Abweichung weiter im gewohnten Takt.
  • Das Panel überträgt beim ersten Aufruf etwa ein Viertel der bisherigen Datenmenge. Skripte, Stilvorlagen und Antworten der API gehen komprimiert hinaus, und die Stilvorlage des Code-Editors lädt erst mit dem Editor. Ein bestehender Panel-Host bekommt die Komprimierung beim Update in seinen nginx-Vhost nachgetragen; die vorherige Fassung bleibt als kastra-panel.conf.vor-gzip daneben liegen.
  • Lange Protokolle und große Verzeichnisse bleiben im Panel flüssig. Angezeigt werden die letzten 1 000 Zeilen eines Protokolls, die letzten 2 000 Zeilen eines Rollouts und die ersten 500 Einträge eines Verzeichnisses; der Rest steht im Download oder wird nachgelegt. Das Protokoll einer Aufgabe öffnet am Ende statt am Anfang.
  • Die Übersicht, die Statusseite und die Container-Seite holen, was sie von den Nodes brauchen, in einer einzigen Anfrage an die Control Plane statt in einer je Node oder je Container.
  • Ein Panel in einem Tab im Hintergrund fragt die Control Plane nicht mehr ab; beim Zurückkommen holt es sofort nach.
  • Angaben wie „vor 3 Minuten“ werden erst beim nächsten Laden der Seite weitergezählt.
  • Die Hinweise in den Verlaufsbalken von Status und Auslastung erscheinen als schlichter Hinweis des Browsers.
  • Das Web-Terminal zeichnet über die Grafikkarte und bleibt auch bei viel Ausgabe flüssig.
  • Mehrere Änderungen an einem Node kurz hintereinander werden zusammen ausgerollt. Jede behält ihre Aufgabe; die erste trägt das Protokoll des Nodes, die übrigen zeigen „Wird zusammen mit Aufgabe … ausgerollt“ und enden mit demselben Ergebnis.

Behoben

  • Ein Download aus dem Dateimanager belastet die Control Plane nicht mehr mit der Dateigröße. Bisher lag eine Datei zweimal vollständig in ihrem Speicher.
  • Ein langsamer oder hängender Node hält Rollout, Terminal und Dateimanager der anderen Nodes nicht mehr an, und offene Protokollfenster legen die Control Plane nicht mehr still.
  • Ein Web-Terminal mit viel Ausgabe hält Heartbeat, Rollout-Ergebnisse und Protokolle seines Nodes nicht mehr an.
  • Ein langer nächtlicher Lauf wie der monatliche Wiederherstellungs-Probelauf verzögert die Erkennung ausgefallener Nodes nicht mehr.
  • Das Protokoll eines Rollouts kommt in Stapeln an; ein Selbstupdate schreibt nicht mehr für jede Zeile die ganze Tabelle nach.
  • Eine Adressänderung eines DNS-Nodes löst einen Rollout aus, nicht einen je Zone, und der Start der Control Plane wartet nicht mehr auf den Abgleich aller Zonen.
  • Die Aufgabenliste eines Kunden ist vollständig, auch wenn andere Kunden mehr Aufgaben haben.
  • Die SSH-Übersicht lädt auf Nodes mit vielen Anmeldeversuchen nicht mehr Hunderte Megabyte Journal in den Speicher des Agents.
  • Die Seite Komponenten eines Nodes öffnet deutlich schneller, und die Bereiche Composer und Dateien antworten in großen Verzeichnissen schneller.
  • Wer viele Domains kurz hintereinander anlegt, etwa über die API, bekommt nicht mehr ab etwa der hundertsten einen unerwarteten Fehler. Die Rollouts dahinter warteten bisher jeder für sich und liefen über.

Rendert anders

  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.
  • wildfly-zugriff — neu ist /var/lib/kastra/wildfly-zugriff.json, einmal je Node: die Domains, deren Verzeichnis zuletzt für WildFly freigegeben war. Auf einem Node ohne Freigabe steht dort eine leere Liste.

26.09.13.31

Normal Test 6 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).

Rendert anders

  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.

26.09.13.30

Normal Test 6 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).

Rendert anders

  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.

26.09.13.26

Normal Test 6 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).

Rendert anders

  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.

26.09.13.25

Normal Test 6 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).

Rendert anders

  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.

26.09.13.23

Normal Test 6 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).

Rendert anders

  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.

26.09.13.22

Normal Test 6 Punkte

Neu

  • Eine Domain ohne eigene Fehlerseite zeigt ihren Besuchern jetzt die Fehlerseite von Kastra statt der nackten Seite des Webservers — im Erscheinungsbild des Panels, hell oder dunkel, auf Deutsch mit einer englischen Zeile und mit einem Knopf zur Startseite. Das gilt für alle zehn Statuscodes aus dem Bereich Fehlerseiten, auch für die Wartungsseite (503). Eigene Seiten an Subscription oder Domain, die Fehlerseiten einer Anwendung und ErrorDocument in einer .htaccess gehen weiter vor.
  • Im Bereich Fehlerseiten heißt die unterste Ebene Kastra-Standard; Anlegen öffnet die Seite von Kastra im Editor als Ausgangspunkt für eine eigene.
  • **Der Verweis Hinweise im Update-Bericht führt jetzt zu einer Seite.** Unter getkastra.de steht eine Webseite mit dem Changelog je Fassung und je Kanal — derselbe Text wie im Bericht vor der Bestätigung, dazu je Kanal, was er bedeutet: test bekommt jeden Bau, stabil eine von Hand freigegebene Fassung aus test; keiner von beiden ist unter Produktionsbedingungen geprüft. Dazu Funktionen, Aufbau, Installation und die Lizenz (MIT).

Rendert anders

  • nginx-vhost — jeder Vhost trägt zehn error_page-Zeilen und die interne Location /.kastra-fehler/, auch ohne hinterlegte Seite. Der Kommentar über dem Block heißt jetzt „Fehlerseiten (Plan 029, E-184)“, der im Wartungsblock nennt die Seite von Kastra.
  • apache-vhost — im Modus nginx+Apache stehen Alias und ErrorDocument für alle zehn Codes im Backend-Vhost.
  • fehlerseiten — neu sind zehn Dateien /var/lib/kastra/fehlerseiten/kastra-<code>.html, einmal je Node.