웹 사이트 컨텐츠를 저장하기 위해 권장되는 디렉토리는 무엇입니까?


18

웹 프로그래밍을 처음 시작했을 때 새 프로젝트를 만들고 싶을 때는 항상에 디렉토리를 만드는 법을 배웠습니다 /var/www/. 그러나 많은 튜토리얼에서 사람들이 디렉토리를 만드는 경향이 있다고 읽었습니다 /home/username/.

에 넣는 아이디어가 마음에 들지 않습니다 /home/username/.

파일 시스템의 특정 영역에 배치 할 때의 장점 / 단점이 올바른 위치에 있습니까?


그것이 가장 선호되는 것 ( "best"는 대부분 개발을 위해 이것을 가장 안전한 것으로 변경해야한다는 것을 의미합니다. 거기에서 서비스를 제공하는 경우 개인 파일과 웹 공유 항목 사이에 일정한 거리를 유지하기 위해 외딴 무언가를 원할 것입니다. 그러나 백만 개의 구성이 있습니다. 나는 /var/www보통 다른 드라이브에 붙어 있습니다 (기본 설정).
nerdwaller

"최상의"디렉토리는 없습니다. 파일의 물리적 위치는 중요하지 않기 때문에 전적으로 귀하의 의견입니다.
Ramhound

답변:


33

"최상의"디렉토리는 없습니다. 그리고 사람들은이 질문은 주관적이라고 주장 수도, 또는 파일의 실제 위치는 중요-하지 않는 그들에 대한 말이 맞아하면서 후기가 있습니다 유닉스 계열 시스템에 무엇을 넣을 위치에 대한 표준화 권고.

파일 시스템 계층 표준 이 정의하고 다음을 제공합니다 :

  • /var– 로그와 같이 정상 작동 중에 변경되는 데이터를 저장하는 /var/www장소는 Apache 용 웹 컨텐츠를 배치하는 기본 디렉토리이지만, 그 사용법은 전혀 표준화되어 있지 않으며 사람들이 사용하기 때문에 "정상적인"장소입니다. 기본 설정을 자주 변경하지 마십시오.

  • /srv–이 디렉토리는 시스템이 제공하는 데이터를 포함해야합니다. 이것은 일반적으로 원하는 장소입니다. FHS는 다음과 같이 설명합니다.

    이를 지정하는 주된 목적은 사용자가 특정 서비스에 대한 데이터 파일의 위치를 ​​찾을 수 있고 읽기 전용 데이터, 쓰기 가능한 데이터 및 스크립트 (예 : cgi 스크립트)에 대해 단일 트리가 필요한 서비스를 합리적으로 배치 할 수 있도록하기위한 것입니다. 특정 사용자에게만 관심이있는 데이터는 해당 사용자의 홈 디렉토리로 이동해야합니다. (…)

    데이터를 구성하는 한 가지 방법은 /srv예를 들어 프로토콜입니다. ftp, rsync, www, 및cvs

    따라서 단순히 /srv/www디렉토리 를 만들고 이것을 사용하십시오. 머신과 함께 제공하려는 모든 가상 호스트에 대한 하위 폴더를 만들 수 있습니다.

  • /home실제로 한 사용자에게만 속해야하는 파일이 포함되어 있습니다. 예를 들어 Apache는 userdirs 를 허용 하므로를 통해 사용자의 웹 파일에 액세스 할 수 있으며 사용자의 홈 디렉토리에서 http://example.com/~username제공됩니다 public_html.

    여러 사람이 공유하는 서버를 사용하고 모든 사람이 자신의 스크립트를 호스트 할 수있게하려면 여기로 가십시오. 자신이 속한 사용자 만 디렉토리를 쓸 수 있도록해야합니다.

본질적으로 /srv/www그리고 /var/www디렉토리입니다 당신은 당신이 호스팅 할 수있는 웹 프로젝트의 서브 디렉토리를 작성해야합니다. 그런 다음 특정 사용자 또는 사용자 그룹이 해당 디렉토리에 쓸 수 있도록 이러한 디렉토리에 다른 권한을 정의 할 수 있습니다. 한 번에 한 명의 사용자를위한 프로젝트가있는 경우을 사용하십시오 /home.


3
http://example.com/~username일반적으로 가리 키지 /home/username/만에 /home/username/public_html/.
choroba

예, 명확성을 위해 추가되었습니다. 끝난.
slhck

몇 년 동안 사용한 /var/www후에는 변화의 시간입니다!
sitilge

또한 www나에게 하위 도메인처럼 들립니다.
sitilge

추가하기 ... / var / www를 사용하는 것은 단일 사이트 서비스 인스턴스에 대한 일반적인 관행이며 기본 Apache 위치와 마찬가지로 / home / usr /을 사용하는 것은 리셀러 서버 또는 다중 사이트에 대한 일반적인 관행입니다. users == clients의 개념에서 나온 호스팅. 둘 다 일반적인 관행이며 shlck의 대답은 파일 시스템의 의도 된 목적을 더 잘 사용하는 것입니다.
Jools

3

파일에 제대로 액세스 할 수있는 한 파일을 아무 곳에 나 배치 할 수 있지만 나중에 파일 시스템이 혼란스러워지면 혼란스러워집니다.

/srv Filesystem Hierarchy Standard를 따르는 경우 가장 논리적입니다.

여러 도메인을 수행하면 /srv/domain1 /srv/domain2등을 수행 할 수 있습니다./ftp /www /tftp /logs /etc.etc.etc

나에게 구축하고 쉽게 제어 할 수있는 매우 견고한 구조를 느낍니다.

그러나 관리자는 원하는만큼 깨끗하거나 지저분해질 수 있습니다.


1

쉽고 빠른 답변입니다.

시스템의 웹 파일에 Linux 시스템의 한 명의 사용자 만 액세스 할 수 있습니다. 사용자의 홈 디렉토리 ( ~/)를 사용하십시오 .

시스템의 웹 파일이 Linux 시스템의 여러 사용자가 액세스하는 경우 사용하십시오 /srv/.

이것이 바로 http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM 상태입니다.

인용문은 다음과 같습니다.

/ srv에는이 시스템에서 제공하는 사이트 별 데이터가 포함됩니다.

이를 지정하는 주된 목적은 사용자가 특정 서비스에 대한 데이터 파일의 위치를 ​​찾을 수 있고 읽기 전용 데이터, 쓰기 가능한 데이터 및 스크립트 (예 : cgi 스크립트)에 대해 단일 트리가 필요한 서비스를 합리적으로 배치 할 수 있도록하기위한 것입니다. 특정 사용자에게만 관심이있는 데이터는 해당 사용자의 홈 디렉토리로 이동해야합니다.

보너스 : www? ftp? 프로토콜별로 정리 하시겠습니까? 응?

여기 http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM에 명시된 바와 같이

  • 시스템의 한 사용자 만 웹 사이트에 액세스하고 브라우저 (http 프로토콜)를 통해서만 액세스하는 경우 : ~/http/your-website-directory/또는 (https 프로토콜) :~/https/your-website-directory/
  • 시스템에서 한 명의 사용자 만 웹 사이트에 액세스하고 브라우저를 통해서만 아니라 여러 프로토콜 (ig http AND tcp AND ...)을 통해 액세스하는 경우 : ~/your-website-directory/
  • 시스템의 여러 사용자가 웹 사이트에 액세스하고 브라우저 (http 프로토콜)를 통해서만 액세스하는 경우 : /srv/http/your-website-directory/또는 (https 프로토콜) :/srv/https/your-website-directory/
  • 시스템의 여러 사용자가 웹 사이트에 액세스하고 브라우저를 통해서만 아니라 여러 프로토콜 (ig http AND ftp AND ...)을 통해 액세스하는 경우 : /srv/your-website-directory/

응 왜 안 www? 이것은 아파치 시대의 유산입니다. www는 사용중인 프로토콜을 지정하지 않습니다. 데비안은 오늘날에도 이것을 사용하지만 Arch linux는 / srv / http를 사용합니다.


0

Apache 웹 서버에는 기본 웹 사이트가 /var/www/있지만 다른 웹 사이트는/srv/

우분투 서버 14.04 LTS에서 이것을 보았습니다. 기본 apache2.conf파일에는 주석 처리 된 블록이 포함됩니다.

#<Directory /srv/>
#   Options Indexes FollowSymLinks
#   AllowOverride None
#   Require all granted
#</Directory>
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.