ドキュメント

• Ubuntu 22.04+ または Debian 12+、Mint 21+、Pop!_OS 22+。
• Fedora 42+、Rocky、AlmaLinux、RHEL、Oracle Linux、CentOS Stream 9–10。
• openSUSE Leap 16+ または Tumbleweed、Arch、Manjaro、EndeavourOS。

提供元が保守しているリリースを選んでください。OS 側の要件が高い場合はそちらが優先されます。 openSUSE Leap 16 では 40 GB を超えるディスク容量が必要です。

チェーンや同時処理する請求書が増えると、CPU や RAM を増やす必要があります。VPS を大きくしても RPC の割り当て上限はなくなりません。セットアップの流れには自動テストがありますが、すべてのディストリビューションで新規 VPS の全工程を検証済みではありません。

インストーラーを確認。コマンドに追加： --check を追加するとインストールせずに互換性を確認できます。オプションを見るには --help を使ってください。

鍵や設定を置き換えず、保存済みの進行状況から再開：

bash <(curl -fsSL https://releases.whollycrypto.com/setup_wholly.sh) --resume

追加のベースドメインでも同じサービス名を使えます。IPv6 レコードもすべてこの VPS に向ける必要があります。Cloudflare プロキシを有効にするのは、次の作業を済ませてからにしてください： ドメインの検証.

認識済みステーブルコインの新しい見積もりは切り上げます： 1.321 USDC → 1.33 USDC。許容差がゼロでも同じです。最小額は 0.01 トークンです。

既存の請求書、残高、一部入金後の残額は正確な値を維持します。その他のトークンやカスタムトークンは通常の精度を使います。

Basic Auth のログイン情報の保存先： /root/whollycrypto/config/setup-credentials.txt。コンソールのメールアドレスとパスワードとは別です。

新規プロジェクトが引き継ぐ設定： システムの既定通貨とタイムゾーン。ストアはプロジェクトの通貨を使います。既存アカウントのタイムゾーンは「設定 → アカウント」で個別に管理します。

whollycrypto welcome でコンソールの URL を確認できます。

1. 共有ノード、為替レート、ドメイン、インストール用クレジット、更新は次の画面で管理します： 運営者パネル.
2. 開く ウォレット → 受取用ウォレットを作成 で BTC、ETH、Ethereum 上の USDC/USDT を設定します。独立した 2 つの復元フレーズを両方バックアップしてください。この専用プロジェクトでは売上請求書を発行できません。既存の受取用ストアは維持されます。
3. クレジット通貨、手数料、管理者メールアドレスを指定して加盟店を追加します。招待と加盟店用 Basic Auth 情報は非公開で渡してください。パスワードは加盟店が設定します。運営者の Basic Auth 情報は絶対に共有しないでください。
4. 加盟店はあなたの決済画面でチャージできます。説明付きのクレジット調整を記録することもできます。プロジェクトやストアの作成にはクレジットが必要です。ユーザーとクレジット履歴の管理はこちら： 加盟店 → 管理.

運営者のセットアップでは、4 つ目のアドレスを指定します。例： operator.example.com。専用の Basic Auth ユーザー名とパスワードも必要です。ラベルを選び、DNS を VPS に向け、DNS を確認して HTTPS を有効にします。パネルはそのアドレスで直接開きます。加盟店、決済、API のアドレスは別々のままです。

新しい運営者用 Basic Auth でログインした後、管理者のメールアドレスとパスワードを入力します。加盟店の Basic Auth は変わりません。DNS や証明書でエラーが出ても設定を再開できます。7.0.0 から更新する運営者もこの手順を完了してください。既存の公開アドレスは引き続き使えます。

手数料が 3% の場合、100 EUR の請求書には加盟店クレジット 3 EUR がかかります。クレジットの通貨が異なる場合は、作成時の法定通貨レートを手数料とともに保存します。

運営者は通常の Wholly Crypto インストール手数料を別途支払います。顧客の資金をオンチェーンで分割することはありません。クレジット購入に再度手数料がかかることもありません。

チャージが加算されるのは、自動検証された決済が確定した場合だけです。決済画面を開いたり請求書を手動承認したりしても加算されません。取消時には台帳に記録されます。取り消したチャージの入金が復活した場合は運営者の確認が必要です。

ホスト先のクレジットが不足すると、IPN、Webhook、資金集約、新規プロジェクトやストアの作成が一時停止します。既存の顧客請求書と受け取りは続きます。インストール用クレジットの不足は、ホストする事業全体の自動処理を止める場合があります。加盟店を無効にするとログインと新規請求書も停止しますが、以前の決済は引き続き監視します。

これはアプリケーション単位の分離です。加盟店ごとに個別の VPS を用意するわけではありません。 加盟店同士で他の加盟店のプロジェクト、ウォレット、API 認証情報、取引所、クレジットにはアクセスできません。サーバー管理者は、ホストするホットウォレットの鍵にアクセスできます。利用開始前に加盟店へ伝えてください。信頼できるホスティング、独立したバックアップ、共有する処理に見合う容量を用意してください。

7.2.0 以降は、 ウォレット で受取残高、アドレス、バックアップを管理し、 資金の集約 で送金と自動ルールを扱います。トークン手数料用の ETH を残してください。 加盟店のチャージ で購入を追跡します。ヘッダーにあるクレジットは、インストール手数料の別途支払いに使います。 自分の事業 で自分のコンソールが新しいタブに開きます。

開く 財務 で獲得手数料、確認済みのインストール費用、推定利益、現在の加盟店クレジットを確認します。日付、加盟店、表示通貨で絞り込み、CSV に書き出せます。

レポートは初回決済時点で請求書をまとめ、最新の手数料取消を反映します。前払い残高は売上ではありません。自社事業の費用は分けて表示します。保留中の請求や不足するレートがある場合、該当する利益は表示できません。換算額には現在キャッシュされている法定通貨レートを使い、ガス代や運営費は含めません。

加盟店を追加 で招待を作成します。7.3.0 以降は、加盟店のクレジット通貨で無料の初期クレジットを指定でき、ゼロでも構いません。運営者の残高が補充されるわけではありません。 招待をメールで送信 は初期状態で選択されています。

まず SMTP プロバイダーを次の画面で設定してください： 設定 → 招待メール 。TLS または STARTTLS を使ってください。接続テストではメールを送りません。メールをオフにしてリンクを非公開で渡すこともできます。メール送信が失敗してもアカウントとクレジットは残ります。加盟店を再作成しないでください。

新しいリンクやパスワードの再設定が必要な場合はこちら： 加盟店 → 管理 → ユーザーアカウント。SMTP で受理されても受信トレイへの配信は保証されません。加盟店の Basic Auth 情報は別途渡し、運営者の認証情報は絶対に共有しないでください。

招待は 48 時間、再設定リンクは 1 時間有効で、それぞれ 1 回だけ使えます。同じ画面でリンクの置き換えや無効化ができます。再設定すると既存のセッションはログアウトしますが、2FA は有効のままです。加盟店の Basic Auth も引き続き必要です。

パスワードを指定して直接アカウントを作成するか、招待を送ります。ユーザー、プロジェクト、ストア、手数料、ローカルの前払いクレジットを管理し、レポートの取得や署名付きライフサイクルイベントの購読ができます。初回ログイン時の資産保管への同意、2FA、テナント分離は維持されます。

すべての書き込みに、保存した冪等性キーが必要です。クレジットの付与はローカルアカウントの調整で、インストール用クレジットのチャージではありません。ウォレットの秘密情報、送金、サーバー設定はこの API の対象外です。

使用 api.your-domain.com/v1/operator。運営者キーはバックエンドに保管し、ブラウザーに置いたりホストする加盟店に渡したりしないでください。

設定 → アドレス帳：チェーンとアドレスを保存します。ネイティブコインと一致する CoinGecko トークンが自動表示されます。管理者が管理する読み取り専用機能で、決済で受け付ける資産は変わりません。

トークン残高の読み取りは 22 チェーンに対応しています。非公開の残高や Bitcoin/CashTokens/Kaspa の補完情報には、別のアクセス手段やインデクサーが必要です。取得に失敗した場合はゼロではなくエラーを表示します。

請求書の残高を別のウォレットにまとめる方法： 手動送金または自動集約。トークンの送金にも、手数料用のチェーンのネイティブコインが必要です。

価格を取得できません はレートについての表示で、残高の問題ではありません。

1. ストア → 決済方法 → EVM または Solana → カスタムトークン.
2. コントラクトまたは mint、名前、ティッカーを入力します。固定 USD 価格か DEX による自動価格を選びます。

ネットワークと小数桁数を確認します。プロジェクト全体の価格を変更しても既存の見積もりは変わりません。カタログに一致するだけでは決済で有効になりません。

自動価格設定

DEX Screener では、コントラクトが完全一致するプール、$10,000 の流動性、1 時間以内の取引が必要です。レートは毎分更新します。取得失敗または 5 分経過したレートでは、新しい見積もりを作成できません。

DEX の価格は操作される可能性があります。これらの確認は監査ではありません。信頼できる標準 ERC-20 または従来の SPL トークンを使ってください。Token-2022 や拡張機能は非対応です。適切なプールがなければ固定価格を使ってください。

スキャナーがオフライン？ 検出待ちの間も、請求書は設定済みの決済方法を維持します。「チェーン接続」で対応 API を確認してください。正常な接続でもスキャナーに対応しているとは限りません。標準では独立した 2 社を使います。

ウォレットとレートは引き続き必要です。Monero/Lightning のサービスが支払いリクエストを発行する必要があります。

API/MCP エラーに含まれる情報： error.details.payment_methods。SDK 2.4.0 では安全な説明が追加されました：PHP getPaymentMethodIssues()、Python payment_method_issues、Node paymentMethodIssues. エラーリファレンス →

暗号資産の見積もりは切り上げ、ストアのスプレッドを含めます。法定通貨建ての請求書でも、受け取った暗号資産が銀行残高に換金されるわけではありません。

承認数ゼロでは検出時に決済が確定し、ネットワーク承認による保護はありません。EVM ネイティブ通貨の支払いは直接送金として検出します。通常と異なる、または不確かな支払いは次の画面で確認してください： 要確認.

初期設定では無効です。有効にする設定： ストア → 請求書 → 金額ゼロの請求書を許可 で手動または API による合計ゼロの請求書を許可します。支払い、受取アドレス、取引、処理手数料なしで即座に完了します。

status はイベント作成時点の請求書の状態です。 event_type は何が起きたかを示します。

• Ethereum の例： payment.received + processing、続いて invoice.settled + settled.
• Solana の例： 検出時点ですでに確定しているため、 payment.received と invoice.settled どちらも次の値を持ちます： settled.

他のチェーンでもどちらの流れも起こります。別々のイベントですが、必ずしも 2 回の支払いではありません。同じ値を共有する項目： sequence 一方、異なる値を持つ項目： event_id 。配信順序は保証されません。 processing が先に起きることを必須条件にしないでください。

イベント： invoice.created, payment.received, invoice.processing, invoice.settled, invoice.expired, invoice.invalid, invoice.cancelled. イベントの全一覧と例外ルール →

amount_status: none, partial, paid, overpaid. paid には許容差を含みますが、最終確定は含みません。 timing_status: on_time または late. resolution: automatic, manually_settled または manually_invalidated。次の場合は例外処理の方針を適用してください： requires_review が true のとき。

invoice_id は API 応答と一致します。 amount, currency と order_id は元の注文を表します。 payment_info には送金、正確な暗号資産額、固定された見積もり・スプレッド・許容差、参考レートが加わります。顧客データとメタデータは非公開情報です。

paid_chain, paid_asset, paid_payment_method_id, paid_asset_amount, paid_asset_amount_received と settlement_exchange_rate は決済を要約します。これらは固定され、不足する証拠や履歴は null のままです。後の入金には次を使ってください： payment_info または 支払い API.

十進数の文字列を使ってください。異なる資産を合算したり、未承認の資金を未入金扱いにしたりしないでください。例外は明示的に処理してください。警告だけでは注文処理や返金は認められません。検証済みの内部ガス補充は顧客の支払いではなく、次のイベントを発生させません： payment.received.

個別の署名用シークレット： ストア → IPN で IPN の配信に署名します。請求書で個別に指定した以下も対象です： ipn_url。次の画面にある各エンドポイント： ストア → Webhook にはそれぞれ専用のシークレットがあり、作成時や更新時に表示されます。

どちらも Wholly-Signature と同じ SDK 検証器を使いますが、API キーではなく対応するシークレットが必要です。IPN シークレットを更新しても Webhook シークレットは変わりません。

生の本文、タイムスタンプ、プロジェクトとストアの範囲を検証します。永続保存してから HTTP 2xx を返してください。ワーカーは設定済み API ホストで現在の請求書を確認し、データベーストランザクション内で注文を 1 回だけ処理します。ヘッダーは署名されません。バージョン 2 の署名済み本文の識別情報を使ってください。

イベント方式： 署名済みの次の項目で重複排除： event_id、続いて絞り込み： invoice.settled. SDK の状態方式： プロジェクト + 次の項目でまとめる： invoice_id + sequence。その後、イベント種別に関係なく状態を確認します。まとめた後にイベントで絞り込まないでください。どちらの方式にも、注文単位の独立した重複防止が必要です。

再試行では元の本文とイベント ID を維持します。古いリビジョンで新しいものを上書きしないでください。IPN は最大 8 回試行し、Webhook の再試行は任意です。クレジット不足で止まるのは配信で、支払いは止まりません。

ストア → IPN / Webhook → 履歴 → 詳細 で保存した本文と結果を確認できます。ペイロードは 90 日で期限切れになります。再送信は決済確定の証明ではありません。

1. 設定 → 取引所： 専用キーを接続し、残高を確認してプロジェクトに許可します。出金権限は付けず、キーの使用元を VPS の IP に制限してください。
2. プロジェクト → 資金集約： 資産、ネットワーク、アドレス、トークンコントラクトを確認します。チェーンとトークンごとに、別のウォレットか 1 つの取引所を選びます。

市場情報は 2 分ごとに更新します。一致を確認できて入金反映済みのものだけ換金でき、古い市場情報では新規注文を止めます。手数料と丸め用に元の資産の 1% を取引所に残します。処理クレジットとは別です。

最低保持額 は自動集約後にプロジェクト全体でコインやトークンを残します。起動条件とは別で、ゼロなら残しません。手数料には超過分を使います。手動送金は変わりません。

結果が不確かな送金は再開し、絶対に別の送金で置き換えないでください。ウォレットは承認または未使用の見積もりの期限切れまで予約されます。大量の集約は分割して行う必要があります。

取引所による保管、KYC、地域制限、手数料が適用されます。銀行への出金やレバレッジはありません。クレジットが不足すると新しい換金を止めますが、送信済みの注文の照合は続きます。

開く 自動チャージ は「リクエスト」の後にあります。バックアップ済みの受取ウォレット、しきい値、購入額、1 日の上限、ネットワーク手数料の上限を選び、許可して保存します。初期状態ではオフです。

利用可能な場合は BTC、ETH、Ethereum 上の USDC/USDT を使います。トークン送金元には ETH が必要です。このルールでは不足するガスを補充しません。運営者は専用の受取ウォレットを使い、ホストされる加盟店は運営者へ支払います。

クレジット不足で集約が止まっていても、承認済みのチャージは実行できます。クレジットを確定できるのは受取側サービスだけです。自動購入は一度に 1 件だけ実行します。無効化で止まるのは未送信の処理で、送信済み取引は取り消されません。

「自動チャージ」で使う操作： 支払いを確認。同じ有効な支払いを再開するか、失敗が検証できた Ethereum 送金を終了してルールを一時停止します。保留中または不確かな支払いは、重複送金を防ぐため保留のままにします。見積もりの期限切れは失敗の証明にはなりません。

標準の 1% は、決済済み請求書の元の法定通貨額を基準にします。顧客の暗号資産支払いを分割することはありません。

手数料は残高がマイナスになっても加算されます。マイナス分を清算し、アカウントの猶予しきい値を超える利用可能クレジットを確保してください。接続が正常なら残高の変化は通常 10〜15 秒で表示されます。

自動処理に猶予があっても、更新のインストールには確認済みクレジットがゼロより多い必要があります。チャージで更新が自動インストールされることはありません。

停止中の通知は試行回数を消費しません。保持されている配信は再開しますが、通常の有効期限は適用されます。取りこぼしたイベントは請求書 API で照合してください。

運営者が処理手数料を無効にすると、新しい処理手数料やクレジット制限は適用されません。以前の費用は履歴に残ります。未接続のインストールでもプロジェクトとストアは設定できますが、請求書の発行には検証済みの請求接続が必要です。発行済みの請求書は引き続き監視します。

• 売上は決済日を基準に、手数料と返金を差し引く前の決済済み請求書額を表示します。ウォレット残高や利益ではありません。
• 換算には過去の会計レートではなく、現在のキャッシュ済みレートを使います。レートがなくても元の通貨の合計は確認できます。
• 請求書の状態グラフは作成日を基準にします。「要確認」の数値は、現在未解決の問題を示します。

BTC、EVM、SOL、TRX に加え、18 のネイティブアダプターに対応します。取引の送信に対応したプロバイダーを使ってください。ZEC は透明アドレスのみ、ADA はトークン出力を保持、DOT は Asset Hub を利用し、HBAR にはリレーが必要です。memo/tag/comment が必要な送金先には外部ウォレットを使ってください。

1. 開く プロジェクト → ウォレット → 資産 → 送金。アドレス帳の項目を選ぶか宛先を入力します。アドレス全体とネットワークを確認してください。
2. 正確な金額または利用可能分の全額集約を選び、手数料レベルを指定します。対応トークンでは、 プロジェクトの ETH をガスに使用 （またはそのチェーンのネイティブコイン）で、同じプロジェクトとチェーンから不足する手数料を補充できます。
3. クリック 送金を準備。送金元、宛先、金額、最大手数料、ガスの割り当てを確認します。 承認して送金 でこの計画を許可します。準備だけでは何も送金しません。

承認後、ガスの補充、承認確認、トークン送金はバックグラウンドで続きます。確認先： 送金状況。ウィンドウを閉じた後も確認できます。ブロードキャストは承認ではありません。

プロジェクトのウォレットに残す ETH： 0 は追加の取り置きをしない設定で、ETH をすべて使う意味ではありません。0.005 は後のために少なくとも 0.005 ETH を残すので、今回の処理には別の資金が必要です。保存済みの自動ルールは変わりません。

1. 開く 自動集約の設定 → 資産 → 設定。ウォレットアドレスか、対応する次の宛先を選びます： 取引所の送金先。両方は選べません。
2. 集約の最低額と次の項目を設定します： 最低保持額。例：100 USDC で起動し、20 USDC を残して最大 80 USDC を送ります。取り置き額はアドレスごとではなく、プロジェクト全体に適用されます。
3. トークンの場合は次を確認します： プロジェクトの ETH をガスに使用 続いて入力： 1 日の補充上限。自動集約をオンにし、続いて ルールを保存 して確認します。設定を開くだけでは何も有効になりません。

1 日の上限は、トークンルールごとに直近 24 時間で割り当てるネイティブ通貨のガス額を制限します。€1 は軽い利用の初期上限の目安で、費用の保証や日額料金ではありません。ガス補充の取引自体にも手数料がかかります。 ネットワーク手数料の上限 % で補充と送金の合計手数料を制限できます。

確認は自動で行います。条件を満たすトークン保有アドレスだけにガスを補充し、空のアドレスには送りません。資金不足で集約の最低額に届かないアドレスは待機します。 ガス上限の説明 →

• ウォレットをバックアップし、少額送金を試してください。ネイティブコインを空にする前にトークンを送ります。プロジェクト内の別の場所にある ETH は、先に各トークンアドレスへ届く必要があります。未使用のガスは自分のウォレットに残ります。
• 最新の残高、正常なプロバイダー、十分なネイティブ資金を用意してください。自動ルールには有効でバックアップ済みのウォレットと、有効なストアで有効化した資産が必要です。次が不足すると： 処理クレジット 送金が一時停止することがあります。
• 確認先： 送金状況で進捗、ガス補充、エクスプローラーのリンクを確認します。結果が不確かな場合は同じ送金を再確認し、代わりの送金を作らないでください。理由と上限を確認してから再開してください。

送金が無効？確認する項目： whollycrypto transfers status。次の操作の前に、有効なルールをすべて確認してください： whollycrypto transfers enable：サーバー全体に適用され、保存済みルールがすぐに動く場合があります。以後の手順を止めても、送信済みの取引は取り消せません。

ストア → 基本： 有効な加盟店・決済・API ホストを選びます。リンクはストア → 既定ストア → システムの順で優先し、廃止した名前は代替先に切り替えます。SDK のホストは別途設定してください。署名付きの再試行は元のリンクを維持します。

• 使用 Full (strict)を使い、Flexible は使わないでください。API キーは不要です。
• コンソール、決済画面、API ではキャッシュとブラウザー・ボットのチャレンジを無効にしてください。
• 許可 /.well-known/acme-challenge/ はポート 80 でリダイレクトやチャレンジなしでアクセスできるようにして、更新に対応してください。

権威 DNS に問い合わせ、オリジンが直接接続か Cloudflare かを確認します。訪問者側に古い DNS がキャッシュされている場合があります。

5.6.2 以降、コンソールの保存と削除は POST を使うため、「Not GET or POST」の例外は不要です。ログインと CSRF 保護は有効なままです。次のホストでは： api.*公開 API の文書に記載されたメソッドを許可してください。

コードの更新や 2FA の無効化には、パスワードと認証アプリまたは未使用の復旧コードが必要です。他のセッションはログアウトします。スマートフォンとサーバーの時刻を同期してください。2FA は侵害されたサーバーを守るものではありません。

テーマアイコンは次の順に切り替わります： ライト → 薄暗い → ダーク 。このブラウザーでの選択を記憶します。ストアの決済画面のテーマは別です。

必要に応じて Cloudflare のアクセスルールを追加できます。HTTPS 更新用チャレンジは除外し、API と決済画面で対話式ログインチャレンジは使わないでください。プロキシモードだけでは IP 制限になりません。

締め出された場合のコマンド： whollycrypto access-reset --domain merchant.example.com を SSH で実行します。そのホスト名だけが 5 秒以内に再開放され、アカウント認証は有効なままです。

実行 whollycrypto ssl --domain merchant.example.com --reissue で強制的に置き換えます。発行制限が適用されます。Cloudflare が HTTP チャレンジを阻む場合は、一時的に DNS のみへ切り替えてください。ウォレット、認証、ドメインは変わりません。

古いアップデーターが進まない場合は、これを一度実行してください。インストール済みの鍵で補助ツールを検証します。

bash <(curl -fsSL https://releases.whollycrypto.com/update_wholly.sh)

セットアップと更新は自動的に次を試します： 公式 GitHub ミラー。署名、チェックサム、クレジットの確認は引き続き必要です。

確認は読み取り専用で、対応が必要な場合はゼロ以外の終了コードを返します。 --fix は管理対象の権限と欠けた CLI リンクだけを修復します。請求の変更、データの削除、サービスの再起動は行いません。

whollycrypto reset
# Preview without changing anything:
whollycrypto reset --scope business --check
whollycrypto reset --scope project --project YOUR_PROJECT_IDENTIFIER --check

1 つのプロジェクト、全事業プロジェクト、修復のみから選びます。プロジェクトのリセットは、選択したプロジェクト、ストア、ウォレット記録、支払い履歴を完全に削除します。修復のみの場合は管理対象の権限と CLI リンクだけを確認・修復します。

先に対象プロジェクトを無効化し、未完了の支払い・送金を解決して、把握しているウォレット残高を移してください。アカウント、ドメイン、ノード、クレジット、請求情報、インストールモードは残ります。運営者の受取ウォレットとホスト先のクレジット記録は保護されます。セットアップウィザードは再開しません。

削除を伴うリセットでは確認文の入力が必要で、消去前に検証済みの復旧バックアップを作成します。サーバー外にもウォレットのバックアップを保管してください。古いアドレスは引き続き入金を受けられますが、削除したプロジェクトでは追跡しません。キャッシュ残高はウォレットが空である証明になりません。

whollycrypto uninstall --check
whollycrypto uninstall

バックアップと確認文の入力後、決済画面、API、ワーカーを停止し、実行ファイルと管理対象のサーバー連携を削除します。保留中の支払い・送金があると削除できません。ファイルは消去せず、復旧バックアップへ移動します。

データベース、設定、鍵、バックアップは残ります。共有の Nginx/PostgreSQL パッケージと TLS 証明書には触れません。オフライン復旧コマンドが表示されます。残したデータの上に新規セットアップを実行しないでください。

リセットと削除のコマンドはネイティブ VPS インストール用で、Docker や Umbrel 用ではありません。コンテナーでは連携環境のバックアップ・停止コマンドを使い、ボリュームを残してください。どちらの削除コマンドも次のオプションは受け付けません： --yes.

whollycrypto htaccess

ユーザーを選び、名前とパスワードを指定して確認します。ブラウザーの最初のログイン画面を再設定する操作で、コンソールアカウントではありません。他のユーザーや API 認証情報は変わりません。

whollycrypto admin-reset

メールアドレスで管理者を選び、新しいパスワードを確認します。セッションとアカウントのログインロックは解除され、IP 制限は残ります。

通常の再設定では 2FA を維持します。認証アプリも復旧コードも失った場合は、明示的に次を実行してください： whollycrypto admin-reset --email admin@example.com --reset-2fa。ログイン後に 2FA を設定し直してください。

データベースが必要ですが、アプリや古いパスワードは不要です。他のアカウント、ウォレット、権限は変わらず、無効なアカウントは無効のままです。

認証アプリも復旧コードも失った場合は、root でアカウントを選んでください。

whollycrypto 2fa-reset
# Or select the account directly:
whollycrypto 2fa-reset --email user@example.com

セッション、認証アプリ、復旧コードを削除します。現在のパスワードでログインし、2FA を設定し直してください。権限、ウォレット、Basic Auth は変わらず、無効なアカウントは無効のままです。

データベースが必要ですが、アプリやクレジットは不要です。非対話モード： --email と --yes.

Enter でパスワードを生成する保存先： /root/whollycrypto/config/credential-resets/：非公開で暗号化されておらず、成功後に使えます。手入力したパスワードは保存しません。

whollycrypto htaccess --user admin --new-user operator
whollycrypto admin-reset --email admin@example.com

端末がない場合は、既存のアカウントに加えて次を指定します： --generate または --password-file /root/private-password.txt、および --yes。パスワードファイルの所有者は root とし、権限モードは次にしてください： 600。パスワードをコマンドや環境変数に入れないでください。

--yes は確認だけを省略します。先に中断した更新の復旧を完了してください。並行してアカウントが変更されると再設定を停止します。