Где мне хранить личные файлы, сохраняя при этом короткий путь?

Я был пользователем Windows и новичок в среде Linux. Я только что установил Ubuntu два дня назад, и меня смущают такие каталоги, как lib , и т. Д. , var , tmp , mnt и т. д. У меня несколько вопросов.

  1. Какова цель этих каталогов ?

В настоящее время я храню файлы своего проекта в /home/shiftar/Public/Projects , но это звучит слишком долго …

  1. Есть ли способ сократить путь к файлу?

  2. Хорошо ли хранить мои файлы проекта в вышеупомянутом каталоге? Или есть какая-то условность? Например, Личные файлы должны храниться там , а Программное обеспечение лучше хранить там. .


Какова цель этих каталогов?

  • lib: модули ядра и эти образы разделяемых библиотек (Cпрограммирование библиотека кода), необходимые для загрузки системы и выполнения команд в корневой файловой системе.
  • etc: файлы конфигурации
  • var: файлы, в которые система записывает данные во время itsoperation
  • tmp: временные файлы
  • mnt: временные точки монтирования для монтирования устройств хранения

Есть ли способ сократить путь к файлу?

Вместо вызова /home/shiftar вы можете использовать ~/

Хорошо ли хранить файлы моего проекта в вышеупомянутом каталоге? Или есть какая-то условность? например, личные файлы должны храниться там … Программное обеспечение лучше хранить там … вот так.

/home/shiftar — это ваш домашний каталог и предназначен для вашего личного использования. В нем вы можете хранить свои личные каталоги, файлы в любых каталогах. ~/Documents может быть хорошим местом для проектов. ~/Public обычно доступен всем в сети. Поэтому, если вы не хотите делиться, поместите свои файлы в другой каталог.


7

Все предыдущие ответы хороши. Я бы просто добавил несколько моментов.

Позже (не сейчас!), Когда вам станет удобнее работать с Linux, вы можете создать отдельный раздел для данных — особенно если у вас большие файлы люблю много музыки или видео. Если вы добавите слишком много из них в свой домашний раздел, вы можете заполнить его, и тогда другие вещи перестанут работать, потому что они не смогут получить необходимое дисковое пространство.

Если вы заполните данные раздел, он ни на что не влияет.

Кроме того, если вы хотите сделать резервную копию своих данных, вы можете просто сделать это в любое время. В/home есть вещи, которые постоянно меняются, поэтому обычно вы не можете «заморозить» его, чтобы получить копию, в которой все синхронизировано. С отдельным разделом данных вы можете в любой момент сделать идеальную резервную копию.

Что касается путей, если вы работаете из командной строки, вы можете определить псевдоним bash (в ~/.bashrc или в ~/.bash_aliases ), чтобы сократить любой путь или даже перейти в каталог.

alias proj = 'cd/home/shift/Public/Projects '

, а затем просто введите proj , чтобы переключиться в этот каталог.

Когда вы освоитесь с bash , вы можете сделать еще больше с помощью функций. Но мы оставим это на потом.

Другой подход — добавить строку в ~/.bashrc как

  export PROJ = '/home/shift/Public/Projects'  

Это сделает переменную среды PROJ доступной для используйте, и вы можете делать такие вещи, как:

  ls "$ {PROJ}" cd "$ {PROJ}" cp mynewfile "$ {PROJ}"  

Он также будет работать без export перед ним, но тогда он будет определен только на верхнем уровне вашей оболочки, а не в какой-либо подоболочке, которую вы могли бы запустить оттуда.

В приведенном выше примере кавычки или фигурные скобки строго не нужны, но они защищают вас от таких вещей, как встроенные пробелы, а также позволяют использовать PROJ как часть слова, например $ {PROJ} ect .

