Wann hört Rotation auf, optional zu sein?

Ein paar Szenarien bringen das Thema regelmäßig genug zur Sprache, dass ich einen Rotationsplan dafür bereithalte. Ich improvisiere lieber keinen unter Druck.

Ein Plugin oder CMS auf einer gehosteten Website wird kompromittiert. Über einen echten Fall auf dieser Art von Server habe ich hier geschrieben: PHP2Shell: So habe ich meine Server bis zum Patch geschützt, eine PHP-Schwachstelle, die einem Angreifer erlaubte, eine Webshell abzulegen, bevor es einen Patch gab. Sobald eine Webshell unter einem Hosting-Benutzer läuft, kann sie oft die eigene config.inc.php dieser Website lesen. Auf einer gemeinsam genutzten ISPConfig-Box liegt diese Datei direkt neben den Zugangsdaten für die eigene Datenbank des Kontrollpanels. Nicht nur das eine Zugangsdatum, hinter dem der Angreifer eigentlich her war.

Eine Konfigurationsdatei landet irgendwo, wo sie nicht hingehört. Ein Backup-Archiv, das in einem öffentlichen Ordner liegen bleibt. Ein Repository, das mit einer versehentlichen Datei gepusht wird. Ein Log, das lesbarer ist, als es sein sollte. config.inc.php und mysql_clientdb.conf haben an keinem dieser Orte etwas zu suchen. Fehler passieren trotzdem, auch mir.

Ein Systemadministrator verlässt das Team. Wie einvernehmlich der Abschied auch war, gemeinsam genutzte Datenbank-Zugangsdaten, die diese Person einmal hatte, sind Zugangsdaten, denen ich nicht mehr vollständig vertraue. Vertrauen wird nicht automatisch übertragen, wenn jemand zur Tür hinausgeht.

Ein vermuteter Einbruch, selbst ein unbestätigter. Dieser Fall lässt sich am schwersten jemandem erklären, der noch nie einen Server unter Angriffsverdacht betrieben hat. Man wartet nicht auf einen Beweis, bevor man handelt. Man geht von einer Kompromittierung aus und rotiert. Eine unnötige Rotation kostet einen Nachmittag. Eine ausgelassene, nach einem echten Einbruch, kann jede Website kosten, die der Server hostet.

Warum ISPConfig-Zugangsdaten rotieren von Hand so fehleranfällig ist

Als ich die Datenbank-Zugangsdaten von ISPConfig zum ersten Mal von Hand rotiert habe, habe ich unterschätzt, wie viele Dateien betroffen sind. Sie müssen alle zusammen geändert werden, sonst geht ein paar Stunden später irgendwo leise etwas kaputt.

Es gibt config.inc.php auf der Server-Seite und eine zweite Kopie auf der Interface-Seite. Beide müssen dieselben neuen Werte bekommen. Es gibt mysql_clientdb.conf, das ISPConfig ausliest, um die eigene Datenbank jeder gehosteten Website zu verwalten, nicht nur seine eigene Haushaltsführung. Dovecot, Pure-FTPd und Postfix führen jeweils eine eigene Kopie einiger dieser Zugangsdaten. Mail und FTP können still aufhören, sich zu authentifizieren, wenn man den Datenbank-Benutzer aktualisiert und dabei nur eine dieser drei Dienste vergisst.

Dann gibt es die Master/Slave-Topologie, die einige meiner Setups verwenden. Ein Slave-Knoten authentifiziert sich über das Netzwerk an der Datenbank seines Masters, mit einem separaten Passwort. Dieses Passwort muss auf dem Master selbst rotiert werden, nicht nur lokal. Bringt man die Reihenfolge durcheinander, kann sich ein Slave vom eigenen Master aussperren, von dem er eigentlich replizieren soll.

Konzeptionell ist nichts davon schwierig. Es sind nur viele Dateien. Mehrere Dienste, die in sinnvoller Reihenfolge neu gestartet werden müssen. Fast keine Toleranz für einen Tippfehler, besonders wenn man das unter Druck macht, gleich nachdem man etwas gefunden hat, das man nicht finden wollte. Genau diese Kombination ist der Grund, warum sich ISPConfig-Zugangsdaten rotieren von Hand immer riskanter anfühlte, als die Aufgabe selbst sein sollte. Deshalb habe ich reset_DB_password.sh geschrieben, nachdem ich das Problem mehr als einmal selbst durchgemacht hatte.

Was reset_DB_password.sh tatsächlich macht

reset_DB_password.sh erkennt, ob der Knoten Standalone, Master oder Slave ist. Dann führt es nur die Phasen aus, die diese Rolle benötigt. Genau so, wie man ISPConfig-Zugangsdaten rotieren sollte: in der richtigen Reihenfolge, für die richtige Rolle.

Phase A rotiert das lokale MySQL-Root-Passwort. Das ist das Passwort, mit dem ISPConfig selbst die Datenbank jeder gehosteten Website verwaltet. Das Skript aktualisiert mysql_clientdb.conf entsprechend dem neuen Wert.

Phase B rotiert das Passwort des ispconfig-Kontrollbenutzers. Sie aktualisiert config.inc.php sowohl auf der Server- als auch auf der Interface-Seite. Danach aktualisiert sie die passenden Zugangsdaten in Dovecot, Pure-FTPd und Postfix, damit Mail und FTP weiter authentifizieren, ohne einen separaten manuellen Durchgang durch drei weitere Konfigurationsdateien.

Phase C läuft nur auf einem Slave. Sie verbindet sich remote mit der Datenbank des Masters. Dort rotiert sie das Passwort des Slave-Benutzers und aktualisiert anschließend lokal dbmaster_password, damit die Replikation weiter korrekt gegen den neuen Wert authentifiziert.

Nach Phase B bietet das Skript an, Dovecot, Pure-FTPd und Postfix für einen neu zu starten. Ich sage fast immer Ja. Wenn man ISPConfig-Zugangsdaten rotiert und dabei einen Mail-Dienst mit dem alten Passwort weiterlaufen lässt, ist man nicht fertig, man ist nur still kaputt. Der Neustart im gleichen Durchlauf, direkt nachdem sich die Konfigurationsdateien geändert haben, hält das Ganze in einem kurzen Wartungsfenster statt in drei separaten, die man später entdeckt.

Backups, bevor sich irgendetwas ändert

Bevor es auch nur eine Datei anfasst, erstellt das Skript eine vollständige rsync-Kopie von /usr/local/ispconfig/ in einem zeitgestempelten Ordner. Es versucht außerdem einen nicht blockierenden mysqldump der Datenbanken mysql und dbispconfig. Nicht blockierend mit Absicht: Ich schließe lieber eine Rotation der Datenbank-Zugangsdaten ab, als auf einen Dump zu warten, der aus irgendeinem unzusammenhängenden Grund hängen bleibt. Jede Konfigurationsdatei, die bearbeitet wird, bekommt erst ihre eigene .bak-Kopie, bevor auch nur eine Zeichenkette darin ersetzt wird.

Nichts davon ersetzt eine unabhängige Backup-Strategie. Ich mache weiterhin ein separates Snapshot oder ein vollständiges Backup, bevor ich das auf einem Server ausführe, der wirklich wichtig ist. Der eigene Disclaimer des Skripts sagt dasselbe, nur direkter, als ich es gerade getan habe.

Erst der Trockenlauf, jedes Mal

Jede Phase fragt nach Bestätigung, bevor irgendetwas geändert wird. –dry-run simuliert einen kompletten Durchlauf, ohne eine einzige Datei zu berühren. Ich benutze dry-run zuerst auf jedem Server, jedes Mal. Auch auf solchen, auf denen ich schon einmal Zugangsdaten rotiert habe und die ich zu kennen glaube. –skip-local-root überspringt Phase A, für den Fall, dass nur das Passwort des Kontrollbenutzers rotiert werden muss. –role=master oder –role=slave überschreibt die automatische Erkennung, für den seltenen Fall, dass sie die Topologie eines Servers nicht selbst korrekt erkennt.

Die erzeugten Passwörter sind 32 Zeichen lang, nur Buchstaben und Ziffern. Lang genug, um Raten zu widerstehen. Einfach genug, dass die Parser von MySQL und PHP niemals über ein vereinzeltes Sonderzeichen in einer Verbindungszeichenfolge stolpern. Ich habe das Skript auf ISPConfig 3.3.1p1 getestet. Gegen ältere oder neuere Zweige habe ich es nicht laufen lassen. Ich würde dort kein identisches Verhalten annehmen, ohne es selbst vorher zu prüfen.

Die Rolle eines Knotens ist nicht immer auf den ersten Blick offensichtlich, besonders auf einem Server, den man geerbt und nicht selbst aufgebaut hat. Deshalb gibt es –role, und deshalb lohnt es sich, die Ausgabe des Trockenlaufs beim ersten Mal Zeile für Zeile zu lesen, nicht nur zu überfliegen. Ich bestätige lieber zwei Minuten lang, dass ein Slave wirklich ein Slave ist, als es mitten in der Rotation auf die harte Tour herauszufinden.

Was ich dir sagen würde, bevor du es ausführst

Hinweis: Das Skript wird wie es ist, zu Informationszwecken bereitgestellt. Die Nutzung erfolgt ausschließlich auf eigenes Risiko: Ich übernehme keine Verantwortung für Datenverlust, Ausfallzeiten oder Fehler, die durch falsche Anwendung, Veränderung des Codes oder einen anderen Kontext als den, in dem ich es selbst einsetze, entstehen. Erstelle immer ein unabhängiges Backup oder einen VM-Snapshot, bevor du es in Produktion ausführst, unabhängig davon, was der eigene Backup-Schritt des Skripts bereits für dich erfasst.

Es ist freie Software. Du darfst sie weiterverbreiten und verändern, mit Nennung meines Namens als ursprünglichen Autor. Der Quellcode von reset_DB_password.sh, und der Rest der ispconfig-fast-tools-Sammlung, liegt auf GitHub unter github.com/matteocisilino/ispconfig-fast-tools.

ISPConfig-Zugangsdaten rotieren ist eine Gewohnheit, kein Aufräumjob

Datenbank-Zugangsdaten nach einem bestätigten Einbruch zu rotieren, ist einfach kompetente Reaktion auf einen Sicherheitsvorfall. Die meisten Administratoren würden es tun, ohne dass man es ihnen zweimal sagen muss. Die schwerere Gewohnheit ist, es auch nach einem bloß vermuteten Einbruch zu tun, bevor jemand Beweise hat. Das ist die einzige Version des Plans, die den Schaden tatsächlich begrenzt, solange er noch begrenzbar ist. Ein Skript, das die richtigen Phasen für die Rolle eines Servers ausführt, zuerst eigene Backups erstellt und mich den ganzen Vorgang per Trockenlauf prüfen lässt, bevor irgendetwas Reales berührt wird. Das macht die Gewohnheit praktisch an einem Dienstagabend, statt theoretisch in einem Blogartikel.

ISPConfig, MySQL, PHP, Dovecot, Pure-FTPd, Postfix und die anderen genannten Namen sind Marken ihrer jeweiligen Inhaber. Sie werden hier nur zur Identifikation der Produkte verwendet.

The post Datenbank-Zugangsdaten-Rotation nach einem ISPConfig-Sicherheitsvorfall first appeared on Matteo Cisilino.

Was ist MPTCP, und warum betrifft es auch dich, wenn du es nicht nutzt

Multipath TCP (MPTCP) ist der Standard RFC 8684. Er erweitert das klassische TCP, damit eine einzelne Verbindung gleichzeitig über mehrere Netzwerkpfade laufen kann. Ein Smartphone kann WiFi und Mobilfunk im selben Moment nutzen, für dieselbe Verbindung. Ein Server mit mehreren Schnittstellen kann dasselbe tun, für Redundanz oder um Bandbreite zu summieren. Apple nutzt es produktiv schon seit iOS 7, im Jahr 2013, für Siri: das ist der bekannteste reale Anwendungsfall. Manche Mobilfunkanbieter, zum Beispiel in Südkorea, setzen es für WiFi/LTE-Bonding ein. Mehrere Rechenzentren nutzen es für Multihoming zwischen verschiedenen Uplinks. Im Linux-Mainline-Kernel ist es seit Version 5.6 enthalten.

