Nossas imagens de discurso não são exibidas em lightbox

[codinghorror (Jeff Atwood)]

@Michael_Uray

Renomeei o app.yml para domain.name.yml e isso fez com que o Docker alterasse o nome DNS de domain.name para seu endereço IP interno. Renomeei-o para domain_name.yml e tudo está funcionando bem agora.

Concordo, o launcher pode ser modificado para avisar sobre isso ou bloqueá-lo na próxima semana, @falco?

[eherman]

@Michael_Uray

Edição: Descobri que renomeei o app.yml para domain.name.yml, o que fez com que o Docker alterasse o nome DNS de domain.name para seu endereço IP interno. Renomeei-o para domain_name.yml e tudo está funcionando corretamente agora.

Estou com o mesmo problema. Você poderia esclarecer exatamente para qual nome é necessário renomear o arquivo .yml?

É necessário incluir o TLD e o subdomínio como parte do nome do arquivo .yml? Para este site, seria meta.discourse.org.yml?

[Michael_Uray]

@eherman

meta.discourse.org.yml

Renomeie para meta_discourse_org.yml.

[Stephen]

O único . no nome do seu arquivo deve preceder a extensão.

[eherman]

Obrigado por esclarecer. Alterei o nome do arquivo e reconstruí, mas ainda não estou vendo nenhum lightbox ou efeito de hover para mostrar a legenda em nenhuma imagem.

@Michael_Uray

Ele mostra um erro no arquivo de log, indicando que não é possível acessar /uploads/....

Qual é esse arquivo de log? Estou tentando confirmar se se trata do mesmo problema.

Também tenho a opção Forçar seu site a usar apenas HTTPS ativada e a porta 80 bloqueada no firewall.

[Michael_Uray]

@eherman

De qual arquivo de log se trata?

cd /var/discourse
./launcher enter app
tail -f /shared/log/rails/production.log

Veja também este artigo sobre os logs do Discourse.

Where does Discourse store and show logs?

When troubleshooting issues or errors with Discourse it is important you look at your logs. Here’s a listing of where they are and what’s in there. Your site domain Administration logs shown in the UI The Discourse admin panel contains several forms of logging: Emails that are sent, skipped, bounced, received and rejected are logged at https://=DOMAIN=/admin/email-logs and the neighboring tabs. Staff actions are logged at https://=DOMAIN=/admin/logs/staff_action_logs Email addresses an…

Se isso acontecer apenas com as postagens existentes, mas as imagens postadas recentemente estiverem corretas, pode ajudar executar:

rake uploads:recover_from_tombstone
rake posts:rebake

Veja também lá.

Old image uploads become broken images

Lest anyone thinks that this query went unanswered, many thanks to @zogstrip for solving this. It seems that Discourse got confused about whether those uploaded images were being used and moved them for subsequent deletion. Though you will probably never need it, the fix went something like this: # copy the "deleted" images from their to-be-deleted staging area cd /var/discourse ./launcher enter app rake uploads:recover_from_tombstone # rebake to see that it doesn't happen again rake posts:re…

[eherman]

Tudo muito útil, obrigado.

Parece que estou tendo o mesmo problema com o erro não é possível acessar '/uploads/default...

A próxima linha do meu arquivo de log é
Iniciado GET "/posts/950" para 127.0.0.1 em 2020-07-07 08:24:05 +0000

Alguma ideia do por que o meu está tentando através do IP de loopback e não do container recém nomeado ou do IP local do container?

[Falco]

@codinghorror

Concordo, o launcher pode ser modificado para avisar sobre isso ou bloqueá-lo na próxima semana?

Isso parece ser específico de instalações não padrão que simultaneamente:

• Não usaram ./discourse-setup e criaram um arquivo yml manualmente

• Estão usando um proxy reverso

• Esse proxy reverso está magicamente configurado usando o nome de um contêiner Docker

