여러분 안녕하세요,
현재 포럼을 관리할 수 없는 상태입니다. 아직 방법을 찾지 못한 새로운 SSL 링크가 필요하기 때문에, 포럼을 잠시 닫을 계획입니다. 사용자분들이 해킹 위험에 노출되는 일은 원치 않습니다.
포럼을 완전히 삭제하지 않고, 일정 기간 동안 모든 사람의 포럼 접근을 차단할 수 있을까요?
이 부분에 대해 도움을 주시면 정말 감사하겠습니다. 감사합니다!
사이트를 읽기 전용 모드로 전환하는 것을 고려해 보셨나요? 이 기능은 관리자 설정의 백업 섹션(your-site-name/admin/backups)에서 찾을 수 있으며, 이 모드를 활성화하면 사이트가 읽기 전용으로 설정되어 사용자가 게시글을 작성할 수 없게 됩니다.
표준 설치인 경우, 재빌드(rebuild)를 수행하면 새로운 SSL 인증서를 발급받을 수 있습니다.
재빌드가 불가능하거나 원치 않는다면, 제안대로 읽기 전용(Read-only) 모드로 설정할 수 있습니다.
또는 ./launcher stop app 명령을 실행하여 컨테이너를 종료할 수도 있습니다.
ondrej님,
답장 주셔서 감사합니다. 해당 내용을 읽어 보았지만, 현재 포럼이 보안이 취약한 상태(링크 앞에 https가 없어 보안 인증서가 없음)라는 문제 때문에 사용자가 포럼에 접속하는 것을 막지는 못합니다.
SSL 설정을 할 시간을 확보한 후에 다시 서버를 시작하려는 것이 목적이라면, 먼저 내장된 SSL 템플릿을 사용해보는 것이 좋습니다. Discourse는 Let’s Encrypt를 SSL에 적용하고 사용하는 것이 매우 쉬우므로, 서버를 중단하기 전에 이를 시도해 보는 것이 좋습니다.
시도해 보려면, app.yml 파일 상단에 있는 아래 코드 중 2번째와 3번째 줄의 #을 제거하세요:
## Uncomment these two lines if you wish to add Lets Encrypt (https)
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"
이어서 같은 파일의 아래쪽에 있는 #LETSENCRYPT_ACCOUNT_EMAIL: me@example.com을 찾아서, 다시 #을 제거하고 예시 이메일 주소를 실제 이메일 주소로 교체하세요.
마지막으로 Discourse를 다시 빌드하면 Let’s Encrypt 인증서를 발급받아 HTTPS를 설정하고, 모든 HTTP 요청을 HTTPS로 리디렉션합니다.
cd /var/discourse
./launcher rebuild app
Discourse를 어떻게 설치하셨나요?
불행히도 저는 Discourse를 설치하는 방법이나 이 시스템이 일반적으로 어떻게 작동하는지 알지 못합니다. 제 아버지는 사업용으로 이 포럼을 설정하셨지만, 올해 돌아가셨습니다. Linode 서버를 하나 보유하고 있으며, Discourse가 해당 서버에 설치되어 있을 가능성이 있습니다.
Simon님, 자세한 설명 감사합니다. 제 아버지가 이 웹사이트를 세우셨는데, 올해 돌아가셨습니다. 저는 Discourse를 설치하고 설정하는 방법에 대해 전혀 알지 못하며, 웹사이트 전반에 대해서도 잘 모르겠습니다. 이 appl.yml 파일을 어디서 찾을 수 있을까요? 아버지가 Discourse를 우리 도메인 서버에 설치하셨을까요? 우리는 Linode를 사용 중인데, 그 안에 "Discourse"라는 이름의 "Linode"가 있습니다. 이것이 무엇을 의미하는지, 그리고 설치를 어떻게 접근해야 하는지 모르겠습니다.
도움 주셔서 감사합니다.
상실의 아픔에 대해 위로의 말씀을 드립니다. 
가장 먼저, 해당 “Discourse” Linode에서 "백업"이 활성화되어 있는지 확인하는 것을 강력히 권장합니다. 이것이 가장 시급한 첫 번째 단계입니다.
두 번째로, https://yoursitedomain.com/admin/backups 에서 Discourse 백업도 활성화되어 있는지 확인하세요.
세 번째로, 웹 브라우저를 통해 관리자 UI 패널에서 직접 업데이트를 실행해 보시는 것이 좋습니다. 이렇게 하면 문제가 해결될 수 있습니다: https://yoursitedomain.com/admin/upgrade
정말 안타깝네요. 그 소식을 듣고 매우 죄송합니다. 해당 서버에 ssh로 접속하는 방법을 모르신다면, 가장 쉬운 방법은 백업을 만든 후 새로 설치하고 백업을 복원하는 것입니다.
서버에 ssh로 접근할 수 있다면, 여기 설명된 커맨드 라인 작업을 수행할 수 있습니다.
이론적으로는 Linode의 SSH 비밀번호를 재설정할 수 있어야 합니다:
https://www.linode.com/docs/guides/accounts-and-passwords/#resetting-the-root-password
그렇게 들리면 꽤 쉬워 보이네요. 이렇게 하면 현재 작동 중인 메일 설정을 그대로 가져올 수 있을 것 같습니다. 하지만 이 시스템이 고장 난 것처럼 들리므로, 저는 여전히 새 설치를 진행할 가능성이 높습니다.
그렇게 생각하지 않습니다. 포함된 샘플 app.yml에 따르면 기본 설정은 web.ssl 또는 web.letsencrypt.ssl 템플릿을 사용하지 않는 것입니다. @Mads가 설명한 HTTP 리디렉션이 없다는 점은 단순히 해당 기본 설정이 유지되고 있다는 의미, 즉 SSL이 처음부터 설정되어 있지 않았다는 것으로 들립니다.
이것은 Discourse를 호스팅하는 서버인 것으로 보입니다. 여전히 이를 종료하고 싶다면 해당 Linode의 전원을 끄면 되지만, 설정 방식에 따라 해당 서버에 다른 것들도 함께 실행 중일 수 있습니다.
@sdpiowa가 말했듯이, 그가 제공한 링크에 설명된 대로 비밀번호를 재설정할 수 있습니다. 페이지를 맨 아래로 스크롤하여 Resetting the Root Password 부분을 확인하세요. 이미 해당 서버의 루트 비밀번호를 알고 있다면 이 작업을 수행할 필요가 없습니다.
루트 비밀번호를 확보한 후, 서버에 접근하는 가장 간단한 방법은 Linode 클라우드 매니저의 LISH 콘솔을 사용하는 것입니다.
https://www.linode.com/docs/guides/using-the-lish-console/
마지막 단계에서 콘솔에 login:이 표시되면 root를 입력하고 엔터를 누른 후, 비밀번호를 입력하고 다시 엔터를 누릅니다. 이 시점에서 셸에 접근할 수 있으며 서버에서 명령을 실행할 수 있습니다. 여기서 실수를 하지 않도록 주의해야 합니다. 대부분의 실수는 단순히 오류가 발생하고 아무 일도 일어나지 않는 수준이지만, 루트 셸에서의 실수는 손상된 결과를 초래할 수 있습니다.
더 이상 진행하기 전에, 수동으로 Discourse 백업을 생성한 후, Linode 클라우드 매니저에서 수동 스냅샷을 찍으세요. 이렇게 하면 문제가 발생했을 때 복구에 필요한 모든 것이 준비되어 있는지 확인할 수 있습니다.
먼저 올바른 위치로 이동하기 위해 디렉토리를 변경하세요:
cd /var/discourse
Linode 이미지는 일반적으로 사용하기 쉬운 텍스트 편집기인 nano가 설치되어 있습니다. app.yml 파일을 편집하세요:
nano containers/app.yml
마우스로 커서를 이동할 수 없으므로 방향키를 사용하여 파일 내에서 이동하고 이전에 설명된 변경 사항을 수행하세요. 완료되면 CTRL+X를 눌러 종료하면 저장할 것인지 묻습니다. Y를 눌러 예라고 답하고 파일 이름을 묻는 메시지가 나오면 그냥 엔터를 누르면 파일이 저장되고 nano에서 나옵니다.
마지막으로, Discourse를 재빌드하고 이 작업을 시작한 후 LISH 창을 닫지 마세요:
./launcher rebuild app
모든 것이 순조롭게 진행된다면, 아마도 10~20분 후에 Discourse가 SSL과 함께 다시 실행될 것입니다.
https가 기본으로 활성화된 지 꽤 오래되었습니다. 운영체제도 이미 수명(EOL)이 종료되었을 가능성이 높습니다.
개인적으로 초보자에게 가장 쉽고 안전한 해결책은 새로 설치하는 것이라고 생각합니다. 하지만 님이 넉넉하게 제공해 주신 설명 덕분에 이 문제를 해결할 수 있을 것 같습니다!
도와주신 여러분, 그리고 자세한 설명 감사드립니다! 이 문제를 도와줄 수 있는 사람을 찾은 것 같고, 여러분의 조언을 꼭 보여드릴 예정입니다. 정말 감사해요 
정말 대단하세요!
제공해 주신 모든 정보에 감사드립니다.
Mads를 도와드리고 있는 Matt입니다. 꽤 경험이 있는 시스템 관리자로 *nix 환경에 익숙합니다. Docker 때문에 조금 더 깊이 파고들었지만 결국 해결했습니다.
Letsencrypt 로그에는 다음과 같이 표시되었습니다:
The CA is processing your order, please just wait. (1/30)
community.fruityknitting.com:Verify error:Fetching https://community.fruityknitting.com/.well-known/acme-challenge/9NEyZhZzZQ9FwGrqGqDNblLiwtOQQGlYr-9nSFUwKhw: Connection refused**
Nginx 설정에서 80 포트가 https로 즉시 리디렉션되도록 되어 있었고, Andrew가 Discourse가 Patreon을 통해 유효한 계정을 확인하도록 설정한 것 같습니다. 이 80 포트 리디렉션과 Patreon 리디렉션 때문에 Letsencrypt가 로컬 파일을 검증하지 못한 것 같습니다.
Nginx의 80 포트 리디렉션을 중지하고 Nginx를 재시작한 후 다음 명령을 다시 실행했습니다:
/shared/letsencrypt/acme.sh --cron --home /shared/letsencrypt
그리고 성공했습니다.
모두의 유용한 조언에 감사드립니다.
좋은 하루 보내세요.
패트레온 리다이렉트가 https가 아니었나요?
로버트가 말한 건, 좀 더 명확히 표현하면 다음과 같습니다:
Nginx가 80 포트에서 443 포트로 무조건 리디렉트하고, 그다음 디스커스 앱이 세션이나 쿠키 같은 것을 위해 바로 페이튼으로 포워딩하는 것 같다는 추측입니다…
이 정도면 Let’s Encrypt 인증이 깨질 수 있습니다.
맞는 설명인가요?
모든 HTTP로 들어오는 통신을 HTTPS로 강제하는 것은 기본적으로 제공하는 기능이라고 생각합니다.
Patreon 관련 부분은 좀 이상해 보이네요?
HTTPS로 100% 처리할 수 있는 것을 왜 그렇게 해야 하는 건가요?
왜 리버스 프록시가 신경 써야 하는 건가요?
로버트, 한번 써보세요…
https://community.fruityknitting.com/