Der Punkt, der mich die Augenbraue hochziehen ließ, ist ein anderer. Seit Version 1.24 verlangen in Go geschriebene Programme standardmäßig MPTCP für lauschende Sockets. Das Go Security Team hat das am 29. Oktober bestätigt. Gleichzeitig hat es eine unangenehme Warnung ausgesprochen: Der Bug, von dem wir heute sprechen, ist nicht MPTCP-spezifisch. Ein System ohne aktive MPTCP-Listener kann trotzdem ähnlichen Angriffen ausgesetzt sein. Der verwundbare Code liegt im generischen TCP-IPv4-Pfad, nicht in einem optionalen Modul. Man kann MPTCP pro Programm deaktivieren, mit der Variable GODEBUG=multipathtcp=0 zur Laufzeit. Doch das Go Security Team bezeichnet diese Abmilderung als „brüchig“: Ein einziger verbleibender MPTCP-Listener reicht aus, um sie zunichtezumachen. Niemand hat bewiesen, dass jeder funktionierende Exploit tatsächlich von MPTCP abhängt. Deshalb bleibt der MPTCP-Code eine Angriffsfläche, auch wenn du ihn in deinem Stack nie bewusst aktivierst: Es reicht, dass er in den Kernel compiliert und erreichbar ist.

Das MPTCP-Projekt selbst erklärt auf seiner eigenen Seite, dass die wichtigsten aktuellen Linux-Distributionen den Kernel standardmäßig mit MPTCP-Unterstützung compiliert ausliefern (CONFIG_MPTCP=y). Es nennt ausdrücklich Debian, Ubuntu, RHEL und Fedora. Das ist eine Aussage des Projekts selbst, keine unabhängige Überprüfung Distribution für Distribution, aber das Konzept bleibt gültig: Die Unterstützung ist auf Kernel-Ebene aktiviert, nicht „opt-in“ auf Betriebssystemebene. Nur die Aushandlung pro einzelner Verbindung bleibt Aufgabe der Anwendung.

Die Schwachstelle im Linux-Kernel CVE-2026-98432 im Überblick

Das CVE-Team des Linux-Kernels hat CVE-2026-98432 am 15. Oktober 2026 veröffentlicht. Der Upstream-Fix war bereits zehn Tage zuvor angewendet worden, am 5. Oktober. Es kommt häufig vor, dass die Veröffentlichung dem Commit mit einer gewissen Verzögerung folgt. Der CVSS-Score von 9,8 (kritisch) kam erst am 24. Oktober, neun Tage nach der Veröffentlichung der CVE.

Das Problem liegt in der Behandlung des TCP-Handshakes für IPv4, genauer in der Funktion tcp_v4_syn_recv_sock(). Wenn eine Verbindung erstellt wird, werden die IP-Optionen des SYN-Pakets vom wartenden Request-Socket an den neuen Socket übergeben. Zum Beispiel Record Route oder Timestamp, falls der Client sie in einem eigens konstruierten SYN einfügt. Das Problem ist, dass sie per Referenz übergeben werden, nicht per Kopie, und ohne das Lock des Listeners. Laut der technischen Analyse des Patches heißen die betroffenen Strukturen inet_opt und ireq_opt. Eine zweite CPU kann diesen Puffer mit kfree() freigeben, aufgerufen von inet_sock_destruct() oder von tcp_v4_reqsk_destructor(). Währenddessen liest eine erste CPU ihn noch in ip_options_build(), um das SYNACK zu bauen. Es ist ein klassisches Use-after-free, verursacht durch eine Race Condition. Der entsprechende IPv6-Pfad, tcp_v6_syn_recv_sock(), kopiert die Optionen statt sie per Referenz zu übergeben: Er ist von der Haupt-Race nicht betroffen. Es gibt auch einen zweiten Angriffsweg, über die Migration von Request-Sockets: net.ipv4.tcp_migrate_req=1 oder ein eBPF-Programm mit BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. Beide sind standardmäßig deaktiviert.

Der Bug ist remote ausnutzbar und erfordert laut Einschätzung des Kernel-Teams weder Authentifizierung noch Benutzerinteraktion. Er ist seit Kernel-Version 4.4 vorhanden. Der Fix stammt von Eric Dumazet, gemeldet von Xinyang Ge von Anthropic. Er verschiebt die Freigabe des Speichers auf die Zeit nach einer RCU-Grace-Period, mit kfree_rcu(): So kann keine CPU mehr einen bereits freigegebenen Puffer lesen. Die korrigierten stabilen Versionen sind 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und die Mainline ab 7.3-rc7.

Widersprüchliche CVSS-Scores: Nicht alle Hersteller sind sich einig

Hier wird die Geschichte komplizierter. Das Kernel-CVE-Team und Ubuntu bewerten die Angriffskomplexität als niedrig und vergeben 9,8 (kritisch). Oracle und SUSE vergeben dagegen 8,1 (wichtig): derselbe CVSS-Vektor, aber hohe Angriffskomplexität. Red Hat hat merkwürdigerweise zwei Bewertungen, die nicht übereinstimmen. Die öffentliche CVE-Seite zeigt „Moderate, 5.9“. Die maschinenlesbare Advisory-Datei, aktualisiert am 29. Oktober, zeigt dagegen „Important, 8.1“, mit hoher Auswirkung auf Vertraulichkeit und Integrität. Am selben Tag hat der interne Bugtracker von Red Hat die Schwere von medium auf high angehoben. Amazon vergibt seinerseits 7,0. Zum Zeitpunkt, an dem ich das schreibe, hat die NVD noch keinen eigenen Score veröffentlicht.

Das sollte man ehrlich sagen. Diese interne Unstimmigkeit bei Red Hat ist kein Detail, das ich selbst hergeleitet habe: Sie wird so vom Originalartikel von The Hacker News berichtet, meiner Hauptquelle für diese Daten. Es ist nicht das erste Mal, dass ein Hersteller für denselben Bug zwei unterschiedliche Zahlen auf unterschiedlichen Kanälen veröffentlicht. Aber hier sagt der Sprung von „moderat“ zu „wichtig“ am selben Tag viel aus. Auch für diejenigen, die den Code schreiben, ist es schwierig, die tatsächliche Ausnutzbarkeit einer Race Condition im Kernel mit Sicherheit einzuschätzen.

Patch-Status: Debian schon korrigiert, andere noch nicht

Das ist der Punkt, der mich am direktesten betrifft: Die Hosting-Umgebungen, die ich verwalte, laufen auf Debian Stable. Und hier sprechen die Fakten klar, ohne dass man etwas betonen müsste: Debian hat diese Schwachstelle im Linux-Kernel bereits korrigiert, sowohl auf trixie als auch auf bookworm. Debian trixie (stable) wurde am 16. Oktober 2026 korrigiert, mit dem Paket linux 6.12.113-1, Advisory DSA-6568-1. Debian 12 (bookworm) wurde in zwei Schritten korrigiert: am 17. und am 22. Oktober 2026, mit linux 6.1.190-1 (Advisory DLA-4841-1) und linux-6.12 6.12.113-1~deb12u1 (Advisory DLA-4850-1). In seiner eigenen Tracking-Tabelle listet Debian für diese CVE keinen eigenen CVSS-Score auf. Es markiert nur den Fix-Status für jedes Release: Das ist die Information, die wirklich zählt, für alle, die entscheiden müssen, ob sie einen Server neu starten.

Es hilft, das mit dem Status anderer weit verbreiteter Distributionen zu vergleichen, um der Sache Gewicht zu geben. Am 30. Oktober hat Red Hat den Status für RHEL 8, 9, 10 und OpenShift 4 aktualisiert. Zuvor war es „fix deferred“ (markiert am 29. Oktober), jetzt ist es „affected“. Kein Veröffentlichungsdatum wurde mitgeteilt. Ubuntu gilt auf allen unterstützten Versionen (22.04, 24.04, 26.04, 26.10) noch als „in Bearbeitung“, ohne Datum. Ubuntu 16.04, 18.04 und 20.04 gelten als verwundbar, ohne dass überhaupt ein Fix aufgelistet ist. SUSE Linux Enterprise Server, von SP4 bis SP7 plus 16.0, befindet sich in derselben Lage. Oracle Linux (UEK), openSUSE Leap 16.0, SUSE Linux Micro 6.2 und Amazon Linux 2023 sind dagegen schon korrigiert. RHEL 7 ist nicht betroffen: Der verwundbare Codepfad wurde auf dieser Release nie ausgeliefert.

Ich sage das nicht, um Ubuntu oder RHEL schlechtzumachen. Es bleiben seriöse Distributionen mit robusten Sicherheitsprozessen. Ich sage es, weil bei diesem einzelnen Bug, in diesem Zeitfenster, die Fakten so sind: Wer sich auf Hosting mit Debian Stable verlässt, hat den Fix schon installiert. Auf anderen, stark genutzten Distributionen bleibt der Server dagegen für einen unbestimmten Zeitraum exponiert. Das ist ein konkreter, nachprüfbarer Vorteil, wenn man sich die Daten ansieht. Es ist keine Meinung über das Debian-Projekt im Allgemeinen.

Der (berichtete, nicht unabhängig verifizierte) Exploit von Anthropic

Der ungewöhnlichste Teil dieser Geschichte betrifft Anthropic, das Unternehmen, das den Bug als erstes über Xinyang Ge gemeldet hat. Laut Branchenberichten hat eines seiner internen KI-Modelle, nicht öffentlich veröffentlicht, selbstständig einen funktionierenden Root-Exploit gebaut. Ausgehend nur vom Patch und vom Report als Prompt. Der zweistufige Angriff würde so funktionieren. In der ersten Phase lässt die Race den Angreifer zusätzliche Bytes aus der Antwort des Kernels empfangen. Von dort gewinnt er eine Kernel-Adresse, um KASLR auszuhebeln. In der zweiten Phase würde derselbe Bug einen Buffer-Overflow verursachen. Er überschreibt einen Callback-Pointer mit der Adresse eines Payloads, den der Angreifer bereits im Kernel-Speicher platziert hat. Wenn der Kernel diesen Pointer aufruft, führt das Payload einen beliebigen Shell-Befehl als Root aus. Eine verlorene Race würde nur diesen einzelnen Verbindungsversuch scheitern lassen, ohne das System abstürzen zu lassen: Wiederholte Versuche wären also möglich. Im von Anthropic beschriebenen Test: 48 Minuten, um die Kernel-Adresse zu stehlen, weitere 5 Minuten bis zur Befehlsausführung.

Red Hat sagt, dass ein entfernter Angreifer, der einen exponierten TCP-Dienst erreicht, die Race generell auslösen kann. Der von Anthropic beschriebene Root-Exploit hätte jedoch gezielt Server mit einem aktiven Multipath-TCP-Listener angegriffen. Der Beitrag von Anthropic klärt nicht, ob ein Server ohne MPTCP genauso ausnutzbar ist. Weder der CVE-Eintrag noch der Upstream-Fix erwähnen MPTCP an irgendeiner Stelle. Es ist die Fachpresse, keine Primärquelle, die diesen Zusammenhang berichtet: Ich schreibe das deshalb mit der Skepsis, die es verdient, nicht als zu hundert Prozent gesicherte Tatsache. Anthropic hat weder den Exploit-Code veröffentlicht, noch die genaue verwendete Kernel-Version, noch die Konfiguration des Zielservers. Ein anderes Unternehmen, Innora, hat eine Root-Cause-Analyse veröffentlicht, mit einer QEMU-Reproduktionsumgebung. Es hat erklärt, kurzfristig keinen bewaffneten Exploit zu veröffentlichen. Derzeit gibt es keine Beweise für eine tatsächliche Ausnutzung durch Hersteller oder CERTs. Der Bug ist nicht im CISA-KEV-Katalog, laut der von CIRCL Luxemburg aktualisierten Kopie vom 28. Oktober.

Was jetzt auf deinen Servern zu tun ist

Kein Hersteller hat einen offiziell sanktionierten Workaround für diese Schwachstelle im Linux-Kernel veröffentlicht. Red Hat sagt ausdrücklich, dass keine der bisher kursierenden Maßnahmen seinem Standard an Deployment-Einfachheit und Stabilität entspricht. Die primäre Abmilderung bleibt, den korrigierten Kernel einzuspielen und neu zu starten, sobald der Patch für deine Distribution verfügbar ist. Auf Debian ist er das schon. Auf RHEL und Ubuntu noch nicht, zum Zeitpunkt, an dem ich das schreibe.

