Ciao,
Ho appena installato Discourse e Cloudflared sul mio R-Pi 4, e ho seguito le istruzioni nel post originale, ma non sono sicuro su cosa mettere come host per Discourse, dovrei semplicemente mettere localhost dato che il tunnel cloudflared lo inoltrerà?
Forse @Falco potrebbe aiutare?
A proposito, scusa per aver riaperto la discussione.
È comunque necessario possedere un dominio per questa guida, quindi il valore dell’host sarà l’apice del dominio o il sottodominio configurato per Discourse e per il tunnel.
Quindi il valore host dovrebbe essere il sottodominio in cui voglio che Discourse sia?
Sì, dovrebbe essere l’URL in cui si desidera che Discourse sia.
Sei sicuro?
Se faccio così, mi dà questo errore:
Ho impostato il nome host di Discourse sul sottodominio esatto in cui voglio che sia discourse.
Ho installato Cloudflared su R-Pi4 dalla CLI (come scritto qui: Set up your first tunnel · Cloudflare One docs) e lo sto eseguendo come servizio.
E ho installato discourse come menzionato nel tuo post originale, ne sono abbastanza sicuro.
Puoi condividere il dominio?
Posso inviartelo in DM? Non vorrei che persone a caso lo vedessero.
Ora funziona ora che hai impostato il dominio corretto?
Sì! L’ho appena avviato! Grazie per il tuo aiuto! Ho solo un problema con MailJet (il provider di posta elettronica che uso per STMP), che si sta divertendo a pre-bloccare le mie email di verifica…
Un post è stato unito a un argomento esistente: Alternative a MailJet?
Ciao, sono riuscito ad avere un’installazione funzionante! Avevo solo una piccola domanda, secondo te quanta attività/quanti membri può gestire un R-Pi 4 Model B con 4 GB di RAM?
Questa è un’ottima domanda. Poiché è difficile stabilire una correlazione diretta tra il numero di utenti e il carico del server in un sistema complesso come Discourse, è giusto riconoscere che il principale collo di bottiglia in un sistema RaspberryPi sono le IOPS di archiviazione.
Quindi, finché la maggior parte delle tue risorse necessarie si trova nella RAM, tra i processi RSS e la cache di Linux, dovresti avere un’esperienza fluida. Il fatto che Cloudflare agisca come una CDN di caching aiuterà anche parecchio, e puoi persino prolungare la durata della configurazione del Pi utilizzando Utilizzo dello storage di oggetti per i caricamenti (S3 e cloni) dopo un po’.
Ho riscontrato questo errore in alcune parti di Docker
FALLITO
--------------------
Pups::ExecError: /usr/local/bin/ruby -e 'if ENV["DISCOURSE_HOSTNAME"] == "discourse.example.com"; puts "Aborting! Domain is not configured!"; exit 1; end' è fallito con ritorno #<Process::Status: pid 115 exit 1>
Posizione del fallimento: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec fallito con i parametri "/usr/local/bin/ruby -e 'if ENV[\"DISCOURSE_HOSTNAME\"] == \"discourse.example.com\"; puts \"Aborting! Domain is not configured!\"; exit 1; end'"
bootstrap fallito con codice di uscita 1
** FALLITO IL BOOTSTRAP ** si prega di scorrere verso l'alto e cercare messaggi di errore precedenti, potrebbero essercene più di uno.
./discourse-doctor potrebbe aiutare a diagnosticare il problema.
9ba0db264ae559f3f748cc1e42a8683ea0b4e355b0d45da0f472afea7ff7c472
Ciò significa che non hai configurato correttamente il tuo dominio. È necessario un dominio valido affinché questo funzioni. Esegui nuovamente ./discourse-setup o modifica il file app.yml per risolvere il problema.
grazie per la risposta
sono riuscito a distribuirlo su RockPi4 
Ciao @Falco,
sono abbastanza sicuro di averlo configurato proprio come la tua guida, ma sto notando qualcosa di strano.
Nella configurazione del container, non sto caricando i template SSL e ho la variabile d’ambiente DISCOURSE_FORCE_HTTPS impostata su true. Non sono sicuro di cosa faccia, ma immagino che imposti SiteSetting.force_https su true e poi lo nasconda nel pannello di amministrazione per evitare che venga disabilitato.
La mia configurazione del tunnel CF è questa:
ingress:
- hostname: dc.example.com
service: http://dc:80 # dc è il nome del mio container dell'app standalone Discourse
Il fatto è che posso visitare http://dc.example.com e non viene reindirizzato a https. È il comportamento previsto?
Puoi riprodurlo? Mi chiedo se sia un bug.
Le mie impostazioni CF pertinenti sono:
So che posso far sì che CF gestisca il reindirizzamento (sia con Always Use HTTPS che con una regola di reindirizzamento bulk), ma avrei pensato che Discourse lo gestisse e reindirizzasse tutti gli URI interni se force_https fosse attivo. Che ne pensi?
Ignorando il problema del reindirizzamento, la navigazione https://dc.example.com funziona bene indipendentemente dal valore di DISCOURSE_FORCE_HTTPS o SiteSetting.force_https.
Modifica: nonostante non capisca cosa faccia effettivamente force_https per noi (forse non fa nulla se i template SSL non sono inclusi?), mi è appena venuto in mente che la configurazione del tunnel probabilmente non funzionerebbe così com’è se Discourse reindirizzasse effettivamente tutto in https. Se lo facesse, argotunnel non potrebbe raggiungere Discourse con http (come service: http://dc:80), quindi forse dovrei:
service: https://dc:443)Comunque, forse la tua guida su argotunnel potrebbe essere aggiornata per tenere conto di questo?
Hai ragione. Non avevo notato che il mio TLD di test .dev è solo HTTPS:
Ho aggiornato la guida dicendo alle persone di usare una regola di pagina per questo, grazie per la segnalazione!
ma ho una domanda..
vedo molte visualizzazioni anonime su Consolidated Pageviewshow, penso che sia a causa di un attacco ddos perché il server cpu è al 60% e il crawler è solo un po’.. ma come proteggersi da un attacco ddos.. grazie in anticipo per la risposta
se si utilizza cloudflare come proxy inverso (una cosa separata da cloudflared/argotunnel), si dovrebbe ottenere una certa protezione ddos pronta all’uso. attivala con la ‘nuvola arancione’ sul tuo record DNS.