サブスクリプションとライセンス

Rediaccのライセンス管理には3つの可動部品があります：

• account は権利を署名し、使用状況を追跡します
• rdc は認証し、ライセンスを要求し、マシンに配信し、実行時に適用します
• renet（マシン上のランタイム）はアカウントサーバーを呼び出さずにインストール済みライセンスをローカルで検証します

このページでは、ローカルデプロイメントでこれらの要素がどのように連携するかを説明します。

ライセンス管理が行うこと

ライセンス管理は2つの異なる事項を制御します：

• フローティングライセンスを通じたマシンアクセスの会計処理
• リポジトリライセンスを通じたリポジトリランタイム認可

これらは関連していますが、同じアーティファクトではありません。

ライセンス管理の仕組み

account はプラン、契約上書き、マシンスロット状態、月次リポジトリライセンス発行の信頼できる情報源です。

rdc はワークステーション上で実行されます。アカウントサーバーにログインし、必要なライセンスを要求し、SSH経由でリモートマシンにインストールします。リポジトリコマンドを実行すると、rdc は必要なライセンスが正しく配置されていることを確認し、実行時にマシン上でそれらを検証します。

通常のフローは次のようになります：

1. rdc subscription login で認証します
2. rdc repo create、rdc repo up、rdc repo down などのリポジトリコマンドを実行します
3. 必要なライセンスが見つからないか期限切れの場合、rdc は account にそれを要求します
4. rdc は署名されたライセンスをマシンに書き込みます
5. ライセンスはマシン上でローカルに検証され、操作が続行されます

ワークステーションとサーバーの分担については rdc vs renet を、リポジトリのライフサイクル自体については リポジトリ を参照してください。

自動化およびAIエージェントには、ブラウザログインの代わりにスコープ付きサブスクリプショントークンを使用してください：

rdc subscription login --token "$REDIACC_TOKEN"

環境を通じてトークンを直接注入することで、CLIが対話的なログインステップなしにリポジトリライセンスを発行・更新できるようにすることもできます：

export REDIACC_TOKEN="rdt_..."
export REDIACC_ACCOUNT_SERVER="https://www.rediacc.com/account"

マシンスロットとリポジトリライセンス

マシンスロット（サーバー側）

マシンスロットの追跡はサーバー側で適用されます。CLIがリポジトリライセンスを発行すると、アカウントサーバーはサブスクリプションのマシンスロットクォータを確認します。セルフサーブの全プラン（Community、Professional、Business）にはマシンスロットが1つ含まれており、複数マシンでの運用はパートナーと個別に構成するEnterprise案件になります。スロットはそのマシンでの最後のリポジトリライセンス発行から5時間保持され、非アクティブ後に自動解放されます。スロットはアクティブにプロビジョニングしている間だけ保持されるため、1つのスロットでも1か月の間に複数台のマシンをカバーできます。

この上限はプランに固定された定数ではなく、お客様のサブスクリプションのレコードから読み取られます。そのため、個別に交渉されたアクティベーション数は、サブスクリプションに設定された時点ですぐに有効になります。プランのティアが決めるのは初期値だけです。

発行と更新では適用のされ方が異なり、この違いが重要です：

• 新しいライセンスの発行は上限で止まります。 すべてのスロットが埋まっている場合、リクエストは MAX_MACHINES_REACHED で失敗し、何もプロビジョニングされません。
• 既存ライセンスの更新が止まることはありません。 すべてのスロットが埋まっている状態で更新したマシンはそのまま動作を続け、そのスロットは上限超過として記録されます。これはポータルのMachinesページ、rdc subscription status、およびライセンスステータスAPIの overLimitCount フィールドで確認できます。マシンが上限内に戻れば、このフラグは自動的に解除されます。

更新の方を意図的に緩くしています。すでに保持しているライセンスを更新するマシンは新規のキャパシティではありませんし、これを拒否すれば、すでに支払い済みのインフラでバックアップが止まってしまうからです。ブロックされ続けるのは、キャパシティを追加する操作です。

マシンライセンスファイルはマシン上には保存されません。スロット適用は発行時にサーバーで行われます。

リポジトリライセンス

リポジトリライセンスは、1台のマシン上の1つのリポジトリに対する署名付きライセンスです。これはマシンに保存される唯一のライセンスファイルであり、データストアごと・署名キーごとに次のように配置されます：

/var/lib/rediacc/license/repos/{guid}/{keyId}.json
/var/lib/rediacc/license/datastores/{datastoreId}/repos/{guid}/{keyId}.json