Als Verteidigung in der Tiefe, nicht als endgültige Lösung, ergeben einige Maßnahmen Sinn. Prüfen, dass net.ipv4.tcp_migrate_req auf 0 gesetzt ist. Kontrollieren, dass keine eBPF-Programme mit BPF_SK_REUSEPORT_SELECT_OR_MIGRATE geladen sind. Eine Filterung eingehender IPv4-Pakete mit Record-Route- oder Timestamp-Optionen erwägen. Abstürze überwachen, die ip_options_build, ip_build_and_send_pkt oder skb_under_panic zitieren. Ein Inventar eventuell exponierter MPTCP-Listener erstellen und vermeiden, sie ohne Grund erreichbar zu lassen. Wenn du auch Schutz gegen häufigere Angriffe auf Anwendungsebene verwaltest, findest du unter wie ich meine Server bis zum Patch für PHP2Shell abgesichert habe denselben Ansatz. Er lautet: abmildern, was möglich ist, während man auf den endgültigen Fix wartet, ohne Schutz zu versprechen, den es nicht gibt.

Für alle, die mich fragen, ob sie sofort aktualisieren sollen: Wenn du Debian Stable nutzt, ist der korrigierte Kernel schon in den Security-Repositories. Das Update ist einfach, und das Zeitfenster der Exposition ist schon geschlossen. Wenn du andere Distributionen nutzt, gibt es heute noch keinen Patch zu installieren. Es lohnt sich, die Advisories deines Herstellers in den nächsten Tagen genau zu verfolgen: Die Lage ändert sich schnell.

Quellen: The Hacker News, Debian Security Tracker und der Fix-Commit. Debian, Red Hat, Ubuntu und die anderen genannten Namen sind Marken ihrer jeweiligen Eigentümer.

The post Linux-Kernel-Schwachstelle: ein Use-after-free im TCP IPv4 first appeared on Matteo Cisilino.

Warum ich das E-Mail-Protokoll in WordPress vor den Server-Logs kontrolliere

Der typische Fall ist immer derselbe. Ein Kontaktformular, das „nicht ankommt“. Ein Kunde, der die Passwort-Reset-E-Mail nicht erhält. Eine Bestellung ohne Bestätigung. Ohne ein Protokoll zur Hand ist die erste Vermutung der Spam-Ordner. Dann die Logs des SMTP-Servers. Dann vielleicht die Firewall. Mit FluentSMTP überspringe ich diese Schritte. Ich sehe sofort, ob WordPress wirklich versucht hat, diese E-Mail zu versenden. An wen, wann, mit welcher Antwort vom Versandserver.

FluentSMTP protokolliert jeden Aufruf von wp_mail(). Nicht nur die E-Mails von Drittanbieter-Plugins, auch die vom Core selbst: Benachrichtigungen über neue Benutzer, Update-Erinnerungen, Fehlerhinweise. Für jeden Versand zeigt das Protokoll Absender, Empfänger, Betreff, vollständige Header, Nachrichtentext. Und die Antwort des SMTP-Providers oder der verwendeten API. Ist eine E-Mail fehlgeschlagen, steht diese Serverantwort genau dort. Ich muss sie nicht raten.

Was wirklich im Versandprotokoll steht

Das Plugin unterstützt Dutzende Connectoren: Amazon SES, SendGrid, Mailgun, Brevo, Postmark, SparkPost. Auch Google Workspace und Microsoft 365 über OAuth, neben dem klassischen generischen SMTP. Auf den Websites, die ich betreue, nutze ich fast immer authentifiziertes SMTP mit der Domain des Kunden. Manchmal eine dedizierte API, wenn das E-Mail-Volumen wächst. In beiden Fällen bleibt das Protokoll gleich. Jede Zeile hat einen Status, versendet oder fehlgeschlagen. Es gibt eine Schaltfläche, um den Inhalt anzusehen oder die Nachricht erneut zu senden, ohne dass der Nutzer die Aktion wiederholen muss, die sie ausgelöst hat.

Der erneute Versand ist die Funktion, die ich am häufigsten nutze. Ein Formular, das zweimal ausgefüllt wurde, weil „es nicht ankam“, wird zu einem Klick im Protokoll. Keine neue Meldung an den Kunden. Für wiederholte Fehlschläge habe ich Benachrichtigungen über Telegram aktiviert. Sobald eine Verbindung nicht mehr funktioniert, weiß ich es, bevor mir jemand schreibt. Statt es aus einem Support-Ticket zu erfahren.

Das Protokoll betrifft nicht nur Benachrichtigungen direkt an mich oder den Kunden, der die Seite verwaltet. Dort landet jede ausgehende E-Mail, die die Website an Dritte schickt: die Bestellbestätigung, die ein Online-Shop an den Endkunden sendet, die Zahlungsquittung, die Versandbenachrichtigung. Kommt diese Bestätigung nicht an, zeigt das E-Mail-Protokoll in WordPress das genauso wie eine interne Benachrichtigung, mit derselben Schaltfläche, um sie an den richtigen Empfänger neu zu senden, ohne dass er den Kauf wiederholen muss.

Wie ich FluentSMTP auf den Websites konfiguriere, die ich betreue

Nach dem Verbinden des passenden Connectors ändere ich die Aufbewahrungsdauer des Protokolls. Standardmäßig bleibt es lange aktiv. Ich stelle sie auf 30 bis 60 Tage, je nach Traffic der Website. Das reicht, um einem spät gemeldeten Problem nachzugehen. Ohne die Datenbank mit Zeilen zu füllen, die ich nie ansehen werde. Danach aktiviere ich mindestens einen Benachrichtigungskanal für Fehlschläge, Telegram oder Slack, je nach Kunde. Das Protokoll allein warnt niemanden, es muss geöffnet werden, um gelesen zu werden.

Auf Websites mit Kontaktformular nutze ich zusätzlich Cisilino Site Defense Network zum Blockieren von Bots. Weniger eingehender Spam bedeutet weniger E-Mails aus den Formularen. Das Protokoll bleibt übersichtlicher, mit weniger Rauschen, das ich beim Suchen der richtigen Nachricht ausblenden muss.

Die SMTP-Zugangsdaten bleiben nicht im Klartext in der Datenbank

Ein Detail, das ich immer prüfe, bevor ich eine Verbindung speichere: wo die Zugangsdaten landen. FluentSMTP verschlüsselt sie standardmäßig mit den SALT-Schlüsseln von WordPress, denselben, die schon in wp-config.php für die Sicherheit der Sitzungen stehen. Man kann die Verschlüsselung deaktivieren, aber das Plugin selbst rät davon ab. Auf den Websites, die ich betreue, bevorzuge ich eine andere Option: das API- oder SMTP-Passwort direkt in wp-config.php speichern, außerhalb der Datenbank, mit Konstanten, die definiert sind, bevor das Plugin sie liest. So legt auch ein Datenbank-Dump oder ein unbefugter Zugriff aufs Panel den Schlüssel des Versandproviders nicht offen. Es ist dasselbe Prinzip, das ich auch sonst anwende: weniger Geheimnisse in der Datenbank, umso besser.

Mehrere Verbindungen gleichzeitig, nicht nur eine nach der anderen

FluentSMTP erlaubt es, mehrere Verbindungen gleichzeitig einzurichten, nicht nur eine nach der anderen. Auf einer Website lege ich die Standardverbindung fest und füge eine zweite als Reserve hinzu: Antwortet der erste Provider nicht, wechselt der Versand automatisch zur Reserveverbindung, ohne dass ich eingreifen muss. Die Wahl der Verbindung hängt von der Absenderadresse ab: Jede Verbindung hat ihr eigenes „Von“, der Rest läuft über die Standardverbindung, mit der Reserve nur bereit, falls die Standardverbindung wirklich ausfällt (ein Fehler des Providers, keine E-Mail, die im Spam landet). Das ist einer der Gründe, warum ich das einem einzelnen SMTP ohne Alternative vorziehe: Haben SendGrid oder Amazon SES ein paar Stunden lang ein Problem, versendet die Website trotzdem weiter, und das E-Mail-Protokoll in WordPress zeigt es sofort. Alles in der kostenlosen Version enthalten, ohne eine kostenpflichtige Pro-Version: Man bezahlt nur den gewählten Versandprovider, nicht das Plugin.

Ein täglicher Gesundheitscheck, nicht nur wenn etwas kaputt ist

Neben dem Protokoll Zeile für Zeile führt FluentSMTP jeden Tag automatisch einen Gesundheitscheck der Verbindung durch. Antwortet der Provider nicht mehr, kommt die Warnung, bevor ein Kunde mir schreibt „die Website versendet keine E-Mails mehr“. Dasselbe Panel zeigt eine Grafik mit den täglichen Gesamtzahlen erfolgreicher und fehlgeschlagener Versände: nützlich, um auf einen Blick zu erkennen, ob ein Rückgang normal ist oder das Symptom für etwas, das gerade kaputtgeht, ohne jedes Mal das Protokoll Zeile für Zeile öffnen zu müssen. Es gibt auch eine periodische Zusammenfassung per E-Mail, mit den Zahlen der Woche: kein Fehlerhinweis, sondern ein Bulletin, das ich kurz überfliege, um zu wissen, ob das Versandvolumen im Rahmen liegt.

Wer wie ich mehrere Websites von der Kommandozeile aus verwaltet, findet in FluentSMTP auch WP-CLI-Befehle: einen Versandtest, einen Gesundheitscheck der Verbindung, Statistiken und das Aufräumen alter Protokolleinträge. Ich nutze sie in denselben Skripten, die schon auf den Servern für andere Wartungsaufgaben laufen, ohne das Panel jeder Website einzeln öffnen zu müssen.

Was das E-Mail-Protokoll in WordPress nicht leisten kann

Es ist keine Wunderlösung. Die Aufbewahrung richtet sich nach Tagen, nicht nach einer Höchstzahl an Zeilen. Auf einer Website mit viel transaktionalem Traffic kann die Protokolltabelle schnell wachsen. Es lohnt sich, sie im Blick zu behalten oder eine kürzere Aufbewahrungsdauer einzustellen. Fehlerbenachrichtigungen kommen nur über die konfigurierten Chat-Kanäle, nicht per E-Mail. Macht Sinn: Eine E-Mail, die vor einer fehlgeschlagenen E-Mail warnt, kann selbst fehlschlagen. Aber das sollte man wissen, bevor man sich darauf verlässt.

Schließlich zeigt das Protokoll, was auf Seiten von WordPress und auf Seiten des Providers passiert ist. Es garantiert nicht die Zustellung im Postfach des Empfängers. Ist eine E-Mail als versendet markiert, landet aber im Spam, ist das ein Problem des Domain-Rufs oder der SPF/DKIM-Konfiguration. Nichts, was ein Protokoll allein lösen kann. Trotzdem bleibt es die erste Stelle, an der ich nachsehe, bevor ich irgendetwas anderes prüfe.

Das Plugin ist kostenlos und Open Source. Die offizielle Seite auf wordpress.org, ohne Funktionen, die hinter einer Pro-Version blockiert sind. Wer auch nur eine Website mit Kontaktformular betreut, für den lohnt es sich, es nur für das E-Mail-Protokoll in WordPress zu installieren. Löst es das erste „ich habe die E-Mail nicht bekommen“ in einer Minute statt in einer halben Stunde, hat es sich bereits ausgezahlt.

The post E-Mail-Protokoll in WordPress: warum ich es mit FluentSMTP kontrolliere first appeared on Matteo Cisilino.

In diesem Artikel erkläre ich, was das ist und welche PHP-Versionen betroffen sind. Ich erzähle, wie ich die Server, die ich betreue, abgesichert habe, solange es keinen Patch gab. Außerdem beschreibe ich, wie ich zum endgültigen Update gekommen bin. Hier findest du auch das Skript, das ich benutzt habe, und die Befehle zum Starten.

Was ist PHP2Shell

Das Problem liegt darin, wie PHP Anfragen vom Typ multipart/form-data liest. Das ist das Format, mit dem der Browser Dateien sendet. PHP verarbeitet es, bevor irgendein Skript startet.

Darum braucht es kein Upload-Formular. Eine einzige Anfrage an irgendeine PHP-Datei der Seite kann genügen.

Die beiden Lücken in Kürze:

