Vous voulez donc Servir Discourse à partir d’un sous-dossier (préfixe de chemin) au lieu d’un sous-domaine ?
Cool. Ça ressemble à ce que je cherche. Merci.
Comment puis-je y accéder ?? Je veux dire, comment trouver cette partie ?? Il y a 2 ensembles de lignes identiques ! Lesquelles sont destinées à être modifiées ou changées ??
EDIT à partir d’ici :
Laisse tomber mec..! Merci pour ton temps ! Je l’ai trouvé moi-même ![]()
Au fait, ta méthode ne fonctionne pas tout à fait.
Vous devez également configurer les variables d’environnement au moins dans Discourse 3.
Ouvrez votre fichier app.yml
Recherchez les variables d’environnement et remplissez-les.
Merci pour cela,
J’ai d’abord configuré Discourse en mode autonome, qui m’affiche la page d’inscription correcte en http. J’ai ensuite installé nginx mais sans certificat, car je l’utilise dans un laboratoire de test sans accès Lets Encrypt. Je vois maintenant la page d’inscription, mais sans style. Dans les logs nginx sur l’hôte, je vois des erreurs 404. Une idée pour résoudre cela ?
Merci
Résolu : j’ai dû commenter try_files $uri $uri/ =404;", ce qui est par défaut sous debian 11 et nginx 18.0-6.
Erreurs. Après avoir configuré cela, le navigateur Chrome affiche des erreurs :
Contenu mixte : la page « <URL> » a été chargée via HTTPS, mais a demandé une police non sécurisée « <URL> ». Cette requête a été bloquée ; le contenu doit être servi via HTTPS.
Avez-vous activé force_https ?
Oui, je l’ai fait à l’étape certbot --nginx. Et j’ai essayé plusieurs fois, ça n’a pas fonctionné.
Vous devez définir le paramètre de discourse force_https, pas sur nginx. Il est préférable de le faire avec une variable d’environnement, mais vous pouvez le faire dans l’interface utilisateur si vous pouvez accéder à admin/settings.
J’ai suivi les étapes ci-dessus et j’ai réussi à exécuter nginx, mais en accédant à l’URL, j’ai reçu une erreur ERR_TOO_MANY_REDIRECTS.
Quelqu’un peut-il m’aider à comprendre pourquoi ?
bind() vers unix:/shared/nginx.http.sock a échoué (95 : Opération non prise en charge)
Je suis donc confus, je ne peux pas exécuter /discourse-setup car je l’installe sur un serveur web existant, mais je suis censé modifier un fichier .yml qui n’est pas créé tant que je n’ai pas exécuté /discourse-setup. Donc app.yml n’existe pas, comment puis-je donc le modifier ?
Copiez standalone.yml du répertoire des exemples.
Je me sens idiot après avoir parcouru ce post vingt fois et avoir manqué que la dernière ligne de cette section disait « Ajouté ». Puis-je suggérer à @riking de modifier l’introduction pour qu’elle ressemble à ceci :
J’ai apporté la modification suggérée (et supprimé les publications concernant le fait qu’il s’agissait d’un wiki que votre niveau de confiance vous empêche apparemment de modifier - désolé pour cela). C’est un changement subtil, mais je pense qu’il pourrait aider d’autres personnes. Merci.
J’ai une configuration légèrement différente : mon proxy inverse ne fonctionne pas sur la machine hôte, mais dans un conteneur Docker séparé.
J’utilise actuellement un réseau Docker pour connecter les deux, donc je n’expose pas Discourse via un socket Unix.
Cela fonctionne bien, mais présente un inconvénient majeur : la limitation de débit ne voit que l’adresse IP du proxy inverse et limite donc par erreur le proxy inverse…
Je vois plusieurs options :
- Supprimer le modèle de limitation de débit. (Pas une excellente option…)
- Créer mon propre modèle qui configure Nginx pour
set_real_ip_fromle proxy inverse. - Ajuster le modèle de limitation de débit pour utiliser
$http_x_forwarded_forau lieu de$binary_remote_addr. - Exposer le socket Unix dans le conteneur du proxy inverse. (Je ne sais pas si/comment c’est possible.)
Idéalement, je ne voudrais pas créer mon propre modèle ni modifier ceux existants, mais utiliser la configuration par défaut aussi près que possible, c’est-à-dire l’option 4.
Des idées ? Avantages/inconvénients ? Réflexions ?
Je comprends que vous ayez eu ce problème il y a longtemps, mais je viens de le rencontrer ce soir et j’ai trouvé une solution qui a fonctionné pour moi.
Mon problème venait de mon registraire qui agissait comme un proxy avec les paramètres SSL/TLS réglés sur “flexible”. Le passer à “Full” a résolu le problème immédiatement - j’aurais juste aimé y avoir pensé avant de reconstruire ~20 fois.
Qu’est-ce qu’une installation à deux conteneurs ? Merci.
Un conteneur est un concept Docker et constitue essentiellement une unité de traitement isolée qui peut avoir une configuration indépendante du système d’exploitation.
Normalement, Discourse et toutes ses dépendances (dans l’installation standard) s’exécutent dans un seul conteneur.
Il existe des installations plus avancées où d’autres services peuvent s’exécuter dans un autre conteneur et même une où Discourse est divisé en deux (un pour la base de données et un pour le web) - une « installation à deux conteneurs ».
NB Discourse utilise son propre lanceur personnalisé qui n’est pas tout à fait le même que celui utilisé par Docker standard.
J’ai une question : si un proxy inverse se trouve dans un conteneur Docker séparé, peut-il toujours utiliser des sockets Unix ?


