Bash-Skripte, die ich auf jedem neuen Server wieder einsetze

Jeder Server, den ich übernehme, ob ein frischer VPS oder eine Maschine, die ein Kunde schon seit Jahren betreibt, bekommt dieselbe kleine Sammlung von Skripten in /usr/local/bin. Keines davon ist besonders raffiniert. Es sind genau die Dinge, die man in fünf Minuten hinschreibt und dann wieder vergisst, nur dass ich dieselben, leicht aktualisierten Versionen seit Jahren mit mir herumtrage, weil sie sich immer wieder auszahlen.

1. Der Schnellüberblick: Wie sieht dieser Server eigentlich aus

Das Erste, was ich auf jedem unbekannten oder neuen Server ausführe, ist ein kurzes Übersichtsskript. Es zeigt Plattenbelegung, Speicher, Load Average, die fünf größten Speicherverbraucher und alles, was auf einem Netzwerkport lauscht:

#!/bin/bash
# server-snapshot.sh
echo "== Uptime & Load =="
uptime

echo -e "\n== Festplattenbelegung =="
df -hT --total | grep -E '^(Total|/dev)'

echo -e "\n== Speicher =="
free -h

echo -e "\n== Top 5 Speicherverbraucher =="
ps aux --sort=-%mem | head -6

echo -e "\n== Offene Ports =="
ss -tulpn | grep LISTEN

Nichts davon könnte man nicht auch manuell eintippen, aber fünf einzelne Befehle bei jedem Login auf einen Server zu tippen, dessen Zustand man nicht mehr genau im Kopf hat, ist genau der Punkt, an dem Dinge übersehen werden. Ein Skript, ein Blick, und ich habe ein mentales Modell der Maschine, bevor ich überhaupt etwas anfasse.

2. Herausfinden, was die Platte tatsächlich füllt

"Die Platte ist voll" ist einer der häufigsten Alarme, die ich bekomme, und die Ursache liegt fast nie dort, wo man sie erwarten würde. Dieses Skript geht vom Root-Verzeichnis aus, sortiert nach Größe und hört bei einer sinnvollen Tiefe auf, damit man nicht in tausenden Zeilen versinkt:

#!/bin/bash
# disk-hogs.sh
du -ahx --max-depth="${1:-3}" / 2>/dev/null | sort -rh | head -25

Ohne Argument prüft es drei Ebenen tief, mit einer Zahl als Argument geht es tiefer. In neun von zehn Fällen ist die Antwort: Logs, ein altes Backup, das jemand vergessen hat, oder ein verirrtes node_modules-Verzeichnis, das irgendwie auf den Server gelangt ist.

3. Zertifikatsablauf prüfen, ohne Dashboard

Nicht jede Seite hängt an einem Monitoring-Stack, gerade bei kleineren Kundensetups. Für diese Fälle gibt eine kurze Schleife über eine Domain-Liste an, wie viele Tage jedes Zertifikat noch gültig ist:

#!/bin/bash
# cert-check.sh
while read -r domain; do
  expiry=$(echo | openssl s_client -servername "$domain" -connect "$domain:443" 2>/dev/null \
    | openssl x509 -noout -enddate | cut -d= -f2)
  days=$(( ($(date -d "$expiry" +%s) - $(date +%s)) / 86400 ))
  printf "%-35s %s Tage\n" "$domain" "$days"
done < domains.txt

Ich pflege pro Kunde eine domains.txt mit einem Hostnamen pro Zeile und lasse das Skript monatlich laufen. Da Let's Encrypt die Erneuerung normalerweise automatisch übernimmt, besteht die eigentliche Aufgabe dieses Skripts darin, die Fälle zu finden, in denen die Erneuerung still und leise fehlgeschlagen ist.

4. Logs und Journal aufräumen

Das systemd-Journal und Anwendungslogs füllen über Monate ganz unauffällig die Platte. Bevor ich einem "mysteriösen" Plattenplatzproblem nachgehe, läuft das hier:

#!/bin/bash
# log-cleanup.sh
journalctl --vacuum-time=2weeks
find /var/log -name "*.gz" -mtime +30 -delete
find /var/log -name "*.log.*" -mtime +30 -delete

Bewusst konservativ gehalten: Zwei Wochen Journal und 30 Tage rotierte Logs reichen für fast jede Debugging-Session, während die Platte nicht langsam Richtung voll wandert.

Alles an einem Ort

Alle diese Skripte liegen in einem kleinen Git-Repo, das ich auf jeden Server klone, den ich verwalte:

git clone https://github.com/yourname/server-toolkit /opt/toolkit
ln -s /opt/toolkit/*.sh /usr/local/bin/

Die Skripte selbst sind nicht der Punkt. Der Punkt ist, dass ich um 23 Uhr, wenn auf einem Server, in den ich seit Monaten nicht eingeloggt war, etwas nicht stimmt, nicht vor einem leeren Terminal sitze. Ich tippe dieselben Befehle, die ich immer tippe, und genau diese Vertrautheit ist mehr wert als jedes einzelne Skript für sich.