• CVE-2026-109618. Wenn der Speicher ausgeht, während PHP die Anfrage liest, werden Daten beschädigt. Der Schaden zeigt sich beim Aufräumen am Ende der Anfrage und kann zur Codeausführung führen.
• CVE-2026-109619. Ein Teil des Zustands einer Anfrage bleibt im Speicher. Eine spätere Anfrage im selben Prozess verwendet ihn wieder.

Diese technischen Details stammen aus der Analyse des niederländischen NCSC und aus anderen öffentlichen Quellen. Ich habe nicht versucht, die Lücken auf meinen Servern auszunutzen.

Welche PHP-Versionen sind betroffen

Die korrigierten Versionen erschienen am 21. Oktober 2026: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Jede ältere Version ist betroffen.

Für die Zweige 8.1 und älter gibt es keine offizielle korrigierte Version, weil sie nicht mehr unterstützt werden. PHP hat nur minimale Backports des Quellcodes für 7.4, 8.0 und 8.1 veröffentlicht. Für noch ältere Zweige ist nichts bekannt.

Das Risiko betrifft jede Art, PHP auszuführen. Am stärksten ausgesetzt ist mod_php. Auch PHP-FPM, php-cgi, FrankenPHP und LiteSpeed zählen. Dazu kommen alle Anwendungen darüber: WordPress, Joomla, Drupal, Nextcloud, phpMyAdmin, Roundcube und das ISPConfig-Panel.

Bei Debian gibt es ein Detail, das man kennen sollte. Debian übernimmt die Korrekturen als Backport und ändert die PHP-Versionsnummer nicht. Ein Server kann eine niedrige Nummer zeigen und trotzdem schon korrigiert sein. Deshalb vergleicht das Skript keine Versionen. Es prüft, ob das Changelog des installierten Pakets die beiden CVEs nennt.

Die Schutzmaßnahme, bis der Patch da ist

Als die Lücken öffentlich wurden, waren die Patches für die Distributionen noch nicht verfügbar. Ich wollte die Server nicht ungeschützt lassen. Also habe ich das Risiko mit einem Skript verringert.

Die Schutzmaßnahme ist kein Patch. Wer session.upload_progress abschaltet, schließt nur einen der bekannten Angriffswege zur CVE-2026-109619. Gegen die CVE-2026-109618 hilft das nicht. Die Maßnahme sollte die Angriffsfläche bis zum Update verkleinern, nicht das Update ersetzen.

Was das Skript macht

Das Skript ist für Debian 12 und 13 gedacht. Es funktioniert mit Apache (mod_php, FastCGI, suPHP, PHP-FPM) und mit Nginx (PHP-FPM). Es erkennt Server, die mit ISPConfig verwaltet werden, ob Apache oder Nginx.

Die Optionen:

• Ohne Optionen prüft es nur. Für jedes PHP-Paket kontrolliert es, ob das Changelog die beiden CVEs nennt. Es meldet Prozesse, die noch eine alte Binärdatei nutzen, und liest die aktiven Einstellungen und die offenen Web-Ports aus.
• --update aktualisiert zuerst den Paketindex.
• --logs sucht verdächtige Spuren: neue PHP-Dateien in Upload- oder Cache-Ordnern, typische Webshell-Muster, Verweise auf php2shell in den Logs. Das ist eine Heuristik und beweist keine Kompromittierung.
• --harden wendet die unten beschriebene Absicherung an.
• --dry-run zeigt zusammen mit --harden, was passieren würde, ohne etwas zu ändern.
• --skip-disable-functions lässt zusammen mit --harden disable_functions unangetastet.
• --rollback nimmt zurück, was --harden angewendet hat.

Was sich mit –harden ändert

Für jede PHP-Version in /etc/php legt das Skript die Datei mods-available/cve-hardening.ini an. Es aktiviert sie mit phpenmod für die SAPIs fpm, apache2 und cgi. So gilt der Schutz für alle Seiten auf einmal.

Die originalen php.ini bleiben unberührt. Die CLI wird nicht angefasst, also laufen composer, artisan und wp-cli weiter.

Die Datei setzt drei Dinge:

• session.upload_progress.enabled = Off
• expose_php = Off
• disable_functions mit exec, passthru, shell_exec, system, proc_open, popen und pcntl_exec, zusätzlich zu den bereits vorhandenen.

Danach testet das Skript die Konfiguration und lädt PHP-FPM und Apache nur neu, wenn der Test besteht. Vor dem Schreiben legt es ein Backup in /var/backups/php-cve-hardening/ an.

Die Grenzen, die du kennen solltest

• disable_functions kann manche Anwendungen kaputt machen, zum Beispiel WordPress mit bestimmten Plugins oder Magento. Dann nimm --rollback oder starte erneut mit --skip-disable-functions.
• Die Direktiven php_admin_value in den PHP-FPM-Pools haben Vorrang vor der globalen Datei. Das Skript meldet sie, ändert sie aber nicht.
• Bei ISPConfig werden die Dateien in pool.d vom Panel neu erzeugt. Overrides korrigierst du im Panel unter Sites, Website, Options, Custom php.ini settings, nicht von Hand.
• Die php.ini einzelner Seiten (FastCGI- oder suPHP-Modus von ISPConfig) und PHP-Versionen in /opt werden nicht verwaltet. Sie müssen separat geprüft werden.

So startest du das Skript

Das Skript liegt hier: https://cisilino.com/mscripts/php20261.sh

Bevor du etwas aus dem Internet ausführst, lies es. Du kannst es herunterladen und öffnen:

wget -qO php20261.sh https://cisilino.com/mscripts/php20261.sh
less php20261.sh

Wenn du es direkt aus der Ferne starten willst, brauchst du Root-Rechte. Das sind die Befehle, in der Reihenfolge, die ich empfehle.

1. Nur prüfen, mit Aktualisierung des Paketindex:

wget -qO- https://cisilino.com/mscripts/php20261.sh | sudo bash -s -- --update

2. Absicherung simulieren, ohne Änderungen:

wget -qO- https://cisilino.com/mscripts/php20261.sh | sudo bash -s -- --harden --dry-run

3. Anwenden:

wget -qO- https://cisilino.com/mscripts/php20261.sh | sudo bash -s -- --harden

4. Entfernen, falls etwas kaputtgeht:

wget -qO- https://cisilino.com/mscripts/php20261.sh | sudo bash -s -- --rollback

Nach --harden und nach --rollback musst du nichts von Hand neu starten. Das Skript lädt PHP-FPM und Apache selbst neu, nachdem es die Konfiguration getestet hat. Ein Neustart ist dagegen nach dem Update des PHP-Pakets nötig, weil die laufenden Prozesse die alte Binärdatei im Speicher halten:

sudo systemctl restart 'php*-fpm' apache2

Die Anführungszeichen um php*-fpm sind wichtig. Ohne sie expandiert die Shell das Sternchen, nicht systemctl. Wenn der Server nur Nginx nutzt, lass apache2 weg.

Das Ergebnis des Skripts ist auch ein Exit-Code: 0, wenn alles in Ordnung ist, 1 bei Warnungen, 2 wenn das System verwundbar ist oder etwas getan werden muss.

Auf Servern mit ISPConfig: ispconfig-multipart-guard

Wer ISPConfig nutzt, hat ein zusätzliches Werkzeug. Das Projekt hat das Skript ispconfig-multipart-guard veröffentlicht, beschrieben in der offiziellen ISPConfig-Meldung.

Das Prinzip ist einfach. Wenn das Problem in Multipart-Anfragen liegt, stoppt der Webserver sie, bevor sie PHP erreichen:

• Es blockiert Anfragen mit Content-Type: multipart/... für alle Seiten, für ausgewählte Seiten oder für das Control Panel;
• bei Nginx antwortet es auf PHP-Anfragen der blockierten Seiten mit 415, statische Dateien bleiben unverändert. Bei Apache antwortet es mit 403, auch bei statischen Dateien;
• standardmäßig blockiert es nur das ISPConfig-Panel. Die Seiten blockierst du mit Befehlen wie block all oder block esempio.it;
• es legt einen Cronjob an, der alle 5 Minuten seine Hooks wiederherstellt, falls ISPConfig die Konfiguration neu schreibt;
• es hat eine Liste erlaubter IPs, die weiterhin Dateien hochladen dürfen.

Es läuft auf Debian und Ubuntu, mit ISPConfig 3.2 oder 3.3 (auch ohne ISPConfig), mit Nginx oder mit Apache 2.4 und neuer.

Der Preis: Auf blockierten Seiten funktionieren Uploads nicht. Das gilt auch für CMS-Medien, Formularanhänge, Anhänge im Webmail und Importe in phpMyAdmin. Normale Seiten und urlencoded-Formulare laufen weiter. Auch das ist eine vorläufige Maßnahme und keine Korrektur.

Dieses Skript und meines schließen sich nicht gegenseitig aus. Meines greift in die PHP-Konfiguration ein, das von ISPConfig in den Webserver. Ich habe sie nicht in der Praxis verglichen und kann dir nicht sagen, wie sie sich zusammen in jeder Konfiguration verhalten.

Das endgültige Update, in zwei Schritten

Die Schutzmaßnahmen sollten nur kurz gelten. Ich habe die Server aktualisiert, sobald die Updates verfügbar waren, in zwei Schritten:

1. Direkt kompilieren. Solange die Distribution auf dem jeweiligen Server ihr Paket noch nicht veröffentlicht hatte, habe ich PHP aus dem Quellcode in den korrigierten Versionen kompiliert.
2. Offizielles Paket. Als das offizielle Paket der Distribution für diesen Server erschien, habe ich die Kompilierung durch das Paket ersetzt.

Der zweite Schritt ist wichtig. Ein von Hand kompiliertes PHP aktualisiert sich nicht zusammen mit dem Rest des Systems. Das Paket der Distribution schon, und das Skript kann das über das Changelog prüfen.

Was du jetzt tun solltest

1. Aktualisiere PHP auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Unter Debian kannst du auch das Paket der Distribution nehmen, wenn das Changelog die beiden CVEs nennt.
2. Starte PHP-FPM und Apache neu und lass das Skript dann ohne Optionen noch einmal laufen. Es darf keine Probleme mehr melden.
3. Wenn du PHP 8.1 oder älter nutzt, plane den Wechsel auf einen unterstützten Zweig. Für diese Zweige gibt es keine offizielle korrigierte Version.
4. Lass session.upload_progress deaktiviert, bis zur nächsten Korrekturversion, falls deine Anwendung es nicht braucht.
5. Prüfe Logs und neue Dateien, mit --logs oder von Hand, und suche nach PHP-Dateien, die in Upload-Ordnern aufgetaucht sind.
6. Vergiss PHP in Containern, Images und Appliances von Dritten nicht. Sie müssen separat aktualisiert werden.
7. Wenn deine Seite WordPress nutzt: Das Plugin Cisilino Site Defense Network löst PHP2Shell nicht. Es schützt aber den Login und führt ein Aktivitätsprotokoll, das hilft zu verstehen, was auf der Seite passiert.

Quellen

• ISPConfig: PHP2Shell, kritische PHP-Schwachstellen (CVE-2026-109618, CVE-2026-109619)
• NCSC-NL: Wiki zu PHP2Shell

ISPConfig, PHP, Debian und die anderen genannten Namen sind Marken der jeweiligen Inhaber. Sie dienen nur zur Identifizierung der Produkte.

The post PHP2Shell: So habe ich meine Server bis zum Patch geschützt first appeared on Matteo Cisilino.

Ich stand davor nach einer Optimierung. Ich hatte OPTIMIZE TABLE ausgeführt in der Hoffnung, Platz zurückzugewinnen, aber das Dateisystem schrumpfte nicht wie erwartet. Ohne ein „Vorher“, mit dem man das „Nachher“ vergleichen konnte, ließ sich nicht sagen, ob die Optimierung gewirkt hatte, welche Datenbank wirklich verantwortlich war und ob der fehlende Platz vielleicht ganz woanders steckte.

Die Werkzeuge, die ich hatte, beantworteten nur die Hälfte des Problems.

• du zeigt die Dateien auf der Platte, sagt aber nicht, zu welcher Tabelle sie gehören.
• information_schema (oder pg_class bei PostgreSQL) liefert die logischen Größen, sieht aber weder Binlogs noch ibdata1, Undo-Logs oder WAL.
• beide zeigen nur einen einzigen Augenblick: Der Vergleich über die Zeit bleibt Handarbeit mit Copy-and-paste und Tabellenkalkulation.

