Bootsnap::CompileCache::PermissionError

Bonjour à tous. J’ai installé une nouvelle version de Discourse dans Docker.
Le problème est que, après la reconstruction du conteneur, celui-ci est bien en cours d’exécution et je peux accéder à la page de l’application. Cependant, je reçois une erreur 502. Dans les journaux ou lorsque j’essaie d’accéder à rails c (à l’intérieur du conteneur), tout ce que je vois est cette erreur :
permission_error : bootsnap n’a pas la permission d’écrire des entrées de cache dans ‘tmp/cache/bootsnap/compile-cache’ (ou, moins probablement, n’a pas la permission de lire ‘/usr/local/lib/ruby/2.7.0/set.rb’) (Bootsnap::CompileCache::PermissionError)

Pour résoudre ce problème, je dois exécuter chown -R discourse:discourse /var/www/discourse/tmp (plus précisément, le répertoire /var/www/discourse/tmp/cache/bootsnap) à l’intérieur du conteneur. Immédiatement après, l’application fonctionne correctement, même sans redémarrage. C’est une tâche très fastidieuse à effectuer manuellement après chaque reconstruction.

J’ai pensé que je pourrais résoudre cela en utilisant la section des commandes personnalisées dans app.yml avec la commande chown -R discourse:discourse /var/www/discourse/tmp mentionnée ci-dessus, mais malheureusement, cela ne fonctionne pas. Les commandes semblent bien être exécutées (j’ai essayé mkdir juste pour vérifier), mais les permissions des fichiers ne sont pas modifiées.

Quel pourrait être le problème ici et comment peut-il être résolu ? Existe-t-il une méthode pour modifier correctement les permissions des fichiers ?

1 « J'aime »

C’est étrange. Avez-vous suivi l’installation standard officielle de Discourse ?

1 « J'aime »

Bien sûr. Aucune étape supplémentaire n’a été effectuée.

1 « J'aime »

Peux-tu coller ton fichier container.yml (sans les mots de passe) ?

Bien sûr. Voici :

## Ceci est le modèle de conteneur Docker Discourse tout-en-un, autonome
##
## Après avoir apporté des modifications à ce fichier, vous DEVEZ reconstruire
## /var/discourse/launcher rebuild app
##
## SOYEZ *TRÈS* PRUDENT EN ÉDITANT !
## LES FICHIERS YAML SONT EXTRÊMEMENT SENSIBLES AUX ERREURS D'ESPACEMENT OU D'ALIGNEMENT !
## visitez http://www.yamllint.com/ pour valider ce fichier au besoin

templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
## Décommentez ces deux lignes si vous souhaitez ajouter Lets Encrypt (https)
  - "templates/web.ssl.template.yml"
  #- "templates/web.letsencrypt.ssl.template.yml"

## quels ports TCP/IP ce conteneur doit-il exposer ?
## Si vous souhaitez que Discourse partage un port avec un autre serveur web comme Apache ou nginx,
## consultez https://meta.discourse.org/t/17247 pour plus de détails
expose:
  - "80:80"   # http
  - "443:443" # https

params:
  db_default_text_search_config: "pg_catalog.english"

  ## Définissez db_shared_buffers à un maximum de 25 % de la mémoire totale.
  ## sera défini automatiquement par bootstrap en fonction de la RAM détectée, ou vous pouvez le remplacer
  #db_shared_buffers: "256MB"

  ## peut améliorer les performances de tri, mais ajoute l'utilisation de la mémoire par connexion
  #db_work_mem: "40MB"

  ## Quelle révision Git ce conteneur doit-il utiliser ? (par défaut : tests-passed)
  #version: tests-passed

env:
  LC_ALL: en_US.UTF-8
  LANG: en_US.UTF-8
  LANGUAGE: en_US.UTF-8
  # DISCOURSE_DEFAULT_LOCALE: en

  ## Combien de requêtes web simultanées sont prises en charge ? Dépend de la mémoire et des cœurs CPU.
  ## sera défini automatiquement par bootstrap en fonction des CPU détectés, ou vous pouvez le remplacer
  #UNICORN_WORKERS: 3

  ## TODO : Le nom de domaine auquel cette instance Discourse répondra
  ## Requis. Discourse ne fonctionnera pas avec une adresse IP brute.
  DISCOURSE_HOSTNAME: 'example.com'

  ## Décommentez si vous souhaitez que le conteneur soit démarré avec le même
  ## nom d'hôte (option -h) que celui spécifié ci-dessus (par défaut "$hostname-$config")
  #DOCKER_USE_HOSTNAME: true

  ## TODO : Liste d'e-mails séparés par des virgules qui seront définis comme administrateurs et développeurs
  ## lors de l'inscription initiale, par exemple 'user1@example.com,user2@example.com'
  DISCOURSE_DEVELOPER_EMAILS: 'test@mail.com'

  ## TODO : Le serveur de messagerie SMTP utilisé pour valider les nouveaux comptes et envoyer des notifications
  # L'ADRESSE SMTP, le nom d'utilisateur et le mot de passe sont requis
  # ATTENTION : le caractère '#' dans le mot de passe SMTP peut causer des problèmes !
  DISCOURSE_SMTP_ADDRESS: smtp.mail.io
  #DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: 111
  DISCOURSE_SMTP_PASSWORD: 111
  #DISCOURSE_SMTP_ENABLE_START_TLS: true           # (optionnel, par défaut true)
  #DISCOURSE_SMTP_DOMAIN: discourse.example.com    # (requis par certains fournisseurs)
  #DISCOURSE_NOTIFICATION_EMAIL: noreply@discourse.example.com    # (adresse à partir de laquelle envoyer les notifications)

  ## Si vous avez ajouté le modèle Lets Encrypt, décommentez ci-dessous pour obtenir un certificat SSL gratuit
  #LETSENCRYPT_ACCOUNT_EMAIL: me@example.com

  ## L'adresse CDN http ou https pour cette instance Discourse (configurée pour récupérer)
  ## consultez https://meta.discourse.org/t/14857 pour plus de détails
  #DISCOURSE_CDN_URL: https://discourse-cdn.example.com
  
  ## La clé d'adresse IP Maxmind pour la recherche d'adresses IP
  ## consultez https://meta.discourse.org/t/-/137387/23 pour plus de détails
  #DISCOURSE_MAXMIND_LICENSE_KEY: 1234567890123456