マシンのデフォルトストレージ上にあるリポジトリは1つ目のパスを使います。名前付きデータストア内のリポジトリは2つ目のパスを使い、{datastoreId} はそのデータストアが作成されたときに与えられたアイデンティティです。このスコープ分けこそが、データストアのフォークを正しく計測させます。フォークされたデータストアはまったく新しいアイデンティティを持つため、その中のリポジトリはライセンスが1つもない状態から始まり、最初のライセンス対象操作で missing を報告し、それぞれ独自のライセンスが発行されます。実際に置かれているデータストアとは別のデータストアを指すライセンスを持つリポジトリは、自動的に再発行されるのではなく identity_mismatch として即座に失敗します。これがライセンスファイルの横流しを防いでいます。

{keyId} は16桁の16進数フィンガープリント（署名元サーバーのEd25519公開鍵に対するSHA-256の先頭8バイト）です。複数のアカウントユニバースによって管理されているリポジトリ（例えば本番とbenchが同じマシンにデプロイしている場合）は、{guid}ディレクトリの下に署名キーごとに1つのファイルを保持します。マシンのrenetビルドは、自身に組み込まれたキー、またはそのキーにチェーンされた委任証明書で検証できるファイルのみを検証します。他のユニバースのファイルは無効なままです。ユニバースを切り替えてもライセンスは無効になりません：新しいユニバースでの最初の操作でそのユニバースのライセンスが一度だけ発行され（missingという結果になった場合は自動発行）、その後は両方が共存します。

以下のために使用されます：

• rdc repo create、rdc repo fork、rdc repo commit：プロビジョニング前に検証されます（チェックの時点ではリポジトリがまだ存在しないため、アイデンティティ証明なしで事前発行され、作成後にアイデンティティ証明付きで再発行されます）
• rdc repo resize、rdc repo expand、rdc repo merge、rdc repo promote：有効期限を含めて完全に検証されます
• バックアップ転送は有効期限を含めて完全に検証されます：rdc repo push、rdc repo pull、rdc repo migrate、およびスケジュールされたバックアップ
• rdc repo up、rdc repo up --all、rdc repo exec、およびマシン再起動時のリポジトリ自動起動：有効期限と委任証明書の有効期間の両方をスキップして検証されます
• rdc repo down、rdc repo delete、およびリポジトリの一覧表示のような読み取り専用コマンドには、ライセンスは一切不要です

署名、鍵の紐付け、マシンの紐付け、リポジトリの紐付け、そして委任証明書のすべての制約は、これらすべてで強制されます。最後のグループが緩めているのは2つの期間チェックだけです。そのため、ライセンスの期限切れや証明書の失効によって、自分のデータを起動したり停止したりできなくなることはありません。

リポジトリライセンスはマシンとターゲットリポジトリに紐付けられています。各ライセンスには、マシンID、リポジトリGUID、サブスクリプションID、プラン制限、有効期限が含まれます。暗号化されたリポジトリの場合、Rediaccは基盤となるボリュームのLUKSアイデンティティも検証します。

複数のサブスクリプションが同じマシン上で共存できます。各リポジトリは独自のサブスクリプションコンテキストを持つ独自のライセンスを保持しています。

クラスター

クラスタリングはEnterprise契約の一部としてパートナー経由で販売されます。セルフサーブのプランオプションではないため、以下では購入方法ではなく、どのように計測されるかを説明します。

ノードはマシンです。 クラスターそのものにライセンス上のアイデンティティはありません。クラスター内の各ノードは、Renet Agentがインストールされた通常のマシンであり、単体のマシンとまったく同じように数えられます。

プール制はありません。 5ノードのクラスターが、共有のクラスタースロット1つを消費するわけではありません。各ノードは最初にリポジトリが配置された時点で自分のスロットを確保し、そのスロットは他と同じ5時間のフローティング方式に従います。つまり、そのノードでの最後のリポジトリライセンス発行から5時間保持され、その後は自動的に解放されます。

クラスターの構築は無料で、計測の対象になるのはリポジトリの配置です。 クラスターの作成、ノードの参加、分散ストレージ層のインストール、Kubernetesコントロールプレーンの立ち上げには、スロットは一切かかりません。計測が始まるのは、リポジトリがノードに配置された時点です。

