Diesen Server aufräumen

Ein Server, der seit Monaten läuft, sammelt Ballast an: Paketdownloads, die nicht mehr gebraucht werden, alte Kernel-Images in /boot, gestoppte Docker-Container, Build-Caches, rotierte Logdateien, Sicherheitsupdates, die noch installiert werden müssen, und Dienste, die nach und nach Speicher verlieren. Für sich genommen ist das alles nicht schlimm, aber irgendwann ist die Festplatte voll, ein Update schlägt fehl oder eine Website wird langsamer, als sie sein sollte.

Diesen Server aufräumen ist ein Button, der all das in einem Durchlauf erledigt — und ein Chatgespräch, das alles Riskante bestätigt, bevor es ausgeführt wird.

Was genau passiert

Drei Kategorien, jede einzeln ausführbar — hake an, was du möchtest, und lass den Rest aus:

• Speicherplatz freigeben — leert den Paketdownload-Cache, entfernt Abhängigkeiten von entfernten Paketen, bereinigt gestoppte Docker-Container + verwaiste Images, kürzt Docker-Build-Cache, der älter als eine Woche ist, reduziert systemd-Logs auf die letzten 30 Tage, löscht rotierte Logdateien (.gz / .1 / .old), die älter als 30 Tage sind, und entfernt optional alte Kernel-Images / deaktivierte snap-Revisionen.
• Sicherheitsupdates installieren — aktualisiert die Paketliste und installiert die neueste Version jedes installierten Pakets (apt update + apt upgrade). Wenn das Update einen neuen Kernel enthält, wird daraus eine Folgeaufgabe „neu starten, wenn es passt“ — nichts, was einfach ohne dein Zutun passiert.
• Dienste mit Speicherlecks neu starten — optional. Startet deine Websites + Datenbanken + Worker nacheinander neu (jeweils ca. 10–30 s Ausfallzeit), damit der Speicher, den sie über Wochen langsam angesammelt haben, zurückgesetzt wird. Wir messen die Antwortzeit davor und danach und behaupten nur dann „schneller“, wenn es dafür echte Hinweise gibt.

Zusätzlich laufen immer ein paar rein lesende Prüfungen: Bericht zu Speicherplatz-Schwerpunkten (welche Verzeichnisse deine Festplatte belegen), fehlgeschlagene Dienste (alles, was systemd markiert hat), aktuelle SSH-Anmeldungen (damit dir unbekannte auffallen), Fail2ban-Status und eine Prüfung auf /var/run/reboot-required (die Datei, mit der ein Kernel-Update signalisiert: „Du musst neu starten“).

So startest du es

Vier Einstiegspunkte, dasselbe Modal:

Die Speicher-CTA ist der häufigste Weg — du hast bemerkt, dass die Festplatte voller wird, schaust dir den Speicher an, und der Aufräum-Button ist direkt dort.

Das Vorab-Modal

Wenn du einen Einstiegspunkt anklickst, öffnet sich dieselbe Checkliste. Das Modal erfüllt zwei Aufgaben gleichzeitig: Es zeigt dir genau, was gleich passiert, und autorisiert die sicheren Schritte, damit der Chat deine Zeit nicht damit verschwendet, für Dinge, die du bereits angehakt hast, noch einmal zu fragen.

Achte auf die Punkte — an ihnen erkennst du, was dich erwartet:

• Salbeigrün (sicher) — wird sofort ausgeführt. Keine Chat-Nachfrage, keine Bestätigung, danach nur ein einzeiliger „erledigt“-Status.
• Pfirsich (im Chat bestätigen) — pausiert vor der Ausführung für ein Ja/Nein im Gespräch. Wird für Dinge wie das Installieren von Updates verwendet, die Dienste kurz neu starten könnten.
• Rosé (pro Element bestätigen) — listet jeden Kandidaten auf (z. B. jedes verwaiste Docker-Volume) und fragt einzeln nach. Die Stufe „Bist du bei genau diesem Element wirklich sicher?“.

Jede Zeile hat außerdem einen aufklappbaren Bereich „Was macht das?“ mit dem exakten Shell-Befehl, den wir ausführen. Technische Nutzer können also prüfen, dass es keine Überraschung gibt. Nicht-technische Nutzer können ihn einfach ignorieren.