Ich brauchte etwas Einfaches: den Zustand aller Datenbanken zu einem bestimmten Zeitpunkt festhalten, später erneut festhalten und mir sagen lassen, was sich geändert hat, die Unterschiede sortiert vom größten zum kleinsten. So fällt der Übeltäter sofort auf.

Herausgekommen ist ein einzelnes Bash-Skript ohne Abhängigkeiten außer dem Datenbank-Client und den üblichen Linux-Werkzeugen (awk, du, df). Es funktioniert mit MySQL/MariaDB und mit PostgreSQL. Ich teile es hier in der Hoffnung, jemandem denselben frustrierenden Nachmittag zu ersparen.

Was es tut

Das Skript hat vier Befehle.

• snapshot speichert den aktuellen Zustand (Datenbanken, Tabellen, Dateien im Datenverzeichnis, Platz des Dateisystems).
• compare vergleicht zwei Momentaufnahmen und zeigt die Unterschiede, die größten zuerst.
• report zeigt die größten Datenbanken und Tabellen einer einzelnen Momentaufnahme.
• list listet die gespeicherten Momentaufnahmen auf.

Der Vergleich ist in vier Abschnitte unterteilt, damit keine blinden Flecken bleiben.

• Größe jeder Datenbank (Daten + Indizes).
• freier oder rückgewinnbarer Platz (data_free bei MySQL, Schätzung der toten Tupel bei PostgreSQL).
• Größe jeder Tabelle.
• tatsächliche Dateien im Datenverzeichnis: Datenbankordner, ibdata1, Binlogs, Undo, pg_wal.

Der letzte Abschnitt löst das Rätsel oft. Viele Male gehört der „auffällige“ Platz zu keiner Datenbank, sondern zu den Binärlogs oder zu den gemeinsamen InnoDB-Dateien.

Voraussetzungen

• Linux mit Bash 4 oder höher, awk, du, df (alles Standard).
• der Client mysql oder psql, mit einem Benutzer, der die Metadaten aller Datenbanken lesen darf.
• Root-Rechte (oder die des Benutzers mysql/postgres), wenn Sie auch die Dateien auf der Platte messen wollen; ohne sie wird dieser Abschnitt mit einer Warnung übersprungen.

Installation

Speichern Sie das Skript (am Ende des Artikels) in einer Datei und machen Sie es ausführbar.

nano db_space_compare.sh
chmod +x db_space_compare.sh

Zugangsdaten

Für MySQL/MariaDB ist der sauberste Weg eine Datei ~/.my.cnf mit den Zugangsdaten, damit sie nicht im Befehlsverlauf auftauchen.

[client]
user=root
password=LA_TUA_PASSWORD

Alternativ können Sie die Optionen über eine Umgebungsvariable übergeben.

export MYSQL_OPTS="-u root -pPASSWORD -h 127.0.0.1"

Für PostgreSQL funktionieren ~/.pgpass, die Variablen PG* oder PG_OPTS.

export PG_OPTS="-U postgres -h localhost"

So verwenden Sie es

Der typische Ablauf ist vorher, Optimierung, nachher, Vergleich.

# 1. fotografia prima dell'ottimizzazione
sudo ./db_space_compare.sh snapshot prima

# 2. esegui l'ottimizzazione (OPTIMIZE TABLE, VACUUM FULL, ...)

# 3. fotografia dopo
sudo ./db_space_compare.sh snapshot dopo

# 4. confronto
sudo ./db_space_compare.sh compare prima dopo

Für PostgreSQL genügt es, die Option -e postgres hinzuzufügen.

sudo ./db_space_compare.sh -e postgres snapshot prima
sudo ./db_space_compare.sh -e postgres snapshot dopo
sudo ./db_space_compare.sh -e postgres compare prima dopo

Die verfügbaren Optionen sind.

• -e mysql|postgres wählt die Engine (Standard: mysql).
• -d DIR ändert den Ordner, in dem die Momentaufnahmen gespeichert werden (Standard: ./db_snapshots).
• -n N legt fest, wie viele Zeilen pro Abschnitt angezeigt werden (Standard: 20).

Geben Sie keine Bezeichnung an, erhält die Momentaufnahme Datum und Uhrzeit als Namen. Das ist praktisch, um das Wachstum über die Zeit zu überwachen.

Beispielausgabe

Hier ein Vergleich mit Testdaten, extra gebaut, um einen typischen Fall zu zeigen: Die Datenbank shop schrumpft nach der Optimierung, aber die Datenbank log wächst und die Binlogs verdoppeln sich.

Confronto 'prima' (2026-10-11 20:00:00)  ->  'dopo' (2026-10-11 22:00:00)
Filesystem /var: usato 46.6 GiB -> 48.4 GiB (+1.9 GiB)

=== Database - dimensione totale ===
  NOME                                                      PRIMA         DOPO    DIFFERENZA  NOTE
  log                                                    21.4 GiB     27.5 GiB      +6.1 GiB  +28.3%
  shop                                                    5.6 GiB      3.6 GiB      -2.0 GiB  -35.0%

=== Tabelle - dimensione (dati + indici) ===
  NOME                                                      PRIMA         DOPO    DIFFERENZA  NOTE
  log.eventi                                             21.4 GiB     27.5 GiB      +6.1 GiB  +28.3%
  shop.ordini                                             5.6 GiB      3.6 GiB      -2.0 GiB  -35.0%
  log.nuova                                                   0 B      1.0 KiB      +1.0 KiB  NUOVO

=== File nella data directory (cartelle DB, ibdata1, binlog, undo, WAL) ===
  NOME                                                      PRIMA         DOPO    DIFFERENZA  NOTE
  log                                                    21.4 GiB     27.5 GiB      +6.1 GiB  +28.3%
  mysql-bin.*                                             3.7 GiB      8.4 GiB      +4.7 GiB  +125.0%
  shop                                                    5.7 GiB      3.6 GiB      -2.0 GiB  -36.1%
  ibdata1                                                11.2 GiB     11.2 GiB           0 B

Hier ist der Übeltäter offensichtlich: Die Tabelle log.eventi ist um mehr als 6 GiB gewachsen, und die Dateien mysql-bin.* sind von 3,7 auf 8,4 GiB gestiegen. Die Optimierung von shop hat funktioniert, aber der Gewinn wurde vom Rest aufgefressen.

Wie man die Ergebnisse zum Speicherplatz von MySQL liest

• Am Anfang jedes Abschnitts stehen die Einträge mit der größten Änderung. Eine Datenbank oder Tabelle, die nach der Optimierung nicht schrumpft (oder sogar wächst), ist der erste Verdächtige.
• Schrumpfen die Tabellen, das Dateisystem aber nicht, liegt der Platz woanders: Sehen Sie sich den Abschnitt über die Dateien im Datenverzeichnis an (Binlogs, ibdata1, Undo, pg_wal).
• MySQL/MariaDB: ibdata1 schrumpft nie, auch nicht mit OPTIMIZE TABLE. Mit innodb_file_per_table=OFF ist der Wert von data_free gemeinsam genutzt und wenig aussagekräftig.
• PostgreSQL: Ein einfaches VACUUM gibt keinen Platz an das Betriebssystem zurück, dafür braucht man VACUUM FULL (oder pg_repack). Der angezeigte „rückgewinnbare“ Platz ist eine Schätzung auf Basis der toten Tupel. Wie PostgreSQL den Platz selbst berechnet, erklärt die Dokumentation zur Plattenbelegung.

Wachstum über die Zeit überwachen

Hängt das Problem nicht an einer einzelnen Optimierung, sondern an schrittweisem Wachstum, lohnt es sich, die Momentaufnahmen mit cron zu automatisieren, eine pro Stunde, und dann zwei beliebige Zeitpunkte zu vergleichen.

# crontab -e (come root)
0 * * * * /usr/local/bin/db_space_compare.sh -d /var/lib/db_snapshots snapshot >/dev/null 2>&1

Ohne Bezeichnung heißt jede Momentaufnahme nach Datum und Uhrzeit (zum Beispiel 20261011-140000). Mit list sehen Sie die vorhandenen, mit compare vergleichen Sie zwei. In wenigen Tagen zeigt sich, welche Datenbank ungewöhnlich wächst.

./db_space_compare.sh -d /var/lib/db_snapshots list
./db_space_compare.sh -d /var/lib/db_snapshots compare 20261011-140000 20261012-140000

Das vollständige Skript

Hier ist der Code. Kopieren Sie ihn in eine Datei namens db_space_compare.sh, machen Sie sie ausführbar, und Sie sind startklar.

#!/usr/bin/env bash
#
# db_space_compare.sh
# Fotografa l'occupazione di spazio di tutti i database (MySQL/MariaDB o
# PostgreSQL) e confronta due fotografie (es. prima/dopo l'ottimizzazione)
# per capire quale database, tabella o file occupa spazio in modo anomalo.
#
# Uso:
#   db_space_compare.sh [opzioni] snapshot [etichetta]   (default: data-ora)
#   db_space_compare.sh [opzioni] compare  <prima> <dopo>
#   db_space_compare.sh [opzioni] report   <etichetta>
#   db_space_compare.sh [opzioni] list
#
# Opzioni:
#   -e mysql|postgres   motore del database (default: mysql)
#   -d DIR              cartella delle fotografie (default: ./db_snapshots)
#   -n N                righe mostrate per sezione (default: 20)
#
# Credenziali:
#   MySQL/MariaDB: ~/.my.cnf oppure MYSQL_OPTS="-u root -pPASSWORD -h 127.0.0.1"
#   PostgreSQL:    ~/.pgpass, variabili PG* oppure PG_OPTS="-U postgres -h localhost"
#                  (non mettere -d in PG_OPTS: lo script si collega a ogni database)
#
# Per misurare anche i file su disco (cartelle dei DB, ibdata1, binlog, undo,
# pg_wal) va eseguito come root o come utente mysql/postgres; altrimenti
# quella parte viene saltata con un avviso.
#
# Esempio:
#   sudo ./db_space_compare.sh snapshot prima
#   ... ottimizzazione (OPTIMIZE TABLE / VACUUM FULL / ...) ...
#   sudo ./db_space_compare.sh snapshot dopo
#   sudo ./db_space_compare.sh compare prima dopo

set -euo pipefail
export LC_ALL=C

ENGINE=mysql
OUTDIR=./db_snapshots
TOPN=20
SNAP_IN_PROGRESS=""

die()  { echo "ERRORE: $*" >&2; exit 1; }
warn() { echo "ATTENZIONE: $*" >&2; }
usage() { sed -n '2,/^$/{s/^# \{0,1\}//;p}' "$0"; exit "${1:-0}"; }

cleanup() {
  if [[ -n $SNAP_IN_PROGRESS ]]; then
    rm -rf -- "$SNAP_IN_PROGRESS"
    echo "Fotografia incompleta rimossa: $SNAP_IN_PROGRESS" >&2
  fi
}
trap cleanup EXIT

while getopts ":e:d:n:h" opt; do
  case $opt in
    e) ENGINE=$OPTARG ;;
    d) OUTDIR=$OPTARG ;;
    n) TOPN=$OPTARG ;;
    h) usage 0 ;;
    *) usage 1 ;;
  esac
done
shift $((OPTIND - 1))

[[ $ENGINE == mysql || $ENGINE == postgres ]] || die "motore non valido: '$ENGINE' (usa mysql o postgres)"
[[ $TOPN =~ ^[0-9]+$ ]] || die "-n deve essere un numero"

read -r -a MYSQL_ARGS <<< "${MYSQL_OPTS:-}"
read -r -a PG_ARGS    <<< "${PG_OPTS:-}"

my() { mysql "${MYSQL_ARGS[@]+"${MYSQL_ARGS[@]}"}" --batch --skip-column-names "$@"; }
pg() { psql  "${PG_ARGS[@]+"${PG_ARGS[@]}"}" -X -q -A -t -F $'\t' -v ON_ERROR_STOP=1 "$@"; }

# Funzioni awk comuni: formattazione in KiB/MiB/GiB, chiave e valore di riga.
#   nk = numero di colonne che formano il nome (1 = database, 2 = db.tabella)
#   vc = colonne da sommare per il valore (es. "4,5" = dati + indici)
AWK_LIB='
function h(b,   a, i, u) {
  split("B KiB MiB GiB TiB PiB", u, " ")
  a = (b < 0) ? -b : b; i = 1
  while (a >= 1024 && i < 6) { a /= 1024; i++ }
  if (i == 1) return sprintf("%s%d B", (b < 0 ? "-" : ""), a)
  return sprintf("%s%.1f %s", (b < 0 ? "-" : ""), a, u[i])
}
function hs(b) { return (b > 0 ? "+" : "") h(b) }
function key(   k, i) { k = $1; for (i = 2; i <= nk; i++) k = k "." $i; return k }
function val(   n, c, i, s) { n = split(vc, c, ","); s = 0; for (i = 1; i <= n; i++) s += $(c[i]); return s }
'

