사용자간에 파일을 공유 할 수있는 가장 적합한 디렉토리는 무엇입니까?

또는 그룹에 속한 파일을 어디에 둘 수 있습니까?

유닉스 시스템에 두 명의 사용자 ( joe 및 sarah) 가 있다고 가정하십시오 . 둘 다 영화 애호가 그룹 의 구성원입니다 . 영화 파일을 어디에 두어야합니까?

• /home/{joe,sarah}/movies해당 디렉토리는 그룹이 아닌 joe / sarah에 속하기 때문에 적절 하지 않습니다.

• /home/movies-enthusiast영화 애호가 는 사용자가 아닌 그룹 이기 때문에 적절 하지 않습니다.

• /var/movies-enthusiast 선택 사항 일 수 있지만 FHS에서 허용되는지 확실하지 않습니다.

• /srv/movies-enthusiast 옵션 일 수도 있지만 영화는 시스템 서비스에 필요한 파일이 아닙니다.

사용하지 마십시오

• /usr공유 가능한 읽기 전용 데이터입니다. 여기의 데이터는 관리상의 이유로 만 변경해야합니다 (예 : 새 패키지 설치).
• /opt 일반적으로 자 급식이거나 어떤 이유로 시스템의 나머지 부분과 격리해야하는 프로그램 (예 : 중간 및 중간 상호 작용 허니팟 프로그램)에 사용됩니다.
• /var입니다 "내용이 지속적으로 같은 로그, 스풀 파일, 임시 이메일 파일 등 시스템의 정상 작동 --- 중에 변화가 예상되는 파일입니다." 나는 이것을 다음과 같이 생각하고 싶다 : 당신의 데이터가 목록에 요약되어 보이지 않으면, 일반적으로 데이터에 속하지 않습니다 /var(그러나 예외는 있습니다).

사용하다

• /home사용자 홈 디렉토리 용입니다. 일부는이 디렉토리를 그룹 파일의 영역으로 간주합니다. FHS는 실제로 "대규모 시스템에서 (특히 / home 디렉토리가 NFS를 사용하는 많은 호스트간에 공유되는 경우) 사용자 홈 디렉토리를 세분화하는 것이 유용합니다. 세분화는 / home / staff, / home과 같은 서브 디렉토리를 사용하여 수행 할 수 있습니다. / 손님, / 가정 / 학생 등 "
• /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, 저장된 패키지 등)에 개인적으로 사용 합니다 .

루트에서이 목적으로 새 마운트 지점이나 디렉토리를 작성하는 데 아무런 문제가 없습니다.

특히 이것이이 시스템의 주요 목적이라면

/ 영화-열정

