{
  "kanal": "test",
  "version": "26.09.15.1",
  "veroeffentlicht": "2026-09-15T10:37:33Z",
  "mindestversion": "",
  "hinweise": "https://getkastra.de/aenderungen/26.09.15.1/",
  "aenderungen": {
    "art": "normal",
    "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."],
    "geaendert": ["**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."],
    "eingriffe": [],
    "rendert": ["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."]
  },
  "pakete": ["kastra-agent", "kastra-control-plane", "kastra-ui"]
}