meta_get() { awk -F= -v k="$2" '$1 == k { sub(/^[^=]*=/, ""); print; exit }' "$1/meta.txt"; }

# ---------------------------------------------------------------- raccolta dati

# Occupazione reale su disco delle voci di primo livello della data directory:
# cartelle dei database, ibdata1, binlog, undo, redo log, pg_wal, base, ...
# I file numerati (mysql-bin.000123, relay-log.000045, ...) sono sommati in una voce.
collect_disk() {
  local d=$1 out=$2
  : > "$out"
  if [[ -z $d || ! -r $d || ! -x $d ]]; then
    warn "data directory '${d:-?}' non leggibile: salto i file su disco (esegui come root per includerli)"
    return 0
  fi
  { du -sb -- "$d"/* 2>/dev/null || true; } |
    awk -F'\t' -v p="$d/" '
      { n = $2
        if (index(n, p) == 1) n = substr(n, length(p) + 1)
        if (n ~ /\.[0-9][0-9][0-9][0-9][0-9][0-9]$/) sub(/[0-9]+$/, "*", n)
        s[n] += $1 }
      END { for (n in s) printf "%s\t%.0f\n", n, s[n] }' > "$out"
}

write_meta() {
  local dir=$1 datadir=$2 version=$3
  {
    echo "timestamp=$(date '+%Y-%m-%d %H:%M:%S')"
    echo "engine=$ENGINE"
    echo "host=$(hostname)"
    echo "version=$version"
    echo "datadir=$datadir"
    if [[ -n $datadir && -e $datadir ]]; then
      { df -P -B1 -- "$datadir" 2>/dev/null || true; } |
        awk 'NR == 2 { print "fs_mount=" $6; print "fs_used=" $3; print "fs_avail=" $4 }'
    fi
  } > "$dir/meta.txt"
}

# File prodotti da ogni fotografia (separati da TAB):
#   tables.tsv     db, tabella, engine, dati, indici, libero/recuperabile, righe
#   databases.tsv  db, dati, indici, libero/recuperabile, totale
#   disk.tsv       voce della data directory, byte su disco
#   meta.txt       data, host, versione, filesystem

snapshot_mysql() {
  local dir=$1 pre="" datadir version
  command -v mysql >/dev/null 2>&1 || die "client 'mysql' non trovato"
  my -e "SELECT 1" >/dev/null || die "connessione a MySQL/MariaDB fallita (controlla ~/.my.cnf o MYSQL_OPTS)"

  # MySQL 8 tiene in cache le statistiche di information_schema fino a 24 ore:
  # senza questo, i valori "dopo" l'ottimizzazione potrebbero essere quelli vecchi.
  if [[ -n $(my -e "SHOW VARIABLES LIKE 'information_schema_stats_expiry'") ]]; then
    pre="SET SESSION information_schema_stats_expiry = 0;"
  fi

  my -e "$pre
    SELECT table_schema, table_name, IFNULL(engine, '-'),
           IFNULL(data_length, 0), IFNULL(index_length, 0), IFNULL(data_free, 0), IFNULL(table_rows, 0)
      FROM information_schema.TABLES
     WHERE table_type IN ('BASE TABLE', 'SYSTEM VERSIONED')
       AND table_schema NOT IN ('information_schema', 'performance_schema', 'sys')" > "$dir/tables.tsv"

  my -e "$pre
    SELECT s.schema_name,
           IFNULL(SUM(t.data_length), 0), IFNULL(SUM(t.index_length), 0), IFNULL(SUM(t.data_free), 0),
           IFNULL(SUM(t.data_length), 0) + IFNULL(SUM(t.index_length), 0)
      FROM information_schema.SCHEMATA s
      LEFT JOIN information_schema.TABLES t
             ON t.table_schema = s.schema_name
            AND t.table_type IN ('BASE TABLE', 'SYSTEM VERSIONED')
     WHERE s.schema_name NOT IN ('information_schema', 'performance_schema', 'sys')
     GROUP BY s.schema_name" > "$dir/databases.tsv"

  datadir=$(my -e "SELECT @@datadir"); datadir=${datadir%/}
  version=$(my -e "SELECT VERSION()")
  collect_disk "$datadir" "$dir/disk.tsv"
  write_meta "$dir" "$datadir" "$version"
}

snapshot_postgres() {
  local dir=$1 maindb=${PGDATABASE:-postgres} datadir version db
  command -v psql >/dev/null 2>&1 || die "client 'psql' non trovato"
  pg -d "$maindb" -c "SELECT 1" >/dev/null || die "connessione a PostgreSQL fallita (controlla PG_OPTS, PGUSER, ~/.pgpass)"

  pg -d "$maindb" -c "SELECT datname FROM pg_database WHERE datallowconn AND NOT datistemplate ORDER BY 1" > "$dir/.dblist"

  # Per ogni database: dimensione di ogni tabella (catalogo incluso, es. pg_largeobject)
  # e stima dello spazio occupato da tuple morte (bloat recuperabile con VACUUM FULL).
  : > "$dir/tables.tsv"
  while IFS= read -r db; do
    [[ -n $db ]] || continue
    pg -d "$db" -c "
      SELECT current_database(), s.schemaname || '.' || s.relname, 'table',
             pg_table_size(s.relid), pg_indexes_size(s.relid),
             CASE WHEN s.n_live_tup + s.n_dead_tup > 0
                  THEN (pg_table_size(s.relid)::numeric * s.n_dead_tup / (s.n_live_tup + s.n_dead_tup))::bigint
                  ELSE 0 END,
             s.n_live_tup
        FROM pg_stat_all_tables s
       WHERE s.schemaname <> 'information_schema'
         AND s.schemaname NOT LIKE 'pg_toast%'" < /dev/null >> "$dir/tables.tsv" \
      || warn "impossibile leggere le tabelle del database '$db'"
  done < "$dir/.dblist"

  pg -d "$maindb" -c "SELECT datname, pg_database_size(oid) FROM pg_database WHERE datallowconn AND NOT datistemplate" > "$dir/.dbsize"
  awk -F'\t' '
    FILENAME == ARGV[1] { d[$1] += $4; i[$1] += $5; f[$1] += $6; next }
    { printf "%s\t%.0f\t%.0f\t%.0f\t%s\n", $1, d[$1], i[$1], f[$1], $2 }' \
    "$dir/tables.tsv" "$dir/.dbsize" > "$dir/databases.tsv"

  datadir=$(pg -d "$maindb" -c "SHOW data_directory" 2>/dev/null || true)
  version=$(pg -d "$maindb" -c "SHOW server_version")
  collect_disk "$datadir" "$dir/disk.tsv"

  # Dettaglio di base/<oid> con il nome del database al posto dell'oid
  if [[ -n $datadir && -r $datadir/base && -x $datadir/base ]]; then
    pg -d "$maindb" -c "SELECT oid, datname FROM pg_database" > "$dir/.oidmap"
    { du -sb -- "$datadir"/base/* 2>/dev/null || true; } |
      awk -F'\t' '
        FILENAME == ARGV[1] { name[$1] = $2; next }
        { o = $2; sub(/.*\//, "", o); printf "base/%s\t%s\n", ((o in name) ? name[o] : o), $1 }' \
        "$dir/.oidmap" - >> "$dir/disk.tsv"
  fi
  write_meta "$dir" "$datadir" "$version"
}

# --------------------------------------------------------------- presentazione

print_fs() {
  local d=$1 used avail mount
  used=$(meta_get "$d" fs_used); avail=$(meta_get "$d" fs_avail); mount=$(meta_get "$d" fs_mount)
  [[ -n $used ]] || return 0
  awk -v u="$used" -v a="$avail" -v m="$mount" "$AWK_LIB"'
    BEGIN { printf "Filesystem %s: usato %s, libero %s\n", m, h(u), h(a) }'
}

top_section() {
  local f=$1 nk=$2 vc=$3 title=$4
  echo
  echo "=== $title ==="
  if [[ ! -s $f ]]; then echo "  (nessun dato)"; return 0; fi
  awk -F'\t' -v nk="$nk" -v vc="$vc" "$AWK_LIB"'
    { v = val(); printf "%.0f\t%s\t%s\n", v, key(), h(v) }' "$f" |
    sort -t $'\t' -k1,1nr -k2,2 |
    awk -F'\t' -v top="$TOPN" 'NR <= top && $1 > 0 { printf "  %-60s %12s\n", $2, $3 }'
}

compare_section() {
  local fa=$1 fb=$2 nk=$3 vc=$4 title=$5
  [[ -f $fa ]] || fa=/dev/null
  [[ -f $fb ]] || fb=/dev/null
  echo
  echo "=== $title ==="
  if [[ ! -s $fa && ! -s $fb ]]; then echo "  (nessun dato)"; return 0; fi
  printf '  %-50s %12s %12s %13s  %s\n' "NOME" "PRIMA" "DOPO" "DIFFERENZA" "NOTE"
  awk -F'\t' -v nk="$nk" -v vc="$vc" "$AWK_LIB"'
    FILENAME == ARGV[1] { k = key(); A[k] = val(); S[k] = 1; next }
                        { k = key(); B[k] = val(); S[k] = 1 }
    END {
      for (k in S) {
        inA = (k in A); inB = (k in B)
        a = inA ? A[k] : 0; b = inB ? B[k] : 0; d = b - a
        if (!inA)                 note = "NUOVO"
        else if (!inB)            note = "RIMOSSO"
        else if (a > 0 && d != 0) note = sprintf("%+.1f%%", 100 * d / a)
        else                      note = ""
        printf "%.0f\t%s\t%s\t%s\t%s\t%s\n", (d < 0 ? -d : d), k, h(a), h(b), hs(d), note
      }
    }' "$fa" "$fb" |
    sort -t $'\t' -k1,1nr -k2,2 |
    awk -F'\t' -v top="$TOPN" 'NR <= top { printf "  %-50s %12s %12s %13s  %s\n", $2, $3, $4, $5, $6 }'
}

# -------------------------------------------------------------------- comandi

cmd_snapshot() {
  local label=${1:-$(date '+%Y%m%d-%H%M%S')}
  [[ $label =~ ^[A-Za-z0-9][A-Za-z0-9._-]*$ ]] || die "etichetta non valida: usa solo lettere, numeri, . _ -"
  local dir=$OUTDIR/$label
  [[ ! -e $dir ]] || die "la fotografia '$label' esiste già ($dir)"
  mkdir -p -- "$dir"
  SNAP_IN_PROGRESS=$dir
  echo "Fotografia '$label' ($ENGINE) in corso..."
  "snapshot_$ENGINE" "$dir"
  rm -f -- "$dir/.dblist" "$dir/.dbsize" "$dir/.oidmap"
  SNAP_IN_PROGRESS=""
  echo "Salvata in $dir ($(wc -l < "$dir/tables.tsv") tabelle)"
  print_fs "$dir"
  top_section "$dir/databases.tsv" 1 5 "Database più grandi"
}

cmd_report() {
  local label=${1:-}
  [[ -n $label ]] || die "uso: report <etichetta>"
  local d=$OUTDIR/$label
  [[ -f $d/meta.txt ]] || die "fotografia '$label' non trovata in $OUTDIR"
  echo "Fotografia '$label' del $(meta_get "$d" timestamp) - $(meta_get "$d" engine) $(meta_get "$d" version) su $(meta_get "$d" host)"
  print_fs "$d"
  top_section "$d/databases.tsv" 1 5   "Database più grandi (dati + indici)"
  top_section "$d/tables.tsv"    2 4,5 "Tabelle più grandi (dati + indici)"
  top_section "$d/tables.tsv"    2 6   "Tabelle con più spazio recuperabile (data_free / tuple morte stimate)"
  top_section "$d/disk.tsv"      1 2   "Voci più grandi nella data directory"
}

cmd_compare() {
  local a=${1:-} b=${2:-}
  [[ -n $a && -n $b ]] || die "uso: compare <etichetta_prima> <etichetta_dopo>"
  [[ $a != "$b" ]] || die "le due etichette sono uguali"
  local da=$OUTDIR/$a db=$OUTDIR/$b
  [[ -f $da/meta.txt ]] || die "fotografia '$a' non trovata in $OUTDIR"
  [[ -f $db/meta.txt ]] || die "fotografia '$b' non trovata in $OUTDIR"
  [[ $(meta_get "$da" engine) == "$(meta_get "$db" engine)" ]] || warn "le due fotografie sono di motori diversi"

  echo "Confronto '$a' ($(meta_get "$da" timestamp))  ->  '$b' ($(meta_get "$db" timestamp))"
  local ua ub m
  ua=$(meta_get "$da" fs_used); ub=$(meta_get "$db" fs_used); m=$(meta_get "$db" fs_mount)
  if [[ -n $ua && -n $ub ]]; then
    awk -v a="$ua" -v b="$ub" -v m="$m" "$AWK_LIB"'
      BEGIN { printf "Filesystem %s: usato %s -> %s (%s)\n", m, h(a), h(b), hs(b - a) }'
  fi

  compare_section "$da/databases.tsv" "$db/databases.tsv" 1 5   "Database - dimensione totale"
  compare_section "$da/databases.tsv" "$db/databases.tsv" 1 4   "Database - spazio libero/recuperabile"
  compare_section "$da/tables.tsv"    "$db/tables.tsv"    2 4,5 "Tabelle - dimensione (dati + indici)"
  compare_section "$da/disk.tsv"      "$db/disk.tsv"      1 2   "File nella data directory (cartelle DB, ibdata1, binlog, undo, WAL)"

  cat <<'EOF'

Come leggere il risultato:
  - In cima a ogni sezione ci sono le voci cambiate di più: un database o una
    tabella che dopo l'ottimizzazione non cala, o addirittura cresce, è il
    primo sospetto.
  - Se le tabelle calano ma il filesystem no, lo spazio sta altrove: guarda la
    sezione "File nella data directory" (binlog, ibdata1, undo, pg_wal).
  - MySQL/MariaDB: ibdata1 non si restringe mai, nemmeno con OPTIMIZE; con
    innodb_file_per_table=OFF il data_free è condiviso e poco indicativo.
  - PostgreSQL: VACUUM semplice non restituisce spazio al disco, serve
    VACUUM FULL (o pg_repack); lo spazio "recuperabile" è una stima.
EOF
}

cmd_list() {
  if [[ ! -d $OUTDIR ]]; then echo "Nessuna fotografia in $OUTDIR"; return 0; fi
  local d found=0
  for d in "$OUTDIR"/*/; do
    [[ -f $d/meta.txt ]] || continue
    found=1
    printf '%-24s %s  %-8s  %s\n' "$(basename "$d")" "$(meta_get "$d" timestamp)" \
      "$(meta_get "$d" engine)" "$(meta_get "$d" host)"
  done
  [[ $found -eq 1 ]] || echo "Nessuna fotografia in $OUTDIR"
}

cmd=${1:-}
shift || true
case $cmd in
  snapshot) cmd_snapshot "$@" ;;
  compare)  cmd_compare "$@" ;;
  report)   cmd_report "$@" ;;
  list)     cmd_list ;;
  ""|help)  usage 0 ;;
  *)        die "comando sconosciuto: '$cmd' (usa snapshot, compare, report, list)" ;;
