Wenn der Server um Erlaubnis fragt
Auf meinem Server läuft neben den ernsthaften Diensten auch ein Minecraft-Server. Ein geplanter Job prüft ihn regelmäßig, und wenn dabei etwas schiefgeht, ist die Ursache fast immer dieselbe: Es liegt eine neue Version vor, und die alte will nicht mehr.
Die naheliegende Lösung wäre, das Update einfach automatisch einzuspielen. Ich habe mich dagegen entschieden, und der Grund dafür ist der eigentliche Inhalt dieses Beitrags.
Zwei Extreme, die beide falsch sind
Alles von Hand zu machen bedeutet: Der Job meldet einen Fehler, ich lese die Nachricht abends, öffne den Laptop, verbinde mich per SSH, sehe nach, spiele das Update ein. Fünf Minuten Arbeit, verteilt auf zwanzig Minuten Kontextwechsel.
Alles automatisch zu machen bedeutet: Um drei Uhr nachts entpackt ein Skript ohne Aufsicht eine neue Serverversion über ein laufendes Verzeichnis. Wenn dabei etwas schiefgeht – ein unvollständiger Download, eine geänderte Verzeichnisstruktur, eine überschriebene Konfiguration – merke ich es am nächsten Morgen an den Beschwerden.
Dazwischen liegt die Variante, die ich für die richtige halte: Der Job erkennt das Problem selbst, schlägt die Lösung selbst vor, und fragt einmal kurz nach. Die Entscheidung dauert zwei Sekunden am Handy, die Ausführung übernimmt wieder die Maschine.
Der Aufbau
In n8n sind das fünf Bausteine:
- Schedule Trigger – der geplante Lauf
- Execute Command – die eigentliche Prüfung
- Bei Fehler: Telegram, „Send and Wait for Response" mit Antworttyp Approval
- If auf das Ergebnis
- Bei Zustimmung: Execute Command mit dem Update, danach eine Rückmeldung
Der entscheidende Baustein ist der dritte. Der Telegram-Node hält die Ausführung an, schickt eine Nachricht mit zwei Schaltflächen und läuft weiter, sobald geklickt wurde. Du brauchst keinen zweiten Workflow, keine Zustandsverwaltung, keine Tabelle mit offenen Anfragen. n8n hält die pausierte Ausführung, bis eine Antwort kommt.
Vier Fallstricke
Der Fehlerfall erreicht deinen Zweig nie. Das ist der Fehler, den ich zuerst gemacht habe. Der Execute-Command-Node wirft bei einem Exit-Code ungleich null einen Fehler und bricht die Ausführung ab – die nachgelagerte Verzweigung wird nie erreicht, und es kommt weder eine Erfolgs- noch eine Fehlermeldung an. Du merkst nicht, dass etwas kaputt ist; du merkst nur, dass es still ist. In den Einstellungen des Nodes muss On Error auf Continue (using error output) stehen.
Ohne Zeitlimit wartet der Workflow ewig. Drückst du den Knopf nicht, bleibt die Ausführung offen. Bei einem Job, der stündlich läuft, sammeln sich diese Ausführungen an. Setz ein Limit – eine Stunde reicht – und behandle den Ablauf wie ein Nein.
Der Antwort-Link ist der Schlüssel. Die Schaltflächen sind Links auf deinen n8n-Webhook mit einem Token darin. Wer den Link hat, kann die Aktion auslösen, ganz ohne Zugriff auf deinen Chat. Solche Nachrichten leitet man nicht weiter, und die Empfängeradresse gehört fest in den Node und nicht dynamisch aus dem Trigger.
Eine Frage ohne Information ist keine Frage. „Fehler aufgetreten, Update einspielen?" ist wertlos – du weißt ja nicht, ob der Fehler überhaupt mit dem Update zu tun hat. Nimm die tatsächliche Fehlerausgabe mit in die Nachricht. Dann entscheidest du anhand dessen, was passiert ist, statt anhand einer Vermutung.
Und das Update selbst
Zwei Regeln, die bei Minecraft Bedrock teuer erkauft sind: Erst sichern, dann anfassen. Und beim Entpacken die Konfigurationsdateien ausnehmen, sonst überschreibt das Archiv server.properties, permissions.json und allowlist.json mit den Standardwerten.
tar czf backups/worlds-$(date +%F-%H%M).tar.gz worlds
tmux send-keys -t mc "stop" Enter
unzip -o -q bedrock-server-neu.zip \
-x 'server.properties' 'permissions.json' 'allowlist.json' 'worlds/*'Was ich daraus mitnehme
Die interessante Frage bei Automatisierung ist selten „lässt sich das automatisieren". Fast alles lässt sich automatisieren. Die interessante Frage ist: Was passiert, wenn es schiefgeht, während niemand hinsieht?
Wo die Antwort „nichts Schlimmes" lautet, kann der Ablauf durchlaufen. Wo sie „Datenverlust" lautet, gehört ein Mensch dazwischen – aber einer, dem die Maschine die Arbeit bis zur Entscheidung abgenommen hat und ab der Entscheidung wieder. Genau das macht diese Rückfrage. Sie kostet zwei Sekunden und verhindert den einen Fall, den man sonst am Morgen danach bereut.