멀티사이트 비활성화 후에도 기존 멀티사이트 도메인이 기본 포럼을 계속 제공합니다

[Abdelrahman_MoHamed]

이전에는 약 22개의 서로 다른 포럼으로 구성된 Discourse 멀티사이트 설정을 사용하고 있었습니다. 최근 멀티사이트 구성을 제거하고 기본 사이트만 유지하기로 결정했습니다:

현재 기본 사이트: forum.mamapedia.com
제거된 기존 멀티사이트 도메인: forum.employ.com (그리고 다른 21개)

문제점:

멀티사이트 설정을 비활성화한 후에도 기존 멀티사이트 도메인이 여전히 기본 포럼(forum.mamapedia.com)을 서빙하고 있습니다. 예를 들어:

• **forum.mamapedia.com**을 방문하면 예상대로 작동합니다
• 하지만 **forum.employ.com**을 방문하면 여전히 Mamapedia 포럼이 로드됩니다

forum.employ.com과 같은 기존 도메인은 다음 중 하나가 되어야 한다고 예상했습니다:

1. 에러를 표시해야 합니다 (더 이상 설정되지 않았으므로)
2. 적절히 리다이렉트되거나 완전히 비활성화되어야 합니다

설정 참고 사항:

• Cloudflare의 SSL 인증서를 프록시 옵션이 활성화된 상태로 사용하고 있습니다 (트래픽이 서버로 직접 가지 않음).
• 기존 도메인의 A 레코드를 제거할 수는 있지만, DNS 기반의 우회 조치를 의존하기보다 근본 원인을 파악하고 수정하기를 원합니다.

현재까지 수행한 조치:

1. discourse.conf 및 데이터베이스에서 멀티사이트 설정을 제거했습니다
2. Discourse를 재시작하고 app.yml 설정을 확인했습니다
3. 캐시를 비우고 시크릿 모드에서 테스트했습니다

예상 동작:

• forum.mamapedia.com은 계속 작동해야 합니다
• forum.employ.com 및 기타 기존 도메인은 Mamapedia 포럼을 서빙하지 않아야 합니다

질문:

1. 기본 포럼을 서빙하지 않도록 기존 도메인을 적절히 제거하는 방법은 무엇인가요?
2. Nginx/Traefik 설정, Cloudflare 설정을 조정해야 하는지, 아니면 놓친 Discourse 전용 설정이 있는 건가요?

Nginx Config

[pfaffman (Jay Pfaffman)]

표준 설치로 전환해야 합니다. 멀티사이트 구성을 위해 했던 작업은 서버가 여러 도메인을 제공할 수 있도록 하기 위한 것이었습니다.

새로운 서버를 만들고 백업을 복원하면 기존 서버로 되돌릴 수 있으므로 아무것도 깨지지 않습니다.

유일한 주의점은 재구축 중에는 DNS를 새 서버로 가리켜야 인증서를 발급받을 수 있다는 것입니다. 또한 Cloudflare DNS만 사용하도록 설정하세요.

[Abdelrahman_MoHamed]

pfaffman 님, 안녕하세요. 멀티사이트 구성에서 표준 설치로 전환을 시도했지만, 문제가 여전히 지속되고 있습니다.

수행한 작업:

1. Discourse 설치 제거:

• /var/discourse 디렉터리를 전체적으로 삭제했습니다.

2. Discourse 재설치:

• Discourse 저장소를 다시 클론했습니다.
• 필요한 설정으로 app.yml을 다시 생성했습니다.

3. 앱 재빌드:

• ./launcher rebuild app을 실행했습니다.

4. DNS 업데이트:

• 도메인을 새 서버로 지정했습니다.
• SSL 인증서 발급을 허용하기 위해 Cloudflare를 DNS 전용 모드로 설정했습니다.

SSL 관련 추가 문제:

• app.yml에서 SSL을 활성화하고 Cloudflare 프록시를 비활성화했을 때, SSL을 활성화한 후에도 다음과 같은 문제가 발생했습니다.

질문:

1. 데이터베이스 백업을 복원하지 않은 것이 문제의 원인이 될 수 있을까요?
2. 이전 멀티사이트 구성을 정리하기 위해 추가적인 단계가 필요할까요?
3. 이 구성에서 문제를 일으키지 않고 SSL을 활성화하는 올바른 방법은 무엇인가요?

이전에 이 작업을 수행해 보신 분들의 조언을 부탁드립니다!

[pfaffman (Jay Pfaffman)]

@Abdelrahman_MoHamed

필요한 설정으로 app.yml을 다시 생성했습니다.

discourse setup을 실행했나요, 아니면 수동으로 처리했나요?

ssl 및 let’s encrypt 템플릿이 있나요?

주황색 구름(재빌드)을 여러 번 실행했다면 레이트 리밋에 걸렸을 수 있습니다.

[RGJ (Richard - Communiteq)]