esac

Abschließende Hinweise

• Das Skript liest den Speicherplatz von MySQL nur aus und ist auf den Datenbanken schreibgeschützt: Es führt nur SELECT auf den Metadaten aus. Es schreibt ausschließlich in den Ordner der Momentaufnahmen.
• Unter MySQL 8 setzt es information_schema_stats_expiry = 0 in der Sitzung, weil sonst die zwischengespeicherten Statistiken (bis zu 24 Stunden) auch nach der Optimierung „alte“ Werte zeigen könnten.
• Schlägt eine Momentaufnahme auf halbem Weg fehl, wird sie automatisch entfernt, um keine unvollständigen Daten zu hinterlassen.
• Bevor Sie es in der Produktion einsetzen, probieren Sie es in einer Testumgebung aus und prüfen die Berechtigungen des Datenbankbenutzers.

Wenn Sie es nutzen und einen Fall finden, den es nicht abdeckt, oder Ideen zur Erweiterung haben (andere Engines, CSV-Export, E-Mail-Benachrichtigungen), schreiben Sie mir in die Kommentare. Läuft MySQL nach einem Upgrade gar nicht mehr, hilft dieser Artikel: MySQL startet nach dem Debian-12-Upgrade nicht mehr.

The post Welche Datenbank belegt den Speicherplatz? Ein Skript für MySQL und PostgreSQL first appeared on Matteo Cisilino.

Wir brauchten MySQL 5.7 in Docker auf einem Server, der sonst mit einer aktuellen Distribution läuft. Einige Altanwendungen sind nicht mit MySQL 8 kompatibel (geänderte Standard-Authentifizierung, strengere SQL-Modi, neue reservierte Wörter), und sie kurzfristig zu migrieren kam nicht in Frage.

Eine so alte Version direkt auf dem Host zu installieren, bringt mehrere Probleme. Die offiziellen Repositories aktueller Distributionen bieten sie nicht mehr an. Pakete von Drittanbietern können mit dem Rest des Systems in Konflikt geraten, und ein OS-Update könnte sie zerstören.

Wir haben uns deshalb entschieden, sie in einem Docker-Container zu isolieren. Der Host bleibt sauber und aktuell, die Datenbankversion ist festgelegt und reproduzierbar. Daten und Konfiguration liegen in einem Ordner, der sich leicht sichern und verschieben lässt.

Dieser Artikel erzählt, wie wir sie eingerichtet haben und vor allem, auf welche Hindernisse wir unterwegs gestoßen sind. Es sind die unbeabsichtigte Freigabe des Ports 3306 und ein iptables-Fehler beim Neustart. Dazu kam das Schreiben einer Firewall mit nftables, die nur autorisierte IPs durchlässt.

Hinweis: MySQL 5.7 hat im Oktober 2023 das Ende des Supports (EOL) erreicht und erhält keine Sicherheitspatches mehr. Es ist eine Übergangslösung: Das Ziel bleibt die Migration auf MySQL 8.x oder MariaDB. Gerade deshalb ist es umso wichtiger, es nicht offen zu lassen.

1. Ordnerstruktur

/opt/mysql57/
├── docker-compose.yml
├── .env
├── conf.d/        # configurazioni personalizzate (my.cnf aggiuntivi)
├── data/          # dati del database (volume persistente)
└── logs/

Die Datei .env enthält die Zugangsdaten, damit sie nicht im Compose landen.

TZ=Europe/Rome
MYSQL_ROOT_PASSWORD=una_password_molto_lunga_e_casuale
MYSQL_DATABASE=nome_db
MYSQL_USER=nome_utente
MYSQL_PASSWORD=altra_password_robusta

Schützen Sie sie mit chmod 600 .env.

2. Die docker-compose.yml

services:
  mysql57:
    image: mysql:5.7
    container_name: mysql57
    restart: unless-stopped
    env_file:
      - .env
    ports:
      - "3306:3306"
    environment:
      TZ: "${TZ:-Europe/Rome}"
      MYSQL_ROOT_PASSWORD: "${MYSQL_ROOT_PASSWORD}"
      MYSQL_DATABASE: "${MYSQL_DATABASE}"
      MYSQL_USER: "${MYSQL_USER}"
      MYSQL_PASSWORD: "${MYSQL_PASSWORD}"
    command:
      - --default-authentication-plugin=mysql_native_password
    volumes:
      - ./data:/var/lib/mysql
      - ./conf.d:/etc/mysql/conf.d:ro
      - ./logs:/var/log/mysql
    healthcheck:
      test: ["CMD-SHELL", "mysqladmin ping -h 127.0.0.1 -uroot -p$$MYSQL_ROOT_PASSWORD --silent"]
      interval: 20s
      timeout: 5s
      retries: 10
      start_period: 45s
    ulimits:
      nofile:
        soft: 65535
        hard: 65535

Einige Entscheidungen, die man beachten sollte.

• restart: unless-stopped: Die Datenbank startet nach einem Neustart des Servers von selbst wieder.
• Volumes als Bind-Mount: Daten, Konfiguration und Logs liegen auf dem Host, Backups und Migrationen sind also einfache Ordnerkopien.
• Healthcheck: erlaubt anderen Diensten zu warten, bis MySQL wirklich bereit ist ($$ sorgt dafür, dass die Variable im Container und nicht von Compose aufgelöst wird).
• ulimits nofile: vermeidet den Fehler „too many open files“ unter Last.

3. Erstes Problem: Der Port von MySQL 5.7 in Docker ist für die ganze Welt offen

Die Zeile - "3306:3306" entspricht 0.0.0.0:3306:3306: Docker veröffentlicht den Port auf allen Schnittstellen des Hosts, auch der öffentlichen.

Das Heimtückischste ist, dass Docker seine eigenen Regeln direkt in die Firewall des Kernels schreibt und diese vor denen von UFW oder firewalld ausgewertet werden. Eine aktive Firewall genügt nicht: Der Port bleibt erreichbar. Die Docker-Dokumentation beschreibt dieses Verhalten unter Packet filtering and firewalls.

Die möglichen Wege sind.

1. Nur localhost: "127.0.0.1:3306:3306", wenn die Datenbank nur vom Host oder über einen SSH-Tunnel genutzt wird.
2. Kein veröffentlichter Port: Sind die Clients andere Container, genügt ein gemeinsames Docker-Netzwerk.
3. Bestimmte IP: nur auf einer Adresse eines privaten Netzes/VPN veröffentlichen.
4. Öffentlicher Port mit IP-Filter: unser Fall, weil sich ein externer Client (eine phpMyAdmin-Instanz auf einem anderen Server) verbinden können muss.

Für Fall 4 braucht man eine Firewall, die den Verkehr der von Docker veröffentlichten Ports korrekt filtert.

4. Zweites Problem: iptables-Fehler beim Start

Nachdem wir die Firewall angefasst hatten, lieferte docker compose up.

failed to create network mysql57_default: Error response from daemon:
Failed to Setup IP tables: Unable to enable ACCEPT OUTGOING rule:
(iptables failed: iptables --wait -t filter -A DOCKER-FORWARD -i br-... -j ACCEPT:
iptables: No chain/target/match by that name.

Der Fehler hängt nicht vom Compose ab: Die Kette DOCKER-FORWARD (in neueren Docker-Versionen eingeführt) existierte nicht mehr. Sie war von etwas gelöscht worden, das die Regeln nach dem Start des Daemons bereinigt hatte. Ein Neustart von Docker (systemctl restart docker) legt sie neu an, doch das Problem kehrt zurück, bis der wahre Schuldige beseitigt ist.

Der Schuldige: flush ruleset

Unsere /etc/nftables.conf begann mit.

flush ruleset

Dieser Befehl löscht alle nftables-Tabellen, auch die von Docker angelegten. Außerdem enthielt die Datei eine statische Kopie der Docker-Regeln, mit von Hand eingetragenem Bridge-Namen (br-278550235c3f) und Container-IP (172.18.0.2). Der Bridge-Name ändert sich jedoch jedes Mal, wenn das Compose-Netzwerk neu erstellt wird. Die Kopie war also sofort veraltet, und die Tabelle ip nat geriet in Konflikt mit der von Docker verwalteten.

Goldene Regel: Mit Docker verwendet man in der nftables-Datei kein flush ruleset und kopiert keine seiner Regeln. Man verwaltet nur seine eigene Firewall, in eigenen Tabellen.

5. Die Firewall mit nftables für MySQL 5.7 in Docker

Das Prinzip: Die von Docker veröffentlichten Ports werden mit DNAT umgeschrieben und dann vom Host an den Container weitergeleitet, durchlaufen also die Kette forward, nicht input. Eine Regel drop in einer eigenen Kette forward mit etwas niedrigerer Priorität (also zuerst ausgewertet) verwirft das Paket unabhängig von den accept-Regeln von Docker.

Um fremde Tabellen nicht anzufassen, verwenden wir das Muster table ... + delete table ...: Es macht die Datei ohne Fehler und ohne flush wiederholt ausführbar.

/etc/nftables.conf.

#!/usr/sbin/nft -f

# NIENTE "flush ruleset": cancellerebbe anche le tabelle di Docker

# ---------------- firewall host ----------------
table inet filter
delete table inet filter

table inet filter {

    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        iifname "lo" accept
        ip6 nexthdr icmpv6 accept
        iifname "enp7s0" accept                       # rete privata
        ip saddr 203.0.113.20 tcp dport 22 accept     # SSH da host fidato
        ip saddr 203.0.113.30 tcp dport 22 accept     # SSH da VPN
        ip saddr 203.0.113.20 icmp type echo-request accept
        tcp dport { 80, 443 } accept
    }

    chain output {
        type filter hook output priority filter; policy accept;
    }
}