Der Umschalter Workloads nach der Bereinigung neu starten unten im Modal ist eine eigene Entscheidung. Er startet jede laufende Website / Datenbank / jeden Worker einzeln neu, jeweils mit ca. 10–30 Sekunden Ausfallzeit, misst die Antwortzeit davor und danach und zeigt dir die Differenz. Lass ihn aus, wenn Ausfallzeit jetzt schlimmer wäre als leicht auslaufender Speicher; schalte ihn ein, wenn du ohnehin gerade Wartung machst.

Deine Häkchen werden pro Server gespeichert — wenn du das Modal das nächste Mal auf demselben Server öffnest, sind dieselben Kästchen bereits angehakt. Neue Aktionen, die durch künftige Updates hinzukommen, erscheinen automatisch mit Standardhäkchen, wenn sie sicher sind (und ohne Häkchen bei allen anderen).

Was während des Durchlaufs passiert

Klicke auf Bereinigung starten, und das Modal schließt sich. Ab hier steuert das Gespräch den Ablauf:

1. Momentaufnahme — ein schneller Block rein lesender Befehle erfasst den Zustand „vorher“ (freier Speicherplatz, RAM, Loggröße, ausstehende Updates, fehlgeschlagene Dienste, größte Verzeichnisse, aktuelle Anmeldungen, Fail2ban). Der Chat sagt nur „Momentaufnahme erstellt, X GB frei, N Updates ausstehend. Starte Bereinigung …“ — du bekommst keine Wand aus Rohdaten zu sehen.
2. Sichere Schritte laufen automatisch. apt update, apt clean, journalctl --vacuum, docker system prune, das Löschen rotierter Logs — diese Schritte laufen still, jeder gibt nur einen einzeiligen Status aus. Keine Freigabeaufforderungen (das Modal hat sie autorisiert).
3. Vorsichtige Schritte fragen nach. Alles mit pfirsichfarbenem Punkt (apt upgrade, docker system prune -a, Kernel-Entfernung, snap-Revisionen) stellt vor der Ausführung eine einzeilige Frage im Chat. Sagst du ja, wird die Aktion ausgeführt; sagst du nein, wird sie übersprungen und die nächste Aktion läuft weiter — das Rezept hält nicht wegen einer einzelnen Ablehnung an.

4. Schritte pro Element fragen für jeden Kandidaten einmal. Wenn du das Entfernen verwaister Volumes angehakt hast, listet Faro jedes verwaiste Volume auf und fragt einzeln, inklusive Hinweis, welches Image es früher eingebunden hatte. „Nein zu allen“ / „stopp“ / „Rest überspringen“ bricht die verbleibenden Elemente ab.

5. Optionale Workload-Neustarts. Wenn du sie eingeschaltet hast, wird jede laufende Site/Datenbank mit Antwortzeitmessungen davor und danach neu gestartet.

Wenn der Kernel zu irgendeinem Zeitpunkt aktualisiert wird und ein Neustart nötig ist, damit der neue Kernel tatsächlich verwendet wird, führt das Rezept keinen automatischen Neustart aus. Stattdessen zeigt es eine Folgekarte an, die du später ausführen kannst.

Wenn ein Neustart stattfindet

Alles, was die SSH-Verbindung unterbricht — systemctl reboot, Neustart von sshd / dbus / networking — löst ein festes bernsteinfarbenes Banner aus, das oben im Chat angeheftet wird. Der Chat hält sich selbst mit einer synthetischen Nachricht „Neustart ausgelöst. Der Chat bleibt für ca. 30–60 s still …“ an; solange das Banner angezeigt wird, ist das Senden deaktiviert.

Im Hintergrund versucht eine Prüfung alle paar Sekunden erneut, sich per SSH zu verbinden, mit den Zugangsdaten, die Server Manager beim Verbinden zwischengespeichert hat. Wenn der Server antwortet, wechselt das Banner zu Grün („Server ist wieder da · Uptime 8 s · Monitoring wird fortgesetzt“), verschwindet nach 5 Sekunden automatisch, und das Eingabefeld wird wieder aktiviert. Kein Neuladen des Browsers nötig.

