@최상위 도메인을 www로 리다이렉트

위키 시스템 관리자
1
  1. sudo를 사용하여 권한을 임시로 높여 app.yml을 편집합니다.
cd /var/discourse
sudo nano /containers/app.yml
  1. Discourse 설정 파일 app.yml을 편집합니다.

Discourse 설정 파일 app.yml에서 설정만 수행하면 됩니다. 메인 도메인과 별칭의 관계를 다음과 같이 지정하세요:

DISCOURSE_HOSTNAME: 'www.discourse.cc'      # 메인 도메인 (최종 접근 주소)  
DISCOURSE_HOSTNAME_ALIASES: 'discourse.cc'  # 기타 별칭, 메인 도메인으로 자동 리다이렉트

참고: DISCOURSE_HOSTNAME 뒤에 입력하는 값은 사용자가 최종적으로 접근할 "메인 도메인"이며, DISCOURSE_HOSTNAME_ALIASES에는 메인 도메인으로 리다이렉트할 "별칭"을 입력합니다.
편집이 완료되면 저장합니다(Ctrl+O, 엔터, Ctrl+X로 종료).

  1. 마지막으로 root 권한으로 재구축합니다:
sudo ./launcher rebuild app
1개의 좋아요
任何随机子域名重定向到www
2

표준 설치 환경에서는 루트(root) 계정으로 로그인하기 때문에 일반적으로 이 작업이 필요하지 않습니다.

3개의 좋아요
3

말씀하신 내용을 잘 이해하지 못했습니다. 다시 한번 설명해 주시겠어요?

4

표준 설치는 스크립트를 실행할 때 루트(root) 권한만 있으면 됩니다. 실제로는 루트 로그인 허용을 금지하는 것이 가장 좋은 관행입니다. Digital Ocean은 편의를 위해 기본적으로 루트 로그인을 활성화해 두었습니다. 루트에 대한 비밀번호 로그인을 금지하는 것은 다른 사용자 계정으로 로그인하는 것을 요구하는 것과 거의 동일한 효과를 냅니다.

서버의 일반적인 용도인 관리 목적 외에 이 머신을 다른 용도로 사용할 계획이라면(서버에서는 드문 경우) 반드시 다른 사용자 계정을 만들어야 합니다.

2개의 좋아요
5

루트 계정으로 로그인할 수 없다면, 이 기능을 구현하려면 어떻게 해야 하나요?

6

@pfaffman이 지적했듯이, 장기적으로 볼 때 이는 아마도 좋은 관행일 것입니다.

제 주장은 표준 설치 환경에서는 표준 로그인 방식이 루트를 통해 이루어지므로 sudo가 불필요하다는 것입니다.

여기서 핵심은 “비표준”(더 안전한) 설치에 대한 지침이 일부 사용자에게 혼란을 줄 수 있다는 점입니다:

  • “갑자기 왜 sudo가 필요한 거지?”

물론, 최소 권한으로 로그인하는 것은 좋은 관행입니다.

7

제 지점은 표준 설치에서 root 권한이 필요하지만, root 권한을 얻는 방식에 대해서는 무관(agnostic)하다는 것입니다.

아, 알겠습니다. 그러니 당신의 논거는 결국 “다른 모든 문서가 root 권한을 얻는 방법에 대해 다루지 않으므로” 여기에서도 그렇게 할 필요가 없다는 것이군요. 그 점에는 동의할 수 있습니다.

그러니 원문(OP)을 편집하여 이 세세한 논의를 삭제하는 것이 타당해 보입니다. :slight_smile:

2개의 좋아요