ownCloud oCISでユーザーロールごとにデフォルトのストレージクォータを設定する

ownCloud Infinite Scale (oCIS) でストレージクォータを自動的に割り当てるには、role_quotasプロキシサービスのproxy.yaml設定にマッピングを追加します。各 oCIS ロール ID をバイト単位のクォータにマッピングし、プロキシサービスを再起動します。この設定は、ロールに応じて新規ユーザーにクォータを割り当てるものであり、環境変数ではないため、変更しても既存のアカウントの更新とはみなされません。現在の ownCloud 8.2 のドキュメントでは、プロキシサービスの設定でこのロールベースの方法について説明しています。

役割ベースの割り当てが設定に適合していることを確認してください。

ユーザーが初回ログイン時にoCISロールを受け取り、異なるロールを持つ新規ユーザーに異なる個人ストレージ制限を設定したい場合は、この方法を使用してください。たとえば、標準アカウントには10​​ GiB、より大容量のロールには50 GiBを割り当てることができます。IDプロバイダーはクレームをoCISロールにマッピングできます。または、プロキシのデフォルトのロール割り当て機能を使用して、userまだロールが割り当てられていないユーザーにロールを割り当てることもできます。

ユーザーの個人ストレージクォータとスペースクォータを混同しないでください。スペースクォータはスペースの容量を設定するものであり、OCIS_SPACES_MAX_QUOTAスペースクォータはスペース全体の最大容量を設定するものです。ownCloudのドキュメントには、スペース容量はストレージクォータとは独立しており、スペースのクォータは基となるストレージ容量よりも大きく設定できると記載されています。詳細については、公式のスペースクォータに関するドキュメントとストレージユーザー設定リファレンスを参照してください。

編集する前に、インスタンスで使用されているロール ID を特定し、それぞれの制限値を決定してください。ロール名は、userロールguestの割り当てに役立ちますが、クォータ マップではロール ID が必要です。この例からコピーできる共通の ID はありません。また、ユーザーが OIDC またはプロビジョニング ワークフローを通じて既にロールを受け取っているかどうかを確認してください。クォータ ルールは、ユーザーに一致するロールが割り当てられている場合にのみ有効です。

1. プロキシ設定を見つけてバックアップする

デプロイメントで使用される構成ディレクトリを見つけて、既存のファイルをバックアップしてくださいproxy.yaml。パッケージベースのインストールでは、ディレクトリは の下にある場合があります/etc/ocis。コンテナデプロイメントでは、別のディレクトリがマウントされる可能性があります。すべてのインストールで同じ場所が使用されると想定するのではなく、Proxy コンテナにマウントされたパス、またはデプロイメント構成で指定されたパスを使用してください。

ターミナルコマンドを実行すると、proxy.yaml設定ファイルがエディタで開きます。

既存ファイルのその他の設定はそのまま保持します。既に が含まれている場合はrole_quotas: {}、その空のマッピングを置き換えます。2 つ目のトップレベルrole_quotasキーは追加しないでください。重複する YAML キーは、一貫性のない解析が行われる可能性があります。ファイルにキーが含まれていない場合は、他のトップレベルのプロキシ設定と揃えて、トップレベルに追加します。

2. バイト単位でクォータ値を追加する

プロキシは、バイト単位の整数クォータ値を必要とします。この例では、10 GiB は 10,737,418,240 バイト、50 GiB は 53,687,091,200 バイトに相当します。以下の数値は1001ロール1002ID のサンプルです。ご自身の oCIS インストール環境の ID に置き換えてください。

proxy.yamlエディタには、ロールIDの例とバイト単位のクォータ値を含むrole_quotasマッピングが表示されます。
role_quotas:
  1001: 10737418240
  1002: 53687091200

各ロールエントリは、<code><input type="code></code> の下に一貫してインデントしてくださいrole_quotas。値は、<code><input type="code></code> のような文字列ではなく、バイト単位の整数値で記述してください10GB。既に <code><input type="code></code> セクションを使用している場合はrole_assignment、同じファイルに残しておいても構いません。クォータマップは、別のトップレベル設定です。

3. 新規ユーザーに適切な役割が割り当てられていることを確認する

デフォルトのロール割り当てドライバでは、既存のロールを持たないユーザーはuser初回ログイン時に を受け取ります。すべての新規ユーザーに 1 つの制限を与える必要がある場合は、そのロールの ID を目的のクォータにマッピングします。クォータがユーザー カテゴリによって異なる場合は、各カテゴリが正しい oCIS ロールにマッピングされるようにロール割り当てを構成し、各ロールの ID を に追加しますrole_quotas。

概念的なIDプロバイダー図は、新規ユーザー向けにownCloudロールにマッピングされたOIDCロールクレームを示しています。

OIDC の場合、プロキシはロールクレームを読み取り、クレーム値を の oCIS ロール名にマッピングできますproxy.yaml。クレーム名とマッピングは、ID プロバイダが実際に発行するものと一致している必要があります。ドキュメントに記載されているデフォルトのクレームは です。rolesデフォルトのマッピングにはocisAdmin、ocisSpaceAdmin、ocisUser、 、 が含まれますocisGuest。これらのマッピングをカスタマイズする場合は、ロール割り当ての例と制約を確認してください。特に、各アカウントには単一のロールが割り当てられ、クレームが構成済みのロールマッピングと一致しない OIDC ユーザーはログインできない場合があります。クレームの変更は、まず非本番環境のアカウントでテストしてください。

