사용자 간에 공유되는 파일을 배치하기에 가장 적합한 디렉토리는 무엇입니까?

사용하지 마세요

• /usr읽기 전용 데이터를 공유하는 데 사용됩니다. 여기의 데이터는 관리상의 이유로만 변경할 수 있습니다(예: 새 패키지 설치).
• /opt일반적으로 독립 실행형 프로그램이나 어떤 이유로 시스템의 나머지 부분(예: 낮거나 중간 정도의 상호 작용 허니팟)과 격리되어야 하는 프로그램에 적합합니다.
• /var이다"로그, 스풀 파일, 임시 이메일 파일 등 시스템이 정상적으로 작동하는 동안 내용이 지속적으로 변경될 것으로 예상되는 파일입니다."나는 이런 식으로 생각하고 싶습니다. 데이터가 목록에서 제대로 보이지 않으면 일반적으로 목록에 속하지 않습니다 /var(예외가 있지만).

사용

• /home사용자 홈 디렉터리에 사용됩니다. 어떤 사람들은 이 디렉토리를 그룹 파일 영역으로 간주하기도 합니다. FHS는 실제로 다음과 같이 말합니다."대규모 시스템에서(특히 /home 디렉토리가 NFS를 사용하여 많은 호스트 간에 공유되는 경우) 사용자 홈 디렉토리를 세분화하는 것이 유용합니다. 하위 디렉토리는 /home/staff, /home /guests, /와 같은 하위 디렉토리를 사용하여 수행할 수 있습니다. 집/학생 등”
• /srv그룹 파일에 적합하고 일반적으로 선호되는 위치입니다. Chris Down의 기사에 언급된 이유로 나는 일반적으로 그룹 공유 파일에 이 디렉토리를 사용합니다.답변;그룹 파일 공유는 서버에서 제공하는 서비스로 봅니다.

man hierFHS에서 설명하는 각 디렉토리의 목적에 대한 자세한 내용은 hier(7) 매뉴얼 페이지( )를 참조하십시오.

제 생각에는 가 딱 맞는 곳인 것 같아요 /srv/movies-enthusiast. "서비스"는 데몬이나 프로그램일 필요는 없으며 시스템에서 제공하는 서비스(영화를 볼 수 있는 것과 같은)이면 됩니다. 이것은에서 온 것입니다FHS:

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

나는 귀하의 사용이 그 정의에 속하며 서비스를 제공한다고 확실히 생각합니다.

이것파일 시스템 계층 표준(FHS)는 혼란을 피하기 위해 "유닉스 배포판 개발자, 패키지 개발자 및 시스템 구현자"가 따라야 할 레이아웃을 지정합니다.당신의네임스페이스.

이 때문에당신의네임스페이스에 대해서는 적절하다고 생각하는 것을 선택해야 합니다. 의미가 있는 것을 찾으면 /groups/movies-enthusiast거기에 게시해야 합니다. 입력하기 쉽기 때문에 짧은 경로 이름을 선호한다면 /g/movies-enthusiast(또는 /g/m-e)이 적합할 것입니다.

선택한 경로는 FHS에 정의되어 있지 않으므로 배포판이나 타사 패키지가 해당 경로를 건드리면 안 됩니다. 따라서 FHS를 읽어서 호환 소프트웨어가 사용할 수 있는 경로를 알아내야 합니다(디렉토리는 알아야 할 대부분의 내용을 알려줍니다).

예를 들어 저는 개인적으로 /av시청각 콘텐츠, /src소스 코드, /data정의되지 않은 데이터(예: 가상 머신 이미지, CD 이미지, chroot, 저장된 패키지 등)를 저장하는 데 사용합니다.

FHS를 기억하는 것이 중요합니다.여러 당사자(예: 로컬 사이트, 배포판, 애플리케이션, 문서 등) 간의 파일 배치를 조정해야 하는 문제를 해결합니다.; FHS는 귀하가 직면할 수 있는 모든 상황에 대해 규칙을 만들려고 시도하지 않습니다.로컬 파일의 로컬 배치는 로컬 문제입니다.(FHS 3.0, 섹션 1.1).