クラスターのフォークはリポジトリ単位で再計測されます。 クラスター全体をフォークすると、フォークされたデータストアには新しいアイデンティティが与えられるため、フォーク内の各リポジトリは、どのノードで動いていても、最初に触れられた時点で独自のライセンスを取得します。単純な移行はその逆です。リポジトリをマシン間で移動してもライセンスは一緒に移動し、検証も通り続けます。ストレージのアイデンティティは何も変わっていないからです。

クラスターでの更新は、上記のソフトな確保ルールに従います。 各ノードは無人で自分のライセンスを更新するため、アクティベーション数を超えて拡大したクラスターもそのまま動作を続け、上限を超えたノードを報告します。真夜中にバックアップが失敗することはありません。新しいノードの追加は、これまでどおり上限でブロックされます。

クラスターのサイジングはチェックボックスではなく、話し合いで決めるものです。クラスターのアクティベーション数は注文時に合意し、担当パートナーがサブスクリプションに直接設定します。まずは お問い合わせ からご相談ください。

デフォルト制限

リポジトリサイズは権利レベルによって異なります：

• Community：最大 10 GB
• 有料プラン：プランまたは契約の制限

有料プランのデフォルト制限は：

プラン	フローティングライセンス	リポジトリサイズ	月次リポジトリライセンス発行数	委任証明書のデフォルト/最大
Community	1	10 GB	100	15d / 30d
Professional	1	100 GB	2,000+	60d / 120d
Business	1	500 GB	5,000+	90d / 180d
Enterprise	カスタム	1 TB+	15,000+	120d / 365d

契約固有の制限により、特定の顧客に対してこれらの値を上げたり下げたりすることができます。委任証明書の有効期間は subscription.expiresAt + 3 day grace でハードキャップが設けられているため、月次請求のサブスクリプションでは請求サイクルに合わせた証明書が自然に発行されます。完全なルールについては ライセンスチェーンと委任 - 有効期間ポリシー を参照してください。

無料トライアルとCommunityへのフォールバック

新規登録では、ProfessionalまたはBusinessの14日間無料トライアルが自動的に開始します。登録時にクレジットカード情報を登録しますが、実際の課金はトライアル終了時に初めて発生するため、それより前に解約すれば費用は一切かかりません。トライアルは顧客一人につき1回限り利用できます。

Communityは無料の標準プランとして常に存在します。新規アカウントが直接申し込むことはできなくなり、代わりにサブスクリプションが終了するたびにCommunityへ自動的に移行します。具体的には、トライアル中の解約、有料プランの後日解約、または支払い失敗の場合です。Communityへのフォールバック後は、マシン1台、リポジトリあたり10GB、月100回のセットアップという制限になります。トライアル制導入前に作成されたアカウントは、既存のCommunityアクセス権をそのまま維持します。

制限の適用は、最も重要な部分では緩やかなままです。サブスクリプションが終了した後も、稼働中のリポジトリ（up、down、delete、自動起動）はそのまま動作を続けます。ただしそこから先は2つの異なるルールが適用され、この2つを混同することが、60日間の猶予が一貫していないように見える原因になっています：

• アカウントサーバーを必要とする操作 は、有効なサブスクリプションなしには実行できません。サーバーが署名を拒否するためです。具体的には create、fork、およびライセンスのリフレッシュや更新です。サブスクリプションが失効すると、新しいものは一切プロビジョニングされなくなります。
• 有効なインストール済みライセンスさえあれば足りる操作 は、そのライセンスがハード期限切れになるまで、サーバーを介さずに動作し続けます。具体的には、すでに持っているリポジトリに対する resize と expand、およびバックアップ転送（push、pull、スケジュールされたバックアップ）です。リポジトリの主ライセンスはサブスクリプション終了日から60日後にハード期限切れとなり、これが60日間の猶予の正体です。フォークのライセンスははるかに短命で最長7日のため、フォークを多用するマシンは後述の自動更新に依存します。

つまり、サブスクリプションが失効すると、フリートを増やすことはすぐにできなくなり、その中のリポジトリを大きくすることは60日後にできなくなります。

VM移行猶予期間

ホスティングプロバイダーがVMを異なる物理ハードウェアに移行する場合、マシンIDが変わります（DMI UUID、/etc/machine-id、NICのMACアドレスなどのハードウェア識別子から派生）。リポジトリライセンスはマシンIDに紐付けられているため、通常は移行によってすべてのライセンスが無効になります。

これを透過的に処理するために、リポジトリライセンスには 40日間のマシンID猶予期間 が含まれています。マシンIDが一致しなくても、ライセンスが40日以内に発行された場合、ライセンスはまだ受け入れられます。ライセンスは30日ごとに更新されるため、次の更新で自動的に新しいマシンIDに紐付けられます。

