Estoy haciendo esto para configurar Discourse: ./discourse-setup, pero estoy obteniendo el error en la imagen.
¿Cómo puedo solucionar este error? Uso Ubuntu 18.04
Hay un carácter no imprimible en el nombre de host que escribiste:
Inténtalo de nuevo, pero asegúrate de escribirlo correctamente. Si estás copiando y pegando, verifica que el origen esté limpio.
Parece que ya tienes WordPress en ejecución en esa IP.
Sí, WordPress está instalado. ¿No puedo usar ambos en el mismo servidor?
Es posible, pero no es fácil. Además, no puedes usar discourse-setup. Te recomiendo que primero lo pruebes en un servidor que no esté ejecutando otra cosa.
Ejecutar otros sitios web en la misma máquina que Discourse.
Seguí estos pasos pero no obtuve resultados. Mientras tanto, uso WEBMIN.
¿Alguien tiene más ideas?
Si las instrucciones del tema que enlacé anteriormente no te funcionan, lo más sencillo es ejecutar Discourse en su propio servidor.
Será muy difícil hacerlo funcionar con Webmin.
Sé que será difícil, pero no me veo como un aficionado. Probé las instrucciones que vinculaste. ¿Hay algún otro enlace que deba leer?
Hay algunos temas howto sobre el problema.
Hola @Murto
Por si sirve de algo, encuentro que Discourse, como aplicación backend de Rails, es mucho más fácil de configurar si se configura Rails para usar un socket de dominio Unix en lugar de un puerto TCP/IP; y se configura la aplicación de Discourse detrás de un proxy inverso.
De esta manera, los puertos TCP/IP quedan expuestos únicamente a través del proxy inverso, y la aplicación de Discourse (y el contenedor) queda expuesta a través de un socket de dominio Unix; así puedes ejecutar tantas instancias de contenedores de Discourse como desees sin preocuparte por conflictos de sockets TCP/IP. En mi opinión, esta es una forma muy limpia de ejecutar Discourse.
Hay muchos HOWTO y tutoriales en este sitio para guiarte en la configuración, si te atascas y quieres cambiar un poco de dirección. Hay una plantilla “socket” en la distribución de Discourse que puedes usar para configurar la “parte de Discourse de la configuración”; y luego solo configuras el proxy inverso (hay innumerables tutoriales sobre cómo hacerlo) y ¡listo!
Espero que te ayude.
Aún no he podido solucionar el problema. ¿Hay alguien que pueda explicarlo con más detalle? 
Prueba lo siguiente:
netstat -lnptu | grep :443
y luego:
kill -9 PID (reemplaza PID con el número de salida del comando anterior)
Te recomiendo configurar un proxy inverso en tu servidor expuesto a internet y hacer que redirija a WordPress o a Discourse según el host.
Por ejemplo, ejecuta un servicio de nginx usando los puertos 80 y 443 en el host y configura que proxye las solicitudes de blog.tudominio al servicio de WordPress (ya sea a un puerto interno de tu host, si usas Apache + WordPress, en cuyo caso podrías redirigir al puerto de Apache, como 8080, o mediante FastCGI).
Luego, en el mismo servidor, puedes ejecutar Discourse, asegurándote de cambiar los puertos en app.yml por puertos no utilizados en el host, como 8081, o usar un socket Unix como mencionó @neounix. Después, proxyea las solicitudes de foro.tudominio a ese puerto o al socket. Para ejecutar Discourse, deberás ejecutar ./launch rebuild app en el directorio de Discourse (que debería ser /var/discourse).
En este caso, no ejecutarías discourse-setup para crear un archivo de intercambio (swapfile) de 2 GB (principalmente usado para actualizaciones que pueden requerir más memoria, aunque quizás no lo necesites si tu servidor tiene mucha memoria) ni para crear el archivo app.yml. En su lugar, deberías hacerlo tú mismo. Si no sabes qué poner en el archivo app.yml, te recomiendo ejecutar la instalación recomendada en un servidor separado, aunque sea solo para familiarizarte más con Discourse y ver el app.yml generado, que podrías usar en tu servidor compartido (recordando cambiar los puertos o eliminarlos si usas el enfoque del socket).
Te aconsejo seguir uno de los temas howto al respecto si no puedes avanzar.
¿Puedes explicar cómo realizar el proceso de proxy inverso? Aprendí qué hacer, pero no sé cómo hacerlo.
No tengo un ejemplo a mano porque no uso un proxy frontal, aunque creo que lo implementé hace algún tiempo. En cualquier caso, no hay ningún secreto; debería funcionar como con otros proxies inversos. A continuación, solo un resumen de lo que se debe hacer usando puertos (y no sockets):
-
Asegúrate de tener un servicio de WordPress ejecutándose en un puerto que no sea 80 ni 443 (por ejemplo, 8443) y que funcione. Puedes intentar exponerlo primero a internet para verificar que funciona.
-
Haz lo mismo con Discourse, mapeándolo a puertos diferentes.
Cambio:
expose:
- "80:80" # http
- "443:443" # https
A (por ejemplo):
expose:
- "8081:80" # http
- "8444:443" # https
En tu archivo app.yml (si no lo tienes, te recomiendo ejecutar Discourse en una máquina independiente siguiendo la guía oficial solo para ver cómo funciona, y revisar el archivo app.yml generado en /var/discourse/containers/). Aquí hay un ejemplo del archivo app.yml: discourse_docker/samples/standalone.yml at master · discourse/discourse_docker · GitHub
- Instala nginx y, en su archivo de configuración, añade las directivas de proxy. Deberían ser similares al siguiente fragmento de ejemplo:
upstream blog {
server localhost:8080;
}
server {
server_name blog.barinaklar.com;
server_tokens off;
listen 80;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
return 301 https://blog.barinaklar.com$request_uri;
}
}
server {
server_name blog.barinaklar.com;
server_tokens off;
listen 443 ssl;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
proxy_pass http://blog;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
upstream forum {
server localhost:8081;
}
server {
server_name forum.barinaklar.com;
server_tokens off;
listen 80;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
return 301 https://forum.barinaklar.com$request_uri;
}
}
server {
server_name forum.barinaklar.com;
server_tokens off;
listen 443 ssl;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
proxy_pass http://forum;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Esto asume que WordPress se ejecuta en el puerto 8080 y Discourse en el puerto 8081. Asegúrate de configurar un firewall para bloquear el acceso a estos puertos (los proveedores de servicios en la nube suelen bloquear todos los puertos por defecto, excepto el 22, así que quizás no sea necesario).
En este caso, deberás encargarte de generar los certificados SSL/TLS (puedes hacerlo con certbot ejecutándose periódicamente en una tarea cron, por lo que ya he incluido las rutas /.well-known/acme-challenge/ en la configuración de nginx).
Como mencioné antes, esto es solo un resumen y podría haber algo que se me haya pasado. Debes prestar especial atención a la URL base debido al cambio de puertos (para evitar que intente redirigir al usuario a https://tudominio:8081 en lugar de https://tudominio, y realizar los ajustes necesarios si es preciso).
Esto podría no ser necesario si WordPress se ejecuta en un contenedor con el puerto 80 o 443 dentro del contenedor. Con Discourse también debería funcionar correctamente. El problema que podría surgir está relacionado con https, ya que podría redirigir a http porque está usando el puerto http en el proxy, por lo que deberás verificar si ocurre y solucionarlo en ese caso.
Gracias por tu ayuda. Lo aplicaré e informaré sobre las transacciones.