¿Cuál es el directorio más apropiado donde colocar archivos compartidos entre usuarios?


83

O: ¿ dónde puedo poner archivos que pertenecen a un grupo?

Supongamos que hay dos usuarios en un sistema Unix: Joe y Sarah . Ambos son miembros del grupo de entusiastas del cine . ¿Dónde debo poner sus archivos de película?

  • /home/{joe,sarah}/moviesno son apropiados porque esos directorios pertenecen a joe / sarah , no a su grupo;

  • /home/movies-enthusiasttampoco es apropiado, porque el entusiasta del cine es un grupo, no un usuario;

  • /var/movies-enthusiast podría ser una opción, pero no estoy seguro de que esto esté permitido por la FHS;

  • /srv/movies-enthusiast también podría ser una opción, sin embargo, las películas no son archivos requeridos por los servicios del sistema.


66
¡Votado para mencionar a FHS! Este usuario * nix y administrador casual del sistema de 20 años no lo sabía. ¡Gracias!
CPRitter

Respuestas:


72

No usar

  • /usres para datos de solo lectura compartibles. Los datos aquí solo deberían cambiar por razones administrativas (por ejemplo, la instalación de nuevos paquetes).
  • /opt generalmente es para programas que son independientes o que necesitan aislarse del resto del sistema por alguna razón (programas honeypot de interacción baja y media, por ejemplo).
  • /vares para "archivos cuyo contenido se espera que cambie continuamente durante el funcionamiento normal del sistema, como registros, archivos de cola y archivos temporales de correo electrónico". Me gusta pensar de esta manera: si sus datos no se verían correctamente resumidos en una lista, generalmente no pertenecen /var(aunque hay excepciones a esto).

Utilizar

  • /homees para directorios de inicio de usuarios. Algunos ven este directorio como un área para archivos de grupo también. El FHS en realidad señala que, "en sistemas grandes (especialmente cuando los directorios / home se comparten entre muchos hosts que usan NFS) es útil subdividir los directorios de inicio de los usuarios. La subdivisión se puede lograr usando subdirectorios como / home / staff, / home / invitados, / hogar / estudiantes, etc. "
  • /srves una ubicación aceptable y a menudo preferida para archivos de grupo. Generalmente uso este directorio para archivos compartidos en grupo por la razón mencionada en la respuesta de Chris Down ; Veo el intercambio de archivos grupales como un servicio que proporciona el servidor.

Consulte la página de manual de hier (7) ( man hier) para obtener más información sobre el propósito de cada directorio descrito por el FHS.


1
Supongo que en un caso más genérico, uno puede usar el /srv/datadirectorio para archivos de datos.
Victor Yarema

44
+1 por mencionar man hier. No sabía que existía.
Zach Boyd

Gracias, información y referencias muy útiles para un nuevo usuario de Linux.
Shivam

28

En mi opinión, el lugar correcto es /srv/movies-enthusiast. Un "servicio" no tiene que ser un demonio o un programa, solo tiene que ser un servicio que proporciona el sistema (como poder llevar sus películas allí). Aquí hay una cita de la FHS :

/ srv contiene datos específicos del sitio que sirve este sistema.

Definitivamente creo que su uso cae dentro de esa definición y proporciona un servicio.


Supongo que en un caso más genérico, uno puede usar el /srv/datadirectorio para archivos de datos.
Victor Yarema

11

El estándar de jerarquía del sistema de archivos (FHS) especifica un diseño para que los "desarrolladores de distribución de Unix, desarrolladores de paquetes e implementadores de sistemas" se adhieran para no ensuciar su espacio de nombres.

Como es su espacio de nombres, debe elegir cualquier nombre que considere adecuado. Si encuentra que /groups/movies-enthusiasttiene sentido, debe ponerlo allí. Si le gustan los nombres de ruta cortos porque son más fáciles de escribir, /g/movies-enthusiast(o quizás /g/m-e) sería adecuado.

