Ah, cela a en effet plus de sens
Vous pouvez vérifier localement avec n’importe quel client SSH que vous préférez. Selon votre configuration, les fichiers devraient se trouver dans un chemin du type /var/discourse/shared/standalone/uploads/default/original/2X/
Vous pouvez donc exécuter ls -R /var/discourse/shared/standalone/uploads/ | grep 4064b pour trouver le fichier 4064b…d.png.
Je parle de la même instance Discourse que @masterakay.
Nous avons migré vers S3 il y a plus de deux ans ; aucun fichier dans le répertoire local des uploads n’est postérieur à 2018.
À ma connaissance, les images sont téléchargées dans le dossier « original », puis traitées (recadrées, réduites, etc.) et placées dans le dossier « optimized ». Les URL utilisées par Discourse lors du téléchargement d’images proviennent toujours du dossier « /original/1X/ ». D’une manière ou d’une autre, avec la mise à niveau, le dossier « 1X » a disparu.
Il existe un dossier « default » qui contient de nombreux fichiers téléchargés (images, etc.) ainsi que des versions recadrées. On y trouve environ 10 000 fichiers, ce qui représente environ 2,5 Go.
Le problème est que les URL des images dans les publications pointent toujours vers la version « original ».
Nous avons remarqué que les fichiers manquants constituent un sous-ensemble des fichiers présents dans le dossier « default ».
Les nouveaux téléchargements fonctionnent sans problème et sont stockés dans « /original/2X/ ».
Quelqu’un a-t-il des idées sur l’endroit où le dossier « /original/1X/ » a pu disparaître et s’il est possible de le rétablir ?
@sam@codinghorror Je suis vraiment désolé de vous entraîner dans cette affaire, mais c’est assez urgent. Nous sommes étudiants et nous nous sentons un peu impuissants face à la pression de l’université qui nous demande de corriger les images.
Comment avez-vous configuré S3 ? Avez-vous défini des valeurs dans app.yml ou uniquement dans l’interface d’administration ? Il semble qu’il y ait une valeur inattendue pour DISCOURSE_S3_BUCKET ou DISCOURSE_S3_BACKUP_BUCKET.
Oui, comme je l’ai expliqué, tout fonctionnait bien jusqu’à la dernière mise à jour. Nous avons suivi toutes les étapes.
En particulier, nous avons fait quelque chose comme ceci :
En ce qui concerne ces valeurs, je ne parviens pas à trouver de variable définie dans app.yml. Ce n’était pas nécessaire auparavant. Quelque chose a-t-il changé ?
En effet. Il est possible que quelque chose ne fonctionne pas correctement dans le code, mais nous ne savons ni quoi ni pourquoi. Nous avons donc besoin de plus d’informations.
Il existe deux méthodes différentes pour configurer S3 : vous pouvez configurer l’environnement dans app.yml ou saisir les valeurs dans l’interface d’administration. Les noms des variables diffèrent légèrement dans chaque cas.
Le sujet que vous avez lié décrit la configuration via l’interface d’administration. Si c’est ainsi que vous avez configuré votre site, pouvez-vous nous indiquer quelles valeurs vous avez pour s3_upload_bucket et s3_backup_bucket ?
Le problème est survenu parce que ces paramètres ne sont pas censés avoir la même valeur — recherchez le sujet de configuration pour la ligne « Dois-je vraiment utiliser des buckets séparés pour les uploads et les sauvegardes ? ».
Un travail de maintenance a été exécuté sur le contenu du bucket de sauvegarde et a affecté les uploads car leurs valeurs se chevauchaient.
@sam, nous devrions probablement l’imposer dans le code, pas seulement dans la documentation.
Pour réparer votre site, voici deux étapes :
Tout d’abord, vous devrez modifier le préfixe des sauvegardes — ajouter /backups à la fin, comme décrit dans le sujet de configuration, est suffisant.
Ensuite, déplacez tout ce qui se trouve dans le bucket S3 vers l’emplacement correct. Tout ce qui se trouve dans le dossier « default » en haut doit être remonté au niveau supérieur.
Par exemple, il y a probablement un dossier « default/originals » qui doit être déplacé vers le haut.
Vous devrez utiliser la console web AWS ou un autre outil pour parcourir le bucket.
Très bien, merci beaucoup ! Je vais essayer les étapes et revenir ici si jamais quoi que ce soit se produit. Tu as une idée de pourquoi cela est arrivé tout à coup ?
Salut @schleifer, c’est logique, j’ai donc ajouté le préfixe « backups » au nom du bucket.
Concernant les uploads existants, tous se trouvent dans /default/ (pas dans des sous-dossiers). Les URL des images dans les publications (et partout ailleurs) utilisent /original/* ou /optimized/*.
Si nous déplaçons tout le contenu du dossier default d’un niveau vers le haut (vers la racine), les images se retrouveront dans /*.
Et non, il n’y a aucun dossier dans defaults, seulement des fichiers d’upload. Il semble contenir des fichiers avec un nom standard de hachage de 40 caractères, ainsi que certains avec des suffixes comme « _2_10x10 » (que je suppose provenir de l’optimisation).
Comment suggères-tu de régler ce problème ? Corriger toutes les publications avec de nouveaux liens prendra du temps. Est-il possible de regrouper les fichiers dans les dossiers appropriés en se basant sur ce nom de fichier ?
C’est… inattendu. Nous allons devoir corriger manuellement pas mal de choses, alors.
La question la plus importante serait : « Les nouveaux téléchargements vont-ils à l’emplacement correct ? »
En supposant que ce soit le cas, vous pouvez placer les anciens téléchargements à un emplacement connu et ajuster leur entrée dans la base de données. Combien y a-t-il de fichiers dans /default/ ?
Heureusement, les nouveaux uploads fonctionnent comme prévu dans les sous-dossiers. De plus, les liens dans les publications pointent vers l’emplacement correct.
Il y a plus de 10 000 fichiers dans /default/. Modifier chaque publication manuellement semble être une tâche considérable. Y a-t-il un moyen de le automatiser ? Peut-être avec un remplacement par expression régulière sur toutes les publications ?
C’est bien le plan, oui. La prochaine étape consiste à placer tous les fichiers AWOL dans un emplacement connu. Dans le bucket, quels sous-répertoires se trouvent sous /original/ ? Il devrait y avoir /1X/ et il peut y en avoir d’autres.
