26.09.22.3

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.