Hola,
Acabo de instalar Discourse y Cloudflared en mi R-Pi 4, y seguí las instrucciones de la publicación original, pero no estoy seguro de qué poner como host para Discourse, ¿debería poner solo localhost ya que el túnel cloudflared lo reenviará?
¿Quizás @Falco podría ayudar?
Por cierto, perdón por revivir el tema.
Aún necesitas tener un dominio para esta guía, por lo que el valor del host será el ápice del dominio o el subdominio que configuraste para Discourse y para el túnel.
Entonces, ¿el valor del host debería ser el subdominio en el que quiero que esté Discourse?
Sí, debería ser la URL donde quieres que esté Discourse.
¿Estás seguro?
Si hago eso, me da este error:
Establecí el nombre de host de Discourse en el subdominio exacto donde quiero que esté Discourse.
Instalé Cloudflared en R-Pi4 desde la CLI (como se indica aquí: Set up your first tunnel · Cloudflare One docs) y lo estoy ejecutando como un servicio.
Y estoy seguro de que instalé Discourse como se menciona en tu publicación original.
¿Puedes compartir el dominio?
¿Puedo enviártelo por mensaje directo? Realmente no quiero que lo vean personas al azar.
¿Está funcionando ahora que has puesto el dominio correcto?
¡Sí! ¡Acabo de iniciarlo! ¡Gracias por tu ayuda! Solo tengo un problema con MailJet (el proveedor de correo que uso para STMP), que se está divirtiendo pre-bloqueando mis correos electrónicos de verificación.
Se dividió una publicación en un nuevo tema: ¿Alguna alternativa a MailJet?
Una publicación se fusionó en un tema existente: ¿Alguna alternativa a MailJet?
¡Hola! Logré tener una instalación funcional. Solo tengo una pequeña pregunta: ¿cuánta actividad/miembros crees que puede manejar una Raspberry Pi 4 Modelo B con 4 GB de RAM?
Esa es una gran pregunta. Dado que es difícil establecer una correlación directa entre el número de usuarios y la carga del servidor en un sistema complejo como Discourse, es justo reconocer que el principal cuello de botella en un sistema RaspberryPi son las IOPS de almacenamiento.
Por lo tanto, siempre que la mayoría de tus recursos necesarios estén en la RAM, entre los procesos RSS y el caché de Linux, deberías tener una experiencia fluida. El hecho de que Cloudflare actúe como una CDN de caché también ayudará bastante, e incluso puedes alargar la vida útil de la configuración de Pi utilizando Usar almacenamiento de objetos para cargas (S3 y clones) después de un tiempo.
He recibido este error en partes de Docker
FAILED
--------------------
Pups::ExecError: /usr/local/bin/ruby -e 'if ENV["DISCOURSE_HOSTNAME"] == "discourse.example.com"; puts "Aborting! Domain is not configured!"; exit 1; end' falló con el retorno #<Process::Status: pid 115 exit 1>
Ubicación del fallo: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec falló con los parámetros "/usr/local/bin/ruby -e 'if ENV[\"DISCOURSE_HOSTNAME\"] == \"discourse.example.com\"; puts \"Aborting! Domain is not configured!\"; exit 1; end'"
bootstrap falló con el código de salida 1
** FALLÓ EL ARRANQUE ** por favor desplácese hacia arriba y busque mensajes de error anteriores, puede haber más de uno.
./discourse-doctor puede ayudar a diagnosticar el problema.
9ba0db264ae559f3f748cc1e42a8683ea0b4e355b0d45da0f472afea7ff7c472
Eso significa que no configuraste tu dominio correctamente. Necesitas un dominio válido para que esto funcione. Ejecuta ./discourse-setup de nuevo o edita el archivo app.yml para solucionarlo.
gracias por responder
lo desplegué con éxito en RockPi4 
Hola @Falco,
Estoy bastante seguro de que lo configuré tal como tu guía, pero estoy notando algo extraño.
En la configuración del contenedor, no estoy cargando las plantillas SSL y tengo la variable de entorno DISCOURSE_FORCE_HTTPS establecida en true. No estoy seguro de lo que hace eso, pero supongo que establece SiteSetting.force_https en true y luego lo oculta en el panel de administración para evitar que se desactive.
Mi configuración de túnel de CF es así:
ingress:
- hostname: dc.example.com
service: http://dc:80 # dc es el nombre de mi contenedor de aplicación independiente de Discourse
El caso es que puedo visitar http://dc.example.com y no se redirige a https. ¿Es ese el comportamiento esperado?
¿Puedes reproducir esto? Me pregunto si es un error.
Mis configuraciones relevantes de CF son:
Sé que puedo hacer que CF se encargue de la redirección (ya sea con Always Use HTTPS o una regla de redirección masiva), pero habría asumido que Discourse se encargaría de eso y redirigiría todas las URIs internas si force_https está activado. ¿Opiniones?
Ignorando el problema de la redirección, navegar por https://dc.example.com funciona bien independientemente del valor de DISCOURSE_FORCE_HTTPS o SiteSetting.force_https.
edición: a pesar de no entender lo que force_https está haciendo realmente por nosotros (¿quizás simplemente no hace nada si las plantillas SSL no están incluidas?), se me ocurrió que la configuración del túnel probablemente no funcionaría tal como está si Discourse realmente redirigiera todo a https. Si lo hiciera, argotunnel no podría acceder a Discourse con http (como service: http://dc:80), así que tal vez debería:
service: https://dc:443)De todos modos, ¿quizás tu guía de argotunnel podría actualizarse para tener esto en cuenta?
Tienes razón. No me había dado cuenta de que mi TLD de prueba .dev solo usa HTTPS:
He actualizado la guía indicando a la gente que use una regla de página para esto, ¡gracias por el informe!
pero tengo una pregunta…
veo muchas vistas anónimas en Consolidated Pageviews, creo que se debe a un ataque DDoS porque el servidor de CPU alcanzó el 60% y el rastreador es solo un poco… pero ¿cómo protegerse de un ataque DDoS? Gracias de antemano por la respuesta.
si usas cloudflare como proxy inverso (una cosa separada de cloudflared/argotunnel), deberías obtener algo de protección ddos lista para usar. actívala con la ‘nube naranja’ en tu(s) registro(s) dns.