Fassung 26.10.11.3

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.