몇 가지 Discourse 인스턴스를 새로운 호스팅으로 이전하는 작업을 준비 중입니다. 계획은 기존 사이트를 읽기 전용으로 설정한 뒤 백업을 받아, 이를 새 호스팅으로 옮긴 후 복원하면서 DNS 설정(짧은 TTL)을 업데이트하는 것입니다. 이 과정은 이곳과 다른 곳의 가이드에서 참고한 것입니다.
DNS 업데이트를 시뮬레이션하기 위해 /etc/hosts 파일 해킹을 사용하고(브라우저에서도 DNS over HTTPS를 비활성화한 상태) 몇 차례 사전 테스트를 해봤습니다. 지금까지는 문제가 없습니다.
하지만 ‘소스’ 사이트에서 브라우저를 닫은 뒤, ‘대상’ 사이트에서 이전이 완전히 끝난 후에만 브라우저를 열도록 주의했음에도 불구하고, 로그인 상태가 기억되지 않습니다.
물론 이전 작업으로 인해 사이트 멤버들이 모두 로그아웃되는 것은 원치 않습니다. 어디를 확인해야 하거나, 제가 놓치고 있는 부분이 있을까요?
현재 테스트 중인 사용자는 관리자 권한을 가지고 있으며 2FA를 사용 중입니다. 또한 Discourse 컨테이너는 SSL을 종료하는 Nginx 뒤에 위치해 있는데, 이것이 문제 해결에 영향을 미칠까요?
회원분들에게 사과하는 것에는 () 전혀 문제가 없지만, 다음과 같은 몇 가지 불리한 부작용을 예상할 수 있어 그런 상황을 정말로 피하고 싶습니다:
회원들이 다시 로그인하지 않고, 향후 포럼에 참여할 가능성이 낮아집니다.
회원들이 비밀번호를 잊고 비밀번호 복구 도움이 필요합니다.
회원들이 비밀번호를 잊고 새 계정을 생성하여, 포럼에 수많은 '좀비 계정’이 남고 사용자 메모나 게시글 이력 등이 없는 중복된 신원들이 혼란을 야기합니다.
SSL 부분은 Discourse 앞단에서 모두 정상적으로 작동합니다(호스트 파일 해킹을 사용하더라도). 생각해 보면, 그렇지 않으면 로드 밸런서에 문제가 생길 것이므로 그럴 수밖에 없습니다. 제 아는데로, 이 설정에서는 SSL이 Nginx에서 종료되므로 Discourse는 SSL에 대해 알지조차 못합니다.
다른 질문은 '모든 사용자를 로그아웃하지 않고 Discourse 서버를 새 IP로 이전할 수 있는가’입니다. 가능하다고 생각했는데, 아마 그 가정은 틀렸을 수도 있습니다…
(1)에서 찾은 값을 사용하여 기존 서버의 app.yml 파일 env: 섹션에 DISCOURSE_SECRET_KEY_BASE를 추가하고 앱을 다시 빌드합니다. 이론적으로 모든 것이 올바르게 진행되면 Discourse는 이제 app.yml의 값을 사용하게 되고 사용자 세션이 유지됩니다. 다음을 실행하여 환경 변수가 사용되고 있는지 확인할 수 있습니다.
GlobalSetting.secret_key_base
새 서버의 app.yml 파일에도 동일한 SECRET_KEY_BASE가 있는지 확인합니다. 백업을 복원하면 사용자 세션이 유지되어야 합니다.
이 플로우를 테스트해 보지 않았으므로, 프로덕션 포럼에 사용할 계획이라면 먼저 반드시 테스트해 보시기 바랍니다!
참고: 여러 Discourse 인스턴스 간에 시크릿 키를 공유해서는 안 됩니다. 시크릿 키를 보유하면 누군가가 사이트에서 자신의 세션 쿠키를 복호화하고 수정할 수 있으며, 이는 매우 심각한 보안 문제를 초래할 수 있습니다.
훌륭합니다 - 샌드박스 인스턴스에서 이걸 직접 시도해 볼게요. 작동하는지 확인해서 다시 보고드리겠습니다
이해했습니다. 이제 백업에서 이 키를 내보낼 수 있는 옵션에 대한 기능 요청을 해야 하는지 고민 중입니다. 제게는 수천 개의 계정이 있는 사이트에서 모든 세션을 잃는 것은 '매우 나쁜 일’로 여겨집니다. 마이그레이션을 연습하면서 이 문제가 드러났지만, 만약 기계나 Docker 인스턴스가 어떤 이유로든 손실되면 키도 함께 손실되어 동일한 세션 손실을 겪게 될 것입니다.
제 생각에는 기본 백업의 보안도 개선되어야 합니다. 비밀번호와 세션이 해시되어 보호될 수 있지만, 개인 메시지 등에 여전히 기밀로 유지되어야 할 많은 다른 데이터가 있을 수 있습니다. 특히 우리 커뮤니티 포럼에서는 전화번호와 주소를 공개된 곳에 올리는 대신, 개인 메시지를 통해 연락처를 교환하고 판매나 수령을 조율하도록 권장하고 있다는 점을 특히 유의해 주세요.
저는 백업에 대해 인스턴스에 진입하여 백업을 생성한 후, 즉시 gpg를 사용하여 공개 키로 암호화하는 방식을 취하고 있습니다. 이렇게 하면 해당 개인 키를 가진 사람이 아닌 누구에게든 백업이 무용지물이 되며, 저는 이 개인 키를 서버 밖에서 패스프레이즈로 보호하여 보관하고 있습니다.
그럼에도 불구하고, 세션의 시크릿 키가 변경되지 않는다면 한 번만 백업하면 되므로, 이를 위한 간단한 절차만 있으면 충분합니다. 아마도 위에서는 바로 그런 내용을 설명해 주셨을 것입니다.
) 전혀 문제가 없지만, 다음과 같은 몇 가지 불리한 부작용을 예상할 수 있어 그런 상황을 정말로 피하고 싶습니다:
)