다른 유사한 "그룹"이있는 경우 함께 그룹화하는 것을 선호하거나 선호하지 않을 수 있습니다 (예 :

/data/movies-entusiast
/data/next-group
etc

또는

/share/movies-enthusiast
/share/next-idea
etc

고려해야 할 질문 :이 목적을 위해 마운트 포인트를 사용 하시겠습니까?

소프트 링크를 고려 했습니까?

어쨌든 규칙이 없습니다. 한 명의 사용자를 관리인으로 만들고 나머지 프로젝트 공간에 액세스하려면 사용자의 홈 디렉토리에서 자유롭게 호스팅하십시오. 또는 / home / shared / * 네임 스페이스를 만듭니다. 당신은 당신의 자신의 보스입니다.

오, 한가지 : 당신이 무엇을 하든지 그것을 문서화하십시오. 시스템 복구, 일일 점검, 백업 등의 일부가되어야합니다. 중요한 구성에주의해야합니다 (예 : 그룹 구성원, 권한 집합, 성능에 대한 fs 조정 가능 매개 변수 및 기본값이 아닌 다른 것).

FHS는 관리자가 쉽게 할 수 있도록하기 때문에 내가 한 일이 아니지만 그 이유 때문에 / srv를 사용합니다. 그래도 완벽한 가늠자. NAS에 있기 때문에 / export / srv를 사용합니다.

드롭 박스가 고정되어 있고 끈적임이 없는지 확인하십시오. 또한 그것을 사용하는 사람들에게 유용한 umask가 있는지 확인하십시오. 그러나 파일 액세스 모드의 예에서 한 것처럼 휠을 사용하지 마십시오. eXecute를 벗기지 마십시오. 그렇지 않으면 O_o 놀람에 빠질 것입니다.

bash-3.2$ mkdir movies
bash-3.2$ sudo chmod 03771 movies
Password:
bash-3.2$ ls -ld movies/
drwxrws--t 2 andrewb wheel 68 Apr  4 17:09 movies/
bash-3.2$ umask 026
bash-3.2$ touch movies/junk
bash-3.2$ ls -l movies/
total 0
-rw-r----- 1 andrewb wheel 0 Apr  4 17:09 junk

FHS 는 로컬 사이트, 배포, 응용 프로그램, 문서 등과 같은 여러 당사자간에 파일 배치를 조정해야하는 문제를 해결 한다는 점을 기억 해야합니다 . FHS는 귀하가 가질 수있는 모든 단일 상황에 대해 규칙을 설정하려고 시도하지 않습니다. 로컬 파일의 로컬 배치는 로컬 문제입니다 ( FHS 3.0, 섹션 1.1 ).

따라서 FHS 규칙에 위배되지 않는 한 기술적으로 movies디렉토리를 어느 곳에 나 배치 할 수 있습니다 . 여전히 귀하의 질문은 가장 적절한 장소 에 관한 것이 었 으므로 몇 가지 일반적인 답변을 고려하십시오 (특정 사용 사례를 고려하여 가장 선호하는 순서에서 선호하지 않는 순서로 정렬).

• /<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>, /home/teachers/<username>또는 /home/staff/<username>공유 물건은 예를 들어에 넣어 될 수 있지만,/home/workgroup/<workgroupname>. 때때로 그들은 또한 부서의 세분이 될 것입니다. 여전히, 당신은 아이디어를 얻는다. 솔직히 말해서 개인적으로이 전략은 마음에 들지 않지만 /homeNFS를 통해 여러 서버에 배포 할 때 작업 이 조금 더 쉬워 지므로 매우 큰 조직에서 선호되는 경향이 있습니다.

개인적으로 / usr / share / movies-enthusiast 또는 / opt / movies-enthusiast를 선택했습니다

/ opt / movies와 같은 별도의 디렉토리를 만들고 적절한 사용자 및 그룹 권한을 설정하고 디스크 quota를 사용 하여 총 디스크 소비를 피할 것을 제안 합니다.

이것은 답변만큼이나 주석이므로 (그렇게 저에게 투표하지 마십시오!)하지만 너무 길어서 주석에 맞지 않습니다.

나는 두 가지 일을한다. 둘 다 당신이 직면 한 문제를 피한다.

1) 시스템 디스크의 모든 여유 공간을 별도의 파티션으로 만들고 데이터 공간 레이블을 지정합니다. 그것은 나의 모든 현재 미디어 파일과 다른 데이터가가는 곳입니다. / media / dataspace로 자동 마운트되며 "data"라는 디렉토리 아래에 "data"라는 항목을 넣어 일상적으로 백업하고 싶지 않은 작업 파일, vms 또는 iso 이미지와 같은 것을 분리합니다.

별도의 파티션을 사용하면 시스템이 가득 차면 / 또는 / home 아래에 저장된 것처럼 시스템이 손상되지 않습니다.

2) 대부분의 데이터 / 미디어, 특히 "지금 당장 사용하지 않는 것"을 다른 물리적 드라이브 (노트북이있는 USB)에 넣었습니다. 따라서 필요한 경우 백업 및 다른 컴퓨터에 쉽게 연결할 수 있습니다.