Die Zusammenfassung und „Was du tun musst“

Wenn der Durchlauf fertig ist, postet Faro eine Abschlussnachricht, die die Erfolge direkt am Anfang beziffert, sowie eine Tabelle mit geänderten Kennzahlen.

Die Tabelle enthält nur Zeilen, bei denen die zugrunde liegende Aktion tatsächlich ausgeführt wurde UND die Änderung nicht null ist — wenn du Docker übersprungen hast, bekommst du also keine Docker-Zeile. Die Spalte „Warum das wichtig ist“ ist in klarer, natürlicher Sprache formuliert („Platz für Datenbanken und Uploads“, „Sicherheitslücken geschlossen“, „Weniger Konkurrenz um CPU“) statt in Fachjargon.

Wenn ein Workload-Neustart eine messbare Verbesserung gebracht hat, siehst du außerdem eine Tabelle Workload-Antwortzeit pro Workload — und nur dann. Das Rezept behauptet nicht wegen Messrauschen „deine Website ist schneller“.

Karten für Folgeaktionen

Alles, was die Bereinigung nicht selbst abschließen konnte — ein ausstehender Neustart, Dienste, die veralteten Bibliothekscode ausführen, Workloads, deren Neustart du abgelehnt hast, verwaiste Volumes, zu denen du nein gesagt hast — erscheint als Abschnitt Was du tun musst mit nummerierten Karten. Jede Karte bietet zwei Möglichkeiten:

• Option A — frag mich hier — ein Chatweg mit einem Klick. Der Antworttext des Callouts erscheint als klickbarer Chip über dem Eingabefeld, damit du nicht wieder nach oben scrollen musst.
• Option B — über die Konsole deines Anbieters — anbieterspezifische Schritt-für-Schritt-Klickanleitung für dieselbe Sache (z. B. „DigitalOcean → Droplet → Power → Reboot“). Praktisch, wenn du es lieber bewusst selbst erledigen möchtest.
• Abwägung — ein Satz pro Karte, der erklärt, wann welcher Weg sinnvoller ist.

Die über dem Eingabefeld angeheftete Chip-Leiste spiegelt diese Karten als ☐ ausstehende Folgeaufgaben. Chip anklicken → der Antworttext wird ins Eingabefeld eingefügt → Senden drücken. Während Faro daran arbeitet, wechselt der Chip zu ⏳ in Bearbeitung; wenn es erledigt ist, wird er ✓ durchgestrichen und nach 5 Sekunden automatisch entfernt. Jeder Chip hat außerdem einen kleinen ×-Button zum Ausblenden, falls du diese Folgeaufgabe ignorieren möchtest — das Ausblenden gilt für den Rest der Browser-Sitzung.

Häufige Sonderfälle

„Keine verwaisten Volumes gefunden“ — die Aktion pro Element meldet das einfach und wird übersprungen. Kein Fehler; die Liste war leer.

Reboot-required war schon vor der Bereinigung gesetzt — das ist häufig, wenn jemand anderes (oder ein früherer Durchlauf) Updates installiert, aber noch nicht neu gestartet hat. Das Rezept prüft /var/run/reboot-required sowohl bei der Momentaufnahme als auch nach apt upgrade. Wenn die Datei schon vorher da war, erscheint die Folgekarte „Server neu starten“ auch dann, wenn diese Bereinigung nichts Neues installiert hat — es ist trotzdem die richtige Aktion.

Meine Sites laufen hinter Traefik / nginx / Apache — das Rezept fasst die Konfiguration deines Webservers nicht an. Es startet die zugrunde liegenden Container (oder systemd-Units) für Sites neu, die es aus dem Inventar erkennen kann; der Proxy läuft ganz normal weiter. Wenn der Reverse Proxy eines Workloads vor Containern sitzt, die Server Manager nicht kennt (ein nicht verwaltetes eigenes Setup), wird er still übersprungen — ohne Prüf-URL gibt es keinen messbaren Neustart.

Snap ist auf diesem Server nicht installiert — der Schritt „Deaktivierte snap-Revisionen entfernen“ meldet nur „Snap ist nicht installiert — wird übersprungen.“ und macht weiter. Ihn auf einem Server ohne snap anzuhaken, ist harmlos.

