Настройка квот хранилища по умолчанию для ролей пользователей в ownCloud oCIS

Для автоматического назначения квоты на хранилище в ownCloud Infinite Scale (oCIS) добавьте role_quotasсопоставление в конфигурацию службы прокси proxy.yaml. Сопоставьте каждый идентификатор роли oCIS с квотой в байтах, затем перезапустите службу прокси. Этот параметр назначает квоты новым пользователям в соответствии с их ролью; это не переменная среды, и изменение этого параметра не следует рассматривать как обновление существующих учетных записей. Текущая документация ownCloud 8.2 описывает этот метод на основе ролей в конфигурации службы прокси .

Убедитесь, что квоты, основанные на ролях, соответствуют вашей конфигурации.

Этот метод следует использовать, если пользователи получают роль oCIS при первом входе в систему, и вы хотите, чтобы новые пользователи с разными ролями начинали работу с разными лимитами личного хранилища. Например, стандартная учетная запись может получить 10 ГиБ, а роль с большей емкостью — 50 ГиБ. Ваш поставщик идентификации может сопоставить свои данные с ролями oCIS, или же назначение роли по умолчанию в прокси-сервере может назначить userроль пользователям, у которых ее еще нет.

Не следует путать личную квоту пользователя на хранилище с квотой на пространство. Квота на пространство определяет емкость пространства, а квота OCIS_SPACES_MAX_QUOTAустанавливает глобальный максимально допустимый объем для пространств. В документации ownCloud указано, что емкость пространства не зависит от квоты на хранилище и что пространство может иметь квоту, превышающую базовую емкость хранилища. Для получения более подробной информации см. официальную документацию по квотам на пространства и справочник по настройке Storage-Users .

Перед редактированием определите идентификаторы ролей, используемые вашим экземпляром, и установите ограничение для каждой из них. Названия ролей, такие как userи , guestполезны для назначения ролей, но карта квот ожидает идентификаторы ролей. В этом примере нет универсального идентификатора, который можно было бы скопировать. Также проверьте, получают ли пользователи уже роли через OIDC или рабочий процесс предоставления ресурсов; правила квот помогают только тогда, когда пользователю назначена соответствующая роль.

1. Найдите и создайте резервную копию конфигурации прокси-сервера.

Найдите каталог конфигурации, используемый вашим развертыванием, и создайте его резервную копию proxy.yaml. В случае установки на основе пакетов он может /etc/ocisнаходиться в каталоге `/etc/config ...

Сохраните остальные настройки существующего файла. Если он уже содержит role_quotas: {}это поле, замените пустое сопоставление. Не добавляйте второй role_quotasключ верхнего уровня: повторяющиеся ключи YAML могут обрабатываться непоследовательно. Если файл не содержит этот ключ, добавьте его на верхнем уровне, выровняв с другими настройками прокси верхнего уровня.

2. Добавьте значения квот в байтах.

Прокси-сервер ожидает целочисленные значения квот в байтах. В этом примере 10 ГиБ равны 10 737 418 240 байтам, а 50 ГиБ равны 53 687 091 200 байтам. Приведенные ниже числа 1001являются 1002лишь примерами идентификаторов ролей; замените их идентификаторами из вашей собственной установки oCIS.

role_quotas:
  1001: 10737418240
  1002: 53687091200

Каждый элемент записи роли должен иметь одинаковый отступ ниже role_quotas. Значения следует указывать в виде целых байтов, а не в виде строк, например 10GB, . Если вы уже используете role_assignmentраздел, он может остаться в том же файле; карта квот — это отдельный параметр верхнего уровня.

3. Убедитесь, что новым пользователям присваивается соответствующая роль.

При использовании драйвера назначения ролей по умолчанию пользователь без существующей роли получает ограничение userпри первом входе в систему. Если все новые пользователи должны получать одно ограничение, сопоставьте идентификатор этой роли с желаемой квотой. Если квоты различаются в зависимости от категории пользователя, настройте назначение ролей таким образом, чтобы каждая категория соответствовала правильной роли oCIS, а затем добавьте идентификатор каждой роли в role_quotas.

Для OIDC прокси-сервер может считывать утверждение ролей и сопоставлять значения утверждения с именами ролей oCIS proxy.yaml. Имя утверждения и сопоставления должны соответствовать тому, что фактически выдает поставщик идентификации. Документированное утверждение по умолчанию — roles; сопоставления по умолчанию включают ocisAdmin, ocisSpaceAdmin, ocisUser, и ocisGuest. Если вы настраиваете эти сопоставления, проверьте примеры назначения ролей и ограничения . В частности, каждая учетная запись получает одну роль, и пользователь OIDC, чьи утверждения не соответствуют ни одному из настроенных сопоставлений ролей, может не иметь возможности войти в систему. Сначала протестируйте изменения утверждений в непроизводственной учетной записи.

4. Перезапустите прокси и подтвердите авторизацию с помощью новой учетной записи.

Проверьте синтаксис YAML с помощью проверок конфигурации вашего развертывания, если таковые имеются, затем перезапустите службу прокси или полное развертывание oCIS в соответствии с указаниями вашего менеджера служб. Прокси должен загрузить обновленный файл, прежде чем новый пользователь получит правило. Избегайте перезапуска несвязанных служб, если это не требуется вашим развертыванием.

1. Создайте временного тестового пользователя, который ранее не входил в этот экземпляр oCIS, или используйте рабочий процесс для непроизводственной учетной записи, который создает действительно нового пользователя.
2. Убедитесь, что присвоенный ему идентификатор роли является одним из ключей в файле role_quotas. Для настройки OIDC проверьте выданное утверждение роли и сопоставление ролей прокси-сервера.
3. Войдите в систему и проверьте отображаемую личную квоту, которую показывает клиент. Загрузите небольшой тестовый файл, затем в тестовой среде попытайтесь загрузить файл, который превысит оставшуюся квоту. Убедитесь, что первая загрузка прошла успешно, а загрузка, превышающая лимит, отклонена.

Пользователь, существовавший до изменения, не является допустимым тестом для проверки пути назначения нового пользователя. Если тестовая учетная запись получает неправильное ограничение, проверьте идентификатор роли, а не отображаемое имя, роль, назначенную при первом входе в систему, активный proxy.yamlпуть и был ли перезапущен прокси-сервер. Сохраните резервную копию до тех пор, пока создание и загрузка новых учетных записей не будут работать должным образом.

Что эта конфигурация не меняет

Указанное сопоставление ролей и квот является правилом адаптации новых пользователей. Само по себе оно не устанавливает политику использования дискового пространства и не доказывает, что данные уже созданных пользователей были обновлены. Управляйте существующими учетными записями и лимитами дискового пространства через поддерживаемый путь администрирования для вашей системы. Также следите за тем, чтобы общие выделенные квоты были реалистичными для емкости хранилища за oCIS: квота — это лимит выделения, а не дополнительная емкость диска или объектного хранилища.