Jaki jest najbardziej odpowiedni katalog, w którym można umieścić pliki współdzielone między użytkownikami?

Lub: gdzie mogę umieścić pliki należące do grupy?

Załóżmy, że w systemie Unix jest dwóch użytkowników: Joe i Sarah . Oboje są członkami grupy entuzjastów filmów . Gdzie mam umieścić ich pliki filmowe?

• /home/{joe,sarah}/moviesnie są odpowiednie, ponieważ katalogi te należą do Joe / Sarah , a nie do ich grupy;

• /home/movies-enthusiastteż nie jest właściwe, ponieważ entuzjasta filmów to grupa, a nie użytkownik;

• /var/movies-enthusiast może być opcją, ale nie jestem pewien, czy jest to dozwolone przez FHS;

• /srv/movies-enthusiast może być również opcją, jednak filmy nie są plikami wymaganymi przez usługi systemowe.

Nie używaj

• /usrsłuży do udostępniania danych tylko do odczytu. Dane tutaj powinny się zmieniać tylko ze względów administracyjnych (np. Instalacja nowych pakietów).
• /opt dotyczy ogólnie programów, które są niezależne lub z jakiegoś powodu wymagają izolacji od reszty systemu (na przykład programy typu plaster miodu o małej i średniej interakcji).
• /varjest przeznaczony do „plików, których zawartość oczekuje się ciągłej zmiany podczas normalnej pracy systemu --- takich jak logi, zbiory buforowe i tymczasowe pliki e-mail”. Lubię myśleć o tym w ten sposób: jeśli twoje dane nie wyglądałyby poprawnie podsumowane na liście, to na ogół nie należą /var(chociaż są wyjątki).

Posługiwać się

• /homejest dla katalogów domowych użytkowników. Niektórzy postrzegają ten katalog jako obszar plików grupowych. FHS faktycznie zauważa, że „w dużych systemach (szczególnie gdy katalogi / home są współużytkowane przez wiele hostów korzystających z NFS), przydatne jest podzielenie katalogów domowych użytkowników. Podział ten można osiągnąć za pomocą podkatalogów takich jak / home / staff, / home / goście, / dom / studenci itp. ”
• /srvjest akceptowalną i często preferowaną lokalizacją plików grupowych. I zazwyczaj używają tego katalogu plików grupowych współdzielony z przyczyny wymienionej w Chris Downa odpowiedź ; Widzę grupowe udostępnianie plików jako usługę świadczoną przez serwer.

Zobacz stronę man hier (7) ( man hier), aby uzyskać więcej informacji o celu każdego katalogu opisanego przez FHS.

Moim zdaniem właściwym miejscem jest /srv/movies-enthusiast. „Usługa” nie musi być demonem ani programem, musi po prostu być usługą zapewnianą przez system (na przykład mieć możliwość dostarczenia tam swoich filmów). Oto cytat z FHS :

/ srv zawiera dane właściwe dla witryny, które są obsługiwane przez ten system.

Zdecydowanie uważam, że twoje użycie jest objęte tą definicją i świadczy usługę.

Filesystem Hierarchy Standard (FHS) określa układ dla „programistów Unix dystrybucji, deweloperów pakietu i implementors systemowych” przestrzegać, aby nie zrobić bałaganu swojej przestrzeni nazw.

Ponieważ jest to Twoja przestrzeń nazw, powinieneś wybrać dowolne imię, które uważasz za odpowiednie. Jeśli uważasz, że /groups/movies-enthusiastma to sens, powinieneś go tam umieścić. Jeśli lubisz krótkie nazwy ścieżek, ponieważ łatwiej je wpisać, /g/movies-enthusiast(lub być może /g/m-e) byłoby odpowiednie.

Ponieważ wybrane ścieżki nie są zdefiniowane w FHS, pakiety dystrybucyjne ani pakiety innych firm nie mogą ich dotykać. W związku z tym powinieneś przeczytać FHS, aby dowiedzieć się, jakie ścieżki mogą być używane przez zgodne oprogramowanie (spis treści powie ci większość tego, co musisz wiedzieć).

