Estou fazendo isso para configurar o Discourse: ./discourse-setup, mas estou recebendo o erro na imagem.
Como posso corrigir esse erro? Uso Ubuntu 18.04
Há um caractere não imprimível no nome de host que você digitou:
Tente novamente, mas certifique-se de digitar corretamente. Se estiver copiando e colando, verifique se a origem está limpa.
Parece que você já tem o WordPress rodando nesse IP.
Sim, o WordPress está instalado. Não posso usar ambos no mesmo servidor?
É possível, mas não é fácil. E você não pode usar discourse-setup. Recomendo que você tente primeiro em um servidor que não esteja executando nada mais.
Segui esses passos, mas não obtive resultados. Enquanto isso, estou usando o WEBMIN.
Alguém tem mais alguma ideia?
Se as instruções no tópico que linkei anteriormente não funcionarem para você, a coisa mais fácil é rodar o Discourse em seu próprio servidor.
Será muito difícil fazê-lo funcionar com o Webmin.
Sei que será difícil, mas não me vejo como um amador. Tentei seguir as instruções que você linkou. Há mais algum link que eu deva ler?
Existem alguns tópicos howto sobre o problema.
Olá @Murto
Apenas para contribuir, acho que configurar o Discourse como um aplicativo Rails no back-end é muito mais fácil se você configurar o Rails para usar um socket de domínio Unix em vez de uma porta TCP/IP; e colocar o aplicativo Discourse atrás de um proxy reverso.
Dessa forma, as portas TCP/IP ficam expostas apenas pelo proxy reverso, enquanto o aplicativo Discourse (e o contêiner) é exposto por meio de um socket de domínio Unix. Assim, você pode executar quantas instâncias de contêiner do Discourse quiser, sem se preocupar com conflitos de sockets TCP/IP. Na minha opinião, essa é uma maneira muito limpa de rodar o Discourse.
Há diversos HOWTOs e tutoriais neste site para guiá-lo na configuração, caso você fique travado e queira mudar um pouco de direção. Existe um modelo “socket” na distribuição do Discourse que você pode usar para configurar a “parte do Discourse da configuração”; e depois basta configurar o proxy reverso (há inúmeros tutoriais sobre como fazer isso) e “você está pronto!”.
Espero que ajude.
Ainda não consegui resolver o problema. Tem alguém que possa explicar em detalhes? 
Tente o seguinte:
netstat -lnptu | grep :443
e depois:
kill -9 PID (substitua PID pelo número de saída do comando acima)
Recomendo configurar um proxy reverso no seu servidor exposto à internet e fazer com que ele redirecione para o WordPress ou o Discourse, dependendo do host.
Por exemplo, execute um serviço nginx usando as portas 80 e 443 no host, e configure-o para fazer proxy das requisições para blog.seudominio ao serviço do WordPress (seja uma porta interna no seu host, caso você esteja usando Apache + WordPress, situação em que você pode redirecionar para a porta do Apache, como 8080, ou usando FastCGI).
Em seguida, no mesmo servidor, você pode executar o Discourse, garantindo que as portas em app.yml sejam substituídas por portas não utilizadas no host, como 8081, ou usar um socket Unix, como sugerido por @neounix. Depois, faça o proxy das requisições para forum.seudominio para essa porta ou para o socket. Para executar o Discourse, você precisará executar ./launcher rebuild app no diretório do Discourse (que deve ser /var/discourse).
Neste caso, você não executaria o discourse-setup para criar um arquivo de swap de 2 GB (principalmente usado para atualizações, que podem exigir mais memória, embora você possa não precisar disso se seu servidor tiver muita memória) nem para criar o arquivo app.yml. Em vez disso, você deve fazer isso manualmente. Se você não souber o que colocar no arquivo app.yml, recomendo executar a instalação recomendada em um servidor separado, mesmo que apenas para se familiarizar melhor com o Discourse e ver o app.yml gerado, que você poderá usar no seu servidor compartilhado (lembrando de alterar as portas ou removê-las se usar a abordagem de socket).
Recomendo seguir um dos tópicos howto sobre o assunto, caso não consiga prosseguir.
Você pode explicar como fazer o processo de proxy reverso? Eu aprendi o que fazer, mas não sei como.
Não tenho um exemplo comigo porque não uso um proxy na frente, embora eu ache que tenha implementado isso algum tempo atrás. De qualquer forma, não há segredo; deve ser feito como você faz com outros proxies reversos. O seguinte é apenas uma visão geral do que deve ser feito usando portas (e não sockets):
-
Certifique-se de ter um serviço do WordPress rodando em uma porta que não seja 80 e 443 (exemplo: 8443) e funcionando. Você pode tentar expô-lo à internet primeiro para verificar se está funcionando.
-
Faça o mesmo com o Discourse, mapeando para portas diferentes.
Mude:
expose:
- "80:80" # http
- "443:443" # https
Para (por exemplo):
expose:
- "8081:80" # http
- "8444:443" # https
No seu arquivo app.yml (se você não tiver, recomendo executar o Discourse em uma máquina dedicada seguindo o guia oficial apenas para ver como funciona, e dar uma olhada no arquivo app.yml gerado em /var/discourse/containers/). Aqui está um exemplo do arquivo app.yml: discourse_docker/samples/standalone.yml at master · discourse/discourse_docker · GitHub
- Instale o nginx e, em seu arquivo de configuração, adicione as diretivas de proxy. Elas devem ser semelhantes ao trecho de exemplo a seguir:
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;
}
}
Isso assume que você tem o WordPress rodando na porta 8080 e o Discourse na porta 8081. Certifique-se de configurar um firewall para bloquear o acesso a essas portas (provedores de nuvem geralmente bloqueiam todas as portas por padrão, exceto a 22, então pode não ser necessário).
Neste caso, você será responsável por gerar os certificados SSL/TLS (você pode fazer isso com o certbot executado periodicamente em uma tarefa cron, então já incluí os caminhos /.well-known/acme-challenge/ na configuração do nginx).
Como disse acima, isso é apenas uma visão geral e pode haver algo que eu tenha esquecido. Você deve prestar atenção especial à URL base devido à mudança nas portas (para verificar se ele não tenta redirecionar o usuário para https://seudominio:8081 em vez de https://seudominio, e fazer as alterações necessárias para que funcione).
Isso pode não ser necessário se o WordPress estiver rodando em um container com a porta 80 ou 443 dentro do container. Com o Discourse, também deve estar ok. O problema que pode surgir é relacionado ao https, que pode redirecionar para http porque está usando a porta http no proxy, então você pode precisar verificar se isso acontece e corrigi-lo nesse caso.
Obrigado pela sua ajuda. Vou aplicar e informar as transações.