Наши пользователи часто запрашивают общее дисковое пространство для использования группой пользователей для обмена или работы с некоторыми файлами. Чтобы иметь возможность также использовать управление квотами, мы создаем новую учетную запись пользователя (которая контролируется квотами) и даем доступ к дому этого пользователя из группы пользователей. Мне вообще такой подход не нравится. Как мы можем создать гибкое решение, которое позволит нам предоставлять определенное количество места некоторым пользователям по запросу с включенным контролем квот?
(Одно из решений, о котором я думаю, - это интенсивное использование LVM для создания нового раздела (lv) для каждой группы, но я не уверен, как он будет масштабироваться.)
Я фанат «софт-квот». Жесткие квоты и ограничения на диск могут ухудшить работоспособность, если, скажем, им действительно понадобится 30 ГБ пространства в день для выполнения какого-то большого проекта. В моей компании есть очень простой сценарий, который захватывает всех пользователей из AD, SMB монтирует их домашние каталоги и производит расчет размера. К этому скрипту прилагается стандартный лимит квоты (для нас 2G), а также список исключений.
Если они нарушают квоту, они вместе с руководством получают уведомление по электронной почте с указанием размера их каталога, а также их квоты.
Не работает для каждой среды или любого масштаба, но при жестком ограничении квоты значительно снижает производительность.
По моему опыту, главными проблемами являются:
Мы определили «проектные» каталоги и используем квоты проекта XFS для обеспечения соблюдения квот. Мы применяем как мягкие, так и жесткие квоты, и у нас есть сценарии для оповещения пользователей по электронной почте о достижении их мягких квот. Это безумно легко сделать с XFS.
Разрешения всегда кажутся огромной проблемой. Теперь мы используем ACL, чтобы гарантировать, что все члены группы имеют доступ ко всем создаваемым файлам, но проблемы возникают, когда мы делимся каталогами с компьютерами, которые не понимают эти ACL, или когда программы создают файлы с явно узкими разрешениями. В итоге мы получаем подкаталоги, в которых нет правильных списков управления доступом, а затем пользователи жалуются, что не могут редактировать некоторые элементы в своей групповой папке, созданные кем-то другим. Это приводит к тому, что все разочаровываются и бегут chmod -R 777 * на все, что у них есть. Похоже, что большинство людей ожидают, что групповая папка будет иметь единый набор разрешений, которые в равной степени применяются ко всем объектам-потомкам файловой системы.
Чтобы обеспечить это, у нас есть скрипт cron под названием Разрушитель разрешений который периодически просматривает все каталоги проекта и исправляет разрешения (как стандартные, так и ACL) для всех объектов файловой системы. Все получают одинаковые уровни разрешений (хотя и поддерживает бит eXecutable), а разрешения определяются в файле конфигурации, который контролируется версией. Это дает нам отличную уверенность в том, что пользователи не обходят бессознательно элементы управления доступом, чтобы предоставить доступ не тем людям.
На наших серверах Mac OS X это немного проще. В HFS есть списки ACL, которые могут переопределить списки ACL всех дочерних объектов файловой системы. Более того, они применяются на стороне сервера, поэтому клиенты, которые не понимают ACL HFS (например, клиенты Linux NFS), также работают должным образом. Мы просто определяем ACL в самом каталоге группы, и все его содержимое всегда одинаково доступно для всей группы.
Другой сложный вопрос заключается в том, кто несет полную ответственность за данные, хранящиеся в каталогах групп / проектов. Данные имеют тенденцию накапливаться и гнить в них, потому что ни один человек не несет ответственности за их порядок. Когда квота достигнута, иногда бывает трудно найти подходящего человека для уведомления. Чтобы решить эту проблему, мы пытаемся назначить одного пользователя в качестве сопровождающего для каждого каталога.
Если вы можете его качать, используйте в качестве файлового сервера машину Solaris (или OpenSolaris). ZFS и более продвинутые ACL NFSv4 на несколько световых лет превосходит то, что вы можете сделать с разрешениями Posix, Posix ACL, LVM и т.д. с сервера. На самом деле это, вероятно, лучше в большинстве случаев, поскольку сложность скрыта от конечных пользователей.
Затем вы можете легко создавать файловые системы ZFS для каждой операционной группы, проекта или чего-либо еще и при необходимости назначать квоты и политики квот.
Это, безусловно, самый гибкий тип системы, который я видел для этой цели, но, конечно, не применим к каждой среде.
Мы использовали отдельный раздел для групповых общих данных. Затем мы устанавливаем групповые квоты и имеем по одному каталогу на группу. Мы также устанавливаем для каталогов setgid, чтобы вновь созданные файлы унаследовали права группы. Это, вероятно, не является полным решением, но может быть полезным началом.