Définir les quotas de stockage par défaut en fonction du rôle de l'utilisateur dans ownCloud oCIS

Pour attribuer automatiquement un quota de stockage dans ownCloud Infinite Scale (oCIS), ajoutez une role_quotascorrespondance à la configuration du service Proxy proxy.yaml. Associez chaque ID de rôle oCIS à un quota en octets, puis redémarrez le service Proxy. Ce paramètre attribue des quotas aux nouveaux utilisateurs en fonction de leur rôle ; il ne s'agit pas d'une variable d'environnement et sa modification ne doit pas être considérée comme une mise à jour des comptes existants. La documentation actuelle d'ownCloud 8.2 décrit cette méthode basée sur les rôles dans la configuration du service Proxy .

Vérifiez que les quotas basés sur les rôles correspondent à votre configuration.

Utilisez cette méthode lorsque les utilisateurs reçoivent un rôle oCIS lors de leur première connexion et que vous souhaitez que les nouveaux utilisateurs ayant des rôles différents disposent de limites de stockage personnel différentes. Par exemple, un compte standard pourrait recevoir 10 Gio et un rôle nécessitant une capacité supérieure, 50 Gio. Votre fournisseur d'identité peut associer ses revendications aux rôles oCIS, ou l'attribution de rôle par défaut du proxy peut attribuer ce userrôle aux utilisateurs qui n'en possèdent pas déjà un.

Ne confondez pas le quota de stockage personnel d'un utilisateur avec le quota d'un espace. Le quota d'un espace définit sa capacité, tandis que OCIS_SPACES_MAX_QUOTAle quota global définit la capacité maximale autorisée pour les espaces. ownCloud indique que la capacité d'un espace est indépendante du quota de stockage et qu'un espace peut avoir un quota supérieur à sa capacité de stockage sous-jacente. Pour plus de détails, consultez la documentation officielle sur les quotas des espaces et le guide de configuration des utilisateurs de stockage .

Avant toute modification, identifiez les ID de rôle utilisés par votre instance et définissez la limite pour chacun. Les noms de rôle, tels que « nom_de_rôle » useret guest« nom_de_rôle », sont utiles pour l'attribution des rôles, mais la table de quotas attend des ID de rôle. Cet exemple ne contient pas d'ID universel. Vérifiez également si les utilisateurs reçoivent déjà des rôles via OIDC ou un flux de provisionnement ; les règles de quotas ne sont pertinentes que si un rôle correspondant est attribué à l'utilisateur.

1. Trouvez et sauvegardez la configuration du proxy

Localisez le répertoire de configuration utilisé par votre déploiement et sauvegardez-en le contenu existant proxy.yaml. Dans une installation basée sur des paquets, il peut se trouver sous/etc/ocis ; les déploiements de conteneurs peuvent monter un répertoire différent. Utilisez le chemin monté dans le conteneur Proxy ou spécifié par la configuration de votre déploiement plutôt que de supposer que chaque installation utilise le même emplacement.

Conservez les autres paramètres du fichier existant. S'il contient déjà role_quotas: {}une entrée vide, remplacez-la. N'ajoutez pas de deuxième role_quotasclé de premier niveau : les clés YAML dupliquées peuvent être analysées de manière incohérente. Si le fichier ne contient pas la clé, ajoutez-la au niveau supérieur, en l'alignant avec les autres paramètres de proxy de premier niveau.

2. Ajouter les valeurs de quota en octets

Le proxy attend des valeurs de quota entières en octets. Dans cet exemple, 10 Gio correspondent à 10 737 418 240 octets et 50 Gio à 53 687 091 200 octets. Les nombres 1001ci 1002-dessous ne sont que des exemples d'identifiants de rôle ; remplacez-les par les identifiants de votre installation oCIS.

role_quotas:
  1001: 10737418240
  1002: 53687091200

Indentez systématiquement chaque entrée de rôle role_quotas. Conservez les valeurs sous forme de nombres d'octets entiers plutôt que sous forme de chaînes de caractères 10GB. Si vous utilisez déjà une role_assignmentsection, elle peut rester dans le même fichier ; la table de quotas est un paramètre de niveau supérieur distinct.

3. Assurez-vous que les nouveaux utilisateurs reçoivent un rôle correspondant.

Avec le pilote d'attribution de rôles par défaut, un utilisateur sans rôle existant reçoit userune limite lors de sa première connexion. Si tous les nouveaux utilisateurs doivent avoir une seule limite, associez l'ID de ce rôle au quota souhaité. Si les quotas diffèrent selon la catégorie d'utilisateur, configurez l'attribution des rôles afin que chaque catégorie soit associée au rôle oCIS approprié, puis ajoutez l'ID de chaque rôle role_quotas.

Pour OIDC, le proxy peut lire une revendication de rôle et associer ses valeurs aux noms de rôles oCIS proxy.yaml. Le nom de la revendication et les associations doivent correspondre à ceux émis par le fournisseur d'identité. La revendication par défaut documentée estroles ; les associations par défaut incluent ocisAdmin, ocisSpaceAdmin, ocisUser, et ocisGuest. Si vous personnalisez ces associations, consultez les exemples et contraintes d'attribution de rôles . En particulier, chaque compte reçoit un seul rôle, et un utilisateur OIDC dont les revendications ne correspondent à aucune association de rôle configurée peut ne pas pouvoir se connecter. Testez d'abord les modifications de revendications sur un compte hors production.

4. Redémarrez le proxy et vérifiez avec un nouveau compte.

Vérifiez la syntaxe YAML à l'aide des contrôles de configuration de votre déploiement, le cas échéant, puis redémarrez le service Proxy ou l'ensemble du déploiement oCIS selon votre gestionnaire de services. Le Proxy doit charger le fichier mis à jour avant qu'un nouvel utilisateur ne reçoive la règle. Évitez de redémarrer les services non liés, sauf si votre déploiement l'exige.

1. Créez un utilisateur de test jetable qui ne s'est jamais connecté à cette instance oCIS auparavant, ou utilisez un flux de travail de compte hors production qui provisionne un utilisateur véritablement nouveau.
2. Vérifiez que l'identifiant de rôle attribué figure parmi les clés role_quotas. Pour une configuration OIDC, examinez la revendication de rôle émise et le mappage des rôles du proxy.
3. Connectez-vous et vérifiez votre quota personnel indiqué par le client. Téléversez un petit fichier de test, puis, dans un environnement de test, tentez un téléversement dépassant votre quota restant. Vérifiez que le premier téléversement réussit et que le téléversement dépassant la limite est refusé.

Un utilisateur existant avant la modification ne constitue pas un test valide du processus d'attribution des nouveaux utilisateurs. Si le compte de test se voit attribuer une limite incorrecte, vérifiez l'ID du rôle plutôt que le nom d'affichage, le rôle attribué lors de la première connexion, le proxy.yamlchemin actif et si le proxy a été redémarré. Conservez la sauvegarde jusqu'à ce que la création de nouveaux comptes et les chargements fonctionnent comme prévu.

Ce que cette configuration ne change pas

Le mappage des rôles et des quotas documenté constitue une règle d'intégration pour les nouveaux utilisateurs. Il ne définit pas à lui seul une politique de capacité d'espace ni ne prouve que les utilisateurs déjà provisionnés ont été mis à jour. Gérez les comptes existants et les limites d'espace via le chemin d'administration pris en charge pour votre déploiement. Veillez également à ce que les quotas totaux attribués soient réalistes par rapport à la capacité de stockage sous oCIS : un quota est une limite d'allocation, et non une capacité supplémentaire de disque ou de stockage objet.