Vom Heimrechner auf einen vServer

Der Auslöser war ein Windows-Update. Es lief in der Nacht zum Sonntag, startete den Rechner neu, und weil der Minecraft-Server nicht automatisch mitstartete, war er bis Sonntagmittag weg. Das war das dritte Mal in einem halben Jahr.

Also habe ich zum ersten Mal in meinem Leben einen Server gemietet. Ein kleiner virtueller Server: vier Kerne, acht Gigabyte RAM, 160 Gigabyte SSD, ein paar Euro im Monat. Nach der Bestellung kam eine E-Mail mit einer IP-Adresse, einem Benutzernamen und einem Passwort. Mehr nicht. Kein Desktop, kein Installationsassistent, kein Fenster.

Die erste Verbindung

ssh root@203.0.113.42

Und dann stand da ein Prompt, und mehr nicht. Ich glaube, ich habe in der ersten Viertelstunde nur ls und cd getippt und mich umgeschaut wie in einer fremden Wohnung.

Was ich in dieser ersten Woche verstanden habe und was mir vorher niemand so gesagt hatte: Ein Linux-Server ohne Oberfläche ist nicht schwieriger, er ist nur schriftlich. Alles, was man unter Windows anklickt, gibt es hier auch — es hat nur einen Namen statt eines Symbols. Dienste starten, Software installieren, Rechte vergeben, Logs lesen. Man muss die Namen lernen, das ist alles.

Die zweite Erkenntnis war unangenehmer: Es gibt kein Rückgängig. Kein Papierkorb, keine Sicherheitsabfrage, kein „Sind Sie sicher?". Ein rm -rf an der falschen Stelle ist endgültig. Ich habe in dieser Woche gelernt, vor jedem Löschbefehl kurz innezuhalten und mir den Pfad laut vorzulesen. Diese Angewohnheit habe ich bis heute.

Was sofort besser wurde

Der Server lief einfach. Keine Updates, die neu starten. Kein Familienmitglied, das den Stecker zieht. Keine Nacht, in der ich den Rechner ausschalten wollte und es nicht konnte.

Die Anbindung war eine andere Welt. Mein Heimanschluss hatte einen Upload, der für zwei Spieler reichte und bei vier eng wurde. Der gemietete Server hing an einer Anbindung, bei der Minecraft-Traffic nicht einmal ein Rundungsfehler ist.

Ich konnte von überall arbeiten. Vorher musste ich am Rechner sitzen. Jetzt reichte ein Terminal. Das klingt nach einer Kleinigkeit und hat mein Verhalten komplett verändert: Ich habe angefangen, Dinge zu automatisieren, weil ich sie plötzlich von unterwegs anstoßen konnte.

Die drei Fehler der ersten Woche

Ich habe alles als root gemacht. Der Zugang kam als root, also habe ich als root gearbeitet — Minecraft gestartet, Dateien angelegt, Software installiert. Das ist bequem und falsch. Der Server lief mit vollen Systemrechten; ein Plugin mit einer Sicherheitslücke hätte alles anfassen können. Der Umbau danach war lästig, weil sämtliche Dateien plötzlich dem falschen Benutzer gehörten:

adduser minecraft
chown -R minecraft:minecraft /srv/minecraft

Ich habe SSH mit Passwort offen gelassen. Nach drei Tagen habe ich zum ersten Mal in /var/log/auth.log geschaut und war ehrlich schockiert: hunderte Anmeldeversuche pro Stunde, mit Benutzernamen wie admin, test, oracle, minecraft. Das ist völlig normal und passiert jedem Server im Internet innerhalb von Minuten. Die Gegenmittel sind Standard, und ich habe sie alle nachgerüstet:

PermitRootLogin no
PasswordAuthentication no

Dazu ein SSH-Schlüssel statt eines Passworts und fail2ban, das nach mehreren Fehlversuchen die Adresse sperrt. Die Zahl der Versuche in den Logs sank innerhalb eines Tages auf fast null.

Ich hatte keine Firewall. Ich dachte, es reiche, keine Dienste zu starten, die man nicht braucht. Stimmt im Prinzip — bis man versehentlich einen startet. Eine ausdrückliche Regel ist besser als eine Annahme:

ufw default deny incoming
ufw allow OpenSSH
ufw allow 25565/tcp
ufw enable

Tipp

Wer zum ersten Mal einen Server mietet, sollte diese drei Dinge in der ersten Stunde erledigen, nicht in der ersten Woche: eigener Benutzer statt root, SSH nur mit Schlüssel, Firewall mit Standardverbot. Danach kann man in Ruhe alles andere einrichten. Umgekehrt herum arbeitet man tagelang auf einem System, das man später ohnehin anfassen muss.