Na przykład osobiście używam /avdo przechowywania treści audiowizualnych, /srckodu źródłowego i /dataniezdefiniowanych danych (takich jak obrazy maszyn wirtualnych, obrazy płyt CD, chrooty, zapisane pakiety itp.).

Nie ma nic złego w tworzeniu nowego punktu montowania lub katalogu do tego celu z katalogu głównego.

Szczególnie, jeśli jest to główny cel tego systemu, po prostu bym stworzył

/ entuzjasta filmów

Jeśli istnieją inne podobne „grupy”, mogę, ale nie chcę, organizować je razem, np

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

lub

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

Pytania do rozważenia: Czy zamierzasz w tym celu poświęcić punkt montowania?

Czy zastanawiałeś się nad softlinkami?

W każdym razie nie ma żadnych zasad. Jeśli chcesz, aby jeden użytkownik był depozytariuszem i dać reszcie dostęp do tego obszaru projektu, możesz go hostować w katalogu osobistym użytkownika. Lub utwórz przestrzeń nazw / home / shared / *. Jesteś swoim własnym szefem.

Och, jedno: cokolwiek zrobisz, udokumentuj to. Musi stać się częścią odzyskiwania systemu, codziennych kontroli, kopii zapasowych itp. Należy odnotować ważną detencję konfiguracji (np. Członkostwo w grupach, zestawy uprawnień, przestrajanie fs dla wydajności i wszystko inne, co nie jest domyślne)

FHS ma również ułatwić administrację, więc wybrałbym / srv z tego powodu, chociaż nie jest to to, co zrobiłem. Miejcie jednak doskonałą perspektywę. Używam / export / srv, ponieważ jest na NAS.

Jeśli jest to pole rozwijane, upewnij się, że jest ono zarówno ustawione jak i lepkie. Upewnij się również, że osoby korzystające z niego mają przydatne umask. Nie używaj jednak koła tak, jak zrobiłem to w przykładzie trybów dostępu do plików. Nie usuwaj eXecute, bo czeka Cię niespodzianka.

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

Należy pamiętać, że FHS zajmuje się kwestiami, w których umieszczanie plików musi być koordynowane między wieloma stronami, takimi jak lokalne witryny, dystrybucje, aplikacje, dokumentacja itp . ; FHS nie próbuje ustalać reguł dla każdej możliwej sytuacji: lokalne umieszczanie plików lokalnych jest problemem lokalnym ( FHS 3.0, sekcja 1.1 ).

Dlatego technicznie możesz umieścić swój movieskatalog w dowolnym miejscu, o ile nie jest to sprzeczne z konwencjami FHS . Twoje pytanie dotyczyło jednak najbardziej odpowiedniego miejsca, więc zastanówmy się nad kilkoma typowymi odpowiedziami (uporządkowane według najbardziej preferowanych do moich mniej preferowanych, biorąc pod uwagę konkretny przypadek użycia):

• /<someprefix>/<groupname>lub /media/<volumename>/<groupname>: Szczerze mówiąc, nie wiem, dlaczego ta opcja ma złą reputację w świecie Linuksa, ale wyjaśnijmy to: to naprawdę twój system, a FHS mówi, że jesteś wolny od tworzenia nowych katalogów na poziomie głównym ponieważ nie kolidujesz z niczym, dla którego istnieje ustalona semantyka. Możesz na przykład utworzyć katalog /groupslub /shareduporządkować w nim pliki według własnego uznania. Wiem, że niektórzy administratorzy wolą, aby były one nieco odizolowane od reszty systemu plików, więc montują odrębny wolumin (tj. Pod /media/<volumename>/<groupname>). Oba są w porządku i oba są zgodne z FHS, naprawdę.