Debido a que las rutas que elige no están definidas en el FHS, la distribución o los paquetes de terceros no deben tocarlos. Como tal, debe leer el FHS para saber qué rutas puede utilizar el software compatible (la tabla de contenido le indicará la mayor parte de lo que necesita saber).

Por ejemplo, yo personalmente uso /avpara donde almaceno mi contenido audiovisual, /srcpara el código fuente y /datapara datos indefinidos (como imágenes de máquinas virtuales, imágenes de CD, chroots, paquetes guardados, etc.).


Yo personalmente uso / data para todos esos archivos, luego / data / movies para contenido audiovisual, / data / src para código fuente, / data / music. todo en un lugar (jerárquico).
meduz

Seguir o cumplir con los estándares de una muy buena idea, incluso si no es un desarrollador, un desarrollador de distribución, un desarrollador de paquetes o un implementador del sistema.
Felipe Alvarez

Agregar un nuevo directorio no está en contra del FHS; En realidad, yo diría que a veces no se requiere crear nuevos directorios para seguir cumpliendo con FHS . El FHS menciona específicamente que cualquier pregunta que no necesite ser coordinada entre múltiples partes está fuera del alcance de ese estándar. Por lo tanto, tratar de adaptarse a cada necesidad eventual dentro de uno de los directorios definidos por FHS está obligado a crear situaciones en las que los archivos se colocan dentro de directorios donde no deberían estar.
jwatkins

7

No hay nada de malo en crear un nuevo punto de montaje o directorio para este propósito desde la raíz.

Particularmente si este es el propósito principal de este sistema, simplemente crearía

/ entusiasta del cine

Si hay otros "grupos" similares, puedo preferir o no alojarlos juntos, p. Ej.

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

o

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

Preguntas a considerar: ¿Vas a dedicar un punto de montaje para este propósito?

¿Has considerado los enlaces suaves?

En cualquier caso no hay reglas. Si desea convertir a un usuario en el custodio y dar acceso al resto a este espacio de proyecto, siéntase libre de alojarlo en el directorio de inicio del usuario. O cree un / home / shared / * nombre-espacio. Eres tu propio jefe.

Oh, una cosa: hagas lo que hagas, documentalo. Debe formar parte de la recuperación del sistema, las comprobaciones diarias, las copias de seguridad, etc. Es necesario tener en cuenta las detenciones de configuración importantes (p. Ej., Membresías de grupos, conjuntos de permisos, ajustes ajustables para el rendimiento y cualquier otra cosa que no sea predeterminada)


1

FHS también debe facilitar la administración, por lo que iría con / srv por esa razón, aunque no es lo que he hecho. Sin embargo, tenga una retrospectiva perfecta. Yo uso / export / srv porque está en NAS.

Si es un cuadro desplegable, asegúrese de que sea rígido y pegajoso. También asegúrese de que quienes lo usan tengan una umask útil. Sin embargo, no use la rueda como lo hice en el ejemplo de los modos de acceso a archivos. No despojes a eXecute o te sorprenderá 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

Es importante recordar que el FHS aborda cuestiones en las colocaciones de archivos necesitan ser coordinados entre múltiples partes, tales como sitios locales, distribuciones, aplicaciones, documentación, etc ; el FHS no intenta establecer reglas para cada situación que pueda tener: la ubicación local de los archivos locales es un problema local ( FHS 3.0, sección 1.1 ).