Dienste, die von selbst wieder hochkommen

Der eigentliche Gewinn kam, als ich verstanden habe, wie man einem Linux-System sagt: Dieses Programm soll laufen, und wenn es abstürzt, starte es neu.

[Unit]
Description=Minecraft Server
After=network.target
 
[Service]
User=minecraft
WorkingDirectory=/srv/minecraft
ExecStart=/usr/bin/java -Xmx6G -Xms6G -jar paper.jar nogui
Restart=on-failure
RestartSec=10
 
[Install]
WantedBy=multi-user.target

systemctl enable minecraft — und der Server startet beim Hochfahren mit. Restart=on-failure — und er kommt nach einem Absturz von allein zurück.

Damit war der Grund für den Umzug endgültig aus der Welt. Aber es steckt noch etwas Größeres darin, das ich erst später formulieren konnte: Der Unterschied zwischen „ein Programm läuft" und „ein Dienst läuft" ist die Frage, was passiert, wenn es nicht mehr läuft. Ein Programm ist dann weg. Ein Dienst kommt zurück, meldet sich, hinterlässt Spuren im Log.

Die erste Woche in Befehlen

Für alle, die vor demselben leeren Prompt sitzen — das ist ungefähr die Reihenfolge, in der ich mir die Umgebung erschlossen habe, und sie hat sich bewährt.

Wo bin ich? pwd, ls -la, df -h, free -m. Verzeichnis, Inhalt, Plattenplatz, Speicher. Vier Befehle, und man hat ein Bild von der Maschine.

Was läuft? systemctl list-units --type=service --state=running, ss -tlnp. Welche Dienste laufen, welche Ports lauschen. Der zweite Befehl war für mich eine Offenbarung — er beantwortet die Frage „was ist von außen erreichbar" direkter als jede Firewall-Konfiguration.

Was ist passiert? journalctl -xe, journalctl -u <dienst> -f. Systemprotokoll, und das Protokoll eines einzelnen Dienstes im Verlauf. Das -f am Ende ist der Unterschied zwischen „nachsehen" und „zusehen".

Wer war da? journalctl -u ssh, last. Beim ersten Blick in die Anmeldeversuche war ich ehrlich erschrocken.

Der Moment, in dem es klick gemacht hat

Es gab einen konkreten Augenblick, in dem ich verstanden habe, worin der Unterschied zwischen einem Rechner und einem Server besteht.

Ich hatte einen Dienst eingerichtet, der beim Systemstart mitläuft, und danach zum Testen die Maschine neu gestartet. Nach neunzig Sekunden war sie wieder da, mit allem, was laufen sollte — ohne dass ich etwas getan hätte.

Das klingt trivial. Für mich war es der Übergang von „ich starte Programme" zu „ich beschreibe einen Zustand, und das System stellt ihn her". Genau dieselbe Denkweise steckt Jahre später in Container-Definitionen, in Konfigurationsdateien für Dienste und in allem, was man heute deklarativ nennt.

Wer diesen Gedanken einmal verinnerlicht hat, richtet Systeme anders ein: nicht als Folge von Handgriffen, sondern als Beschreibung dessen, was gelten soll. Der Test dafür ist immer derselbe — einmal neu starten und nachsehen, was fehlt.

Was mich am meisten überrascht hat

Wie schnell aus „ich habe einen Server" ein „ich betreibe etwas" wurde.

Auf dem Rechner unter dem Schreibtisch lief Minecraft, sonst nichts. Auf dem gemieteten Server lief nach drei Monaten: der Minecraft-Server, der Discord-Bot, ein Webserver für die Seite, ein Sicherungsskript, ein Zeitplan, der jede Nacht aufräumt. Und weil das alles auf derselben Maschine lag, habe ich zum ersten Mal darüber nachgedacht, wie sich Dinge gegenseitig behindern. Wenn Minecraft sechs von acht Gigabyte belegt und der Bot einen Speicherschub braucht, wird es eng.

Diese Frage — wer bekommt wie viel, und was passiert, wenn alle gleichzeitig wollen — hat mich seitdem nie mehr losgelassen. Sie ist bei einem Server mit acht Gigabyte dieselbe wie bei einem Rechner mit vierundsechzig, auf dem heute mehrere Minecraft-Server, mehrere Webdienste und eine Datenbank nebeneinander laufen. Nur die Zahlen sind größer, und die Antworten muss man immer noch messen.