Bash-Skripte, die ich auf jedem neuen Server wiederverwende
Werbung
Jeder Server, den ich übernehme – egal ob frischer VPS oder eine Maschine, die beim Kunden schon seit Jahren läuft – bekommt denselben kleinen Satz an Skripten in /usr/local/bin gelegt.
Keines davon ist ein Meisterwerk. Es sind genau die Skripte, die man mal eben in fünf Minuten runterschreibt und dann eigentlich wieder vergisst. Und doch schleppe ich genau diese Skripte, nur leicht aktualisiert, seit Jahren mit mir herum. Sie machen sich einfach immer wieder bezahlt.
1. Der "Wie sieht dieser Server aus"-Snapshot
Das absolut Erste, was ich auf einem neuen oder mir unbekannten Server ausführe, ist ein schnelles Snapshot-Skript. Es spuckt Disk-Usage, Arbeitsspeicher, Load Average, die Top-RAM-Fresser und alle lauschenden Netzwerk-Ports aus:
#!/bin/bash
# server-snapshot.sh
echo "== Uptime & Load =="
uptime
echo -e "\n== Disk Usage =="
df -hT --total | grep -E '^(Total|/dev)'
echo -e "\n== Memory =="
free -h
echo -e "\n== Top 5 Memory Consumers =="
ps aux --sort=-%mem | head -6
echo -e "\n== Listening Ports =="
ss -tulpn | grep LISTEN
Darin steckt nichts, was man nicht auch manuell tippen könnte. Aber fünf separate Befehle von Hand abzufeuern, jedes Mal, wenn man sich auf einem Server einloggt, den man nicht komplett auswendig kennt – genau so rutschen einem Dinge durch. Ein Skript, ein kurzer Blick, und ich habe ein mentales Modell der Kiste im Kopf, bevor ich auch nur eine einzige Config-Datei anfasse.
2. Den wahren Speicherfresser finden
"Festplatte voll" ist einer der häufigsten Alerts, die ich bekomme. Die Ursache liegt fast nie dort, wo die Leute sie vermuten. Dieses Skript wandert vom Root-Verzeichnis abwärts, sortiert Ordner nach Größe und stoppt bei einer sinnvollen Tiefe, damit man nicht unter Tausenden von Zeilen Output begraben wird:
#!/bin/bash
# disk-hogs.sh
du -ahx --max-depth="${1:-3}" / 2>/dev/null | sort -rh | head -25
Ohne Parameter prüft es drei Ebenen tief. Übergibt man eine Zahl, gräbt es tiefer. In neun von zehn Fällen ist die Antwort: unrotierte Logs, ein uraltes Backup, das jemand vergessen hat, oder ein verirrter node_modules-Ordner, der es irgendwie auf den Produktionsserver geschafft hat.
3. Zertifikatsablauf prüfen – ganz ohne Dashboard
Nicht jede Website sitzt hinter einem schicken Monitoring-Stack, besonders nicht bei kleineren Kunden-Setups. Für diese Fälle gibt mir ein schneller Loop über eine Domain-Liste exakt aus, wie viele Tage noch auf jedem SSL-Zertifikat verbleiben:
#!/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 days\n" "$domain" "$days"
done < domains.txt
Ich pflege eine domains.txt pro Kunde mit einem Hostnamen pro Zeile und lasse das monatlich laufen. Da Let's Encrypt die Verlängerung normalerweise automatisch erledigt, besteht der wahre Job dieses Skripts darin, die Randfälle zu erwischen, bei denen eine Hintergrund-Erneuerung stillschweigend fehlgeschlagen ist.
4. Logs und Journal-Bloat aufräumen
Das systemd-Journal und die App-Logs haben die Angewohnheit, eine Festplatte über Monate hinweg leise und heimlich zu füllen. Bevor ich mich auf die Jagd nach einem "mysteriösen" Disk-Usage-Problem mache, lasse ich dieses Cleanup-Skript laufen:
#!/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
Es ist bewusst konservativ eingestellt. Zwei Wochen Journal-Logs und 30 Tage rotierte Applikations-Logs sind für nahezu jede Debugging-Session mehr als ausreichend. Gleichzeitig verhindert es, dass die Festplatte schleichend der 100%-Marke entgegenkriecht.
Alles an einem Ort
All das lebt in einem winzigen Git-Repository, 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/
Es geht hier überhaupt nicht um die Skripte selbst. Es geht darum, dass ich abends um 23 Uhr auf einem Server, auf dem ich seit Monaten nicht mehr eingeloggt war, nicht vor einem leeren Terminal sitze. Ich führe exakt die gleichen Befehle aus wie immer, und diese Vertrautheit ist weit mehr wert als jedes der Skripte für sich allein genommen.
Werbung