• /srv/<groupname>lub /srv/<someprefix>/<groupname>: Według FHS /srvzawiera dane właściwe dla witryny, które są obsługiwane przez ten system . FHS następnie wyjaśnia, że metodologia stosowana do nazewnictwa podkatalogów / srv jest nieokreślona . Z mojego osobistego doświadczenia wynika, że ​​większość administratorów, którzy wykorzystują /srvkatalog , korzysta z podkatalogu dla klienta, witryny lub projektu, a następnie umieszcza katalogi danych na tym poziomie. Niezależnie od tego, jak ją zbudujesz,/srvjest całkowicie akceptowalne przechowywanie plików do współdzielenia przez wielu użytkowników, jeśli można zasadnie uznać, że udostępnianie tych plików samo w sobie stanowi usługę. Zadaj sobie pytanie: „Czy sensownie byłoby udostępnić te pliki za pośrednictwem SMB / NFS / AFS / GIT / ...?” Jeśli tak, to możesz rozsądnie uznać, że twój katalog jest lokalną usługą udostępniania plików, a tym samym przechowywać je w podkatalogu /srv, nawet jeśli nie istnieje demon obsługujący te pliki w innych systemach.

• /home/<groupname>lub /home/<some-prefix>/<groupname>: FHS mówi: /hometo dość standardowa koncepcja, ale wyraźnie jest to system plików specyficzny dla danego miejsca . Absolutnie nie ma wymogu, aby każdy katalog /homebył nazwą rzeczywistego użytkownika i dopuszczalne jest posiadanie podkatalogów dla grup, chociaż należy zachować ostrożność, aby uniknąć ewentualnych konfliktów między grupą a użytkownikiem. Mimo to widziałem tę strategię stosowaną w kilku dużych konfiguracjach (zwłaszcza uniwersytetach) z pewną strategią komplementarności, aby uniknąć możliwości konfliktu; na przykład prawdziwi użytkownicy mieliby swoje katalogi domowe /home/students/<studentid>, /home/teachers/<username>lub /home/staff/<username>, na przykład, udostępniane rzeczy/home/workgroup/<workgroupname>. Kiedyś byliby także działem; wciąż masz pomysł. Szczerze mówiąc, osobiście nie podoba mi się ta strategia, ale ułatwia to trochę, gdy /homejest dystrybuowana na kilka serwerów (na przykład przez NFS), dlatego jest preferowana w bardzo dużych organizacjach.

Osobiście wybrałbym / entuzjasta / usr / share / movies-entuzjasta lub / opt / movies-entuzjasta

Proponuję utworzyć osobny katalog, taki jak / opt / movies, ustawić dla nich odpowiednie uprawnienia użytkowników i grup, a także użyć dysku, quotaaby uniknąć całkowitego zużycia dysku.

To jest tak samo komentarz jak odpowiedź (więc proszę, nie głosuj za mną!), Ale jest o wiele za długi, aby zmieścić się w komentarzu.

Robię dwie rzeczy, z których obie unikają problemu.

1) Wykonuję osobną partycję całego wolnego miejsca na dysku systemowym i oznaczam go datacace. Tam trafiają wszystkie moje bieżące pliki multimedialne i inne dane. Zostaje automatycznie zamontowany jako / media / dataspace, a ja umieszczam wszystko, co „dane” w katalogu o nazwie „dane”, aby oddzielić je od rzeczy takich jak pliki robocze, vms lub obrazy ISO, których nie chcę rutynowo tworzyć kopii zapasowych.

Korzystanie z oddzielnej partycji ma tę dodatkową zaletę, że jeśli się zapełni, nie naruszy mojego systemu tak, jak gdyby był zapisany w / / / home.

2) Umieszczam większość moich danych / multimediów, zwłaszcza rzeczy, których nie używam „teraz” na innym dysku fizycznym (w moim przypadku USB z notebookiem). Ułatwia to tworzenie kopii zapasowych i podłączanie do innego komputera, jeśli zajdzie taka potrzeba.