Por lo tanto, técnicamente puede colocar su moviesdirectorio en cualquier lugar, siempre que no vaya en contra de las convenciones de FHS . Aún así, su pregunta era sobre el lugar más apropiado , así que consideremos algunas respuestas comunes (ordenadas por el más preferido a mi menos preferido, dado su caso de uso específico):

  • /<someprefix>/<groupname>o /media/<volumename>/<groupname>: Sinceramente, no sé por qué esta opción tiene una mala reputación en el mundo Linux, pero dejemos esto claro: este es realmente su sistema, y ​​el FHS dice que no puede crear nuevos directorios en el nivel raíz mientras ya que no entra en conflicto con nada para lo cual haya una semántica bien establecida. Podría, por ejemplo, crear un directorio /groupsu /sharedorganizar archivos en ellos como mejor le parezca. Sé que algunos administradores prefieren tenerlos algo aislados del resto del sistema de archivos, por lo que montan un volumen distinto (es decir, debajo /media/<volumename>/<groupname>). Ambos están bien y ambos cumplen con FHS, de verdad.

  • /srv/<groupname>o /srv/<someprefix>/<groupname>: De acuerdo con la FHS, /srvcontiene datos específicos del sitio que son servidos por este sistema . El FHS luego continúa explicando que la metodología utilizada para nombrar subdirectorios de / srv no está especificada . Desde mi experiencia personal, la mayoría de los administradores que explotan el /srvdirectorio continúa con un subdirectorio por cliente, por sitio o por proyecto, y luego ubican los directorios de datos en ese nivel. Como sea que lo estructura, el/srves perfectamente aceptable almacenar archivos para compartirlos entre varios usuarios si puede considerar razonablemente que compartir estos archivos constituye un servicio en sí mismo. Pregúntese: "¿Tendría sentido compartir esos archivos a través de SMB / NFS / AFS / GIT / ...?" Si es así, puede considerar razonablemente que su directorio es un servicio local de intercambio de archivos y, por lo tanto, almacenarlos dentro de un subdirectorio de /srv, a pesar de que no hay un demonio que realmente sirva esos archivos a otros sistemas.

  • /home/<groupname>o /home/<some-prefix>/<groupname>: El FHS dice: /homees un concepto bastante estándar, pero claramente es un sistema de archivos específico del sitio . No hay absolutamente ningún requisito de que cada directorio /homesea ​​el nombre de un usuario real, y es aceptable tener subdirectorios para grupos, aunque se requiere precaución para evitar eventuales conflictos entre un grupo y un usuario. Aún así, he visto esta estrategia utilizada en varias configuraciones grandes (especialmente universidades) con alguna estrategia de compartimentación para evitar la posibilidad de conflicto; por ejemplo, los usuarios reales tendrían sus directorios de inicio en /home/students/<studentid>, /home/teachers/<username>o /home/staff/<username>, mientras que las cosas compartidas se pondrían en/home/workgroup/<workgroupname>. En algún momento también serían una subdivisión del departamento; Aún así, te haces una idea. Para ser honesto, personalmente no me gusta esta estrategia, pero hace las cosas un poco más fáciles cuando /homese distribuye entre varios servidores (por ejemplo, a través de NFS), por lo que suele preferirse en organizaciones muy grandes.


0

Yo personalmente optaría por / usr / share / movies-entusiasta o / opt / movies-entusiasta


0

Sugiero crear un directorio separado como / opt / movies, configurar los permisos de usuario y grupo apropiados para ellos y también puede usar el disco quotapara evitar el consumo total del disco.


0

Esto es tanto un comentario como una respuesta (¡así que por favor no me denigren por ello!), Pero es demasiado largo para caber en un comentario.

Hago dos cosas, las cuales evitan el problema que estás enfrentando.

1) Hago una partición separada de todo el espacio libre en el disco de mi sistema y lo etiqueto como espacio de datos. Ahí es donde van todos mis archivos multimedia actuales y otros datos. Se monta automáticamente como / media / dataspace y pongo cualquier cosa que sea "datos" en un directorio llamado "datos" para separarlo de cosas como archivos de trabajo, vms o imágenes iso de las que no quiero hacer una copia de seguridad rutinaria.

El uso de una partición separada tiene el beneficio adicional de que, si se llena, no compromete mi sistema como lo haría si se almacenara en / o / home.

2) Pongo la mayoría de mis datos / medios, especialmente cosas que no estoy usando "en este momento", en otra unidad física (USB en mi caso con una computadora portátil). Eso facilita la copia de seguridad y la conexión a otra computadora, si surge la necesidad.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.