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.

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.