**apt autoremove würde etwas entfernen, das ich behalten möchte** — jedem autoremove-Schritt geht ein Probelauf voraus, der „Würde entfernen: pkg-a, pkg-b, …“ ausgibt. Wenn die Liste falsch aussieht, sag nein — der echte Lauf passiert erst nach deiner Bestätigung.

Ich habe zu einem Schritt ja gesagt und möchte mittendrin zurück — mit Esc hältst du den Agenten an. Befehle, die bereits laufen, werden nicht unterbrochen (sie laufen zu Ende), aber die Schleife wird beendet. Du kannst Faro später bitten, alles Übersprungene erneut aufzurufen.

Der Chat wirkt während eines Dienst-Neustarts festgefahren — alles, was sshd, dbus oder den Netzwerk-Stack neu startet, löst dasselbe Banner aus wie ein Neustart (Kurzzeit-Variante). Wenn das Banner angezeigt wird, ist der Chat absichtlich pausiert; wenn es nicht angezeigt wird und der Chat wirklich eingefroren wirkt, siehe Wiederherstellen, wenn SSH nicht mehr funktioniert.

Der Abschlussbericht — worauf du achten solltest

Die Zusammenfassungsnachricht ist bewusst immer gleich aufgebaut, damit du sie schnell erfassen kannst:

1. Überschrift — eine fette Zeile: „🧹 6,2 GB freigegeben und 14 Sicherheitsupdates installiert.“ Das ist der Gewinn. Werte, die sich nicht geändert haben, werden nicht erwähnt.
2. Einzeilige Erläuterung — die größte konkrete Verbesserung in klarer, natürlicher Sprache (am meisten Speicher freigegeben, Sicherheitspatches installiert, weniger fehlgeschlagene Dienste — was auch immer am stärksten war).
3. Tabelle „Was sich geändert hat“ — Vorher / Nachher / Änderung / Warum das wichtig ist, eine Zeile pro Kennzahl, die sich tatsächlich bewegt hat. Mögliche Zeilen: freier Speicherplatz (GB und %), freie Inodes (%), Docker-Speicherverbrauch, Größe der Systemlogs, ausstehende Sicherheitsupdates, fehlgeschlagene Dienste, verfügbarer Arbeitsspeicher, Hintergrundlast.
4. Tabelle „Workload-Antwortzeit“ (nur wenn du Neustarts aktiviert hast UND es einen messbaren Gewinn gab) — pro Workload vorher / nachher / Änderung.
5. Abschnitt „Was du tun musst“ (nur wenn es Folgeaufgaben gibt) — die oben beschriebenen nummerierten Karten.
6. Fußzeile „Übersprungen: …“ (nur wenn du Schritte abgelehnt hast) — die Liste der Aktionsbezeichnungen, damit du später erneut starten und sie noch einmal prüfen kannst.

Wenn der Server bereits aufgeräumt war und nichts zu tun ist, schließt Faro mit „Dein Server ist bereits aufgeräumt. Nichts zu tun.“ — keine erfundene Zusammenfassungstabelle, kein aufgeblähter Bericht.

Referenz

Was vorab autorisiert wird und was trotzdem nachfragt

Speicherung deiner Häkchen — deine Auswahl (und der Umschalter für Workload-Neustarts) wird im localStorage deines Browsers gespeichert, nach Server-Hostname getrennt. Wenn du Browserdaten löschst, werden die Häkchen auf die Standardauswahl zurückgesetzt.

Wie Folgeaufgaben + Neustart-Bypass funktionieren — wenn das Bereinigungsrezept aktiv ist, umgehen die rein lesenden Momentaufnahme-Skripte des Rezepts und alle von dir im Modal angehakten Befehle der sicheren Stufe die Klassifizierung destruktiver Befehle — so werden doppelte Nachfragen „Diesen Befehl genehmigen?“ vermieden. Vorsichts- und Pro-Element-Stufen fragen immer erneut. Der Bypass ist inhaltsbewusst (jedes Befehlssegment wird gegen eine Allowlist rein lesender Befehle geprüft), und verbotene Muster wie rm -rf / werden grundsätzlich blockiert.