Qual è la directory più appropriata in cui posizionare i file condivisi tra gli utenti?


83

Oppure: dove posso mettere i file appartenenti a un gruppo?

Supponiamo che ci siano due utenti su un sistema Unix: joe e sarah . Sono entrambi membri del gruppo di appassionati di film . Dove devo mettere i loro file di film?

  • /home/{joe,sarah}/moviesnon sono appropriati perché quelle directory appartengono a joe / sarah , non al loro gruppo;

  • /home/movies-enthusiastnon è appropriato, perché gli appassionati di film sono un gruppo, non un utente;

  • /var/movies-enthusiast potrebbe essere un'opzione, ma non sono sicuro che ciò sia consentito dall'FHS;

  • /srv/movies-enthusiast potrebbe anche essere un'opzione, tuttavia i filmati non sono file richiesti dai servizi di sistema.


6
Votato per menzione di FHS! Questo utente * nix e amministratore di sistema casual di 20 anni non lo sapeva. Grazie!
CPRitter

Risposte:


72

Non usare

  • /usrè per dati di sola lettura condivisibili. I dati qui dovrebbero cambiare solo per motivi amministrativi (es. Installazione di nuovi pacchetti.)
  • /opt è generalmente per programmi che sono autonomi o che devono essere isolati dal resto del sistema per qualche motivo (programmi di honeypot di interazione bassa e media, per esempio).
  • /varè per "file il cui contenuto dovrebbe cambiare continuamente durante il normale funzionamento del sistema --- come registri, file di spool e file di posta elettronica temporanei". Mi piace pensarlo in questo modo: se i tuoi dati non sembrano riassunti correttamente in un elenco, generalmente non appartengono /var(tuttavia, ci sono eccezioni a questo.)

Uso

  • /homeè per le home directory degli utenti. Alcuni vedono questa directory come un'area anche per i file di gruppo. L'FHS in realtà osserva che "su sistemi di grandi dimensioni (specialmente quando le directory / home sono condivise tra molti host utilizzando NFS) è utile suddividere le home directory degli utenti. La suddivisione può essere realizzata utilizzando sottodirectory come / home / staff, / home / ospiti, / casa / studenti, ecc. "
  • /srvè una posizione accettabile e spesso preferita per i file di gruppo. In genere utilizzo questa directory per file condivisi in gruppo per il motivo menzionato nella risposta di Chris Down ; Vedo la condivisione di file di gruppo come un servizio fornito dal server.

Vedi la pagina man di hier (7) ( man hier) per maggiori informazioni sullo scopo di ogni directory descritta dall'FHS.


1
Suppongo che in alcuni casi più generici si possa usare la /srv/datadirectory per i file di dati.
Victor Yarema,

4
+1 per citare man hier. Non sapevo che esistesse.
Zach Boyd,

Grazie, informazioni e riferimenti molto utili per un nuovo utente di Linux.
Shivam,

28

Secondo me, il posto giusto è /srv/movies-enthusiast. Un "servizio" non deve essere un demone o un programma, deve solo essere un servizio che il sistema fornisce (come essere in grado di portare lì i tuoi filmati). Ecco una citazione dall'FHS :

/ srv contiene dati specifici del sito forniti da questo sistema.

Penso che il tuo utilizzo rientri in tale definizione e fornisca un servizio.


Suppongo che in alcuni casi più generici si possa usare la /srv/datadirectory per i file di dati.
Victor Yarema,

11

Il Filesystem Hierarchy Standard (FHS) specifica un layout a cui "sviluppatori di distribuzioni Unix, sviluppatori di pacchetti e implementatori di sistemi" devono aderire per non confondere il proprio spazio dei nomi.

Poiché è il tuo spazio dei nomi, dovresti scegliere qualsiasi nome che ritieni adatto. Se trovi /groups/movies-enthusiastun senso, dovresti metterlo lì. Se ti piacciono i nomi di percorsi brevi perché sono più facili da digitare, /g/movies-enthusiast(o forse /g/m-e) sarebbero adatti.

