Voici la fin de mon fichier unicorn.stderr.log pour ce que cela vaut
I, [2023-08-22T04:18:52.795267 #81] INFO -- : Rafraîchissement de la liste des gems
fatal: propriété douteuse détectée dans le dépôt à '/var/www/discourse'
Pour ajouter une exception pour ce répertoire, appelez :
git config --global --add safe.directory /var/www/discourse
I, [2023-08-22T04:18:57.742262 #81] INFO -- : écoute sur addr=127.0.0.1:3000 fd=10
fatal: propriété douteuse détectée dans le dépôt à '/var/www/discourse'
Pour ajouter une exception pour ce répertoire, appelez :
git config --global --add safe.directory /var/www/discourse
I, [2023-08-22T04:19:04.916798 #81] INFO -- : démarrage de 1 sidekiqs supervisés
I, [2023-08-22T04:19:04.927971 #81] INFO -- : démarrage du démon EmailSync
I, [2023-08-22T04:19:07.993280 #81] INFO -- : processus maître prêt
I, [2023-08-22T04:19:11.010040 #174] INFO -- : worker=0 prêt
I, [2023-08-22T04:19:11.994849 #188] INFO -- : worker=1 prêt
I, [2023-08-22T04:19:12.524936 #203] INFO -- : worker=2 prêt
Fraîchement configuré à partir d’un hébergeur cloud. Je n’ai fait que mettre à jour le système, installer docker, zsh, nginx et lancer la configuration de discourse, qui a échoué.
Modification :
J’ai reconstruit le serveur cloud avec Fedora, j’ai juste installé docker, puis j’ai retenté l’installation fraîche.
Une autre erreur différente
[Tue 22 Aug 2023 05:51:02 PM UTC] Run reload cmd: sv reload nginx
warning: nginx: unable to open supervise/ok: file does not exist
[Tue 22 Aug 2023 05:51:02 PM UTC] Reload error for :
Started runsvdir, PID is 2941
ok: run: redis: (pid 2953) 0s
ok: run: postgres: (pid 2954) 0s
supervisor pid: 2949 unicorn pid: 2981
Attendez, pourquoi avez-vous installé nginx ? L’installation par défaut échouera s’il y a déjà quelque chose sur l’hôte qui utilise le port 80.
Sur une nouvelle gouttelette Digital Ocean, je n’ai rien fait qui ne soit pas dans le guide d’installation officiel, et cela a bien fonctionné. Laissant l’installateur Discourse installer docker pour moi et tout le reste.
Ouais, ça semble être le cas. Cela semble définitivement être un problème car j’ai vu plusieurs personnes le signaler (@DarthLasciel , @Godmar_Back et peut-être @kdambekalns ).
Faites-moi savoir s’il y a quelque chose que vous souhaitez voir de mon installation.
Le problème se produit-il toujours si vous essayez de provisionner sous un nouveau sous-domaine sur un serveur flambant neuf et en suivant strictement notre guide d’installation officiel, en vous abstenant d’installer des paquets supplémentaires sur l’hôte ?
Pouvez-vous également partager votre fichier [redacted] app.yml ?
À l’exception de la partie sous-domaine, j’ai fait exactement cela.
Nouveau serveur Fedora, installation de docker, installation de discourse, configuration sans nginx installé sur le serveur. Résulte en l’erreur postée ci-dessus.
## voici le modèle de conteneur Docker tout-en-un et autonome pour Discourse
##
## Après avoir apporté des modifications à ce fichier, vous DEVEZ reconstruire
## /var/discourse/launcher rebuild app
##
## SOYEZ *TRÈS* PRUDENT LORS DE LA MODIFICATION !
## LES FICHIERS YAML SONT EXTRÊMEMENT SENSIBLES AUX ERREURS D'ESPACEMENT OU D'ALIGNEMENT !
## visitez http://www.yamllint.com/ pour valider ce fichier si nécessaire
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
## Décommentez la ligne suivante pour activer l'écoute IPv6
#- "templates/web.ipv6.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:
- "9980: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 augmente l'utilisation de la mémoire par connexion
#db_work_mem: "40MB"
## Quelle révision Git ce conteneur doit-il utiliser ? (défaut : tests-passed)
#version: tests-passed
env:
LC_ALL: de_DE.UTF-8
LANG: de_DE.UTF-8
LANGUAGE: de_DE.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 un simple numéro IP.
DISCOURSE_HOSTNAME: 'redacted.de'
## Décommentez si vous souhaitez que le conteneur démarre avec le même
## nom d'hôte (-h option) que celui spécifié ci-dessus (par défaut "$hostname-$config")
#DOCKER_USE_HOSTNAME: true
## TODO : Liste des e-mails séparés par des virgules qui seront faits administrateurs et développeurs
## lors de la première inscription, par exemple 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'me@example.com,you@example.com'
## TODO : Le serveur de messagerie SMTP utilisé pour valider les nouveaux comptes et envoyer des notifications
# L'adresse, le nom d'utilisateur et le mot de passe SMTP sont requis
# ATTENTION, le caractère '#' dans le mot de passe SMTP peut causer des problèmes !
DISCOURSE_SMTP_ADDRESS: none.com
#DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: user@none.com
DISCOURSE_SMTP_PASSWORD: none
#DISCOURSE_SMTP_ENABLE_START_TLS: true # (facultatif, défaut true)
#DISCOURSE_SMTP_DOMAIN: discourse.example.com # (requis par certains fournisseurs)
#DISCOURSE_NOTIFICATION_EMAIL: noreply@discourse.example.com # (adresse pour 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 tirer)
## 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 de géolocalisation 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 'De' pour votre première inscription, décommentez et modifiez :
## Après avoir reçu le premier e-mail d'inscription, re-commentez la ligne. Elle ne doit s'exécuter qu'une seule fois.
#- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"
- exec: echo "Fin des commandes personnalisées"
J’ai le même problème de permission où unicorn.pid n’est pas accessible en écriture. Je voulais vous donner plus d’informations en voyant si cela se reproduit avec le guide d’installation officiel, mais cela ne correspond pas à mon système. D’abord, il s’est plaint parce que les ports 80/443 sont déjà utilisés, puis il a effectué des vérifications d’e-mail qui ont échoué. Avez-vous un fichier app.yml qui crée simplement une image docker ne nécessitant rien d’externe ? On suppose que ce même problème devrait se reproduire avec cela aussi bien.
Une installation Docker ratée était à blâmer. Je ne comprends vraiment pas pourquoi il est toujours si difficile d’installer un Docker à jour et fonctionnel. Et il semble qu’ils aient finalement intégré docker-compose à docker (donc vous pouvez faire docker compose ...), bien que je n’y ai toujours pas prêté une attention particulière.
@rtwfroody et @StanD, est-ce que cela résout également votre problème ?
Je suis à peu près sûr que mon installation Docker fonctionne bien et que je n’utilise pas Docker Compose. Franchement, tout ce que j’ai fait, c’est supprimer un plugin (le plugin discourse-checklist qui n’est plus nécessaire) et reconstruire une instance auto-hébergée et à jour qui fonctionne bien depuis des années.
Malheureusement, mon travail quotidien m’a empêché de m’en occuper ces dernières 24 heures. Je devrais m’y remettre ce soir. Je verrai si je peux fournir plus d’informations.
J’ai eu le même problème lors d’une nouvelle installation sur une EC2 (Ubuntu 22.04.3 LTS).
J’avais déjà de l’expérience dans la configuration de Discourse (environ 2-3 fois).
Initialement, j’ai pensé qu’il s’agissait d’un problème de compilation et j’ai exécuté ./launcher rebuild app plusieurs fois, ce qui m’a fait épuiser la limite hebdomadaire de certificats SSL offerte par Let’s Encrypt, raison pour laquelle le site affichait l’erreur site cant be reached error.
Plus tard, j’ai essayé ./launcher logs app. Il affichait les erreurs suivantes :
directory for pid=/var/www/discourse/tmp/pids/unicorn.pid not writable (ArgumentError).
\"detail\": \"Error creating new order :: trop de certificats (5) déjà émis pour cet ensemble exact de domaines au cours des dernières 168 heures - Problème de limite de débit Let’s Encrypt
La seule chose que j’ai faite différemment du guide officiel était l’installation de Docker.
J’ai installé Docker en utilisant sudo apt install docker.io. Je l’ai complètement désinstallé et j’ai laissé l’installation de Docker se faire avec ./discourse-setup.
Et ça a fonctionné !!
Comme l’a dit @pfaffman, c’était un problème avec l’installation de Docker.
PS : J’ai continué avec un nouveau sous-domaine lors de la 2ème tentative d’installation car je devais configurer le serveur Discourse en priorité.
[Note : Mon cas n’est pas vraiment un problème d’ Installation, mais l’erreur produite est la même que dans ce sujet et ma solution (ci-dessous) pourrait être utile à d’autres. Modérateurs (@pfaffman ?), n’hésitez pas à catégoriser ceci plus appropriément.]
Le message ArgumentError apparaît après avoir exécuté ./launcher rebuild app sur mon instance auto-hébergée sous docker (installée et fonctionnelle depuis de nombreuses années). Cela se produit parce que unicorn ne parvient pas à écrire un fichier pid dans le répertoire /var/www/discourse/tmp/pids (à l’intérieur du conteneur). Le journal montre une boucle de messages ArgumentError alors qu’il tente d’écrire ce fichier toutes les quelques secondes.
Je me connecte au conteneur depuis la machine hôte via
Cela me montre une liste des propriétaires:groupes dans ce répertoire
root:root
discourse:discourse
Je rends ensuite le répertoire /var/www/discourse/tmp/pids lisible par tous via
chmod +r /var/www/discourse/tmp/pids
À ce stade, un fichier unicorn.pid est écrit dans ce répertoire. Le fichier a un propriétaire:groupe de discourse:www-data.
Ma solution a été de changer récursivement la propriété de /var/www/discourse en discourse:www-data.
chown -R discourse:www-data /var/www/discourse
Cela prend beaucoup de temps car il y a plus de 100 000 fichiers. Il n’est probablement pas nécessaire de faire tout le répertoire, mais c’est ce que j’ai fait.
Enfin, j’ai rendu le fichier /etc/postgres/13/main/pb_hba.conf lisible par tous
chmod +r /etc/postgres/13/pg_hba.conf
Redémarrez le conteneur et tout fonctionne.
Il semble que la configuration de la propriété des fichiers ne soit pas tout à fait correcte, mais je ne suis pas assez expérimenté dans l’art de définir les permissions pour trouver une solution plus simple. Le fait que le fichier unicorn.pid ait un groupe www-data semble être la clé.
Il semble que je devrais répéter cette procédure chaque fois que je fais un rebuild (c’est-à-dire chaque fois que je modifie le fichier app.yml). Notez également que ce n’est pas un problème avec un plugin particulier.
J’espère que cela suffira comme information pour que l’un des développeurs jette un œil et dise : “Bien sûr ! Il suffit de changer x pour résoudre le problème.”