26.10.23.15

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.