Poiché i percorsi scelti non sono definiti nell'FHS, i pacchetti di distribuzione o di terze parti non devono toccarli. Come tale, dovresti leggere l'FHS per sapere quali percorsi possono essere utilizzati dal software conforme (il sommario ti dirà la maggior parte di ciò che devi sapere).

Ad esempio, lo uso personalmente /avper il luogo in cui memorizzo il mio contenuto audiovisivo, /srcper il codice sorgente e /dataper i dati non definiti (come immagini di macchine virtuali, immagini cd, chroot, pacchetti salvati, ecc.).


Personalmente uso / data per tutti questi file, quindi / data / film per contenuti audiovisivi, / data / src per codice sorgente, / data / musica. tutto in un unico posto (gerarchico).
meduz,

Seguire o aderire agli standard di una buona idea molto spesso, anche se non sei un sviluppatore, sviluppatore di distribuzione, sviluppatore di pkg o implementatore di sistema.
Felipe Alvarez,

L'aggiunta di una nuova directory non è contro l'FHS; in realtà, direi che a volte non è necessario creare nuove directory per rimanere conformi a FHS ! L'FHS menziona specificamente che qualsiasi domanda che non debba essere coordinata tra più parti non rientra nell'ambito di applicazione di tale standard. Pertanto, cercare di soddisfare ogni eventuale necessità all'interno di una delle directory definite da FHS è destinata a creare situazioni in cui i file vengono inseriti in directory in cui non dovrebbero trovarsi.
jwatkins,

7

Non c'è nulla di sbagliato nella creazione di un nuovo mount point o directory a questo scopo dalla radice.

Soprattutto se questo è lo scopo principale di questo sistema, vorrei solo creare

/ Film-appassionato

Se esistono altri "gruppi" simili, posso o meno preferire ospitarli insieme, ad es

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

o

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

Domande da considerare: hai intenzione di dedicare un mount-point per questo scopo?

Hai considerato i softlink?

In ogni caso non ci sono regole. Se vuoi rendere un utente il custode e dare agli altri l'accesso a questo spazio del progetto, sentiti libero di ospitarlo nella home directory dell'utente. O crea uno spazio / nome / condiviso / *. Sei il tuo capo.

Oh, una cosa: qualunque cosa tu faccia, documentala. Deve entrare a far parte del ripristino del sistema, dei controlli giornalieri, dei backup, ecc. È necessario notare importanti dettagli sulla configurazione (ad es. Appartenenze a gruppi, set di autorizzazioni, parametri sintonizzabili per le prestazioni e qualsiasi altra cosa che non sia predefinita)


1

FHS è anche quello di rendere semplice l'amministratore, quindi andrei con / srv per quel motivo, sebbene non sia quello che ho fatto. Avere il senno di poi perfetto però. Uso / export / srv perché è su NAS.

Se è una casella di riepilogo, assicurati che sia setgid e appiccicoso. Assicurati anche che chi lo utilizza abbia un umask utile. Tuttavia, non usare la ruota come ho fatto nell'esempio delle modalità di accesso ai file. Non spogliare eXecute o ti verrà una sorpresa 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

1

È importante ricordare che l'FHS risolve i problemi in cui i posizionamenti dei file devono essere coordinati tra più parti come siti locali, distribuzioni, applicazioni, documentazione, ecc . ; l'FHS non cerca di stabilire regole per ogni singola situazione che potresti avere: il posizionamento locale dei file locali è un problema locale ( FHS 3.0, sezione 1.1 ).