実際には：

• VM移行、マシンIDが変わる：リポジトリは実行を続けます（40日以内）
• 次の rdc 操作で新しいマシンIDでライセンスが更新される
• 手動操作は不要
• rdc machine status <machine> --system --licenses でマシンIDとライセンス状態を確認できます

Edgeチャンネルのアカウント はCommunityプランで動作し、制限が2倍になります（20GBのリポジトリ、月200回のセットアップ、マシン2台）。有料プランはStableチャンネルでのみ利用可能です。詳細は リリースチャンネル を参照してください。

リポジトリの作成、起動、停止、再起動時の動作

リポジトリの作成とフォーク

リポジトリを作成またはフォークする場合：

1. rdc はサブスクリプショントークンが利用可能であることを確認します（必要に応じてデバイスコード認証をトリガー）
2. rdc はアカウントサーバーからリポジトリライセンスを事前発行します（この時点でサーバーはマシンスロットクォータと月次発行制限をチェック）
3. 事前発行されたリポジトリライセンスがマシンに書き込まれ、ローカルで検証されます（署名、マシンID、リポジトリGUID、有効期限、サイズ制限）
4. 作成が成功した後、rdc はリポジトリアイデンティティ証明付きでリポジトリライセンスを再発行します（LUKS UUIDまたはストレージフィンガープリント）

このアカウントバックアップされた発行は、月次の リポジトリライセンス発行 使用量にカウントされます。各ライセンスにはアカウント保有者のメールアドレスと会社名が含まれており、renetがライセンスを検証する際にログに記録されます。

リポジトリの起動、停止、削除

rdc はマシン上にインストールされたリポジトリライセンスを検証しますが、有効期限チェックをスキップします。署名、マシンID、リポジトリGUID、アイデンティティは引き続き検証されます。サブスクリプションが期限切れでも、ユーザーが自分のリポジトリの操作をブロックされることはありません。

リポジトリのリサイズと拡張

rdc は有効期限とサイズ制限を含む完全なリポジトリライセンス検証を実行します。

マシン再起動と自動起動

自動起動は rdc repo up と同じルールを使用します。有効期限はスキップされるため、リポジトリは常に自由に再起動します。

リポジトリライセンスは長期有効期間モデルを使用します：

• refreshRecommendedAt はソフト更新ポイントです
• hardExpiresAt はブロッキングポイントです

リポジトリライセンスが古くなっているがハード有効期限前であれば、ランタイムは続行できます。ハード有効期限に達すると、rdc はリサイズ/拡張操作のためにそれを更新する必要があります。

その他のリポジトリ操作

リポジトリの一覧表示、リポジトリ情報の検査、マウントなどの操作にはライセンス検証は不要です。

ステータスの確認とライセンスの更新

人間によるログイン：

rdc subscription login

自動化またはAIエージェントによるログイン：

rdc subscription login --token "$REDIACC_TOKEN"

非対話型環境では、REDIACC_TOKEN を設定するのが最もシンプルな選択肢です。トークンはエージェントが必要とするサブスクリプションとリポジトリライセンス操作のみにスコープを限定する必要があります。

アカウントバックアップされたサブスクリプションステータスを表示：

rdc subscription status

1台のマシンのマシンアクティベーション詳細を表示：

rdc subscription status -m hostinger

1台のマシンにインストールされたリポジトリライセンス詳細を表示：

rdc subscription status -m hostinger

マシン上のリポジトリのライセンスを更新：

rdc subscription refresh -m hostinger --repo my-app

--repo の ref はローカルの rdc 設定で解決できる必要があります。マシン上で発見されたがローカル設定にないリポジトリは拒否されます。失敗として報告され、自動分類はされません。

初回使用時、使用可能なリポジトリライセンスが見つからないライセンス済みリポジトリまたはバックアップ操作は、アカウント認可ハンドオフを自動的にトリガーする場合があります。CLIは認可URLを表示し、対話型ターミナルではブラウザを開こうとし、認可と発行が成功した後に一度操作を再試行します。

非対話型環境では、CLIはブラウザの承認を待ちません。代わりに、rdc subscription login --token ... または REDIACC_TOKEN でスコープ付きトークンを提供するよう指示します。

マシンの初回セットアップについては、マシンセットアップ を参照してください。

ライセンスの自動更新