## Le conteneur Docker est sans état ; toutes les données sont stockées dans /shared
volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log

## Les plugins vont ici
## consultez https://meta.discourse.org/t/19157 pour plus de détails
hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git

## Toutes les commandes personnalisées à exécuter après la construction
run:
  - exec: echo "Début des commandes personnalisées"
  ## Si vous souhaitez définir l'adresse e-mail 'From' pour votre première inscription, décommentez et modifiez :
  ## Après avoir reçu le premier e-mail d'inscription, recliquez sur la ligne. Elle ne doit être exécutée qu'une seule fois.
  #- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"
  #- exec: chown -R discourse:discourse /var/www/discourse/tmp/cache/bootsnap  # exemple de commande sur la façon dont j'ai essayé de corriger les permissions de fichier
  - exec: echo "Fin des commandes personnalisées"

Vous n’avez pas exécuté discourse-setup, si ? Cela aurait dû définir certaines options que vous avez commentées. Je viens d’apporter ces modifications et je veux m’assurer que tout fonctionne comme prévu.

Y a-t-il une raison pour laquelle vous n’utilisez pas Let’s Encrypt ?

Je ne vois pas d’explication à votre problème, cependant.

Premièrement, l’application a été construite en utilisant discourse-setup. Après plusieurs tentatives de reconstruction sans obtenir de résultat positif, j’ai basculé vers l’un des fichiers de configuration .yml prédéfinis du répertoire /samples, puis je l’ai simplement modifié avec mes identifiants.

Pourquoi pas Let’s Encrypt ? On m’a demandé d’utiliser les certificats du client. Mais autant que je comprenne, les certificats n’ont rien à voir avec le problème, car ils sont valides et ne posent aucun souci.

Le problème semble se situer au niveau du projet, et est spécifiquement lié aux permissions du fichier de cache bootsnap (peut-être que le problème vient du côté de Bootsnap).

Merci. Je suis d’accord, ce n’est probablement pas le problème. J’ai effectué quelques installations hier qui ont parfaitement fonctionné. Je ne vois aucune explication à votre problème.

1 « J'aime »

Nous rencontrions le même problème et je confirme que l’exécution (à l’intérieur du conteneur Docker) de :

chown -R discourse:discourse /var/www/discourse/tmp

a résolu le problème ! Aucun redémarrage n’a été nécessaire. Avant le changement de propriétaire, les permissions du répertoire ‘tmp’ étaient attribuées à ‘discourse:www-data’. J’espère qu’une solution sera apportée à l’avenir pour que cette action manuelle ne soit plus requise après chaque reconstruction.

1 « J'aime »

Exécutez-vous le lanceur en tant que root ?

1 « J'aime »

Oui @pfaffman, je le suis. Est-ce là le problème ?

Je ne pense pas. Je lance toujours mes instances auto-hébergées en tant que root et je n’ai jamais rencontré un problème comme celui-ci.

Qui est le propriétaire du répertoire si vous n’utilisez pas chown ? Dans un conteneur récemment reconstruit, cela ressemble à ceci :

# ls -l /var/www/discourse/tmp
total 36
lrwxrwxrwx 1 root      root         19 Mar  2 14:56 backups -> /shared/tmp/backups
drwxr-xr-x 1 discourse discourse  4096 Mar  2 14:57 cache
drwxr-xr-x 1 discourse discourse  4096 Mar  2 14:57 ember-rails
drwxr-xr-x 1 discourse root       4096 Mar  2 15:04 pids
lrwxrwxrwx 1 root      root         20 Mar  2 14:56 restores -> /shared/tmp/restores
drwxr-xr-x 2 discourse root       4096 Mar  2 14:56 sockets
drwxr-xr-x 2 discourse discourse 12288 Mar  2 15:02 stylesheet-cache

Avez-vous ajouté des commandes ou des hooks personnalisés à votre app.yml en plus du clonage des plugins ?

3 « J'aime »

Le propriétaire utilisateur et le groupe du répertoire /var/www/discourse/tmp étaient discourse:www-data après le lancement du conteneur. La réattribution à discourse:discourse a résolu le problème. Cela ne m’était jamais arrivé auparavant, alors que j’utilise Discourse depuis plusieurs mois. Quoi qu’il en soit, c’était une correction facile et cela aurait pu être un hasard, donc je ne veux plus vous ennuyer avec cela. Merci beaucoup @gerhard !

2 « J'aime »