사용 가능한 사이트와 nginx의 conf.d 디렉토리의 다른 사용법은 무엇입니까


98

리눅스 사용 경험이 있지만 nginx 사용 경험이 없습니다. 나는 응용 프로그램 서버에 대한 부하 분산 옵션을 연구하는 임무를 맡았습니다.

나는 apt-get을 사용하여 nginx를 설치했으며 모두 괜찮아 보입니다.

몇 가지 질문이 있습니다.

사이트에서 사용 가능한 폴더와 conf.d 폴더의 차이점은 무엇입니까? 이러한 폴더는 모두 nginx의 기본 구성 설정에 포함되어 있습니다. 튜토리얼은 둘 다 사용합니다. 무엇을위한 것이며 가장 좋은 방법은 무엇입니까?

사이트 사용 폴더는 무엇에 사용됩니까? 어떻게 사용합니까?

기본 구성은 www-data 사용자? 해당 사용자를 만들어야합니까? 해당 사용자에게 nginx 실행을위한 최적의 권한을 부여하려면 어떻게합니까?


질문 할 때 스코프 크립을 피하십시오. www-data별도의 주제입니다. 대부분의 운영 체제는 포트 80에 루트로 바인딩 한 후 프로세스가 실행할 수있는 권한이 낮은 별도의 사용자를 정의합니다. 구성 파일에 정의되어 있습니다. 거기에서 기본적인 보안 관행을 적용하십시오. 사용자가 웹 서버에 쓸 필요가없는 것에 쓰지 말고, 의도적이지 않은 한 다른 사용자가 파일에 쓰지 못하게하십시오.
— 앤드류 B

답변:


93

sites- * 폴더는 nginx_ensite및 로 관리됩니다 nginx_dissite. 검색으로이를 찾는 Apache httpd 사용자의 경우 해당하는 항목은 a2ensite/ a2dissite입니다.

이 sites-available폴더는 현재 활성화되어 있는지 여부에 관계없이 모든 호스트 구성 을 저장하기위한 것 입니다.

이 sites-enabled폴더에는 사이트 사용 가능 폴더의 파일에 대한 심볼릭 링크가 포함되어 있습니다. 심볼릭 링크를 제거하여 호스트를 선택적으로 비활성화 할 수 있습니다.

conf.d작업을 수행하지만 폴더에서 무언가를 이동하거나 삭제하거나 비활성화해야 할 경우 변경해야합니다. sites- * 폴더 추상화는 작업을 좀 더 체계적으로 만들어 별도의 지원 스크립트로 관리 할 수있게합니다.

(당신이 나와 같지 않고 스크립트에 대해 전혀 모르고 심볼릭 링크를 직접 관리 한 많은 데비안 관리자 중 하나가 ...)


12
내가 뭔가 잘못 받았 니? downvote를 이해하지 못합니다.
— Andrew B

1
이것이 nginx에 내장되어 있는지 궁금합니다. 내가 수동으로 설치 github.com/perusio/nginx_ensite
— lfender6445

18
그것은 sites-available|sites-enabled데비안주의이며 nginx 나 Apache가하는 것이 아니라는 점에 유의 해야합니다. 과거에는 꽤 유용했을지 모르지만 구성 관리 및 컨테이너 시대에는 유틸리티가 다소 제한적입니다.
— Michael Hampton

구성 관리 및 컨테이너가 sites-available | sites-enabled 유틸리티의 유틸리티를 제한하는 방법에 대해 언급 할 수 있습니까?
— karthik vee

1
요컨대 요즘 서버는 종종 단일 웹 사이트 / 서비스 만 제공하는 임시 컨테이너로 표시되므로 nginx.conf가독성의 손실없이 포함될 수 있습니다 . 이것은 몇 년 전 서버가 일반적으로 수십 개의 웹 사이트를 저장하는 방식과 반대입니다.
— adamczi

38

이전 답변에 가장 중요한 것은 디렉토리를 호출하는 방법이 아니라 (매우 유용한 규칙이지만) 실제로 넣은 것입니다 nginx.conf. 구성 예 :

http {
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*.conf;
    include /etc/nginx/sites-enabled/my_own_conf;
...
}

여기에 사용 된 유일한 지시문은 include 이므로, eg conf.d/와 내부적으로 차이가 없습니다 sites-enabled/.

위의 문서에서 :

Syntax:     include file | mask;
Default:    —
Context:    any

Includes another file, or files matching the specified mask, 
into configuration. Included files should consist of 
syntactically correct directives and blocks.

따라서 원래의 질문에 답하십시오. 내부적 인 차이는 없으며 다른 답변의 조언을 기억하여 최선의 방법으로 사용할 수 있습니다. 그리고 '올바른'답변을 선택하는 것을 잊지 마십시오.