4. プロキシを再起動し、新しいアカウントで認証してください。

デプロイメントの構成チェックが利用可能な場合は、YAML構文を検証し、サービスマネージャに従ってプロキシサービスまたはoCISデプロイメント全体を再起動してください。プロキシは、新しいユーザーがルールを受信する前に、更新されたファイルをロードする必要があります。デプロイメントで必要とされる場合を除き、無関係なサービスの再起動は避けてください。

一般的なアップロードテストパネルには、4.2GBのファイルアップロードと、50GBの割り当て容量のうち46.8GBの残量が表示されます。
  1. 以前にこのoCISインスタンスにログインしたことのない使い捨てのテストユーザーを作成するか、または完全に新規のユーザーをプロビジョニングする非本番環境アカウントのワークフローを使用してください。
  2. 割り当てられたロール ID が のキーのいずれかであることを確認してくださいrole_quotas。OIDC 設定の場合は、発行されたロール クレームとプロキシのロール マッピングを調べてください。
  3. サインインして、クライアントが公開している個人用クォータを確認してください。小さなテストファイルをアップロードした後、テスト環境で残りのクォータを超えるアップロードを試みます。最初のアップロードが成功し、制限を超えるアップロードが拒否されることを確認してください。

変更前に存在していたユーザーは、新規ユーザー割り当てパスの有効なテスト対象ではありません。テストアカウントで誤った制限が設定された場合は、表示名ではなくロールID、初回ログイン時に割り当てられたロール、アクティブなproxy.yamlパス、およびプロキシが再起動されたかどうかを確認してください。新規アカウントのプロビジョニングとアップロードが期待どおりに動作するようになるまで、バックアップを保持してください。

この構成で変わらないのは

文書化されたロールとクォータのマッピングは、新規ユーザー向けのオンボーディングルールです。それ自体では、スペース容量ポリシーを確立したり、既にプロビジョニングされているユーザーが更新されたことを証明したりするものではありません。既存のアカウントとスペース制限は、デプロイメントでサポートされている管理パスを通じて管理してください。また、割り当てられるクォータの合計は、oCISのストレージ容量に対して現実的な値に設定してください。クォータは割り当て制限であり、追加のディスク容量やオブジェクトストレージ容量ではありません。

コメントを残す

ownCloud oCISでユーザーロールごとにデフォルトのストレージクォータを設定する

ownCloud oCISでユーザーロールごとにデフォルトのストレージクォータを設定する

役割ごとに、新しいownCloud Infinite Scaleユーザーにバイト単位のストレージ制限を割り当てます。proxy.yamlの例と安全な検証チェックリストも含まれています。

ownCloud同期証明書のTLSソースエラーを修正する

ownCloud同期証明書のTLSソースエラーを修正する

TLS検証を無効にせずに、サーバーのホスト名、証明書チェーン、プライベートCAの信頼、およびキャプティブポータルの問題を確認することで、ownCloudデスクトップの同期を復元します。

アップグレード後にownCloudの整合性警告をクリアする

無効ファイルレポートを使用して、一致しないコアファイルまたはアプリ署名を特定し、正しいリリースファイルを復元し、整合性チェックを安全に検証します。

ownCloud Infinite ScaleをDocker Composeでインストールする

ownCloud Infinite Scaleを公式のComposeサンプルからデプロイし、ドメインと永続ストレージを設定した後、TLS、コンテナ、および初回ログインを確認します。

ownCloud Infinite Scale 用の S3 Blob Storage の設定

ownCloud Infinite Scale 用の S3 Blob Storage の設定

ownCloud Infinite Scaleがファイルコンテンツを確実に保存できるように、S3NGドライバー、バケットのアクセス許可、永続的なメタデータストレージ、およびアップロードサイズを設定します。

ownCloudのアップロードが99%で止まった場合は、これらの制限を確認してください。

ownCloudのアップロードが99%で止まった場合は、これらの制限を確認してください。

ownCloud Serverへのアップロードが完了間近で停止する原因を特定するには、ファイルの状態、クォータ、一時ディスク容量、PHPの制限、プロキシのタイムアウトなどを確認してください。

ownCloudのApache .htaccess警告を安全にクリアする

ownCloudのApache .htaccess警告を安全にクリアする

ownCloudのウェブルートに対してのみAllowOverride Allを設定し、アクティブなApache仮想ホストを検証し、安全にリロードして.htaccessルールを復元します。

ownCloud Enterprise Auditingを設定し、ログを確認する

ownCloudのエンタープライズ監査アプリを有効にし、admin_auditイベントを保護されたログファイルにルーティングして、実際のユーザー操作が記録されていることを確認します。

ownCloud Infinite ScaleをOIDCを使用してKeycloakに接続します。

ownCloud Infinite ScaleをOIDCを使用してKeycloakに接続します。

Keycloakのレルム発行者、Webクライアント、およびユーザークレームを整合させることで、ownCloud Infinite ScaleがWebクライアントとモバイルクライアント全体でユーザーを確実にサインインできるようにします。

ownCloudのファイルを共有を失うことなく新しい所有者に移動する

ownCloudのoccコマンドを使用して、所有ファイルと共有フォルダを転送し、何が残るかを把握し、古いアカウントを削除する前にアクセス権を確認してください。