이 문제가 발생하는 이유는 간단합니다. 멀티사이트(Multisite)는 호스트네임(hostname)을 기반으로 포럼을 선택합니다. 비멀티사이트 설치 환경에서는 어떤 호스트네임으로 접속하든 이를 받아들입니다. 따라서 모든 구식 호스트네임을 해당 설치 환경으로 지시하는 한, 남은 사이트가 해당 호스트네임 모두에서 서비스됩니다.

@Abdelrahman_MoHamed

구식 도메인의 A 레코드를 삭제할 수는 있지만, DNS 기반의 우회책에 의존하기보다 근본 원인을 파악하고 수정하는 것이 훨씬 중요합니다.

구식 레코드가 사이트로 가리키고 있는 것 자체가 근본 원인입니다.
구식 구성을 정리하는 것은 우회책이 아니라 해결책입니다.

[pfaffman (Jay Pfaffman)]

와. 사실 관계에서 당신과 의견이 달랐던 마지막 순간이 언제였는지 기억이 나질 않네요. 일반적으로 제가 댓글을 남긴 주제에서 당신의 아바타를 보면 무언가를 배울 수 있을 거라는 걸 압니다!

@RGJ

이 일이 일어나는 이유는 간단합니다. 멀티사이트(Multisite)는 호스트네임에 기반하여 포럼을 선택합니다.

맞습니다. 하지만 그들은 표준 설치(standard install)로 전환했다고 주장합니다. 저는 그 말을 믿지 않습니다.

@RGJ

비멀티사이트 설치 환경은 어떤 호스트네임으로 접속하든 이를 받아들입니다.

수년 전부터(하지만 Let’s Encrypt가 사용 가능해졌을 때부터라고 생각합니다) 표준 설치 환경에서 다른 호스트네임을 통해 접속하면 리다이렉트가 발생합니다(이것은 IP 주소를 사용하여 쉽게 확인할 수 있으며, 방금 /etc/hosts에 forum.bigmouth.bass를 표준 설치 환경으로 설정하여 테스트해 보니 예상대로 리다이렉트되었습니다). 대부분의 브라우저가 기본적으로 그렇게 하듯 https를 통해 접속하면 인증서 오류가 발생합니다.

만약 다른 호스트네임으로 사이트를 접근하는 데 DNS만 필요했다면, 누구나 당신의 사이트로 가리키는 DNS 레코드를 생성하여 사이트를 하이재킹할 수 있을 것입니다.

제가 생각하기에 이것이 핵심인 것 같습니다:

templates/web.ssl.template.yml

제 추측으로는 app.yml에 여전히 다음과 같은 내용이 있을 것입니다:

@pfaffman

   # 모든 호스트를 메인 도메인 이름으로 리다이렉트하지 않음
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /if \(\$http_host[^\}]*\}/m
        to: ""
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /return 301.*$/
        to: "return 301 https://$host$request_uri;"

[RGJ (Richard - Communiteq)]

@pfaffman

무언가를 배울 수 있을 것 같아요!

아, 제 정보를 더 자주 업데이트해야 한다는 걸 이제야 알았네요! 그 코드는 2014년부터 있었던 거라, 정말 오래된 정보를 갖고 있었던 것 같아요.

정말 맞으세요. 리다이렉트되겠네요.

[Abdelrahman_MoHamed]

@RGJ, @pfaffman 님,

app.yml 파일을 확인해 보았지만, 사용자 정의 리디렉션 설정이나 오버라이드가 없습니다. 그러나 여전히 우리의 인스턴스가 알 수 없는 호스트명을 메인 도메인으로 리디렉션하지 않고 있습니다.

1. Nginx 설정: templates/web.ssl.template.yml의 리디렉션 로직이 실제로 적용되고 있는지 확인하는 방법이 있을까요? 컨테이너 내부에서 생성된 Nginx 설정을 수동으로 확인해야 하나요?

2. Discourse 디버깅: 컨테이너 내에서 Discourse가 호스트명을 올바르게 처리하고 있는지 확인하기 위해 실행할 수 있는 로그나 명령어가 있을까요?

3. 기타 잠재적 원인: app.yml이 문제없다면, 예상되는 리디렉션 동작을 방해할 수 있는 다른 요인은 무엇일까요? Cloudflare나 다른 설정이 간섭하고 있을까요?

이 문제를 더 깊이 파고들 수 있는 조언을 주시면 감사하겠습니다!

[RGJ (Richard - Communiteq)]

@RGJ

오래된 설정을 정리하는 것은 우회책이 아니라 해결책입니다.

여기 몇 가지 힌트를 드리겠습니다.

[pfaffman (Jay Pfaffman)]

기존 도메인 모두에 오렌지 클라우드가 활성화되어 있나요? 오렌지 클라우드를 해제하면 문제가 해결되나요? 그렇다면, 처음부터 예상했던 대로 리처드의 말이 맞고 설정을 정리해야 합니다.