movies따라서 기술적으로 디렉토리를 어디에 든 둘 수 있습니다 .FHS 관행을 위반하지 않는 한. 그러나 귀하의 질문은가장 적합한따라서 몇 가지 일반적인 답변을 고려해 보겠습니다(특정 사용 사례에 따라 가장 선호하는 것부터 가장 덜 선호하는 것 순으로 정렬).

• /<someprefix>/<groupname>또는 /media/<volumename>/<groupname>: 솔직히 말해서 이 옵션이 Linux 세계에서 왜 나쁜 평판을 가지고 있는지는 모르겠지만 명확히 해두자면 그렇습니다.당신의시스템이며 FHS는 확립된 의미와 충돌하지 않는 한 루트 수준에서 새 디렉터리를 생성할 수 있다고 말합니다. 예를 들어, 원하는 대로 디렉토리를 생성 /groups하거나 그 안의 파일을 구성할 수 있습니다. /shared일부 관리자는 이를 파일 시스템의 나머지 부분과 분리하는 것을 선호하여 다른 볼륨(예: 아래 /media/<volumename>/<groupname>)을 마운트합니다. 둘 다 훌륭하고 FHS를 준수합니다.

• /srv/<groupname>또는 /srv/<someprefix>/<groupname>: FHS에 따르면,/srv이 시스템에서 제공하는 사이트별 데이터가 포함되어 있습니다.. FHS는 계속해서 설명했습니다./srv 하위 디렉터리의 이름을 지정하는 데 사용되는 방법이 지정되지 않았습니다.. 내 개인적인 경험에 따르면 /srv이 디렉터리를 활용하는 대부분의 관리자는 클라이언트별, 사이트별 또는 프로젝트별 하위 디렉터리를 사용한 다음 데이터 디렉터리를 해당 수준에 배치합니다. 구조화 방법에 관계없이 /srv해당 파일을 공유하는 것이 그 자체로 서비스를 구성한다고 합리적으로 가정할 수 있는 경우 여러 사용자 간에 공유할 파일을 저장하는 것은 완벽하게 허용됩니다. 스스로에게 물어보세요. "이러한 파일을 SMB/NFS/AFS/GIT/...를 통해 공유하는 것이 합리적입니까?" 그렇다면 디렉터리를 로컬 파일 공유 서비스로 간주하여 하위 디렉터리에 저장할 수 있습니다. /srv, 실제로는 이러한 파일을 다른 시스템에 제공하는 데몬이 없더라도 마찬가지입니다.

• /home/<groupname>또는 /home/<some-prefix>/<groupname>: FHS는 다음과 같이 말합니다./home상당히 표준적인 개념이지만 분명히 사이트별 파일 시스템입니다.. 아래의 각 디렉터리가 실제 사용자의 이름이어야 한다는 요구 사항은 전혀 없으며 /home그룹의 하위 디렉터리는 허용되지만 그룹과 사용자 간의 최종 충돌을 피하기 위해 예방 조치를 취해야 합니다. 그럼에도 불구하고 충돌 가능성을 피하기 위해 몇 가지 분할 전략을 사용하는 몇몇 대규모 기관(특히 대학)에서 이 전략이 사용되는 것을 보았습니다. 예를 들어 실제 사용자의 홈 디렉토리는 또는 /home/students/<studentid>에 배치되고 공유 콘텐츠는 배치됩니다. 안에 . 때로는 부서의 지점일 수도 있지만 요점은 알 수 있습니다. 솔직히 말해서 저는 개인적으로 이 전략을 좋아하지 않지만 여러 서버에 분산할 때(예: NFS를 통해) 작업이 훨씬 쉬워지므로 대규모 조직에서 선호되는 경향이 있습니다./home/teachers/<username>/home/staff/<username>/home/workgroup/<workgroupname>/home