Bonjour,
Je viens d’installer Discourse et Cloudflared sur mon R-Pi 4, et j’ai suivi les instructions du post original, mais je ne suis pas sûr de ce qu’il faut mettre comme hôte pour Discourse, dois-je simplement mettre localhost puisque le tunnel cloudflared le transmettra ?
Peut-être que @Falco pourrait aider ?
Au fait, désolé pour le déterrage.
Vous devez toujours posséder un domaine pour ce guide, donc la valeur de l’hôte sera soit l’apex du domaine, soit le sous-domaine que vous avez configuré pour Discourse et pour le tunnel.
Donc la valeur de l’hôte devrait être le sous-domaine que je veux pour Discourse ?
Oui, ce devrait être l’URL où vous souhaitez que Discourse soit.
Êtes-vous sûr ?
Si je fais ça, j’obtiens cette erreur :
J’ai défini le nom d’hôte Discourse sur le sous-domaine exact où je veux que Discourse soit.
J’ai installé Cloudflared sur R-Pi4 depuis la CLI (comme écrit ici : Set up your first tunnel · Cloudflare One docs) et je l’exécute en tant que service.
Et j’ai installé Discourse comme mentionné dans votre post original, j’en suis à peu près sûr.
Pouvez-vous partager le domaine ?
Puis-je vous l’envoyer en MP ? Je ne voudrais pas que des inconnus le voient.
Est-ce que ça marche maintenant que vous avez mis le bon domaine ?
Oui ! Je viens de le démarrer ! Merci pour votre aide ! J’ai juste un problème avec MailJet (le fournisseur de messagerie que j’utilise pour STMP), qui s’amuse à pré-bloquer mes e-mails de vérification…
Une publication a été divisée en un nouveau sujet : Alternatives à MailJet ?
Un message a été fusionné dans un sujet existant : Alternatives à MailJet ?
Salut, j’ai réussi à avoir une installation fonctionnelle ! J’ai juste une petite question, combien d’activité/membres pensez-vous qu’un R-Pi 4 Model B avec 4 Go de RAM peut gérer ?
C’est une excellente question. Comme il est difficile d’établir une corrélation directe entre le nombre d’utilisateurs et la charge du serveur dans un système complexe comme Discourse, il est juste de reconnaître que le principal goulot d’étranglement dans un système RaspberryPi est l’IOPS de stockage.
Donc, tant que la plupart de vos ressources nécessaires sont dans la RAM, entre les processus RSS et la mise en cache Linux, vous devriez avoir une expérience fluide. Le fait que Cloudflare agisse comme un CDN de mise en cache aidera également beaucoup, et vous pouvez même prolonger la durée de vie de la configuration du Pi en utilisant Utiliser le stockage objet pour les téléchargements (S3 et clones) après un certain temps.
J’ai reçu cette erreur dans les parties de Docker
ÉCHEC
--------------------
Pups::ExecError : /usr/local/bin/ruby -e 'if ENV[\"DISCOURSE_HOSTNAME\"] == \"discourse.example.com\"; puts \"Aborting! Domain is not configured!\"; exit 1; end' a échoué avec le retour #<Process::Status: pid 115 exit 1>
Emplacement de l'échec : /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec a échoué avec les paramètres \"/usr/local/bin/ruby -e 'if ENV[\\\"DISCOURSE_HOSTNAME\\\"] == \\\"discourse.example.com\\\"; puts \\\"Aborting! Domain is not configured!\\\"; exit 1; end'\"
bootstrap a échoué avec le code de sortie 1
** ÉCHEC DU BOOTSTRAP ** veuillez faire défiler vers le haut et rechercher les messages d'erreur précédents, il peut y en avoir plus d'un.
./discourse-doctor peut aider à diagnostiquer le problème.
9ba0db264ae559f3f748cc1e42a8683ea0b4e355b0d45da0f472afea7ff7c472
Cela signifie que vous n’avez pas correctement configuré votre domaine. Vous avez besoin d’un domaine valide pour que cela fonctionne. Exécutez à nouveau ./discourse-setup ou modifiez le fichier app.yml pour corriger cela.
Merci pour votre réponse. J’ai réussi à le déployer sur RockPi4 
Salut @Falco,
Je suis à peu près sûr de l’avoir configuré exactement comme dans ton guide, mais je remarque quelque chose d’étrange.
Dans la configuration du conteneur, je ne charge pas les modèles SSL, et j’ai la variable d’environnement DISCOURSE_FORCE_HTTPS définie sur true. Je ne suis pas sûr de ce que cela fait, mais je suppose que cela définit SiteSetting.force_https sur true puis le masque dans le tableau de bord administrateur pour éviter qu’il ne soit désactivé.
Ma configuration de tunnel CF ressemble à ceci :
ingress:
- hostname: dc.example.com
service: http://dc:80 # dc est le nom de mon conteneur d'application autonome Discourse
Le fait est que je peux visiter http://dc.example.com, et il n’est pas redirigé vers https. Est-ce le comportement attendu ?
Peux-tu reproduire cela ? Je me demande si c’est un bug.
Mes paramètres CF pertinents sont :
Je sais que je peux faire en sorte que CF gère la redirection (soit avec Always Use HTTPS, soit avec une règle de redirection en masse), mais j’aurais supposé que Discourse s’en chargerait et redirigerait toutes les URI internes si force_https est activé. Des idées ?
En ignorant le problème de redirection, la navigation sur https://dc.example.com fonctionne bien, quelle que soit la valeur de DISCOURSE_FORCE_HTTPS ou SiteSetting.force_https.
Edit : Bien que je ne comprenne pas ce que force_https fait réellement pour nous (peut-être qu’il ne fait rien si les modèles SSL ne sont pas inclus ?), il m’est apparu que la configuration du tunnel ne fonctionnerait probablement pas telle quelle si Discourse redirigeait réellement tout en https. S’il le faisait, argotunnel ne pourrait pas atteindre Discourse en http (comme service: http://dc:80), donc je devrais peut-être :
service: https://dc:443)Quoi qu’il en soit, peut-être que ton guide argotunnel pourrait être mis à jour pour tenir compte de cela ?
Vous avez raison. Je n’avais pas remarqué que mon domaine TLD de test .dev n’autorisait que HTTPS :
J’ai mis à jour le guide pour indiquer aux utilisateurs d’utiliser une règle de page pour cela, merci pour le signalement !
mais j’ai une question…
je vois beaucoup de vues anonymes sur Consolidated Pageviewshow, je pense que c’est à cause d’un ddos car le serveur cpu est à 60% et le crawler n’est que très peu… mais comment se protéger des ddos.. merci d’avance pour votre réponse
Si vous utilisez Cloudflare comme proxy inverse (une chose distincte de Cloudflared/Argotunnel), vous devriez obtenir une certaine protection DDoS prête à l’emploi. Activez-la avec le « nuage orange » sur votre ou vos enregistrements DNS.