하지만 클라우드플레어 사용 시 악의적인 행위자(이 경우 당신)가 다른 사람의 사이트를 해당 도메인에 서빙할 수 있다면, 이는 문제가 됩니다.

[Abdelrahman_MoHamed]

Discourse를 다운로드한 후

./discourse-setup

을 실행해야 하나요, 아니면 다운로드 후 기존 app.yml을 붙여넣고 나서

./launcher rebuild app

을 실행해야 하나요?
어떤 경로를 선택해야 하나요?

[Abdelrahman_MoHamed]

이미 오래된 도메인들은 제거했지만, 맞아요, 그쪽에서는 주황색 버튼이 활성화되어 있었습니다. 문제는 이제 누군가가 저희 서버 IP를 확보하고, 프록시 옵션을 활성화한 레코드를 등록하면, 그쪽 도메인으로 저희 사이트를 서빙하게 된다는 점입니다.

[pfaffman (Jay Pfaffman)]

정말 표준 설치인지 확인하려면 discourse-setup을 실행해야 합니다. 이전 app.yml을 붙여넣으면, 거기에 속하지 않는 것이 있을 수 있습니다. 여전히 표준 설정을 가지고 있는지 확신이 서지 않습니다.

@Abdelrahman_MoHamed

현재 문제는 누군가가 우리 서버 IP를 얻고, 프록시 옵션을 활성화한 레코드가 있으면 그들의 도메인으로 우리 사이트를 서빙하게 된다는 것입니다.

그렇다고 확신하지는 않지만, 만약 그렇다면 여러분이 할 수 있는 일은 없습니다.

[Jagster (Jakke Flemming)]

@Abdelrahman_MoHamed

누군가 우리 서버 IP를 알게 된 경우

전 세계 서버 IP의 대부분은 공개되어 있습니다. IP 시스템의 본래 취지이기도 합니다.

[Abdelrahman_MoHamed]

정말 고맙습니다 @pfaffman @RGJ. 이제 깔끔해졌고 거의 완벽해졌네요.

현재 겪고 있는 문제는 모든 브랜드 이미지와 일부 사용자의 이미지가 사라졌다는 것입니다.

브랜드 데이터는 문제없어 보이며 구 서버에서 다운로드할 수 있지만, 사용자 이미지와 사이트의 모든 이미지도 사라진 상태입니다.

새 서버

구 서버

메모:

• 같은 도메인으로 discourse remap을 실행하고 rake posts:rebake를 수행하여 마이그레이션 단계를 따랐습니다.
• 멀티사이트(multisite) 이력과 관련이 있어서 이 링크에 따라 특정 remap이 필요한 것일까요?
  Serve Discourse from a subfolder (path prefix) instead of a subdomain - #101 by jtraulle ?

[pfaffman (Jay Pfaffman)]

이 사이트가 멀티사이트의 메인 사이트가 아니라면, 업로드 경로는 기본값이 아니라 사이트 이름과 사이트 식별자로 구성됩니다.

[Jacob_Peebles]

누락된 이미지들을 살펴보니 '중첩’된 URL을 사용하는 것 같습니다. 아래는 그 중 하나입니다:

(https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png)

@pfaffman 님, 실제로 이 사이트는 멀티사이트 설정의 메인 사이트였습니다.

CC: @Abdelrahman_MoHamed

[pfaffman (Jay Pfaffman)]

@Jacob_Peebles

/user_avatar/forum.mamapedia.com/

음. 만약 메인 사이트였다면 그 경로는 https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png일 것으로 예상했지만, 그것도 작동하지 않습니다.

아직 구형 사이트를 가지고 있다면, 이 사이트의 백업을 받아 새 사이트에 복구해 보겠습니다.

[Abdelrahman_MoHamed]

@pfaffman 님, 감사합니다. 지금까지 제가 진행한 작업은 정상적으로 작동하는 것 같습니다.

기존 서버에 접속하여 데이터를 /var/discourse/shared/standalone/uploads/default 경로에서 새 서버의 동일한 경로로 이동시켰더니, 모든 사용자 아바타와 게시글이 정상적으로 복구되었습니다.

현재의 새로운 문제는 사이트 브랜딩이 작동하지 않는다는 것입니다. 업데이트를 시도해 봐도 마찬가지입니다.

1분짜리 화면 녹화 영상입니다.
https://www.veed.io/view/89c9e122-57bd-40b3-a5c5-d510a56973e4?panel=share

[Jacob_Peebles]

여기 다시 돌아와서 혹시 아이디어가 있는 분이 있는지 확인하려고 합니다. 우리 쪽에서는 거의 마무리 단계에 와 있으며, ‘로고 없음’ 저장 문제의 트러블슈팅에 대한 도움만 필요합니다. 해결에 도움이 될 만한 아이디어가 있으시면 미리 감사드립니다!