동의합니다. @falco 님, 다음 주에 런처를 수정하여 이 문제에 대해 경고하거나 이를 차단할 수 있을까요?
저도 동일한 문제를 겪고 있는데, .yml 파일을 정확히 어떤 이름으로 변경해야 하는지 설명해 주실 수 있나요?
yml 파일 이름에 TLD와 서브도메인을 포함해야 하나요? 이 사이트의 경우 meta.discourse.org.yml가 맞나요?
meta_discourse_org.yml으로 이름 변경하세요.
파일 이름에서 .는 확장자 앞에 오도록 하나만 사용해야 합니다.
확인해 주셔서 감사합니다. 파일 이름을 변경하고 다시 빌드했지만, 이미지에서 캡션을 표시하는 라이트박스나 호버 효과가 여전히 보이지 않습니다.
이것은 어떤 로그 파일인가요? 동일한 문제인지 확인해 보고 있습니다.
또한 Force your site to use HTTPS only 옵션을 켜 두었고, 방화벽에서 80 포트를 차단해 두었습니다.
cd /var/discourse
./launcher enter app
tail -f /shared/log/rails/production.log
Discourse 로그에 관한 이 글도 참고하세요.
이 문제가 기존 게시물에서만 발생하고 새로 게시한 이미지는 정상이라면, 다음 명령을 실행하는 것이 도움이 되었습니다.
rake uploads:recover_from_tombstone
rake posts:rebake
아래 링크도 참고하세요.
정말 유용합니다. 감사합니다.
제 환경에서도 can't reach '/uploads/default... 오류가 발생하는 것 같습니다.
로그 파일의 다음 줄은 다음과 같습니다.
Started GET "/posts/950" for 127.0.0.1 at 2020-07-07 08:24:05 +0000
왜 제 환경에서는 새로 이름이 지정된 컨테이너나 컨테이너의 로컬 IP가 아닌 루프백 IP를 통해 요청을 시도하는 것일까요? 혹시 원인이 무엇일까요?
이것은 동시에 다음 조건을 만족하는 비표준 설치 환경에서 발생하는 문제인 것으로 보입니다:
-
./discourse-setup을 사용하지 않고 yml 파일을 수동으로 생성한 경우 -
리버스 프록시를 사용하는 경우
-
해당 리버스 프록시가 도커 컨테이너 이름을 사용하여 마법처럼 구성되었을 경우
이러한 코너 케이스를 해결하기 위해 모든 사용자를 대상으로 현재 결정론적인 컨테이너 이름을 변경하는 것은 권장하지 않습니다. 단, yml 파일 이름에 점을 하나 더 추가하는 것만으로도 같은 문제가 발생할 수 있다면 예외입니다.
실제로는 사용했지만, 두 개의 Discourse 인스턴스를 실행 중이라 나중에 파일 이름을 변경했습니다. 그렇지 않으면 동일한 Docker 인스턴스에서 두 파일 모두 app으로 호출되었을 것입니다.
사용 중인 도메인 이름과 일치하도록 파일 이름을 변경하는 것이 합리적이라고 생각합니다.
작은 커뮤니티에서는 하나의 서버에 여러 사이트를 실행하는 것이 꽤 흔합니다.
이름 문제를 일으킨 것은 리버스 프록시가 아니었습니다. Docker 자체가 컨테이너 이름을 내부 DNS에 자동으로 추가하기 때문이었습니다. 문제는 Docker에서 Discourse 컨테이너 이름이 외부 DNS 이름과 동일한 이름(예: app.yml → meta.discourse.org.yml)이었다는 것입니다.
.yml 파일에 주어진 도메인 이름과 파일 이름이 일치할 경우, 최소한 강력한 경고 메시지를 표시하도록 제안합니다.
여전히 이미지 접근이 불가능하여 크기를 가져올 수 없는 동일한 문제가 발생하고 있습니다.
크기를 가져오기 위해 '/uploads/default/original/1X/9385b0977b09b0f2239c287de980b6fc238d0da0.png’에 접근할 수 없습니다.
이것은 ./discourse-setup를 사용하여 완전히 표준적인 방법으로 설치한 환경에서 발생하고 있습니다.
이 문제를 해결하기 위한 다른 아이디어가 있을까요?
Discourse 앱 내에서 이미지를 다운로드하려고 하면 어떤 일이 발생합니까?
./launcher enter app
wget https://yourdomain.com/uploads/default/original/1X/9385b0977b09b0f2239c287de980b6fc238d0da0.png
이름 해석이 올바른 IP 주소로 지정되고 있습니까?
apt-get update
apt-get install inetutils-ping
ping yourdiscoursedomain.com
또는
apt-get update
apt-get install dnsutils
nslookup yourdiscoursedomain.comMichael, 도움 주셔서 다시 한번 감사합니다. 정말 감사드립니다.
도메인은 성공적으로 ping할 수 있지만, wget가 웹 프록시를 통해 접속을 시도하는 것 같습니다.
이 가이드를 따라 모든 관련 위치에 no-proxy 변수를 추가했습니다.
무엇을 놓치고 있는 걸까요? 서버가 사용 중인 웹 프록시를 사용하지 않도록 컨테이너를 설정하는 방법은 무엇인가요? app.yml에 no proxy를 추가해야 하나요?
app.yml 파일의 no-proxy 매개변수에 도메인을 추가하고 다시 빌드한 결과, 이제 요구된 대로 프록시가 무시됩니다.
하지만 앱 내에서 wget을 실행할 때 여전히 오류가 발생합니다.
WARNING: The certificate of ‘MYDOMAIN.com’ is not trusted.
WARNING: The certificate of ‘MYDOMAIN.com’ doesn’t have a known issuer.
이것은 제 SSL 인증서가 내부 CA에서 발급된 것이기 때문입니다. --no-check-certificate 플래그와 함께 동일한 wget 명령을 실행하면 정상적으로 작동합니다.
인증서를 신뢰할 대상으로 추가하거나, 인증서를 확인하지 않도록 플래그를 추가하는 방법은 무엇일까요?
@Michael_Uray discourse 컨테이너가 SSL 인증서를 신뢰할 수 있도록 루트 CA를 어디에 추가해야 하는지 아시나요?
이 가이드를 따라 진행했지만, 이는 서버 자체에 적용되는 것이지 discourse가 실행되는 컨테이너에는 적용되지 않는 것 같습니다.
리버스 프록시를 사용하지 않는다면 컨테이너 내부로 들어가서 직접 추가해야 하지만, 이렇게 하면 영구적으로 유지되지 않을 것 같습니다. 아마 app.yml 파일에 해당 항목을 추가하거나, 컨테이너 내 CA 경로를 app.yml을 통해 어떻게든 영구적으로 설정해야 할 것입니다.