ここまでの説明は、すべて誰かがキーボードの前にいることを前提にしています。スケジュールされたバックアップはそうではありません。自動更新は、まさにそのケースのためにあります。

スケジュールされたバックアップは厳格なティアで検証されるため、期限切れでないライセンスが必要です。そしてフォークのライセンスは最長7日です。マシンはアカウントの認証情報を一切保持しない設計になっているため、自動更新が入る前は、フォークのバックアップは作成から1週間後、深夜3時に静かに止まっていました。

トークンを持たないマシンが更新できる仕組み

Rediaccが発行または更新するすべてのライセンスには、それに署名したアカウントサーバー上の更新エンドポイントの完全なアドレスが renewalUrl として含まれています。マシンはそのアドレスを自分にインストールされたライセンスから読み取るため、アカウントサーバーの場所を教えてもらう必要がありません。

次にマシンは、インストール済みのライセンスをそのエンドポイントに提示します。ライセンス自体が認証情報です。ライセンスには署名があり、サーバーはその署名を検証します。APIトークンはどこにも登場しません。サーバーは新しい有効期間を持つライセンスを返し、マシンはそれをインストールして再検証してから、更新完了とみなします。

更新はマシン全体を対象とする操作です：

sudo renet license renew

リポジトリは署名したサーバーごとにグループ化されるため、2つのアカウントユニバースにまたがるマシンは、それぞれに1回ずつ接続します。ロックファイルによって2つの更新が同時に走ることはなく、--jitter は、そのままでは全台が正時に目を覚ましてしまうようなマシン群のタイミングを分散させます。

サーバーが更新を拒否するのは3つのケースで、それぞれ意味が異なります：

拒否の理由	何を意味するか
サブスクリプションが失効している、停止されている、または猶予期間を過ぎている	請求の問題です。サブスクリプションが再び有効になれば、更新も自動的に再開します
委任証明書が期限切れまたは失効している	オンプレミス側の設定の問題です。オンプレミスサーバーで証明書を更新すれば、マシンは通常どおり更新できます
マシンのアイデンティティが一致せず、40日間の猶予も過ぎている	そのライセンスは別のマシンのものです。現在のマシンコンテキストから再発行してください

拒否が実行全体を止めることはありません。1つのリポジトリが失効していても、同じマシン上の他のリポジトリの更新は妨げられません。

スケジュールされたバックアップは自分で更新します

Rediaccが書き出すバックアップユニットは、いずれも最初に更新を実行します：

ExecStartPre=-<renet> license renew --jitter 45s

先頭の - は、これがベストエフォートであることを意図的に示しています。更新の拒否、ネットワークの一時的な不調、あるいはまだこのコマンドを知らない古いRenet Agentが、バックアップそのものを巻き添えにしてはいけないからです。バックアップは実行され、ライセンスは可能なときにそのついでに更新されます。

バックアップがブロックされたとき

ライセンスが実際にバックアップを拒否した場合、マシンはそれを記録します。このマーカーは、無人のバックアップがデータのコピーをやめたことを知らせる唯一の手がかりなので、目立つ形で表示されます：

rdc machine status <machine> --licenses

backups 列には理由付きで BLOCKED と表示され、同じ情報がテーブルの下にもエラーとして出力されるため、30個のリポジトリの中に埋もれることはありません。renewed 列は、直近の無人更新がどうなったかを、サーバーが拒否した場合はその拒否コードも含めて示します。これが、対処すべきなのが請求の問題なのか、オンプレミスの証明書の問題なのかを教えてくれます。

更新が成功すればマーカーは消え、ライセンスチェックを通過したバックアップでも同じように消えます。手動で確認したりリセットしたりする必要はありません。

オフライン動作と有効期限

ライセンス検証はマシン上でローカルに行われます。アカウントサーバーへのライブ接続は必要ありません。

つまり：

• 実行中の環境はすべてのコマンドでアカウントへのライブ接続は不要です
• すべてのリポジトリは有効期限切れのライセンスがあっても常に起動、停止、削除できます。ユーザーが自分のリポジトリの操作をブロックされることはありません
• プロビジョニング操作（create、fork）には事前発行されたリポジトリライセンスが必要で、成長操作（resize、expand）には有効なリポジトリライセンスが必要です
• 真に期限切れになったリポジトリライセンスは、リサイズ/拡張の前に置き換える必要があります。ワークステーションから rdc で行うか、マシン自身に更新させます
• ライセンスの署名は埋め込みの公開鍵に対して検証されます。署名検証は無効化できません

回復動作

自動回復は意図的に限定的です：