1
맞아, sites-enabled성가신 중간체처럼 퍼지면서 약간의 분배에 의해 다소 발명되었습니다. 공식 소스 에서 nginx를 가져 가십시오 .이 구성 쓰레기 / 지옥을 제거 할뿐만 아니라 최신 제품을 얻을 수 있습니다.
— Bernard Rosset

2
공식 Nginx 문서에이 이름 규칙에 대한 단일 참조가없는 이유를 설명합니다. 타사 프로젝트입니다! github.com/perusio/nginx_ensite
— AxeEffect

30

일반적으로 sites-enabled폴더는 가상 호스트 정의에 conf.d사용되는 반면 글로벌 서버 구성에 사용됩니다. 여러 웹 사이트 (예 : 가상 호스트)를 지원하는 경우 각 웹 사이트는 자체 파일을 가져 오므로 파일을 안팎으로 이동 sites-enabled하거나 심볼릭 링크를 만들고 제거 하여 매우 쉽게 웹 사이트를 활성화 및 비활성화 할 수 있습니다. 더 나은 아이디어).

conf.d모듈로드, 로그 파일 및 단일 가상 호스트와 관련되지 않은 기타 항목에 사용하십시오 .

기본 구성은 www-data 사용자? 해당 사용자를 만들어야합니까?

루트 사용자가 아닌 사용자로 nginx를 실행해야합니다. 이 경우 이름 www-data이이지만 원하는 이름을 지정할 수 있습니다.

해당 사용자에게 nginx 실행을위한 최적의 권한을 부여하려면 어떻게합니까?

나는이 질문에 대한 대답이 확실하지 않습니다 (현재 nginx를 실행하지 않습니다). 아파치와 같은 것이면 www-data사용자 는 정적 파일에 대한 읽기 권한 만 필요하고 디렉토리에서 읽기 + 실행이 필요하다는 것입니다 )를 제공하거나 CGI 스크립트와 같은 항목에 대한 권한을 읽고 실행하며 다른 곳에서는 권한이 없습니다.


1
유효한 쉘 레코드를 제거하여이 사용자의 로그인 기능을 사용하지 않기 때문에 웹 서버를 실행하기위한 전용 사용자를 갖는 것도 중요합니다.
— DukeLion

> 'root가 아닌 사용자로 nginx를 실행해야합니다.'-이것에 대해 더 자세히 설명해 주시겠습니까?
— lfender6445

1
권한이없는 사용자로 실행하면 원격 손상으로 인해 발생할 수있는 피해를 막을 수 있습니다. 웹 서버를 실행 중이고 root어떤 종류의 원격 손상이있는 경우 공격자는 즉시 시스템에 대한 모든 액세스 권한을 갖습니다. 권한이없는 사용자로 실행하는 경우 관리 액세스는 일종의 로컬 악용과 결합해서 만 사용할 수 있습니다.
— larsks

14

무슨 일이야?

때문에 당신은 데비안이나 우분투를 사용하고 있어야합니다 악 sites-available / sites-enabled로직이 사용되지 않습니다 nginx를 상류 포장 에서 http://nginx.org/packages/ .

두 경우 모두의 표준 include지시문을 사용하여 구성 규칙으로 구현됩니다 /etc/nginx/nginx.conf.

다음 /etc/nginx/nginx.conf은 nginx.org의 공식 nginx 업스트림 패키지에 대한 스 니펫입니다 .