Улучшите этот ответ
отредактировано 18 декабря 2015 в 11:39 iv>
17 дек. ’15 в 0:07
  • Вау, похоже, хороший подход. Спасибо, Джо. Кстати, я думаю, что время жизни alias ' только до перезапуска, не так ли? Должен ли я устанавливать псевдоним при каждом запуске или есть ли способ установить псевдоним навсегда? — theapache64 17 дек. ’15 в 2:55
  • 1
    Правильно. Как правило, вы должны добавить определение псевдонима в .bashrc в свой домашний каталог или, если он настроен для чтения, вы можете добавить его в .bash_aliases в вашем домашнем каталоге. Псевдоним работает только в начале командной строки, но функция будет работать где угодно. Их просто немного сложнее использовать для чего-то вроде этого. — Джо 18 дек. ’15 в 11:18
добавить комментарий |

Все предыдущие ответы хороши. Я бы просто добавил несколько моментов.

Позже (не сейчас!), Когда вам станет удобнее работать с Linux, вы можете создать отдельный раздел для данных — особенно если у вас большие файлы люблю много музыки или видео. Если вы добавите слишком много из них в свой домашний раздел, вы можете заполнить его, и тогда другие вещи перестанут работать, потому что они не смогут получить необходимое дисковое пространство.

Если вы заполните данные раздел, он ни на что не влияет.

Кроме того, если вы хотите сделать резервную копию своих данных, вы можете просто сделать это в любое время. В/home есть вещи, которые постоянно меняются, поэтому обычно вы не можете «заморозить» его, чтобы получить копию, в которой все синхронизировано. С отдельным разделом данных вы можете сделать идеальную резервную копию в любое время.

Что касается путей, если вы работаете из командной строки, вы можете определить псевдоним bash (в ~/.bashrc или в ~/.bash_aliases ), чтобы сократить любой путь или даже перейти в каталог.

alias proj = 'cd/home/Shiftar/Public/Projects'

, а затем просто введите proj , чтобы переключиться в этот каталог.

Когда вы освоитесь с bash, вы сможете делать еще больше с помощью функций. Но мы оставим это на потом.

Другой подход — добавить строку в ~/.bashrc как

  export PROJ = '/home/shift/Public/Projects'  

Это сделает переменную среды PROJ доступной для используйте, и вы можете делать такие вещи, как:

  ls "$ {PROJ}" cd "$ {PROJ}" cp mynewfile "$ {PROJ}"  

Он также будет работать без export перед ним, но тогда он будет определен только на верхнем уровне вашей оболочки, а не в какой-либо подоболочке, которую вы могли бы запустить оттуда.

В приведенном выше примере кавычки или фигурные скобки строго не нужны, но они защищают вас от таких вещей, как встроенные пробелы, а также позволяют использовать PROJ как часть слова — например, $ {PROJ} ect .


1

Ubuntu похожа на вашу обычную Windows. Только это другая операционная система. Я не уверен, какую версию Ubuntu вы используете. Независимо от этого, все среды Linux, включая Ubuntu, предлагают очень удобный графический интерфейс, такой же, как и у окон, который не должен быть трудным для понимания тем, кто привык к окнам. Если вам не нравится терминал, вы всегда можете просто используйте графический интерфейс и получайте доступ к своим файлам и папкам оттуда.

Что касается того, где вы должны их хранить, это опять же ваш собственный рабочий стол. Это просто другая система. Это точно так же, как окна. Просто сохраните их там, где вы бы хранили их в окнах.

Путь к файлу можно сократить. В настоящее время вы находитесь в проектах. Вы можете двигаться вверх по дереву и хранить файлы, скажем, в «домашней» папке. Это все зависит от вас. Но, как правило, рекомендуется хранить личные файлы внутри вашего имени пользователя, в данном случае это «шифар».

Знак «/» указывает на корневой каталог. Он содержит «дом», в котором есть «Шифар» и так далее. Они предназначены исключительно для хранения и систематизации данных. Каталог — это то, что вы бы назвали папкой в ​​ваших окнах.

Надеюсь, это поможет.