Pertanto, puoi tecnicamente mettere la tua moviesdirectory ovunque, purché non vada contro le convenzioni FHS . Tuttavia, la tua domanda riguardava il posto più appropriato , quindi consideriamo alcune risposte comuni (ordinate dalla più preferita alla mia meno preferita, dato il tuo caso d'uso specifico):

  • /<someprefix>/<groupname>oppure /media/<volumename>/<groupname>: Onestamente non so perché questa opzione abbia una cattiva reputazione nel mondo Linux, ma chiariamolo: questo è davvero il tuo sistema, e l'FHS afferma che sei libero di creare nuove directory a livello di root finché poiché non sei in conflitto con nulla per cui esiste una semantica ben consolidata. Ad esempio, è possibile creare una directory /groupso /sharede organizzare i file in questi come meglio credi. So che alcuni amministratori preferiscono avere questi in qualche modo isolati dal resto del filesystem, quindi montano un volume distinto (cioè sotto /media/<volumename>/<groupname>). Entrambi vanno bene ed entrambi sono conformi a FHS, davvero.

  • /srv/<groupname>oppure /srv/<someprefix>/<groupname>: secondo l'FHS, /srvcontiene dati specifici del sito forniti da questo sistema . L'FHS continua spiegando che la metodologia utilizzata per nominare le sottodirectory di / srv non è specificata . Dalla mia esperienza personale, la maggior parte degli amministratori che sfruttano la /srvdirectory continua con una sottodirectory per client, per sito o per progetto, quindi inserisce le directory dei dati a quel livello. Comunque lo strutturi, il/srvè perfettamente accettabile archiviare i file da condividere tra più utenti se si può ragionevolmente considerare che la condivisione di questi file costituisce di per sé un servizio. Chiediti: "Avrebbe senso condividere eventualmente quei file tramite SMB / NFS / AFS / GIT / ...?" In tal caso, puoi ragionevolmente considerare che la tua directory è un servizio di condivisione file locale e quindi archiviarli in una sottodirectory di /srv, anche se non esiste un demone che serve effettivamente quei file ad altri sistemi.

  • /home/<groupname>oppure /home/<some-prefix>/<groupname>: FHS dice: /homeè un concetto abbastanza standard, ma è chiaramente un filesystem specifico del sito . Non è assolutamente necessario che ogni directory sotto /homesia il nome di un utente reale ed è accettabile avere sottodirectory per i gruppi, anche se è necessaria precauzione per evitare eventuali conflitti tra un gruppo e un utente. Tuttavia, ho visto questa strategia utilizzata in diverse grandi installazioni (in particolare le università) con una strategia di compartimentazione per evitare la possibilità di conflitti; per esempio, gli utenti reali avrebbero le home directory in /home/students/<studentid>, /home/teachers/<username>o /home/staff/<username>, mentre roba condiviso sarebbe ad esempio essere messo in/home/workgroup/<workgroupname>. A volte sarebbero stati anche una suddivisione del dipartimento; tuttavia, hai avuto l'idea. Ad essere sincero, personalmente non mi piace questa strategia, ma rende le cose un po 'più semplici quando /homeviene distribuita su più server (ad esempio tramite NFS), motivo per cui tende a essere preferita in organizzazioni molto grandi.


0

Personalmente opterei per / usr / share / appassionato di film o / opt / appassionato di film


0

Suggerisco di creare una directory separata come / opt / movies, impostare le autorizzazioni utente e di gruppo appropriate per loro e inoltre è possibile utilizzare il disco quotaper evitare il consumo totale del disco.


0

Questo è tanto un commento quanto una risposta (quindi per favore non darmi un voto negativo per questo!), Ma è troppo lungo per inserirsi in un commento.

Faccio due cose, entrambe per evitare il problema che stai affrontando.

1) Faccio una partizione separata di tutto lo spazio libero sul mio disco di sistema e lo etichetta con dataspace. Ecco dove vanno tutti i miei file multimediali e altri dati correnti. Viene montato automaticamente come / media / dataspace e ho inserito tutto ciò che è "dati" in una directory chiamata "dati" per separarlo da cose come file di lavoro, vms o immagini iso che non voglio eseguire regolarmente il backup.

L'uso di una partizione separata ha l'ulteriore vantaggio che, se si riempie, non compromette il mio sistema come se fosse archiviato in / o / home.

2) Ho inserito la maggior parte dei miei dati / supporti, in particolare le cose che non sto usando "in questo momento", su un'altra unità fisica (USB nella mia custodia con un notebook). Ciò semplifica il backup e il facile collegamento a un altro computer, in caso di necessità.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.