• missing：rdc は必要に応じてアカウントアクセスを認可し、リポジトリライセンスをバッチ更新し、一度再試行する場合があります
• expired：rdc はリポジトリライセンスをバッチ更新し、一度再試行する場合があります
• machine_mismatch：即時失敗し、現在のマシンコンテキストから再発行するよう指示します
• repository_mismatch：即時失敗し、リポジトリライセンスを明示的に更新するよう指示します
• sequence_regression：リポジトリライセンスの整合性/状態の問題として即時失敗します
• invalid_signature：リポジトリライセンスの整合性/状態の問題として即時失敗します
• identity_mismatch：即時失敗します。リポジトリのアイデンティティがインストール済みライセンスと一致しません
• cert_expired：成長操作（create、fork、resize）とバックアップ転送（push、pull）では即座に失敗します。repo upと自動起動は引き続き動作し、ソフトなライセンス有効期限モデルと同じ扱いになります。委任証明書を更新してください
• cert_invalid：即時失敗します。委任証明書が制約を満たしていません（マスターキー署名が不正、サブスクリプション/プランの不一致、サイズ上限、またはmaxTotalIssuancesを超えるシーケンス）。根本的な制限を修正した上で証明書を再発行してください

これらの即時失敗ケースは、アカウントバックアップされた更新または発行呼び出しを自動的に消費しません。

このリストを読むうえで、2点補足があります：

• missing は必ずしも問題ではありません。フォークしたばかりのデータストア内でリポジトリに初めて触れたときの正常な結果でもあり、まさにそれがそのフォークを計測対象にします。ライセンスが発行され、スロットが確保され、操作はそのまま続行します。identity_mismatch は意図的にその逆で、別のデータストアからコピーされてきたライセンスファイルは、黙って再発行されるのではなく即座に失敗します。
• このリストが説明しているのは、ワークステーションからの回復です。マシンが自分自身で更新する場合には別の結果があり、それらはコマンドの失敗として上がるのではなく rdc machine status <machine> --licenses で報告されます。スケジュールされたバックアップには、伝える相手がいないからです。

オンプレミス向け委任証明書

オンプレミスおよびエアギャップ環境のデプロイメントでは、アップストリームアカウントサーバーが 委任証明書 を発行し、オンプレミスインストールが独自のEd25519鍵でライセンスに署名することを認可します。この証明書はオンプレミスをプラン制限内に制約し、改ざん防止チェーンを作成します。

サブスクリプションオーナーへの重要事項：

• サブスクリプションごとに1つのアクティブな証明書。 各オンプレミスインストールは独自のローカル台帳に対して月ごと・マシンごとのクォータを適用するため、複数インストールでは実質的なクォータが重複してしまい調整が不可能になります。本番環境、ステージング、DRが必要な顧客はインストールごとに1つのサブスクリプションを購入する必要があります。
• ティアベースのデフォルト有効期間（15d / 60d / 90d / 120d）と上限（30d / 120d / 180d / 365d）については上記の制限テーブルを参照してください。
• カスタマーポータルからのセルフサービス。 組織のオーナーと管理者は /account/delegation-certs で委任証明書の作成、更新、失効ができます。このページはプランティアに関係なく全顧客に表示されます。制限のみが異なります。
• 自動更新 はオンプレミスがアップストリームの更新呼び出しに使用する delegation:renew スコープのAPIトークンを発行するワンクリックブートストラップでサポートされています。
• エアギャップ更新 は、オンプレミス管理者がダウンロードし、オフラインでアップストリームに転送し、アップストリームが処理して新しい証明書を発行する署名済み更新リクエストマニフェストでサポートされています。

運用セットアップについては オンプレミスインストール - エアギャップデプロイメントのライセンス を、暗号化設計については ライセンスチェーンと委任 を参照してください。

月次リポジトリライセンス発行数

このメトリクスは、現在のUTCカレンダー月における成功したアカウントバックアップされたリポジトリライセンス発行アクティビティをカウントします。

含まれるもの：

• リポジトリライセンスの初回発行
• 新しく署名されたライセンスを返す成功したリポジトリライセンス更新

含まれないもの：

• 変更されていないバッチエントリ
• 失敗した発行試行
• 発行前に拒否された未追跡リポジトリ

使用状況と最近のリポジトリライセンス発行履歴の顧客向けビューが必要な場合は、アカウントポータルを使用してください。マシン側の検査が必要な場合は、rdc subscription status -m と rdc subscription status -m を使用してください。