http {
    …
    include /etc/nginx/conf.d/*.conf;
}

다음 /etc/nginx/nginx.conf은 데비안 / 우분투 의 스 니펫입니다 .

http {
    …
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

따라서 NGINX의 관점에서 유일한 차이점은 파일을 conf.d더 빨리 처리해야한다는 것입니다. 따라서 서로 자동으로 충돌하는 구성이있는 경우의 파일이 파일 conf.d보다 우선 sites-enabled합니다.


모범 사례는 conf.d입니다.

당신은 사용해야 /etc/nginx/conf.d하는 표준 규칙, 그리고 어디에서나 작동합니다 같이.

사이트를 비활성화해야하는 경우 파일 이름을 바꾸면 더 이상 .conf접미사, 매우 쉽고 간단하고 오류 방지 기능 이 없어집니다 .

sudo mv -i /etc/nginx/conf.d/default.conf{,.off}

또는 사이트 를 활성화 하는 반대의 경우 :

sudo mv -i /etc/nginx/conf.d/example.com.conf{.disabled,}


피하십시오 sites-available및 sites-enabled모든 비용.

sites-available/ 를 사용해야 할 이유가 전혀 없습니다 sites-enabled.

  • 어떤 사람들은 언급 nginx_ensite하고 nginx_dissite그들이 결석이야 - 스크립트 -이 스크립트의 이름은이 사태의 나머지 부분보다 더 나쁘다 - 그러나 이러한 스크립트는 어디에서도 발견 할 수있다 nginx(도 아마 우분투)도 데비안의 패키지 또한 자체 패키지로 제공되지 않으며, 단순히 두 디렉토리 사이에서 파일을 이동 및 / 또는 연결하기 위해 비표준 타사 스크립트가 필요합니까?!

  • 그리고 스크립트를 사용하지 않으면 (실제로 위와 같은 현명한 선택) 사이트를 관리하는 방법에 대한 문제가 있습니다.

    • 당신은에서 심볼릭 링크를 만들려면 어떻게해야합니까 sites-available에를 sites-enabled?
    • 파일을 복사 하시겠습니까?
    • 파일을 옮기시겠습니까?
    • sites-enabled?의 위치에서 파일을 편집하십시오 .

위의 내용은 여러 사람들이 시스템 관리를 시작하거나 빠른 결정을 내릴 때까지 해결해야 할 사소한 문제처럼 보일 수 있습니다.

이것은 우리에게 다음을 가져옵니다.

  • 파일을 안전하게 제거 할 수 sites-enabled있습니까? 소프트 링크입니까? 하드 링크? 아니면 구성의 유일한 사본입니까? 구성 지옥의 주요 예.

  • 어떤 사이트가 사용 중지 되었습니까? (를 사용하면 —로 conf.d끝나지 않는 파일을 역으로 검색하거나을 사용하십시오 .).conffind /etc/nginx/conf.d -not -name "*.conf"grep -v

위의 모든 내용뿐만 아니라 includeDebian / Ubuntu에서 사용 하는 특정 지시문에 유의하십시오 — /etc/nginx/sites-enabled/*— sites-enabled와 달리 파일 이름 접미사가 지정되지 않았습니다 conf.d.

  • 이것이 의미하는 것은 언젠가는 빠르게 내 파일 또는 둘을 편집하기로 결정한 경우이다 /etc/nginx/sites-enabled, 당신은 emacs같은 백업 파일을 생성 default~하면 모두 한 갑자기, 다음, default및 default~사용 지침을 따라하는 것은도 제공하지 않을 수 있습니다, 활성 구성을 포함 경고가 발생하고 디버깅 세션이 오래 지속될 수 있습니다. (예, 그것은 나에게 일어난 일입니다. 그것은 해커 톤 중이었고, 내 conf가 작동하지 않는 이유에 완전히 당황했습니다.)

따라서 나는 그것이 sites-enabled순수한 악이라고 확신합니다 !


위의 모든 것 외에도 잘못된 심볼릭 링크를 만드는 것이 일반적입니다! stackoverflow.com/a/14107803/1122270 당신이 sites-enabled충분히 악 하다고 생각하지 않은 경우를 대비하여 !
— cnst

또는 때때로 누군가가에서 파일을 편집하기로 결정한 sites-enabled경우 다른 사람 이 파일 을 삭제 하여 파일 을 사용하지 않기로 결정한 경우 해당 파일 이 단지 심볼릭 링크라고 생각하여 conf 파일을 복구하기 위해 nginx 힙의 후속 메모리 덤프가 필요하다고 생각할 수 있습니다. stackoverflow.com/q/45852224/1122270
— cnst

나는에 대한 주장에 동의해야 sites-available하고 sites-enabled, nginx를 다시로드하거나 다시 시작하면 부분 구성 파일을 선택하지 않도록 '실시간'픽업 디렉토리 외부에서 구성 파일을 준비 할 수 있어야합니다. 더 이상 사용하지 않는 구성 파일을 유지하는 것이 유용 할 수도 있습니다. 처음에 IMO 인 nginx를 관리 할 충분한 경험이 있다면 심볼릭 링크를 만드는 것은 특히 어려운 작업이 아닙니다.
— BE77Y

@ BE77Y 더 복잡한 접근법을 취하고 있습니다. 프로그래밍에서는 사용하지 않거나 코드를 주석 처리하지 않고 사용하지 않는 코드를 완전히 제거하는 것이 가장 좋습니다. DevOps가 다른 이유가 없습니다. 구성이 더 이상 필요하지 않으면 제거하십시오 (여전히 VCS에 있어야 함). 부분적인 conf 파일과 동일-왜 파일을 편집하고 nginx를 다시로드 한 것입니까? ( USR1, 로그를 다시 열면 conf가 다시로드되지 않습니다.) symlink "경험"의견이 잘못 지시 된 것으로 나타났습니다. 문제는 일관성 문제이며 경험과는 거의 관련이 없습니다.
— cnst

2
a) 이것은이 논의에 적합한 매체가 아니며 아마도 더 중요한 것은 b) 어떤 경우에도 결실이 없을 가능성이 높다는 것이 분명합니다. 동의하지 않을 것에 동의합시다.
— BE77Y
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.