Recomendo não alterar o nome atual e determinístico do contêiner para todos para resolver esse caso extremo, a menos que isso também possa ocorrer simplesmente adicionando um ponto extra ao nome do arquivo yml.

[Michael_Uray]

@Falco

Não usei ./discourse-setup e criei um arquivo yml manualmente

Eu realmente usei, mas renomeei o arquivo depois, pois tenho duas instâncias do Discourse em execução e, caso contrário, ambas seriam chamadas de app na mesma instância do Docker.
Acho razoável renomear o arquivo para corresponder ao domínio utilizado.

@Falco

Está usando um proxy reverso

Provavelmente é bastante comum para comunidades menores executarem vários sites em um único servidor.

@Falco

Este proxy reverso é magicamente configurado usando um nome de contêiner Docker

Não foi o proxy reverso que causou o problema de nome. Foi o próprio Docker, já que ele adiciona automaticamente o nome do contêiner ao seu DNS interno. O problema era que o nome do contêiner do Discourse no Docker era o mesmo que seu nome de DNS externo (por exemplo, app.yml → meta.discourse.org.yml).

Proponho exibir pelo menos um aviso forte se o nome do arquivo corresponder ao nome do domínio fornecido no arquivo .yml.

[eherman]

Ainda estou com o mesmo problema de não conseguir acessar a imagem para obter as dimensões.

Não foi possível acessar ‘/uploads/default/original/1X/9385b0977b09b0f2239c287de980b6fc238d0da0.png’ para obter suas dimensões.

Isso ocorre em uma instalação totalmente padrão usando ./discourse-setup

Alguma outra ideia de como corrigir isso?

[Michael_Uray]

O que acontece se você tentar baixar a imagem dentro do seu aplicativo Discourse?

./launcher enter app

wget https://yourdomain.com/uploads/default/original/1X/9385b0977b09b0f2239c287de980b6fc238d0da0.png

A resolução de nomes aponta para o endereço IP correto?

apt-get update
apt-get install inetutils-ping
ping yourdiscoursedomain.com

ou

apt-get update
apt-get install dnsutils
nslookup yourdiscoursedomain.com

[eherman]

Obrigado novamente pela sua ajuda, Michael, é muito apreciado.

Consegui fazer o ping no domínio com sucesso, mas parece que o wget está tentando passar por um proxy web.

Siga este guia e adicionei a variável no-proxy em todos os locais relevantes.

Estou esquecendo algo? Como configuro o contêiner para não usar o proxy web que o servidor está usando? Preciso adicionar um no-proxy no app.yml?

[eherman]

Adicionei meu domínio ao parâmetro no-proxy no arquivo app.yml e recompilei, e agora o proxy é ignorado conforme necessário.

Ainda estou recebendo erros ao executar um wget dentro do aplicativo:

AVISO: O certificado de ‘MYDOMAIN.com’ não é confiável.
AVISO: O certificado de ‘MYDOMAIN.com’ não possui uma autoridade emissora conhecida.

Isso ocorre porque meu certificado SSL é de uma CA interna. Quando executo o mesmo comando wget com a flag --no-check-certificate, funciona perfeitamente.

Como posso adicionar o certificado para torná-lo confiável ou adicionar a flag para desativar a verificação?

[eherman]

@Michael_Uray você sabe onde preciso adicionar a CA raiz para permitir que o contêiner do Discourse confie no certificado SSL?

Segui este guia, mas acho que ele se aplica ao próprio servidor e não ao contêiner que está executando o Discourse.

[Michael_Uray]

@Michael_Uray

./launcher enter app

Se você não estiver usando um proxy reverso, com certeza terá que entrar no contêiner e adicioná-lo lá, mas acho que dessa forma não será persistente. Acho que você terá que adicioná-lo de alguma forma ao app.yml ou tornar o caminho correspondente do CA dentro do contêiner persistente de alguma maneira via app.yml.