더 이상 그런 것이 아니라고 생각합니다.
정말 그렇습니다, @jomaxro. 그래서 제가
아, 죄송합니다. 그 변경 사항을 놓쳤네요.
즉, 사용자가 Let’s Encrypt 알림 이메일 주소를 제공하지 않으면 discourse-setup가 도메인이 현재 서버로 해석되는지 확인하지 않고 Let’s Encrypt를 무조건 활성화하게 됩니다. 반면 이메일 주소를 제공하면 해당 확인을 수행합니다. 이는 좋은 아이디어라고 보기 어렵습니다.
유효한 도메인 이름이 없는 상태에서 왜 HTTPS를 강제해야 합니까? 모든 사용자에게 항상 HTTPS 사용을 강제할 계획이라면, 도메인 이름이 유효한지 테스트한 후 실행을 거부해야 하며, 깨진 설치 상태를 제공하는 것보다는 그러는 것이 낫습니다.
현재 작동 방식대로라면, Let’s Encrypt 이메일 주소를 제공하지 않고 도메인이 서버로 해석되지 않는 경우 discourse-setup은 성공한 것처럼 보이지만, nginx가 인증서를 찾을 수 없어 연결을 수락하지 않는 웹 서버를 시작하게 됩니다. Let’s Encrypt 이메일 주소를 묻지 않고 (첫 번째?) 개발자 이메일을 Let’s Encrypt에 사용하되 DNS 테스트는 그대로 수행하는 것이 더 나은 방법이라고 생각합니다. 다만, 이는 이 주제와 무관한 내용입니다.
아니요, Let’s Encrypt는 그렇게 작동하지 않습니다. 이메일은 도메인 검증과 전혀 관련이 없습니다. 이메일은 인증서가 만료될 예정이지만 갱신할 수 없는 경우 사용자에게 알림을 보내는 데 사용됩니다. 검증은 항상 DNS를 통해 수행됩니다.
Let’s Encrypt는 검증 요건을 충족하지 않는 주소에 대해 인증서를 발급할 수 없습니다. 그렇게 된다면 Let’s Encrypt 전체 체계가 하루아침에 붕괴될 것입니다.
아니요. discourse-setup가 작동하는 방식입니다. 예전에는 인증서 발급이 실패할 가능성이 매우 높다고 판단될 때 사용자가 인증서를 요청하는 것을 막아주었습니다. 하지만 이제는 실패할 수밖에 없는 상황에서도 계속 진행하여 인증서를 요청하고, 사용자가 실패했음을 알릴 수 있는 방법이 없기 때문에 아무런 경고 없이 조용히 실패합니다.
다시 말하지만, 왜 실패할까요? 도메인 인증에 이메일은 필수 요건이 아닙니다.
실패 시에도 이메일이 생성된 적이 없습니다.
이메일은 Let’s Encrypt가 갱신에 실패하여 인증서가 만료될 예정일 때 나중에 사용자에게 알려주기 위해 존재합니다. 인증서가 문제없이 갱신되면 사용자는 이메일을 전혀 보지 못합니다.
그 변경 사항의 의도가 그런 것이 아니라고 생각합니다. 의도는 이메일이 제공되었든 아니든 SSL을 활성화하는 것이었습니다. 도메인 해석은 여전히 확인해야 합니다. @Falco 참고 부탁드립니다.
도메인 이름이 호스트로 해석되지 않으면 실패합니다. 이메일 주소는 중요하지 않지만, 이메일 주소가 지정된 경우 Discourse 설정은 해당 주소가 해석되지 않으면 사용자에게 경고합니다.
도메인 이름 해석은 @falco를 반드시 통과해야 합니다. 그렇지 않으면 설정을 중단해야 합니다. 이는 잘못된 변경 사항입니다.
그래서 브랜치에서 몇 가지 변경 사항을 적용했습니다. 작동 방식은 다음과 같습니다:
잘못된 호스트명을 사용한 경우:
root@droplet:/var/discourse# ./discourse-setup
Hostname for your Discourse?: bad-domain.com
Checking your domain name . . .
WARNING:: This server does not appear to be accessible at bad-domain.com:443.
A connection to http://bad-domain.com (port 80) also fails.
This suggests that bad-domain.com resolves to the wrong IP address
or that traffic is not being routed to your server.
Google: "open ports YOUR CLOUD SERVICE" for information for resolving this problem.
If you want to proceed anyway, you will need to run cp samples/standalone.yml containers/app.yml
and edit the containers/app.yml file manually.
올바른 호스트명을 사용한 경우:
root@droplet:/var/discourse# ./discourse-setup
Hostname for your Discourse?: good-domain.com
Checking your domain name . . .
Connection to good-domain.com succeeded.
Email address for admin account(s)? :
변경 사항은 다음 링크에서 대기 중입니다:
@pfaffman @codinghorror 괜찮아 보이나요?
이 변경 사항이 왜 필요했는지에 대한 코멘트
먼저, 이렇게 된 지 거의 3개월이 지났는데 불만이 많지 않다는 점이 놀랍습니다. 또한 이 문제를 제게 알린 주제조차도 이 변경 사항 때문에 어려움을 겪고 있지 않았으므로, 제가 생각하는 것보다 중요도가 훨씬 낮을 수도 있겠다는 생각이 듭니다.
제가 정말로 이해하지 못하는 첫 번째 점은, 여러분이 정말로 discourse-setup을 사용하여 http-only 사이트를 설정하는 것을 불가능하게 만들고 싶은 건지 하는 것입니다. 메일 동작을 위해 이미 DNS 관련 설정을 많이 했을 테니, A 레코드를 직접 생성하는 것도 큰 문제가 아닐 수 있겠습니다.
변경 사항에 대한 피드백
제가 놓친 변경 사항이 없는 한, 스크립트는 질문을 시작하기 전에 app.yml을 생성합니다. 따라서 "DNS 구성 없이 Discourse를 설치하는 것은 지원되지 않습니다. DNS 구성 없이 계속하려면 app.yml을 필요에 맞게 수정한 후 ./launcher rebuild app을 실행하십시오"라고 표시한 뒤, 부트스트랩 없이 종료하도록 하면 됩니다.
또한, 모든 사용자에게 Let’s Encrypt와 HTTPS 사용을 강제할 계획이라면, standalone.yml과 web_only.yml도 그에 맞게 수정하는 것이 합리적일 것입니다. 그러면 그 복잡한 sed 명령문들을 제거할 수 있을 것입니다.
더 깊은 생각들
'이건 내 문제’라는 측면에서, 제 현재 설치 스크립트는 사람들이 DNS를 설정하기 전에 실행됩니다. 저는 드롭렛을 생성하고, Discourse를 설정한 후, DNS 설정 지침이 포함된 이메일을 보내고, DNS가 설정되기를 기다린 다음, 템플릿을 활성화하고 Let’s Encrypt 주소를 설정하기 위해 app.yml을 수정합니다. 하지만 이것은 단순히 역사적인 이유 때문일 뿐, 대신 드롭렛을 생성하고, Mailgun을 구성하고, DNS를 기다린 후에 설치를 수행하는 것이 더 나을 것입니다. 이렇게 하면 여전히 제 스크립트가 discourse-setup을 사용할 수 있는데, 저는 이것이 여전히 정상 작동하는지 확인하기 위한 정기 테스트로 이를 실행하는 것을 좋아합니다. (여러분은 discourse-setup에 대한 자동화 테스트를 하지 않는 거죠?)
네.
이 변경 사항에 대한 불만을 단 한 건도 받지 못했고, 이 기능이 적용된 이후로 HTTP 전용 Discourse 인스턴스가 대량으로 생성되는 일이 없었습니다. 왜냐하면 여러분이 어떤 것이 **선택 사항(OPTIONAL)**이라고 하면 사람들은 아무런 고려 없이 그냥 건너뛰기 때문입니다. 제 생각에는 Discourse에 안전한 기본값을 제공하는 이 변경 사항은 30분 가이드에서 우리가 추구하는 바를 모두 충족하는 훌륭한 변화입니다.
아, 그 방법이 더 좋습니다. 필요한 설명이 더 적으니까요!
아, 이제 이 변경 사항이 여러분의 설정을 깨뜨렸기 때문에 왜 그렇게 격렬하게 반응하셨는지 이해합니다. 죄송합니다.
자동화 작업에는 대화형 스크립트를 대상으로 하기보다는 직접 yml 파일을 사용하는 것을 강력히 권장합니다.
요약: 네, 제가 추천한 작은 언어적 수정 사항이 반영되었으니, 저로서는 괜찮아 보입니다.
동의합니다. 불만이 제로라니! 성공적인 결과인 것 같습니다.
아니요! 그렇지 않았습니다. (!) 제 2단계 설치 과정인 https를 활성화하기 전까지는 사이트가 뜨지 않는다는 것을 겨우 알아차린 정도였습니다. 그리고 제 설정 문제는 당신의 책임이 아닙니다. (아, 이제 제 스크립트가 깨지겠지만, DNS 설정 전에 설치를 진행하는 것보다는 아무튼 더 나을 겁니다. 저는 최소 1년 이상 https가 아닌 설치를 해본 적이 없습니다.)
제 스크립트가 discourse-setup을 사용하도록 한 이유는, 설치 고객들이 표준 설치(Standard Install)를 받고 있는지 확실하게 보장하기 위해서입니다. 그리고 누군가가 "설치를 했는데 작동하지 않는다"고 할 때, 제 스크립트를 실행하여 그들이 해야 했어야 하는 작업을 그대로 수행한 후 "자, 방금 설치를 해봤는데 작동하네요"라고 말할 수 있기 위해서였습니다. 하지만 지난 3년 동안 문제를 발견한 적이 한 번도 없었던 것 같으니, 아마 제 "테스트"가 누구에게도 도움이 되지 않는 것이겠죠.
좋아요, 분석과 리뷰 감사합니다!
PR을 병합했으니 이제 항상 DNS를 검증하게 됩니다.