Улучшите этот ответ
ответил 9 декабря 2015 в 10:50
  • Я определил свой Версия ubuntu в тегах — 14.04. 🙂 — theapache64 09 дек. ’15 в 11:01
  • 9
    Если бы я был новичком в Ubuntu, читая этот ответ, я был бы все еще сбит с толку, но на более высоком уровне … : -/- Byte Commander ♦ 9 декабря ’15 в 13:08
  • 1
    Да, я не понимаю, почему за это проголосовали, это очень сбивает с толку. И объяснив, что каталоги такие же, как папки в windows? Я думаю, этот человек знает это …. — Роб 9 дек., 14:10
  • Я все еще пытаюсь понять, почему «разные системы» и «точно такие же» не исключают друг друга. Вы действительно предполагаете, что управление файлами Windows и управление файлами Linux в точности одинаковы? — jdk1.0 13 мар. ’20 в 18:54
добавить комментарий |

Ubuntu похожа на вашу обычную Windows. Только это другая операционная система. Я не уверен, какую версию Ubuntu вы используете. Независимо от этого, все среды Linux, включая Ubuntu, предлагают очень удобный графический интерфейс, такой же, как и у окон, который не должен быть трудным для понимания тем, кто привык к окнам. Если вам не нравится терминал, вы всегда можете просто используйте графический интерфейс и получайте доступ к своим файлам и папкам оттуда.

Что касается того, где вы должны их хранить, это опять же ваш собственный рабочий стол. Это просто другая система. Это точно так же, как окна. Просто сохраните их там, где вы бы хранили их в окнах.

Путь к файлу можно сократить. В настоящее время вы находитесь в проектах. Вы можете двигаться вверх по дереву и хранить файлы, скажем, в «домашней» папке. Это все зависит от вас. Но, как правило, рекомендуется хранить личные файлы внутри вашего имени пользователя, в данном случае это «шифар».

Знак «/» указывает на корневой каталог. Он содержит «дом», в котором есть «Шифар» и так далее. Они предназначены исключительно для хранения и систематизации данных. Каталог — это то, что вы бы назвали папкой в ​​ваших окнах.

Надеюсь, это поможет.


1