# ---------------- guardia MySQL (porta pubblicata da Docker) ----------------
table ip mysql_guard
delete table ip mysql_guard

table ip mysql_guard {
    set allowed {
        type ipv4_addr
        flags interval
        elements = {
            203.0.113.10        # phpMyAdmin
        }
    }

    chain forward {
        type filter hook forward priority filter - 5; policy accept;
        iifname "enp7s0" accept
        ct status dnat tcp dport 3306 ip saddr @allowed accept
        ct status dnat tcp dport 3306 counter drop
    }
}

Wie die Schutzregel funktioniert.

• ct status dnat wählt nur Pakete aus, die durch DNAT gelaufen sind, also die für die von Docker veröffentlichten Ports bestimmten.
• Die erste Regel akzeptiert, wer im Set allowed ist; die zweite verwirft alle anderen und zählt sie (counter).
• Lokaler Verkehr (127.0.0.1) und Verkehr zwischen Containern im selben Netzwerk läuft nicht über das Forward des Routers und wird daher nicht berührt.

Kompatibilität: In einer ersten Version verwendeten wir ct original proto-dst 3306, aber einige Versionen von nft antworten mit „Can’t parse symbolic invalid expressions“. Im Hook forward ist das DNAT bereits erfolgt und der Container-Port entspricht dem veröffentlichten (3306:3306). Daher ist tcp dport 3306 zusammen mit ct status dnat gleichwertig und funktioniert überall. Ändern Sie das Mapping (z. B. 3307:3306), muss die Regel an den internen Port angepasst werden.

Änderungen anwenden, ohne sich auszusperren

Halten Sie eine zweite SSH-Sitzung als Reserve offen, dann.

nft -c -f /etc/nftables.conf     # solo verifica della sintassi
nft delete table ip nat          # una tantum: elimina la vecchia copia statica
nft -f /etc/nftables.conf
systemctl restart docker         # Docker ricrea le sue tabelle pulite
cd /opt/mysql57 && docker compose up -d

Damit es beim Booten geladen wird, stellen Sie sicher, dass der Dienst aktiv ist (systemctl enable --now nftables) und dass /etc/nftables.conf kein flush ruleset enthält.

IPs zur Laufzeit verwalten

nft add element ip mysql_guard allowed { 203.0.113.50 }
nft delete element ip mysql_guard allowed { 203.0.113.50 }

Um es dauerhaft zu machen, aktualisieren Sie auch das Set in der Datei.

6. Überprüfung

Vom autorisierten Server.

nc -zv IP_PUBBLICO_DB 3306        # deve rispondere "succeeded"

Von jeder anderen IP.

nmap -Pn -p 3306 IP_PUBBLICO_DB   # deve risultare "filtered" / timeout

Auf dem Server muss der Zähler der Drop-Regel bei jedem nicht autorisierten Versuch wachsen.

nft list chain ip mysql_guard forward
ss -tlnp | grep 3306

7. Zweite Barriere: die MySQL-Benutzer

Die Firewall ersetzt nicht die Berechtigungen der Datenbank. Legen Sie den Benutzer mit auf die IP des Clients beschränktem Host an.

CREATE USER 'pma_user'@'203.0.113.10' IDENTIFIED BY 'password_robusta';
GRANT ALL ON nome_db.* TO 'pma_user'@'203.0.113.10';
FLUSH PRIVILEGES;

Gelingt die TCP-Verbindung, MySQL antwortet aber Access denied, liegt das Problem hier und nicht in der Firewall.

8. Was man sich zu MySQL 5.7 in Docker merken sollte

• Docker und die Host-Firewall ignorieren sich nicht: Zu verstehen, welche Kette der Verkehr durchläuft (input oder forward), ist der Schlüssel zu allem.
• Niemals flush ruleset auf einem Host mit Docker; verwenden Sie eigene Tabellen.
• Kopieren Sie keine von Docker erzeugten Regeln in Ihre Dateien: Bridge-Namen und IPs ändern sich.
• Haben Sie den Port schon freigegeben, prüfen Sie die Logs in ./logs und erwägen Sie, die Passwörter zu ändern, vor allem das von root.
• Wo möglich, ziehen Sie ein VPN (WireGuard) oder einen SSH-Tunnel der öffentlichen Freigabe einer Datenbank vor.
• Planen Sie die Migration von MySQL 5.7 auf eine unterstützte Version.

Haben Sie Fragen oder eine andere Lösung für dasselbe Problem? Schreiben Sie es in die Kommentare. Zum Thema MySQL und Debian lesen Sie auch: MySQL startet nach dem Debian-12-Upgrade nicht mehr.

The post MySQL 5.7 in Docker, geschützt mit nftables first appeared on Matteo Cisilino.

MySQL startet nicht mehr: Der Dienst ist fehlgeschlagen, und das Log meldet den Fehler Can't read dir of '/etc/mysql/mariadb.conf.d/'.

# service mysql status
× mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; enabled; preset: enabled)
     Active: failed (Result: exit-code)
     Status: "Server startup in progress"

mysqld: Can't read dir of '/etc/mysql/mariadb.conf.d/' (OS errno 2 - No such file or directory)
mysqld: [ERROR] Stopped processing the 'includedir' directive in file /etc/mysql/my.cnf at line 29.
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
systemd[1]: Failed to start mysql.service - MySQL Community Server.

Beim Prüfen der installierten Pakete ist MySQL ganz normal vorhanden (mysql-community-server-8.0-Pakete aus dem offiziellen Oracle-Repository).

dpkg -l | grep mysql

Die Ursache: Die Alternative my.cnf zeigt auf mariadb.cnf

Unter Debian ist die Datei /etc/mysql/my.cnf keine echte Datei, sondern ein Link, der von update-alternatives verwaltet wird. Mehrere Pakete können ihre eigene Version registrieren, und im automatischen Modus gewinnt die mit der höchsten Priorität.

Beim Upgrade wurde das Paket mariadb-common installiert (und danach entfernt), das /etc/mysql/mariadb.cnf mit Priorität 500 registriert, höher als /etc/mysql/mysql.cnf (Priorität 300). Das Paket wurde entfernt, aber nicht vollständig gelöscht (Status rc), sodass seine Konfiguration aktiv blieb. In Zeile 29 dieser Datei steht das Include von /etc/mysql/mariadb.conf.d/, einem Verzeichnis, das nicht existiert: MySQL liest die Konfiguration, findet das Verzeichnis nicht und bricht ab. Das Ergebnis: „MySQL startet nicht mehr“, obwohl die Pakete in Ordnung sind.

Die gute Nachricht: Die Daten in /var/lib/mysql wurden nicht angetastet. Es ist nur ein Konfigurationsproblem.

Diagnose: prüfen, worauf my.cnf zeigt

ls -l /etc/mysql/my.cnf /etc/alternatives/my.cnf
update-alternatives --display my.cnf
sed -n '25,32p' /etc/mysql/my.cnf
dpkg -l | grep -i mariadb

Wenn das Problem hier liegt, sieht die Ausgabe ähnlich aus wie diese.

/etc/alternatives/my.cnf -> /etc/mysql/mariadb.cnf
/etc/mysql/my.cnf -> /etc/alternatives/my.cnf

my.cnf - modalità automatica
  la versione migliore del collegamento è /etc/mysql/mariadb.cnf
  il collegamento attualmente punta a /etc/mysql/mariadb.cnf
/etc/mysql/mariadb.cnf - priorità 500
/etc/mysql/my.cnf.fallback - priorità 100
/etc/mysql/mysql.cnf - priorità 300

!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/

rc  mariadb-common   1:10.11.18-0+deb12u1   all   MariaDB common configuration files

Lösung Schritt für Schritt

1. Die Konfiguration sichern

cp -a /etc/mysql /root/etc-mysql-backup-$(date +%F)

2. Die Reste von mariadb-common entfernen

Das Purge entfernt mariadb.cnf und den zugehörigen Eintrag in update-alternatives.

apt purge mariadb-common

3. my.cnf wieder auf mysql.cnf zeigen lassen

update-alternatives --remove my.cnf /etc/mysql/mariadb.cnf 2>/dev/null
update-alternatives --set my.cnf /etc/mysql/mysql.cnf

4. Die Konfiguration prüfen

update-alternatives --display my.cnf
cat /etc/mysql/my.cnf
my_print_defaults mysqld

Jetzt muss my.cnf auf /etc/mysql/mysql.cnf zeigen und /etc/mysql/conf.d/ sowie /etc/mysql/mysql.conf.d/ einbinden. Gibt my_print_defaults mysqld die Parameter ohne Fehler aus, ist die Konfiguration korrekt.

5. MySQL starten

systemctl start mysql
systemctl status mysql
journalctl -u mysql -n 50 --no-pager

Wenn my.cnf kein symbolischer Link ist

Ist /etc/mysql/my.cnf eine normale Datei oder existiert /etc/mysql/mysql.cnf nicht, können Sie die Konfiguration von Hand neu anlegen.

mv /etc/mysql/my.cnf /etc/mysql/my.cnf.mariadb.bak
cat > /etc/mysql/my.cnf <<'EOF'
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
EOF
mkdir -p /etc/mysql/conf.d
systemctl start mysql

Schnelle vorläufige Lösung für „MySQL startet nicht mehr“

Muss die Datenbank sofort wieder online, genügt es, das fehlende Verzeichnis anzulegen. Das ist aber nur ein Provisorium: MySQL würde weiterhin die für MariaDB gedachte Konfiguration lesen, daher wenden Sie die vollständige Lösung besser so bald wie möglich an.

mkdir /etc/mysql/mariadb.conf.d && systemctl start mysql

Wie Sie verhindern, dass es wieder passiert

Es lohnt sich herauszufinden, welches Upgrade MariaDB installiert hat, anhand des apt-Verlaufs. Wie wir MySQL 5.7 in Docker betreiben, ohne es dem Internet auszusetzen, steht in diesem Artikel. Was sich in Debian 12 geändert hat, erklären die Release Notes zu Debian 12.

grep -i -B3 -A3 mariadb /var/log/apt/history.log*

Damit mariadb-common künftig nicht erneut installiert wird, kann man es mit einem APT-Pin mit negativer Priorität sperren.

cat > /etc/apt/preferences.d/no-mariadb <<'EOF'
Package: mariadb-*
Pin: release *
Pin-Priority: -1
EOF

Nach jedem größeren Upgrade ist es außerdem gute Praxis, den Status der Alternative mit update-alternatives --display my.cnf zu prüfen.

Häufig gestellte Fragen

MySQL startet nicht mehr: Verliere ich die Daten meiner Datenbanken?

Nein. Das Problem betrifft nur die Konfigurationsdateien in /etc/mysql; die Daten in /var/lib/mysql bleiben unversehrt.

Warum hat Debian mariadb.cnf gewählt?

Weil die Alternative my.cnf im automatischen Modus war und mariadb.cnf Priorität 500 hat, höher als die 300 von mysql.cnf. Mit update-alternatives --set wird die Auswahl manuell und ändert sich nicht mehr von selbst.

Gilt das auch für Ubuntu?

Ja, der Mechanismus von update-alternatives für my.cnf ist unter Ubuntu und den anderen von Debian abgeleiteten Distributionen derselbe.

Fazit

Der Fehler „Can’t read dir of /etc/mysql/mariadb.conf.d/“ nach einem Debian-Upgrade bedeutet keinen Schaden an MySQL, sondern eine MariaDB-Restkonfiguration, die über update-alternatives aktiv geblieben ist. Wenn Sie mariadb-common mit apt purge entfernen und my.cnf wieder auf mysql.cnf setzen, läuft MySQL wieder normal.

The post MySQL startet nach dem Debian-12-Upgrade nicht mehr: Ursache und Lösung first appeared on Matteo Cisilino.