Файлы личные, как у вас не хотите, чтобы другие люди смотрели на них, ваш домашний каталог — хороший выбор, но вы также должны понимать права доступа к файлам — не непосредственно в отношении вашего вопроса, но относящиеся к делу. Вы должны установить свои разрешения как можно более ограничительными, насколько это необходимо. Кроме того, если вас беспокоит конфиденциальность и безопасность, Ubuntu предоставляет способ шифрования только вашего домашнего каталога, чтобы вы могли сохранить свои конфиденциальные данные в безопасности. Это несколько технический (https://help.ubuntu.com/community/EncryptedHome).

Моя обычная практика — шифрование/дешифрование файлов конфиденциальных данных один за другим с помощью gpg — https: //help.ubuntu.com/community/GnuPrivacyGuardHowto. Это тоже технический характер, но он действительно важен и стоит ваших усилий.

Я никогда не чувствовал особого принуждения использовать подкаталоги в моем домашнем каталоге, который устанавливает Ubuntu. Вы можете организовать свои данные по своему усмотрению.

Улучшите этот ответ
ответил 9 декабря 2015 в 18:43
добавить комментарий |

Файлы являются личными, так как вы не хотите, чтобы другие люди смотрели на них, ваш домашний каталог — хороший выбор, но вы должны также понимайте права доступа к файлам — не прямо по вашему вопросу, но актуально. Вы должны установить свои разрешения как можно более ограничительными, насколько это необходимо. Кроме того, если вас беспокоит конфиденциальность и безопасность, Ubuntu предоставляет способ шифрования только вашего домашнего каталога, чтобы вы могли сохранить свои конфиденциальные данные в безопасности. Это несколько технический (https://help.ubuntu.com/community/EncryptedHome).

Моя обычная практика — шифрование/дешифрование файлов конфиденциальных данных один за другим с помощью gpg — https: //help.ubuntu.com/community/GnuPrivacyGuardHowto. Это тоже технический характер, но он действительно важен и стоит ваших усилий.

Я никогда не чувствовал особого принуждения использовать подкаталоги в моем домашнем каталоге, который устанавливает Ubuntu. Вы можете организовать свои данные по своему усмотрению.



Какой каталог лучше всего подходит для размещения файлов, совместно используемых пользователями?

Или: где я могу поместить файлы, принадлежащие группе?

Предположим, в системе Unix есть два пользователя: joe и Сара . Они оба являются членами группы любителей кино .. Куда мне поместить их файлы фильмов?

  • /home/{joe, sarah}/movies не подходят, потому что эти каталоги принадлежат joe / sarah , а не их группе;

  • /home/movies-энтузиаст тоже не подходит, потому что movies-энтузиаст — это группа, а не пользователь;

  • /var/movies-entiast может быть вариантом, но я не уверен, что это разрешено FHS;

  • /srv/movies-entiast тоже может быть вариантом, однако фильмы не являются файлами, которые требуются системным службам.


Не использовать

  • /usr предназначен для данных, доступных только для чтения. Данные здесь должны изменяться только в административных целях (например, при установке новых пакетов).
  • /opt обычно предназначен для программ, которые являются автономными или должны быть по какой-то причине изолирован от остальной системы (например, от программ-приманок с низким и средним уровнем взаимодействия).
  • /var предназначен для » файлы, содержимое которых, как ожидается, будет постоянно меняться во время нормальной работы системы — например, журналы, файлы буферизации и временные файлы электронной почты ». Мне нравится думать об этом так: если бы ваши данные не были ‘ не выглядит правильно в обобщенном виде в списке, обычно он не входит в /var (хотя есть исключения из этого.)

Использовать

  • /home для домашних каталогов пользователей. Некоторые считают, что этот каталог также является областью для групповых файлов. FHS на самом деле отмечает, что «в больших системах (особенно когда каталоги/home совместно используются множеством хостов с помощью NFS) полезно разделить домашние каталоги пользователей. Разделение может быть выполнено с помощью подкаталогов, таких как/home /Staff,/home/guest,/home/student и т. д.
  • /srv — приемлемое и часто предпочтительное место для группы файлы. Я обычно использую этот каталог для файлов, совместно используемых группой, по причине, упомянутой в ответе Криса Дауна; Я рассматриваю групповое совместное использование файлов как услугу, которую предоставляет сервер.

Подробнее см. Справочную страницу hier (7) ( man hier ) информация о назначении каждого каталога, описанного FHS.


33

На мой взгляд, правильное место — это /srv/movies-entiast . «Сервис» не обязательно должен быть демоном или программой, это просто должен быть сервис, который предоставляет система (например, возможность получать туда ваши фильмы). Вот цитата из FHS:

/srv содержит данные для конкретного сайта, которые обслуживаются этой системой.

Я определенно думаю, что ваше использование подпадает под это определение, и предоставляет услугу.

Улучшите этот ответ
ответил 31 марта 2013, 16:54
  • Я полагаю, что в более общем случае можно использовать каталог /srv/data для файлов данных. — Виктор Ярема 01 нояб., 17:37
добавить комментарий |

На мой взгляд, правильное место — это /srv/movies-entiast . «Сервис» не обязательно должен быть демоном или программой, это просто должен быть сервис, который предоставляет система (например, возможность получать туда ваши фильмы). Вот цитата из FHS:

/srv содержит данные для конкретного сайта, которые обслуживаются этой системой.

Я определенно думаю, что ваше использование подпадает под это определение, и предоставляет услугу.


11

Стандарт иерархии файловой системы (FHS) определяет макет, которого должны придерживаться «разработчики дистрибутива Unix, разработчики пакетов и разработчики систем», чтобы не создавать беспорядок в ваших пространство имен.

Поскольку это ваше пространство имен, вам следует выбрать любое подходящее имя. Если вы считаете, что /groups/movies-энтузиаст имеет смысл, вы должны поместить его туда. Если вам нравятся короткие имена путей, потому что их легче набирать, подойдет /g/movies-entiast (или, возможно, /g/me ).

Поскольку выбранные вами пути не определены в FHS, дистрибутив или сторонние пакеты не должны касаться их. Таким образом, вам следует прочитать FHS, чтобы узнать, какие пути могут использоваться совместимым программным обеспечением (оглавление расскажет вам большую часть того, что вам нужно знать).

Например, я лично использую /av для того, где я храню аудиовизуальный контент, /src для исходного кода и /data для неопределенных данных (например, образы виртуальных машин, изображения компакт-дисков, chroot, сохраненные пакеты и т. д.).

Улучшите этот ответ
ответил 01 апреля 2013 в 8:16
  • Я лично использую/data для всех таких файлов, затем/data/movies для аудиовизуального контента,/data/src для исходного кода,/data/music. все в одном (иерархическом) месте. — meduz 03 апр. ’13 в 20:40
  • Следование или соблюдение стандартов очень часто является хорошей идеей, даже если вы не являетесь разработчиком, разработчиком дистрибутива, разработчиком pkg или разработчиком системы. — Фелипе Альварес, 26 июня 2016, 23:28
  • Добавление нового каталога не противоречит FHS; на самом деле, я бы сказал, что иногда требуется не создавать новые каталоги, чтобы оставаться совместимыми с FHS ! FHS особо отмечает, что любой вопрос, который не требует согласования между несколькими сторонами, выходит за рамки этого стандарта. Следовательно, попытка уместить любую возможную потребность в одном из каталогов, определенных FHS, неизбежно приведет к созданию ситуаций, когда файлы помещаются в каталоги, где их не должно быть. — jwatkins 26 сен 2018 в 21:20
добавить комментарий |

Стандарт иерархии файловой системы (FHS) определяет схему, которую должны соблюдать «разработчики дистрибутива Unix, разработчики пакетов и разработчики систем». чтобы не запутать ваше пространство имен.

Поскольку это ваше пространство имен, вам следует выбрать любое подходящее имя. Если вы считаете, что /groups/movies-энтузиаст имеет смысл, вы должны поместить его туда. Если вам нравятся короткие имена путей, потому что их легче набирать, подойдет /g/movies-entiast (или, возможно, /g/me ).

Поскольку выбранные вами пути не определены в FHS, дистрибутив или сторонние пакеты не должны касаться их. Таким образом, вам следует прочитать FHS, чтобы узнать, какие пути могут использоваться совместимым программным обеспечением (оглавление расскажет вам большую часть того, что вам нужно знать).

Например, я лично использую /av для того, где я храню аудиовизуальный контент, /src для исходного кода и /data для неопределенных данных (например, образы виртуальных машин, образы компакт-дисков, chroot, сохраненные пакеты и т. д.).


7

Нет ничего плохого в том, чтобы создать новую точку монтирования или каталог для этой цели из корня.

В частности, если это основная цель данной системы, Я бы просто создал

/movies-энтузиаст

Если есть другие подобные «группы», я могу или не могу предпочесть размещать их вместе, например

 /data/movies-entusiast/data/next-groupetc  

или

 /поделиться/фильмы-энтузиаст/поделиться/следующий-я  deaetc  

Вопросы для обсуждения: собираетесь ли вы выделить для этой цели точку монтирования?

Рассматривали ли вы программные ссылки?

В любом случае правил нет. Если вы хотите сделать одного пользователя хранителем и предоставить остальным доступ к этому пространству проекта, не стесняйтесь разместить его в домашнем каталоге пользователя. Или создайте пространство имен/home/shared/*. Вы сами себе босс.

О, одно: что бы вы ни делали, обязательно задокументируйте это. Он должен стать частью восстановления системы, ежедневных проверок, резервного копирования и т. Д. Следует отметить важные ограничения конфигурации (например, членство в группах, наборы разрешений, параметры fs для производительности и все остальное, что не является значением по умолчанию)

Улучшить этот ответ
4 апр. ’13 в 8:09
добавить комментарий |

Нет ничего плохого в создании новой точки монтирования или каталога для этой цели из корня.

В частности, если это основная цель этой системы, я бы просто создал

/movies-энтузиаст

Если есть другие подобные «группы», я могу или могу не предпочитаю размещать их вместе, например

 /data/movies-entusiast/data/next-groupetc  

или

 /share/movies-entiast/share/next-ideaetc  

Вопросы для рассмотрения: собираетесь ли вы выделить точку монтирования для этого?

Софтлинки учитывали?

В любом случае правил нет. Если вы хотите сделать одного пользователя хранителем и предоставить остальным доступ к этому пространству проекта, не стесняйтесь разместить его в домашнем каталоге пользователя. Или создайте пространство имен/home/shared/*. Вы сами себе босс.

О, одно: что бы вы ни делали, обязательно задокументируйте это. Он должен стать частью восстановления системы, ежедневных проверок, резервного копирования и т. Д. Следует отметить важные ограничения конфигурации (например, членство в группах, наборы разрешений, параметры fs для производительности и все остальное, что не является значением по умолчанию)


3

Важно помнить, что FHS решает проблемы, при которых размещение файлов необходимо координировать между несколькими сторонами, такими как локальные сайты, дистрибутивы, приложения, документация и т. д. ; FHS не пытается устанавливать правила для каждой отдельной ситуации, которая может у вас возникнуть: локальное размещение локальных файлов — это локальная проблема (FHS 3.0, раздел 1.1).

Таким образом, вы можете технически поместить каталог movies где угодно, , если это не противоречит соглашениям FHS . Тем не менее, ваш вопрос касался наиболее подходящего места, поэтому давайте рассмотрим несколько общих ответов (отсортированных от наиболее предпочтительного до менее предпочтительного, с учетом вашего конкретного случая использования):

  • // или /media// : Честно говоря, я не знаю, почему эта опция имеет плохую репутацию в мире Linux, но давайте проясним это: это действительно ваша система, и FHS говорит, что вы свободны от создание новых каталогов на корневом уровне, если вы не конфликтуете ни с чем, для чего существует устоявшаяся семантика. Например, вы можете создать каталог /groups или /shared и организовать в них файлы по своему усмотрению. Я знаю, что некоторые администраторы предпочитают иметь их в некоторой степени изолированными от остальной файловой системы, поэтому они монтируют отдельный том (например, в /media// ). Оба в порядке, и оба действительно соответствуют требованиям FHS.

  • /srv/ или /srv// : согласно FHS, /srv содержит данные для конкретного сайта, которые обслуживаются этой системой . Затем FHS продолжает объяснять, что методология, используемая для именования подкаталогов/srv, не указана . По моему личному опыту, большинство администраторов, использующих каталог /srv , используют подкаталог для каждого клиента, сайта или проекта, а затем помещают каталоги данных на этом уровне. Как бы вы его ни структурировали, /srv вполне приемлем для хранения файлов, которые будут совместно использоваться несколькими пользователями, если вы можете разумно считать, что совместное использование этих файлов само по себе представляет собой услугу. Спросите себя: «Имеет ли смысл в конечном итоге поделиться этими файлами через SMB/NFS/AFS/GIT/…?» Если это так, тогда вы можете разумно считать, что ваш каталог является локальной службой обмена файлами, и, таким образом, хранить их в подкаталоге /srv , даже если нет демона, который фактически обслуживает эти файлы для другие системы.

  • /home/ или /home/ / : FHS говорит: /home — это довольно стандартная концепция, но это явно файловая система, специфичная для сайта . Абсолютно не требуется, чтобы каждый каталог в /home был именем реального пользователя, и допустимо иметь подкаталоги для групп, хотя необходимы меры предосторожности, чтобы избежать возможных конфликтов между группой и Пользователь. Тем не менее, я видел, как эта стратегия использовалась в нескольких крупных организациях (особенно в университетах) с некоторой стратегией сравнения, чтобы избежать возможности конфликта; например, у реальных пользователей свои домашние каталоги в /home/students/ , /home/teachers/ или /home/staff/ , а общие данные, например, будут помещены в /home/workgroup/ . Иногда они также были бы подразделением отдела; тем не менее, вы поняли. Честно говоря, мне лично не нравится эта стратегия, но она немного упрощает ситуацию, когда /home распределяется между несколькими серверами (например, через NFS), поэтому она имеет тенденцию предпочтительнее в очень больших организациях.

Улучшите этот ответ
ответил 26 сен ’18 в 21:08
добавить комментарий |

Важно помнить, что FHS решает проблемы, при которых размещение файлов необходимо координировать между несколькими сторонами, такими как локальные сайты, дистрибутивы, приложения, документация и т. д. ; FHS не пытается устанавливать правила для каждой отдельной ситуации, которая может у вас возникнуть: локальное размещение локальных файлов — это локальная проблема (FHS 3.0, раздел 1.1).

Таким образом, технически вы можете поместить каталог movies где угодно, , если это не противоречит соглашениям FHS . Тем не менее, ваш вопрос касался наиболее подходящего места, поэтому давайте рассмотрим несколько общих ответов (отсортированных от наиболее предпочтительного до менее предпочтительного, с учетом вашего конкретного случая использования):

  • // или /media// : Честно говоря, я не знаю, почему эта опция имеет плохую репутацию в мире Linux, но давайте проясним это: это действительно ваша система, и FHS говорит, что вы свободны от создание новых каталогов на корневом уровне, если вы не конфликтуете ни с чем, для чего существует устоявшаяся семантика. Например, вы можете создать каталог /groups или /shared и организовать в них файлы по своему усмотрению. Я знаю, что некоторые администраторы предпочитают иметь их в некоторой степени изолированными от остальной файловой системы, поэтому они монтируют отдельный том (например, в /media// ). Оба в порядке, и оба действительно соответствуют требованиям FHS.

  • /srv/ или /srv// : согласно FHS, /srv содержит данные для конкретного сайта, которые обслуживаются этой системой . Затем FHS продолжает объяснять, что методология, используемая для именования подкаталогов/srv, не указана . По моему личному опыту, большинство администраторов, использующих каталог /srv , используют подкаталог для каждого клиента, сайта или проекта, а затем помещают каталоги данных на этом уровне. Как бы вы его ни структурировали, /srv вполне приемлем для хранения файлов, которые будут совместно использоваться несколькими пользователями, если вы можете разумно считать, что совместное использование этих файлов само по себе представляет собой услугу. Спросите себя: «Имеет ли смысл в конечном итоге поделиться этими файлами через SMB/NFS/AFS/GIT/…?» Если это так, тогда вы можете разумно считать, что ваш каталог является локальной службой обмена файлами, и, таким образом, хранить их в подкаталоге /srv , даже если нет демона, который фактически обслуживает эти файлы для другие системы.

  • /home/ или /home/ / : FHS говорит: /home — это довольно стандартная концепция, но это явно файловая система, специфичная для сайта . Абсолютно не требуется, чтобы каждый каталог в /home был именем реального пользователя, и допустимо иметь подкаталоги для групп, хотя необходимы меры предосторожности, чтобы избежать возможных конфликтов между группой и Пользователь. Тем не менее, я видел, как эта стратегия использовалась в нескольких крупных организациях (особенно в университетах) с некоторой стратегией сравнения, чтобы избежать возможности конфликта; например, у реальных пользователей свои домашние каталоги в /home/students/ , /home/teachers/ или /home/staff/ , а общие данные, например, будут помещены в /home/workgroup/ . Иногда они также были бы подразделением отдела; тем не менее, вы поняли. Честно говоря, мне лично не нравится эта стратегия, но она немного упрощает ситуацию, когда /home распределяется между несколькими серверами (например, через NFS), поэтому она имеет тенденцию предпочтительнее в очень больших организациях.


1

FHS также упрощает администрирование, поэтому я бы выбрал/srv по этой причине, хотя это не то, что я сделал. Но имейте прекрасную возможность оглянуться назад. Я использую/export/srv, потому что он находится на NAS.

Если это выпадающий список, убедитесь, что он имеет как setgid, так и липкий. Также убедитесь, что у тех, кто его использует, есть полезная маска. Однако не используйте wheel, как я сделал в примере с режимами доступа к файлам. Не удаляйте eXecute, иначе вас ждет O_o сюрприз.

  bash-3.2 $ mkdir moviesbash-3.2 $ sudo chmod 03771 moviesPassword: bash-3.2 $ ls -ld  фильмы/drwxrws - t 2 andrewb wheel 68 4 апр 17:09 фильмы/bash-3.2 $ umask 026bash-3.2 $ touch movies/junkbash-3. 2 $ ls -l фильмы/всего 0-rw-r ----- 1 колесо Эндрюба 0 4 апр 17:09 мусор  

Улучшите этот ответ
4 апр. ’13 в 9:21
добавить комментарий |

FHS также упрощает администрирование, поэтому я бы выбрал/srv по этой причине, хотя это не то, что я сделал. Но имейте прекрасную возможность оглянуться назад. Я использую/export/srv, потому что он находится на NAS.

Если это выпадающий список, убедитесь, что он имеет как setgid, так и липкий. Также убедитесь, что у тех, кто его использует, есть полезная маска. Однако не используйте wheel, как я сделал в примере с режимами доступа к файлам. Не удаляйте eXecute, иначе вас ждет O_o сюрприз.

  bash-3.2 $ mkdir moviesbash-3.2 $ sudo chmod 03771 moviesPassword: bash-3.2 $ ls -ld  movies/drwxrws - t 2 andrewb wheel 68 4 апреля 17:09 movies/bash-3.2 $ umask 026bash-3.2 $ touch movies/junkbash-3.2 $ ls -l movies/total 0-rw-r ----- 1  колесо Эндрюба 0 4 апреля 17:09 мусор  

0

Я лично выбрал бы/usr/share/movies-entiast или/opt/movies-entiast

Улучшите этот ответ
ответил 31 марта ’13 в 18:13
добавить комментарий |

Я бы лично выбрал/usr/share/movies-энтузиаст или/opt/movies-энтузиаст


0

Предлагаю создать отдельный каталог, например/opt/movies, установить соответствующие права пользователя и группы для них, а также вы можете использовать диск quota , чтобы избежать полного использования диска ..

Улучшите этот ответ
ответил 01 апр. ’13 в 8:44
добавить комментарий |

Я предлагаю создать отдельный каталог, например/opt/movies, установить для них соответствующие права пользователей и групп, а также вы можете использовать диск quota , чтобы избежать полного использования диска..


0

Это такой же комментарий, как и ответ (так что, пожалуйста, не понижайте меня за это!), но он слишком длинный, чтобы уместиться в комментарии.

Я делаю две вещи, обе из которых позволяют избежать проблемы, с которой вы столкнулись .

1) Я делаю отдельный раздел всего свободного пространства на моем системном диске и маркирую его как пространство данных. Вот куда попадают все мои текущие медиафайлы и другие данные. Он автоматически монтируется как/media/dataspace, и я помещаю все, что является «данными», в каталог с именем «data», чтобы отделить их от таких вещей, как рабочие файлы, виртуальные машины или ISO-образы, которые я не хочу регулярно резервировать.

Использование отдельного раздела имеет дополнительное преимущество, заключающееся в том, что при его заполнении моя система не подвергается риску, как если бы он хранился в/или/home.

2) Я помещаю большую часть своих данных/носителей, особенно то, что не использую «прямо сейчас», на другой физический диск (USB в моем случае с ноутбуком). Это упрощает резервное копирование и упрощает подключение к другому компьютеру в случае необходимости.

Улучшите этот ответ
ответил 5 апр. ’13 в 22:23
добавить комментарий |

Это такой же комментарий, как и ответ (поэтому, пожалуйста, не понижайте меня за это!), но это слишком долго, чтобы вписывается в комментарий.

Я делаю две вещи, обе из которых позволяют избежать проблемы, с которой вы столкнулись.

1) Я делаю отдельный раздел для всех бесплатных пространство на моем системном диске и обозначьте его как пространство данных. Вот куда попадают все мои текущие медиафайлы и другие данные. Он автоматически монтируется как/media/dataspace, и я помещаю все, что является «данными», в каталог с именем «data», чтобы отделить их от таких вещей, как рабочие файлы, виртуальные машины или ISO-образы, которые я не хочу регулярно резервировать.

Использование отдельного раздела имеет дополнительное преимущество, заключающееся в том, что при его заполнении моя система не подвергается риску, как если бы он хранился в/или/home.

2) Я помещаю большую часть своих данных/носителей, особенно то, что не использую «прямо сейчас», на другой физический диск (USB в моем случае с ноутбуком). Это упрощает резервное копирование и упрощает подключение к другому компьютеру в случае необходимости.

Оцените статью
logicle.ru
Добавить комментарий